はじめに
剃刀境の茂み、nikkieです。
存在を教えていただいた「Refactoring -- Not on the backlog!」の感想エントリです。
非常にしっくり来ました。茂み！
目次
Refactoring -- Not on the backlog!
Ron Jeffries氏による記事。
「バックログにリファクタリングのユーザーストーリーを置くのはよくないよ」ということを言っています。
読んだ感想なのですが、
- なぜよくないか：リファクタリングを後でまとめてやろうとしている
- 規模も大きくなるし、期待していた結果が得られないことも多い
- 後でまとめてやるのではなく、機能開発の中で必要な小さなリファクタリングも込みでやる
いくつも出てくる図では、コードベースでリファクタリングが必要な箇所を茂み（thicket）と表現しています1
- 最初コードベースはきれいで、機能開発は素早くできる
- 機能開発のイメージは、図で左から右につっきる（下の図で黒い矢印）
- コードベースの中に茂みが現れ始める（下の図で緑）
it's really just not very good code. But it doesn't look too bad -- yet.
- 意訳「非常によいコードというわけではないが、悪すぎるようにも見えない。まだ」
- 茂みを避けて開発を続ける
- 避ければ早く進める！
- 経験に照らすと、「コードベースのここ、引っかかるけどいまは先に進むか」（ちょっと汚い避け方を重ねる）みたいなことかなと思います。これが蓄積していく
- 茂みは育つ
- 早く開発したいので茂みを迂回 -> 茂みは育つ が繰り返される
- 茂みがめちゃめちゃ育ってしまい、開発速度が出ない
- 当初のきれいなコードベースを取り戻したい。「リファクタリングだ！！」
コードベースの茂みに対処せず、見て見ぬふりをした結果、大きなリファクタリングが必要になってしまいました。
これに対して、氏の回答は以下です
We take the next feature that we are asked to build, and instead of detouring around all the weeds and bushes, we take the time to clear a path through some of them.
（図は「Refactoring -- Not on the backlog!」より引用です）
茂みを避けずに通れるように道を作るということです（黄色いところ、茂みを貫通してますよね）
ポイントは、今開発している機能に関係する茂みにのみ対処するということ。
今開発している機能とは関係ない茂みは（通るわけではないので）今は無視します
これによりリファクタリングをためて実施ではなく、機能開発と合わせて進めていけますよね。
問題が顕在化するまで見て見ぬふりをするのではなく、問題の芽は今の開発のついでに摘む。
これは非常にしっくり来ました2。
思い出したもの
二つの帽子（『リファクタリング』より）
『リファクタリング（第2版）』にあります（第2章）。
二つの帽子とは
- 機能追加の帽子
- リファクタリングの帽子
一度にかぶる帽子は一つだけというのが肝です（これらを同時にはやらない！）。
機能追加にあたっては
- リファクタリングの帽子：（機能追加の前に）既存のコードの構造を改善
- 機能追加が簡単になるようにリファクタリング
- 機能追加の帽子：機能追加
- リファクタリングの帽子：2の動くコードをリファクタリング
- 動作するきれいなコードにするという理解です
という流れになります。
この1が検出した茂みへの対処だと思いますし、2のまま放置すると茂みになりそうな箇所に3で手を打っておくということかなと思います。
リファクタリングの費用対効果
ミノ駆動さんの記事より
この記事の中には、大きなリファクタリングで自爆というケースもありそうですね。
関連するなと思ったのが「奥義９ : 効果的でない箇所をリファクタリング」です。
「今開発している機能に関係する茂みのみ対処し、それ以外は無視」という判断は、費用対効果を考えてもなかなかいい感じなのではないかと思います。
気づいた茂みすべてに対処しようとしたら時間はたくさん必要ですし、対処してもそこを通らなかったら「なんのために道を作ったんだろう」となってしまいますからね
終わりに
Ron Jeffries氏による「Refactoring -- Not on the backlog!」を読んだ感想を書きました。
コードベースの茂みの例えが私はしっくり来ました。
茂みの対処を後回しにして開発を進めて大きなリファクタリングを招くのではなく、現在の機能開発の中で関連する茂みには道を通す。
二つの帽子や費用対効果も関連して思い出しました。
(追加 2024/03/13)
『The Art of Agile Development, Second Edition』に時間経過とともにコードベースがよくなっていくという箇所3があるのですが、「茂みに対処し続けていけば至れるかもな」と示唆を受けた感覚もあります。
(追加 終わり 2024/03/13)
Uncle Bobは「リファクタリングに許可を求めるな」と著作で再三言っていますが、リファクタリングをRon Jeffries氏が説いたようにとらえていると、「許可を求める必要はないな」と思えますね。
茂みが育たないようにコードベースに絶えず手を入れる必要があるのに、全部まとめてリファクタリングとか、舐めているのですか
- brush（やぶ）という表現もあります↩
- 私は社会生活不適応者なので、「後でまとめて家事をやろう」と見て見ぬふりを重ねた結果、大変なことになります。小さいうちにこまめにやっておくのがいいんですよ！！↩
- Every day, our code is better than it was the day before. ref: James Shore: AoAD2 Practice: Reflective Design↩
