クリーンコードクックブック の商品レビュー

Maximiliano Contieri(著者),田中裕一(訳者)

2026/02/23

読みやすく保守しやすいクリーンなコードを書くにはどうすればいいかということについて、様々な観点で書かれた本。
クリーンコードと一言で言っても、突き詰めていけば奥深いことなんだろうなと思った。

こういう系統の本はいろいろ読んできたけど、『MAPPER』という概念は初めて知った。「Model: Abstract, Partial, and Programmable Explaining Reality」の略で、直訳すると「モデル：抽象的、部分的、かつプログラム可能な現実の説明」とのことで、モデルが備える定義について説明したものらしい。「抽象的」や「部分的」というのは他の本でもよく見るけど、「現実の説明」というのは面白いなと思った。どうやらソフトウェア設計においては現実と対応しているものと考えたほうがいいらしい(まあ、そんな単純ではないだろうけど)。
※「初めて知った」と書いたけど、調べてみるとこの本に関するページしかヒットしなかったので、著者が考えた概念なのかもしれない。

ところどころに用語解説が書いてあって、これもなかなか面白かった。『マーズ・クライメント・オービター』という火星探査機は、メートル法とヤード・ポンド法を間違えた結果、爆発してしまったのだとか。
メートルとヤード・ポンドほどでなくても、タイムアウトやインターバルの設定をするのに、ミリ秒か秒か分か分からないことがあるので、単位の概念は重要なんだろうなと思う。

ただ、それぞれの章に掲載されているサンプルコードの言語がバラバラなうえに、どの言語のコードかも書かれていないのは少しわかりづらいと思った。
統一するか、せめてプログラミング言語は書いておいてほしかった(変数名に$がついていたらPHPなど、なんとなく予想はつきはしたけど)。

ヨーダ記法については知ってたけど、誤って代入してしまわないための工夫だったということは初めて知った。まあでも、Linterで対策はできるのでこの書き方はやめたほうがいいらしい。

変数名の長さについては、バランスが難しいなと思う。前に、独自の略語を変数名に使ってる子がいたので、略さないでと伝えたら、今度はかなり長い名前(30文字ぐらい)をつけてきて、いい伝え方がないもんかと思ったりする。

８章のコメントについては、基本無くすことばかり書いてあったけど、逆にどういうふうに書くのがいいかということについても書いてほしかったところ。
「コメントは非常に重要な設計上の決定を説明する場合にのみ必要とされるべき」と書かれてあったけど、いまいちよく分からないので具体的なサンプルも見たかった。

なお、著者によるとコードは「英語を使用しましょう」とのこと。自分も前はそう思ってたけど、最近は英訳しにくい、もしくは英訳するとよく分からなくなる概念(ドメイン)についてはそのままローマ字で書いたほうがいいんじゃないかなと思うようになった。
まあ、その結果、中途半端に英語とローマ字が混ざって余計に分かりにくくなってしまったりするのだけど…。

後、サンプルコードの中には、他の章で記載されていたアンチパターンで書かれているものもあったりして、そこは統一してくれないかと思った(5章でJavaScriptのvarはconstに変更するようにと書かれてあったのに、別の章ではvarで定義されていたり)。

コレクションの繰り返し処理中に、そのコレクションの要素を削除してしまうという過ちはちょうど最近、自分もやってしまったので反省してるとこ。
自分の場合逆からループして対応したけど、コピーを作成するのが安全なのかもしれない。

レシピ13.7のコードは無限ループしてしまうように思うのだけど、いいのだろうかと思った(あくまで書き方の話なので、問題ないといえばないのだけど)

クラスの継承は「is a」(～である)ではなく、「behave-like-a」(～のように振舞う)関係と考えたほうがいいという考え方はなるほどと思った。
正方形クラスを長方形かひし形のクラスどちらから継承するのはおかしいのだろうな。このへん、自分も勘違いしていたことはあるので気を付けたい。

新しいプログラミング言語を学ぶ際は、まず失敗するテストを書くのがいいという話が面白かった。初めてのプログラミングを学ぶということなら難しいけど、プログラミング自体は学んだことがあるということなら確かにテストコードから始めるのもいいのかもしれない。

2026/01/31

コードの設計と品質に関する原則をレシピ形式でまとめた本。一問一答形式で読みやすく、必要な箇所から拾い読みできる構成が実用的。

いま携わっているプロジェクトのコードに感じていた「もやもや」を言語化するのに役立った。特にフィーチャーエンヴィ、貧血モデル、隠された前提といった概念に名前がつくことで、コードレビューで「なぜ直すべきか」を説明しやすくなった。

全体を通して「現実的な落とし所」を意識しながら読めたのが良かった。すべてを教条的に適用するのではなく、プロジェクトの文脈に合わせて判断する視点が身についた。リファレンスとして手元に置き、必要な時に都度見返していきたい。

2025/11/10

クックブックということで、数々のテクニックというか考慮ポイントが詰まった本。

とはいえ、いずれこういう部分も全て AI がなんとかしてくれる時代はもうすぐそこなんですかねぇ...　知識として吸収するのが大事な場合に読む本になっていくのかもしれません。

ちょっと細かい部分は飛ばしすぎた感もあるので、評価は未評価にて。

2025/02/11

読み始めた時はリーダブルコード的なものかと思って読み進めていたが、中盤に差し掛かる頃には細かいコードの粗を指定するような内容が中心になりlinterを導入してる開発現場では意識せずとも自動的に指摘・修正される内容が多いのでは無いかと感じた。また、各プログラミング言語に依存した内容にならないために擬似コードのようなものが利用された結果、コードに一貫性が無いので少し読み辛さを感じた。ただ、短い節に問題コードを提示しその後修正したコードを提示・解説するというスタイルが一貫していてそこには読みやすさと分かりやすさがあった。

リファクタリングに近い事を説明する章もあるがそちらも今では各言語毎に良い設計を提案する書籍などがあると思うのでそちらを参考にした方が身になるのではないかと思う。Javaの場合だと、「良いコード／悪いコードで学ぶ設計入門」辺りの方がカバーしている内容が幅広くコードにも一貫性がある分読みやすいと思う。