Tidy First? 感想・引用メモ
_ikarigataケントベックの新著『Tidy First？』を今更ながら読み始めた。
原著がすごいのか翻訳が素晴らしいのか、
あまりに気持ちのいいパンチラインが多いので
メモにまとめてみることにする。
第Ⅱ部 『管理術』 序文 の冒頭
整頓をできるようになっただけでは、整頓をマスターしたことにはならない。
本書のタイトルは、疑問符を強調した「Tidy First？」である。
整頓ができるからと言って整頓すべきとは限らないことを伝えたかったのだ。
すごい。第Ⅰ部で語られる小さな整頓術の数々を読んで、『リーダブルコードに毛が生えたくらいでは？』と思わされた直後にこのフレーズ。
たしかに実際のソフトウェア開発ではあるべき整頓の仕方は分かっているが、それをいつやるべきか・どこまでやるか・あるいはやらないべきかの判断こそが難しいのであって、それについて言及した本は今まで読んだことがなかった。
_ikarigata16章 『分けて整頓する』
コード変更には『構造変更(＝整頓)』と『振る舞い変更』があり、それぞれでプルリクを分けよう、という主張。
章の最後、ここまでごく真っ当な”小さな整頓術”について語ってきた流れでしれっと過激なことが書いてあって驚く。
整頓に慣れ、小さなステップで作業することに慣れ、安全に作業することに慣れたら、
整頓のプルリクエストではレビューを必須にしない実験をしてみよう。
こうすればレイテンシーは減り、さらに小さい整頓のプルリクエストを作るインセンティブになる。
17章『連鎖』
整頓は連鎖するものである、というのを第Ⅰ部で紹介したそれぞれの整頓術同士がどのように連関しているのかを例示していくことで明らかにする。
↓気持ちのいい文章すぎる。こんなに短くて使っている語彙もシンプルなのに。
整頓をしたい衝動を抑えることが、整頓スキルのカギとなる。
整頓し終わった。もっと整頓すべきか？それは時と場合による(詳しくは第Ⅲ部で見ていく)。
↓コメントの是非についてのとてもシンプルで誠実な回答。
変更はソフトウェア開発において支配的なコストであり、コードの理解は変更の支配的なコストである。
よって、動作するコードの構造と意図を伝えることは、鍛えられるなかで一番価値のあるスキルの１つだ。
コメントはあくまで構造と意図を伝える方法のー形態であり、
整頓はそれとは異なる道から構造と意図の伝達の限界を追い求める試みであると言えるだろう。
18章『バッチサイズ』
整頓だけのプルリクはレビューしなくてもいい、というフレーズへの補足がしっかりとされていた。
適切に失敗から学習していきなさい、というやさしさ。
整頓はレビューしなくてもよいというレベルの安全と信頼に到達するためには、何か月もかかる。
練習しよう。実験しよう。みんなでエラーをレビューしよう。
20章『絡まりを解きほぐす』
コード修正をしていると得てして発生する『整頓』と『振る舞い変更』が気づかぬうちに絡み合ってしまった状況について、その間の作業をいったんすべて捨てたうえで、『整頓』⇒『振る舞い変更』の順に修正を入れ直せ、という提案。たしかに。
再実装するほど新しい発見の可能性は高まり、
同じような振る舞いの変更からも多くの価値を引き出せるようになる。
毛糸の玉を解きほぐすのは、絡まりがあることに気づくことから始まる。
解きほぐす必要性に気づくのが早いほど、作業は小さくなる。
21章『先に整頓、あとに整頓、改めて整頓、整頓しない』
整頓のタイミングについて。
私が伝えたいのは、本当は、後回しにしても整頓はできるということだ。
改めて整頓するもう1つの理由は、学習ツールとしての役割だ。
コードは自分がどのように構造化されたいかを「知っている」。
あなたがその声に耳を傾けて、現在の構造から望んだ構造へ移行しようとしているのなら、
必ず何かを学ぶはずだ。
整頓はあなたの設計のあらゆる結果を意識するための素晴らしい方法だ。
整頓は設計がどのようになるかを照らし出すのだ。
23章『構造と振る舞い』
構造の変更と振る舞いの変更はどちらも価値を生み出すが、
根本的には別物だと理解するところから始めよう。
どのように？一言で言えば、可逆性だ。
28章『可逆的な構造変更』
筆者の『整頓』という行為への軽やかなスタンスの背景にあるそもそもの思想が明らかになる章。
構造の変更は振る舞いの変更とどう違うだろうか？
先に整頓することに関係する特性の1つは、構造の変更が一般的に可逆的であることだ。
一般的に、私たちは可逆的な決定と不可逆的な決定とは分けて扱わなければいけない。
不可逆的な決定では、レビュー、ダブルチェック、トリプルチェックが大きな価値を持つ。
ベースはゆっくりにし、慎重にならなければいけない。
その決定に大きなメリットがある場合でも、潜在的には間違ったときに大きなデメリットがある。
そう。私たちはメリットを求めるが、それ以上にデメリットを避けたいのだ。
可逆的な決定についてはどうだろうか？
ソフトウェアの設計判断のほとんどは、簡単に戻せる。
その決定にはメリットがある。
間違いを避けることにはほとんど価値がないので、
間違いを避けるために多くを投資するべきではない。
30章『コンスタンチンの等価性』
丁寧なのか雑なのか分からない論法で
ソフトウェアの開発コスト≒結合である、という説を導く。
リリース後の運用期間がある程度長期であれば初期コストを0に近似するのは正しい気はするけど、
その近似に無理がないほどの長期運用がされるソフトウェアがどれほどあるのかは疑問。。
_ikarigata33章『結論』
まだまだ続くと思っていたら突然最終章がやってきた。
（本の後半の2割くらいはすべて索引だった）
「先に整頓するか？」という問いに対する回答はコスト・収益・結合・凝集の4つのパラメータとして左右される。
だが、一番重要なのはあなただ。
整頓はあなたのプログラミングに平穏と満足、喜びをもたらしてくれるだろうか？
多少はありそうだ。
これは重要だ。
なぜなら、あなたが最高の自分でいれば、より良いプログラマーでいられるからだ。
いつも急いでいて、変更に痛みを伴うコードの変更をしているなら、最高の自分ではいられない。