FAILS.FEATURES.BUGS と似たようなネタ。結局は自信度でしかない、という点では同じ。
pride versioning > semantic versioning 😂 pic.twitter.com/FrsTTvzCNn
— Marc Backes (@themarcba) February 12, 2025
バージョニングとは違うけど、ケント・ベック氏は、デプロイまでのバッチをどれだけ日頃から整理するか、という観点でレビューコストと管理コストのトレードオフを解説している。
変更を細かくするとレビューのコストは上がるが、衝突・相互作用・先行投資のコストは下がる。開発者はレビューコストを肌身で感じているため、どうしてもレビューコストを下げる方、つまり衝突・相互作用・先行投資のコストを上げる方に動く。ではどうすればいいか？
変更は構造（Structure）の変更と、振る舞い（Behavior）に分けられる。この構造と振る舞いで整理しながら変更を重ねていけば、レビューコストも下がる。書籍「Tidy First?」だと、第16章、第18章あたり。この本では「整頓はレビューしなくても良い」としている。この域に達することができれば、SHAMEの回数は減るだろうか。
あなたとチームは、レビューのコストを具体的にどれだけ減らせるか見極める必要がある。チームに信頼があり盤石な文化があれば、整頓にはレビューは不要だ。相互作用のリスクが大幅に減れば、整頓がレビューされないからといってソフトウェアが不安定になることはない。
整頓はレビューしなくてもよいというレベルの安全と信頼に達するには、何か月もかかる。練習しよう。実験しよう。みんなでエラーをレビューしよう。
Tidy Fist? 第18章 バッチサイズ (p59, 60)
