脳に収まるコードの書き方

2025年3月11日読了

Credit

Mark Seemann. (2021). Code That Fits in Your Head: Heuristics for Software Engineering. O’Reilly Media, Inc. 吉羽龍太郎、原田騎郎訳. (2024). 脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック. オライリー・ジャパン.

Summary

ソフトウェアを開発する上で脳を混乱させる複雑性を避けるための色々な手法を紹介する本。

プログラミングの複雑性を避ける本でなければ、リーダブルなコードの書き方を説く本でもなければ、綺麗なアーキテクチャとは何たるかを説く本でもない。あくまで、ソフトウェア開発をスッキリした状態で進めるための手法を紹介する本。

Note

• ソフトウェア開発は建築と例えてはならない。だから、プロジェクトとして例えるのは良くない。失敗したソフトウェアだけが終わりを迎えるのであって、成功したソフトウェアの開発は続くから。はえー、良い説明。
• C#には class に static を付けてインスタンス化することがないことを示せる。知らなかった。(本書の本質からずれた発見)
• 「どんな馬鹿でもコンピューターが理解できるコードを書ける。良いプログラマーは人間が理解できるコードを書く」良い言葉。
• パーティカルスライス。取り敢えず動くようにしろ。ごめんなさい、今後意識します。
• WebバックエンドでもDBが関わるとテストが難しいんだな。Webばかりで蔓延するテスト駆動神話が嫌いだったが、特段Webでも支障がないわけでもないと知って安心。
• カプセル化はインスタンスが有効であることを保証すること。なるほど、とても良い説明。
• 80/24ルール。1メソッドは24行まで。1行は80列まで。前者は今後意識する。後者はやり過ぎな気がする。150くらい取って良いんじゃないかな。あるいは、DirectXなりVulkanなり冗長な型シグネチャを持つ体系をよく使っているから?
• 一つのコードの中で7を超えることをしてはいけない。7って結構情報量あると思うので、プロジェクトに制限をかけるときは、もう少し小さめの値を取っても良いかもしれない。……と思ったがフィールドだけで半分以上取られそうなので7で良いかもしれない。
• メソッド名をXに置き換えてから命名する。返戻型や引数型・シグネチャやそのメソッドが定義されたオブジェクトから多くの情報が得られる。そうだよな、と思いつつも、定義自体はそれで良いが、メソッドが実際に使われているコードではそれらの情報が欠落しがちなので、言語サーバがない環境ではかえって読みにくくなるんだよなと。
• テストにおいて、偽陰性は大した問題ではないが、偽陽性は問題。ノイズになるから。へえ、逆だと思っていた。
• テストを書く。問題ないコードを書く。バグに出くわしたら調べる。つまり、バグがないかと確かめること(デバッグ)はしない。
• オブジェクトの合成はネスト。すぐにサイクロマティック複雑度が上がる。マジで分かる。
• ロギングに関して。純粋でない操作を記録し、それ以上は記録しない。言われればそれ以外の何でもない。
• ゾーンに入っているとき、作業を中断したくないと思うが、ゾーンに入っていることは生産性があることを保証しない。本当に本当にこれ。刺さる。死ぬ。
• ファイルをどう構成するか。すべて単一のディレクトリに入れる。解説を読んでなるほど。デメテルの法則ではないが、一つ階層を降るような呼び出しは良くないかもしれない。意識していこう。

Impression

本書のレビューを見たことはないが、私は良書だと思う。 ことソフトウェア開発に絞ると、次のレイヤーがあると考えている：

1. リーダブルコード
2. パラダイム
3. 設計
4. 開発手法
5. 技術選定
6. マネジメント

個人的には、この手の本を探すと、圧倒的に3.が少ないように感じる。 誰でもオブジェクト分割の方法を知っているが、誰もパッケージ分割の方法を教えてくれない。 時と場合に依ることなので解説しづらいというのは分かるのだが。 そんなことでは経験がなければ中規模のソフトウェアすら開発できまい。 本書は3.と4.の間に位置するような本であるため、この不満を少し解消できて嬉しい。

個人的には、学校や競プロでしかコードを書いたことがなく、これから業務や趣味でソフトウェアを開発しようとする全員に読んでほしい。 お勧め。

■