パンくず
内容
2つの帽子
機能の追加とリファクタリングを同時に行ってはならない、という比喩です。
機能の帽子をかぶっている時は機能の追加のみを行う。
リファクタリングの帽子をしている時はリファクタリングのみを行う。
リファクタリングする理由
- 設計の向上
- バグの発見
- 開発スピードの向上
- 可読性の向上
- 品質の向上
リファクタリング自体は新たな機能を追加するものではないので、
開発スピードの向上というと矛盾しているように聞こえるかもしれません。
長期的にみれば、よりよい設計が維持されているソースコードは追加・修正の
工数が下がるためトータルで費やす工数は減ることになります。
障害対応の工数も減りますし。
いつ行うか
- 機能の追加時
- バグ対応時
- コードレビュー時
機能の追加時については、2つの帽子の件があるので機能を追加する前にまず追加しやすいように
リファクタリングしたり、追加後に新たにリファクタリングが可能になる箇所が出てきたらリファクタリング
したりする。同時に行わないこと。
マネージャーの説得
ここが現実の壁ですね。
長期間運用しているシステムに関わっている方は分かると思いますが
リファクタリングをせずに機能追加、バグ対応などを経たシステムは
欠陥住宅のようです。
磨かれない歯のようです。
整備をしない車のようです。
修正を行うとバグが発生するかもしれない、という短期的なリスクを恐れ、
リファクタリングを行わないということは確実な終焉に向けて歩き出していると
考えたほうがよいと思います。
欠陥住宅を補修せずに済み続けることが出来ますか？
磨かれない歯で虫歯を防げますか？
整備をしない車を長期間乗り続けることはできますか？
今の所具体的な開発案は無し。
理詰めで説得してもNGの現場なので。
さすがに書籍に書いてあったような、業務命令を無視してコードを修正とかも出来ませんしね。
