こんにちは、虎の穴ラボのH.Kです。
本記事は虎の穴ラボアドベントカレンダー16日目の記事になります。
次はNSSさんの「Next.js + AWS Amplifyでユーザー認証画面を実装する」になります。ご期待ください！
このたび、社内の技術書購入を支援する制度*1を利用して購入した『読みやすいコードのガイドライン―持続可能なソフトウェア開発のために』を読みました。
読んだきっかけ
この一年くらいOOPや設計の進め方についていろいろ勉強していました。2022年5月に『良いコードで学ぶ設計入門』を読み、ブログで公開していたのもその一環です。
『リーダブルコード*2』のような、どの言語でも通用する普遍的な設計思想を得られそうな本を探しており、見つけたのがこの本です。今まで読んだ本との対比も含めておすすめできるところ等をご紹介いたします。
基本情報
| タイトル | 読みやすいコードのガイドライン |
|---|---|
| サブタイトル | 持続可能なソフトウェア開発のために |
| 著者 | 石川宗寿 |
| 発行日 | 2022/10/22（紙版） |
| 発行 | 技術評論社 |
| ISBN | 978-4-297-13036-7 |
| 紹介ページ | 読みやすいコードのガイドライン（技術評論社） |
本書の記載内容
全7章からなっています。
- 第1章：可読性の高いコードを書くために
- 第2章：命名
- 第3章：コメント
- 第4章：状態
- 第5章：関数
- 第6章：依存関係
- 第7章：コードレビュー
詳細は技術評論社の以下のページからご確認ください。
おすすめする人
技術評論社のページには以下のような読者を想定していると記載されています。
- プログラミングの基本を学び終え、さらにステップアップしたい方
- 1ヶ月以上かかる長期の開発に携わる方
- コーディングのルールをどう運用するか知りたい方
この本を読んだ私が想定する読んでほしい読者は上記に加えて以下のような人たちです。
- レビューを行うエンジニア
- 自分のリファクタリングに根拠を持ちたい方
おすすめする背景
ここからはなぜ、レビューを行うエンジニアやリファクタリングに根拠を持ちたい方におすすめできるかを紹介していきます。
修正する根拠が一般論としてまとまっている
本書は作者の経験を根拠にした書き方をできる限り廃しており、一般論として根拠を示しながら記載していると感じました。
変数名の付け方など同じトピックについて書かれていても実際にコードを書くエンジニアの場合、具体的な経験、あるあるネタとして書かれている『良いコード/悪いコードで学ぶ設計入門*3』のほうが飲み込みやすく感じるかもしれません。
しかし他のエンジニアのレビューをしていると、もっと深く「なぜ良くないのか」を考える機会があるはずです。
著者の考える理想的なコードとそうではないコードを対比させるところは共通していますが、もう一歩深いところにある、「なぜ良くないのか」が非常に論理的に書かれ、さらに「どうすれば良くなるのか」のサンプルも豊富です。
私もレビュー時のプルリクエストへの指摘では、「なぜ良くないのか」を明確にし、指摘できるようになりました。
翻訳本ではなく、日本語としての違和感がない
私がレビューを始めたときの一つの指針として『リーダブルコード』を使っていました。
他にも『ソフトウェア作法*4』等も読みましたが、内容が古くなっていることは否めず、また翻訳本ならではの文章が付き物でした。
その点、本書や前述の『良いコード/悪いコードで学ぶ設計入門』は日本語話者が日本人向けに書かれた本なので非常に読みやすいです。
その中で、この『読みやすいコードのガイドライン』は英語に対する解説が非常に丁寧だと感じました。
「状態を確認する関数」にcheckHogeなどと命名しがちですが、「check」を使う問題点と英語の意味的な解説があり、isHogeや、検査して問題ないものだけ返すのであればfilter, takeを使うと良いなど、どうすれば良いかも明確に書かれています。
これは日本語話者ならではの気配りであると感じます。
その他のおすすめポイント
- Gitの運用フローまでカバーしている
- コメントへの考え方が示されている
- 状態、依存関係等の設計に関する解説がある
Gitの運用フローまでカバーしている
どのようにチェックしていくかはもちろんのこと、追加作業発生時のブランチ戦略の解説があるのは新しいし、嬉しいなと感じました。
コードを修正していくとよく発生する問題ではあったのですが、正解がわからずにいた箇所でした。
コメントへの考え方が示されている
ソース上のコメントをどう行うかが『リーダブルコード』以上に詳細に記載されているように感じました。
Javaで言うJavadocにあたる、「ドキュメンテーション」と// hogeで記載される「非形式的なコメント」に分けて、それぞれの役割を明確にしています。
役割を示した上で、書くべき内容と、書くべきではない内容を例示し、コメントの記載に根拠を得られる内容でした。
状態、依存関係等の設計に関する解説がある
本書の記載内容として章の一覧を提示しました。
その中で第4章にかかれている「状態」や第6章に書かれている「依存関係」はプログラムの複雑さの原因となりやすい部分だと思います。
そして、複雑なプログラムはそのまま読みにくいコードに繋がります。
本書では状態管理や依存関係への考え方、設計思想の解説を通して「読みやすいコード」に近づけていきます。
このように設計での解決を含めて「読みやすいコード」の達成を目指すことがこの本の大きな特徴の一つではないかと感じました。
ちょっとした注意点
この本のサンプルコードはKotlinで記載されています。
また、GUIアプリ（Androidアプリ）のようなものをベースにしているので、その認識があるとコードが読みやすいかもしれません。もちろん、経験がなくてもちゃんと読めます。
Kotlinの文法解説も巻末にありますので、読み進める上では大きく問題はないかと思いますが、ご注意ください。
まとめ
本書を読んだことにより、コードレビューを自信を持って行えるようになりました。
また命名規約やコーディング規約について、本書を参考に、改善をすれば、チーム全体で「持続可能なソフトウェア開発」に近づけると思います。
良いコードに対する理解をより深くするために一読して損はない本です、是非みなさんも手にとってみてください！
P.S.
採用
虎の穴では一緒に働く仲間を募集中です！
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
yumenosora.co.jp
LINEスタンプ
エンジニア専用のメイドちゃんスタンプが完成しました！
「あの場面」で思わず使いたくなるようなスタンプから、日常で役立つスタンプを合計40個用意しました。
エンジニアの皆さん、エンジニアでない方もぜひスタンプを確認してみてください。
store.line.me
