読みやすいコードのガイドライン 持続可能なソフトウェア開発のために

石川宗寿(著者)

• 販売会社／発売会社: 技術評論社
• 発売年月日: 2022/10/22
• JAN: 9784297130367

商品レビュー

2025/06/15

読みやすいコードを書けるようになりたいと思い、読んでみた。
最近、クリーンアーキテクチャだとかドメイン駆動設計だとかのコード設計についての本もいくつか読んでたけど、意識しすぎると逆に読みづらいコードを書いてしまいかねないのだろうなと思った。
イミュータブルなのがいいとか、抽象化するのがいいと聞くけど、やりすぎ厳禁なのだろうなと。

チームで可読性の高いコードを書くのが難しいという話について、囚人のジレンマでたとえているのは面白かった。全体では可読性高く書くようにしたほうがいいけど、個々にとってはその場しのぎで書いたほうがいいという考えもあるとのこと。確かに、そういわれてみると分かる気がする。気を付けたい。

変数名や関数名などの名前についての話は、今なら生成AIに聞くというのでいいような気はした。
本書が発売されたのが、ChatGPTが登場する前の2022年10月なので、今なら生成AIについても書いているのだろうなと思う。

ドキュメントコメントのアンチパターンのうち、宣言と同等の情報しか持たないというのは分かるけど、結果的にそうなってしまうなと思うことはある。そのまま書くなら不要とも書いてあるけど、書かないのもそれはそれでなと思ったりする。

ビックリしたのが、戻り値のドキュメントコメントについて、「@return」といったタグを使うのは、Kotlinでは使わないで文で説明するのを推奨しているらしい。この理由がよく分からなかったのだけど、なんでだろう？　@returnに書いたほうがいいと思うのだけど…。

直和型ってなんだろうと思ったけど、TypeScriptでいうUnion型みたいなものなのかな。TypeScript独特の概念かと思ってたけど、最近のJavaでもそういうのあるのか。

ハッピーパスというアンハッピーパスという概念は初めて知った。それぞれ、関数の目的が達成できるケースと、達成できないケースをいうらしい。例えば、早期リターンするケースはアンハッピーパスなのだとか。そして、場合によってはアンハッピーパスを特殊なハッピーパスとみせせないか考えることも重要なのだとか。なるほど。

2025/02/13

ちょうどチームで悩んでいたことに対するアンサーがたくさんあり、今後の改善につながります。

割とぶつかる問題が多くあり、エンジニアなら書かれている内容を理解し、自らのコードの書き方を振り返るいい機会になると思います。

今後、エンジニアに読んで欲しい本にも入って欲しい内容です！

2024/09/22

中級レベル向けの一冊であると感じた
原則や概念の名前について説明はあるものの、初学者には理解に一苦労するかなと思う

ただ、非常に実践的な内容であることは間違いなく、コードの例もわかりやすい

自分にとっては命名やレビューで身に覚えのあるアンチパターンがあったので、繰り返し本書を振り返りながら改善していきたいと感じた