『読みやすいコードのガイドライン』は可読性設計の本だあああ！！！
こんにちは、リファクタリング大好きなミノ駆動です。
2022/10/22発売の技術書『読みやすいコードのガイドライン ―持続可能なソフトウェア開発のために』を技術評論社様よりご恵贈賜りました。
この記事は、この本の書評です。
いいことがいっぱい書いてあったので、皆さんがお手に取りやすいよう発売前にいち早く記事化した次第です。
あなた誰よ？
どんな立場の者がこの書評を書いたのか、念のため簡単に自己紹介を。
（『読みやすいコードのガイドライン』著者石川宗寿氏ではなく、本記事執筆者の自己紹介です）
ミノ駆動です。
変更容易性の設計入門書『良いコード／悪いコードで学ぶ設計入門』（通称「ミノ駆動本」）の著者です。発売わずか5ヶ月で7刷重版、発行部数2万超え。
アプリアーキテクトとして、アーキテクチャ設計やリファクタリング、拡張性向上、助言など、各種設計業務を生業としています。
Twitterでは不定期でクソコード動画を投稿しています。
総評
タイトルにあるように、この本はソフトウェアにおける可読性設計の本だと感じました。
ソフトウェアには機能適合性や性能効率性など、様々な品質特性があります。ソフトウェアにおける設計とは、なんらかの品質特性向上を促進する、仕組み作りのことです。
可読性とは、コードの意図や関係する処理の流れを、どれだけすばやく正確に読み解けるかを表す指標です。意図が分かりにくい、可読性の低いコードは、読み解くのに莫大な時間がかかります。また、誤ってバグを埋め込みやすくなります。開発生産性に直結します。
この本は、可読性を向上させるための様々な技法をかなり詳細に解説しており、まさに可読性を設計するものだ、という印象を覚えました。
誰にオススメ？
新卒エンジニアさんには、ぜひ手に取ってほしいと思います。可読性の基本のキが、この本には詰まっています。プログラミングスキルの土台作りに寄与するでしょう。
中堅エンジニアさんにもオススメです。命名以外に、本書後半で状態設計や関数設計を扱っており、学び直しに適していると思います。
可読性を理解するためのノウハウが系統立てて解説されているので、育成・指導する立場のシニアエンジニアさんにとっても役立つと思います。
Kotlinで書かれています
サンプルコードはKotlinで書かれています。
私はKotlinは軽く触った程度の経験しかありませんが、本書末尾にKotlin文法の簡単な付録もあり、コードリーディングに苦労しませんでした。
また、フレームワークやDBに依存しない、pureなKotlinコードとして書かれています。
近年、ソフトウェアといえば専らWebアプリを指すような風潮がありますが、特定のIT分野に限定せず、組み込み系でもネイティブでも、広くノウハウを活用できると思います。
コードはbadケースとgoodケースが併記されており、良し悪しの比較が分かりやすいと感じました。
もろもろ感じたこと
可読性といえばとかく命名だけが注目されがちですが、命名だけでなく、挙動の予測のしやすさや、影響範囲がどこまで及ぶか、といった点も可読性を左右します。
そうした点も、しっかり解説してありました。
（目次はこちら）
意図を伝える（命名、コメント）
意図を可能な限り正確に伝えるための命名やコメントの仕方について、かなり詳細に解説しています。
命名はつまるところ処理の要約、抽象化です。
抽象化とは、ある目的のために本質以外の要素を削ぎ落とすことです。
私は自著ミノ駆動本で、目的を冠した名前を設計する、目的駆動名前設計を解説していますが、あくまでクラスやメソッドのスコープ設計に着目した命名であり、具体的な言葉の選び方はあまり深く解説していません。
一方、こちらの『読みやすいコードのガイドライン』では、動詞や副詞など品詞の使い方、単語の選び方など様々な観点で命名の仕方を深掘りしています。
要約とは、ぶっちゃけ最終的には国語力を要しますが、この本の命名ノウハウを参考に訓練すれば、（プログラミング文脈で）かなり要約力が上がり、命名精度が向上するだろう、と感じました。
挙動の予測を容易にする（状態、関数の設計）
変数の値変更といった、状態遷移をずさんに扱うと、システムの挙動予測が困難になり、保守が難しくなります。
挙動を予測しやすくするための技法として、この本では状態設計と関数設計を解説しています。
状態遷移に関しては、私の観測範囲では中堅プログラマが書いたコードでも結構いい加減なものが見られます。
状態設計について、様々な遷移パターンを用いてかなり手厚く解説しており、学び直しにうってつけだと感じました。
影響範囲を局所化する（依存の設計）
クラスや変数がグローバルにいろんなところから参照されていると、ロジック変更の影響が意図しない箇所に伝搬しやすくなり、バグになったりします。
バグにならないよう、影響がどこまで及ぶのか調査する労力も大変になります。
こうした依存の度合いを結合度といいます。
この本では内容結合や共通結合など、結合度の度合いごとにどう依存を低減し、影響範囲を局所化するかについて設計ノウハウを解説しています。
プログラミング初心者は「どこからでも触れた方が便利だから」と、依存関係を考慮せずに動くだけのコードを書きがちです。
依存が無茶苦茶なシステムは、長期にわたる仕様変更や保守に耐えられません。
影響範囲の拡大は開発が本当に辛くなるので、依存を意識し、影響範囲を小さくする設計スキルをぜひ本書で身につけてほしいと感じました。
『リーダブルコード』との比較
可読性を取り扱った有名な書籍として『リーダブルコード』があります。
『リーダブルコード』では命名、コメント、コードブロックの整え方、関数のスコープなどを主に取り扱っています。
『リーダブルコード』『読みやすいコードのガイドライン』双方とも、一部同じようなノウハウの記載があります。
しかし『読みやすいコードのガイドライン』では、命名でも品詞や単語の詳細な選び方に言及しており、『リーダブルコード』とは違った観点が得られる、と感じました。
また、『リーダブルコード』では深く扱っていない状態設計や依存設計を解説しており、『リーダブルコード』とは違ったベクトルで可読性向上を狙えると思います。
したがって、既に『リーダブルコード』を持っているから要らない……ということはなく、新たな観点で可読性設計を学ぶことができると考えます。
輪読会やったら楽しそう
可読性のテコ入れは個人では困難であり、チームで取り組む必要がある旨が、本書冒頭に書かれています（私も首をガクガク縦に揺さぶるほど同意です）。
この本は、可読性についてチームで目線合わせするのにうってつけだと思います。
自著ミノ駆動本が発売されて以来、ミノ駆動本を使った輪読会が多数開催されております。
『読みやすいコードのガイドライン』も同様に、輪読会で読み合わせしながら「そういえば昔ヘンなコード書いちゃったなぁ」「あのコードはこう書くべきだったなぁ」「今実装しているコード、このノウハウ使えば改善できそう」などあれこれ議論すれば、きっと楽しいものになるでしょうし、チーム全体でのリテラシ向上が期待できると思います。
あと、インプットだけでなく、この手の設計技術は手を動かしてアウトプットすることで大幅なスキルアップが望めるので、泥臭い製品コードを使ってどう改善できるか試行錯誤することを強く勧めます。
最後に
いろんな設計観点を学べるのは嬉しいですねぇ。
観点が増えると、選択の幅が広がります。
設計精度が一段と高くなります。
設計は沼ですが、よりパワーアップしてプロダクトに活かせることが、楽しくてしかたがありません。
皆さんも、この『読みやすいコードのガイドライン』でパワーアップしましょう。
この記事が気に入ったらサポートをしてみませんか？