13.3 コードの変更が必要なとき
13.3.1 既存コードへのテスト追加
13.3.2 良い習慣を身につけるために悪いコードをリファクタリングする
13.3.3 不可避なことを先送りする
内容
変更しづらいレガシーコードは地雷と例えることができる。
そのままにしておかないと危ない。
しかし、そんな地雷コードでさえも変更する必要がない限り、そのままにしておけば価値を提供し続けられる。
物理的な機械とは違ってまったく故障しないからだ。
ただし、変更、拡張、リファクタリングが必要になったとき、地雷撤去には大きなコストを生む。
ソフトウェアはリリースされれば新しいビジネスの方向性が見えてくる。
どのレガシーコードがいつまでレガシーコードのままで良いかはわからない。
だから、いつでも変更が簡単な状態を保つことが重要なのだ。
既存コードへのテスト追加は、既存コードをテストしやすいようにする。
テストファースト開発で行うよりも難易度は高くなる場合があるが、変更コストの削減を見込める。
だから変更要求がある機能、あるいはそこに関連する機能については積極的にテストを追加した方がよい。
悪いコードのリファクタリングにはスキルアップの価値がある。
開発者全員がリファクタリングスキルを知っているわけではないが、これはソフトウェア開発において常に必要なスキルだ。
リファクタリングができるようになると、最初からクリーンなコードを書こうとするようになる（プレファクタリング）。
悪いコードをリファクタリングすることで「してはいけないこと」「代わりにすべきこと」がわかるようになる。
ソフトウェア開発者としての目標は、私たちが開発するソフトウェアが価値を創造し、未来でも価値を生み出し続けることだ。
しかし、ソフトウェアは実を結ばずに死ぬか、思った以上に長く生き残るかのどちらかだ。コードが将来どのような形になっていくのかを正確に予測することはできない。
ソフトウェアが価値を生み出し続けるためには、投資対効果をできる限り高くするのと同時に、コストを下げることも必要だ。
学び
- ビジネスが息が長くなるかどうはかはわからない。だから、エンジニアはいつでも変更が簡単な状態にコードを保つ必要がある。
- 早さのために保守性を失うのであれば、それは保守性を考慮したスキル、プラクティスが足りないからだ。本当に早い人は、きれいだからこそ早い。
- 変更要求がある場合、テスト追加するチャンスだし、テスト追加して今後の変更コストを削減した方がよい。
- 開発の学習の中にリファクタリングの工程を入れたほうがよい。TDDを教えることが、それにつながる。
- ソフトウェアが価値を生み続けるために、ランニングコストは常に低くあれ。
学びを活かすアイディア・行動
- テスト追加のタイミングの共有。
- リファクタリング内容と関連モジュールの一覧作成
- リファクタリング内容と関連モジュール一覧を作成し、メンバーに実施してもらうことで、リファクタリング力をアップさせる。
No responses yet