読書メモ。2025年２冊目。
『Tidy First?―個人で実践する経験主義的ソフトウェア設計』を読んでの感想となります。（2025/1/4記載）
本の概要
乱雑なコードは厄介です。コードを読みやすくするには、管理できる小さなまとまりに分割する必要があります。本書は、エクストリームプログラミングの考案者で、ソフトウェアパターンの先駆者であるケント・ベックが、システム全体の構造を念頭に置き、コードを改善するには、いつどこで整頓するのがよいかを解説します。
整頓のしかたを一気に習得するのではなく、整頓を少しずつ試しながら自身の課題解決につなげます。コード行数の多い大きな関数については論理的にコードを小さなチャンクに分割する方法を学び、その過程で、結合、凝集、ソフトウェアシステムの経済的価値（ディスカウントキャッシュフローやオプショナリティ）などソフトウェア設計の背後にある重要な要素を解説します。
また、ソフトウェア設計の基礎理論とそれに作用するフォース、システムにおけるふるまいの変更と構造の変更の違い、先に整頓したりあとに整頓することによるプログラミング体験の向上、大きな変更を小さく安全な手順で始める方法、ソフトウェア設計を人間関係のエクササイズとしてとらえることなどを学びます。
引用：
動機
・一にも二にもケント・ベックの新刊。
感想
構造の変更と振る舞いの変更について解像度を上げて分離した意識ができました。
構造の変更については、つい「今はそのタイミングじゃない」に逃げがち（またはそれを許容しがち）ですが、
レベル感を意識した判断は重要で、「今後も触ることが見えてる機能なら今触る部分は軽くやっちゃおうよ」と言える空気は持っていたい。
第１部で紹介のある整頓は、＝リーダブルコード化といった印象を受けました。
10年ぐらい前に当初が発売された頃は、
自分がテックリードとしてほぼ一人でスマホアプリのバックエンド担当をしており、
開発のたびに随時整頓を繰り返していた記憶があります。
時が流れて、より価値のある開発の加速化が求められる現在、
「どれくらい？」「いつ？」を意識して整頓を行う必要があることを実感しました。
鵜吞みしてきたものに対する解体が必要なことに気付きます。
書き留めたメモ
- ソフトウェア設計について
ソフトウェア設計の他の記述では「どれくらい？」と「いつ？」が抜けている。
まるで時間の制約が何もないところで設計しているかのように見えた。
この文章を読むまで意図できていなかったことに気付きました。 - 凝集について
整頓により凝集度を高めれば、振る舞いの変更が容易になる。
凝集度を高めることで、結合が受容できるようになる。
必ずしも分離だけが正解ではない。 - ひとかたまり
コードの最大のコストは、コードを書くことではく、読んで理解すること。
先に整頓することは、結合を減らし、凝集を高め、認知負荷を減らす。
自宅の作業部屋のいつも見えるところに貼っておきたい内容。 - 分けて整頓する
レビュー速度もインセンティブになる。
すばやいレビューは、多くの小さなプルリクエストを生む。
焦点を絞ったブルリクエストは、レビュー速度をあげる。
遅いレビューは大きなプルリクエストを生み、レビューがさらに遅くなる。
チームの作業スペースのいつも見えるところに貼っておきたい内容。 - バッチサイズについて
次の振る舞いの変更をサポートするために必要な分の整頓を行う。
はるか先の未来のためには行わない。
自分がフルでプログラミングに従事できていたころは、気になったときに気になった分だけ行っていたことを思い出し反省。 - 可逆的な構造変更について
構造の変更は一般的に可逆的。
簡単に戻せるので、間違いを避けるために多くを投資すべきではない。
振る舞いの変更は不可逆。
決定に大きなメリットがある場合でも、潜在的には間違ったときに大きなデメリットがある。
そのため、可逆な範囲までレビュー、チェックなどを通し慎重にアプローチをする。
ここまでの解像度を持ったアプローチに対する意識ができていませんでした。
構造の変更についての意識は個人だけでなく全体で持っていたい。
まとめ
自分自身、プログラミングから少し離れてしまっているものの、
離れているからこそ、改めてこうした直接目に見える形では現れなくても、
開発を進める上で価値ある取り組みを意識していたいと思いました。
昨年の開発生産性カンファレンスでのミノ駆動さんのセッションも思い出しました。
合わせて意識していたい。
今回の本はシリーズものらしく、次刊は「チームのプログラマー同士の関係を癒し、もっと大きな問題に言及する」とのこと。楽しみ。
『エクストリーム・プログラミング』を読んだのも10年ぐらい前なのでそろそろ読み直したい。
