コードに対する基本的な考え方

セイロップの大山です。

この記事は、「リーダブルコード」を読んだ上でのコードについて考え方を改めて再整理したものになります。

これを読むことにあたって、「リーダブルコード」が読まれていることが望ましいですが、読まなくても理解できるように記載します。

まず前提の私がこの本から読み取ったことは、「如何に他者に対して理解しやすいコードを書くか」という事で、その実践的な技法が詰め込まれています。

この記事をリーダブルコードの中身を要約するだけでは少々面白みに欠けるので、何故「他者に対して理解しやすいコードを書くか」という点と重要な技法を一部掻い摘んでピックアップしようと思います。

保守性については、直接的な金銭の影響があり見積もりの手法にもよってきますが、追加開発の場合などで余計なコストを支払うことなく利益に繋げる事ができるかと思います。

引き継ぎのしやすさについては、自分がプロジェクトを抜ける際や後任を育てる時などのコスト低下に一役買ってくれるでしょう。

デバッグのしやすさについては保守性に似ていますが、こちらはバグが瑕疵対応だった場合、基本的に労働力の赤字になるかと思います。

これを如何に少なくするかの戦いであるため、別の項目として扱いました。

チーム開発の効率化ですが、明確な役割を関数名から読み取ることができれば、チーム内での気付きに一役買ってくれます。

他にも色々ありますが、私が特に重要視すべきという点をピックアップしました。

特にエンジニアはじめの頃だと、適切なワードが思い浮かばずに変数名や関数名が適当になってしまったり、一つの決定に何十分も要したりなどの失敗も起こりえます。

しかし、この失敗を乗り越えずに進んだ場合、可読性の悪い不明瞭なコードが生まれることなるため、ここは必ずマスターしてほしいと個人的に思います。

変数や関数の役割に対して、命名から読み取れるようになっていることが良いです。

コメントについても「getUser」に対して、「ユーザーを取得する」というコメントはナンセンスです。

コメントというのは、「なぜそうするのか」を書くべきでしょう。

ネストは、深かったら深いだけ読みにくいので必要に応じて、ifや関数への切り出しなどで対処するのが良いと思います。

変数のスコープを縮めるのは、スコープが小さければ役割を限定することができますし、またコードの影響範囲も小さくなる事が見込めます。

短いコードにするのは、短い分だけ読み直しも早く、意図も読み取りやすくなります。

これを実践するには、口頭でコードの解説を行うというテクニックがリーダブルコードでは解説されています。

リーダブルコードを読んで、知識や技術として可読性の高いコードを書けるテクニックを身につけることを個人的に推奨します。

ただ、今まで触れていませんでしたが100%美しいコードを書くというのは基本的に不可能かと思います。

何故ならエンジニアでご飯を食べていく以上、締切は何処にでも存在します。

限られた期限の中で素早く適切にコードを洗練させていく必要があるため、リーダブルコードという一つの武器を持って、期限の中でより効率的なコードを書いていくのが、業務になると思います。

ここまで読んでいただき、ありがとうございました。良いエンジニアライフを！