レガシーコードとどう付き合うか？
吉岡さんがレガシーコード改善ガイド読書会という勉強会を立ち上げた。レガシーコードとどう付き合っていくか、を議論していくらしい。可能なら参加したいが、ちょいと距離があるので中々難しい。
自分もこのお題目については色々考えてきたし、自分なりに実践もしてきたつもりなので、トラックバック送りながら意見などを...
レガシーの定義
- 「テストがないコードはレガシーコードだ」という定義には100%同意。
- 我々は今この瞬間にもレガシーコードを簡単に書くことができる。
- だけど、そのテストのないレガシーコードにも「レガシー度」みたいな尺度があるのではないかと。
レガシー度
といっても簡単に数値化できるようなものではない。
- monolithic度合い。何千行とある関数とか、何百とメソッド持ってるクラスとか。
- 結合度、依存性などという言葉で表現されるアレ。
- Interfaceの設計。変な値を渡さない工夫をしているか？
- Statelessか否か。
- データ構造。データに意味を持たせてないか？('9999'なら特別な処理がはしる、みたいな)
- 冗長度・重複度・Dead Code比率。
- 複雑度。cyclomaticとか。
- バグコードに依存した正常動作コードの比率。
などなど。ツールで測れるのもあるけど、主観で判断せざるを得ないのもある。
で、レガシー度合いの高いコードは、テストコードで足場を作っていっても中々安眠が得られないことがある、というのをいいたいわけで。特にStatefulなコードは厄介。刹那的にテストコードを書き続ける羽目になりかねない。
レガシーで引っ張る vs スクラッチから綺麗に作りなおす
もう一つ。そもそもそのレガシーコードは「なぜ、その役目を負っているのか？」という分析をしておく必要もあるのではないか。
- そのシステムが生まれた頃の計算機資源制約でそうなった。
- そのシステムが依存する別のレガシーコードの制約でそうなった。
- 当時の法規制や商慣習でそうなった。
等々。つまり、そのレガシーコードが支える業務は、今日の制約や法規制・商慣習などを適用すると、当時よりも理想的なものに持っていける可能性がでてくる。もちろん、再分析〜再設計〜再実装には時間もお金もかかるので、「よし！ 作り替えだ！」などと簡単に判断することはできない。
だけど、盲腸だらけみたいなコードは、いくらテストを当てがっても、変化に追従する速度を劇的に改善することは難しい。スクラッチから綺麗に作り直す検討も並行して進めていく必要があるのではなかろうか。
