「リーダブルコード」を読んだ個人的感想

はじめに

エンジニアとしての基礎力を高めるために、先輩がおすすめしていた本になります。
ここでしっかりと身に付けて、日々の業務で生かせるようにします。

重要なところをピックアップして、個人的な感想ですが、記載していこうと思います。

引用文献

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

各章の解説

1章 理解しやすいコード

ここでは、コードを書く上でいちばん大切な原則がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

読みやすさの基本定理

本書では、以下のように記載があります。

コードは他の人が最短時間で理解できるように書かなければならない

自分の考えだけではなく、相手に理解してもらえるコードを書くよう心がけます。

2章 名前に情報を埋め込む

ここでは、名前に情報を詰め込む考えがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

明確な単語を選ぶ

「get」はあまり明確な単語ではなく、取得する意味であれば、fetchやdownloadの方が明確になります。
汎用的な単語も避けるべきなので、処理に沿った明確な単語を選択できるようにします。

3章 誤解されない名前

ここでは、誤解される名前に気をつける考えがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

ブール値の名前

trueとfalseの意味を明確にしなければなく、is・has・can・shouldなどをつけてわかりやすくすることが多いです。
ここは気をつけようと思います...。

4章 美しさ

ここでは、コードを読みやすくするための余白・配置・順序がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

一貫性と意味のある並び

見た目に関しては、rubocopやprettierで整えてくれると思います。
ただ並び順は、自分で意味のある並びにしないといけません。

本書では、以下の記載があります。

・対応するHTMLフォームのフィールドと同じ並び順にする。
・「最重要」なものから重要度順に並べる
・アルファベット順に並べる

この辺りは意識して書こうと思います。

5章 コメントすべきことを知る

ここでは、コメントの目的がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

自分の考えを記録する

コードの欠陥には必ずコメントをつけ、そのフォーマットが本書には記載があります。
TODO: やFIXME: などです。

コメントを残しすぎてもいけないと思うので、チームで方針を決めて、改善に向かうようなコメントを残していきたいです。

6章 コメントは正確で簡潔に

ここでは、どうすればコメントを正確で簡潔に書けるかがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

歯切れの悪い文章を磨く

本書では以下の記載があります。

コメントを正確にすることと簡潔にすることは両立することが多い

そのコメントで言及するまでの情報を残すようにしたいです。

7章 制御フローを読みやすくする

ここでは、上記の考えがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

三項演算子

条件 ? a : bという条件式で記載ができるので、if / elseより簡潔にかけます。
だからと言って、全て三項演算子にするべきではありません。

三項演算子にすることによって、コードが複雑になり、読みにくくなっては本末転倒です。その場合は、if / elseを使用するべきです。

行数を短くするよりも、他の人が理解するのにかかる時間を短くできるように、心がけます。

8章 巨大な式を分割する

ここでは、コードを飲み込みやすくするための処理や分割の方法がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

要約変数

以下に、本書で記載があったコードを紹介します。

if (request.user.id == document.owner_id) {
}

それほど大きな式ではないですが、以下の方が、もっと明確に概念を伝えることができます。

final boolean user_owns_document = (request.user.id == document.owner_id);

if (user_owns_document) {
}

「この関数で参照する概念」を伝えられるようにしていきます。

9章 変数と読みやすさ

ここでは、変数を使う場合の対処がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

変数は一度だけ書き込む

できる限り変数を操作する場所が減らして、現在地の判断がしやすくなるコードを心がけようと思います。

10章 無関係の下位問題を抽出する

ここでは、大きな問題を小さな問題に分割する考えがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

汎用コードをたくさん作る

例えば時間を取得してフォーマットするコードがあります。それらみたいに、どこでも汎用できるコードに関しては、プロジェクトから完全に切り離すべきだと、本書では記載があります。

そうすると、開発もテストも楽になるため、見つけ次第、積極的に実装しようと思います。

11章 一度に1つのことを

ここでは、コードの「デフラグ」についてがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

タスクは小さくできる

１つのコードに複数のタスクを書くのではなく、別々の記載をすることで、楽に理解できると本書には記載があります。
やはり極力細かくするべきで、ただそれで読みにくくなるコードにならないように気をつけます。

12章 コードに思いを込める

ここでは、コードをより明確にする簡単な手順がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

ロジックを明確に説明する

自分が実装したコードのロジックは、明確に説明しないといけないです。
そうすることで、説明する際に新たな解決策も生み出すことがあるそうなので、メンバーに雑談も交えて説明するのは結構アリだなと思いました。

13章 短いコードを書く

ここでは、コードを書かない時を知ることの大切さがまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

コードを小さく保つ

どれだけプロジェクトが大きくなろうと、コードは小さく保つべきだと本書では記載があります。
そこで以前でも説明した汎用的なコードを実装して、重複コードを削除することが必要になってきます。

どうしてもプロジェクトが大きくなると、重複コードや不要なコードがあるので、しっかり振り返る時間も設けたいなと思いました。

14章 テストと読みやすさ

ここでは、効果的なテストを書くための簡単な技法がまとまっています。
その中で、自分が大切だと思った考え方は、以下になります。

テストを読みやすくて保守しやすいものにする

テストコードが分かりづらいと、本物のコードを修正したり、追加実装した際にテストを追加するのが怖くなります。
そうならないためにも、分かりやすいテストコードを書くように意識しようと思います。

15章 「分 / 時間カウンタ」を設計・実装する

ここでは、問題を解決して、パフォーマンスを改善して、機能を追加するが、コードを読みやすくすることを忘れないように気をつけるべきと本書では記載がありました。

どれだけパフォーマンスが良くなっても、それでコードが読みにくくなればいけないので、その両立をすることが大切になってきます。
ただなかなか難しいと思うので、まずはどちらかを達成できるよう、実装を進めてみようと思います。
（※ このことが頭にあるないとでは、かなり違うかなと思っています。）

最後に

本書を読んで、エンジニアのほとんどがおすすめする理由が分かりました。
コードを相手に伝わるよう、分かりやすく書くのにどうすれば良いかが、全てまとまっている本だと思います。

定期的に読み返して、忘れないように、業務に取り込んでいきます。

最後までご覧いただき、ありがとうございました。