実装を進める上で障害になりそうなところを先回りして直してるように見えるけど、一体どうやって検知しているかという話題。
結論から言うと「慣れです」なんだけど、こういう考え方があるよというのを紹介しておく。
ちょうど10年ぐらい前に話題になった手法だけど、考え方としてはまだまだ現役です。
概要は本家なりこの辺のリンク先なりを見て貰って。
- 開発者のためのソフトウェアテストのスキルアップ | Think IT（シンクイット）
- 大規模コードをリファクタリングする方法『ミカドメソッド(Mikado Methood)』について | Futurismo
- テストとリファクタリングに関する深い方法論 #wewlc_jp
- レガシーソフトウェア改善ガイド | Amazon
僕の理解は
- 1 ループ目
- やりたいことを実現するコードを書く
- ギャップが無ければサクッと実装して終わり
- ギャップがあれば、それを「課題」としてマークする
- 最初のコードを捨てる
- 2 ループ目
- 課題を実現するコードを書く
- ギャップが無ければサクッと実装して終わり
- ギャップがあれば、それを「課題」としてマークする
- 最初のコードを捨てる
- 以下課題がなくなるまで繰り返す
と繰り返すとゴールを達成できる、です。
いわゆる「ヤク刈り」を、1 つずつ、いつでも引き返せる形で行える、というのがポイントなのだろう。
似たような養成ギプスに、 test && commit || revert や TDD があります。
test && commit || revert は、本気でこれをやろうと思うと依存関係の端から作業しないといけないので、ミカドメソッドと同じことを実現しなければいけません。
また、設計技法としての TDD は、テストを書きながら絶対必要になるパーツを実装し、パーツを組み上げて完成させる。これも依存関係を構築していくイメージですね。
最初に思いついた簡単な方法で実現できると爆速で生産性 MAX になるが、様々な理由でそう上手くはいかない。 爆速な理想と、目の前のコードベースとのギャップを実感しながら日々暮らしていくと、要件を言われたときに「絶対ココが問題になるので直しておきましょう」と言えるようになっていく。
依存関係を思い浮かべられる、問題になると自信を持って言える、というのが、必然なのだけど、端から見ると先回りに見えるのだろう。
なぜ依存関係が思い浮かぶのか、に対しては「毎日のヤク刈りの結果、コードベースが頭に入っているから」 なぜ問題になると自信を持って言えるのか、に対しては「毎日のヤク刈りの結果、罠っぽいところに鼻がきくようになっているから」
となってしまって、つまり「慣れ」です。
「慣れ」ではあるんだけど、普段どれだけ意識しながら目の前のコードを読んでいるかでもある。 ヤク刈りをしているときに、今私はヤク刈りをしています、と認識しながらやっていると、分解したタスクのそれぞれの重さについて、勘所が磨かれていくのではないか。
