『レガシーソフトウェア改善ガイド』を読んだ。『レガシーコード改善ガイド』とタイトルが似ていて紛らわしいけれど、続編だとかそういう直接的なつながりはない。そもそも原題は全く違う。- レガシーコード改善ガイド → Working Effectively with Legacy Code
- レガシーソフトウェア改善ガイド → Re-Engineering Legacy Software
こちらの方が扱っている範囲が広い。『レガシーコード改善ガイド』がテスタビリティの低いコードに対してユニットテストを書く方法に特化しているのに対して、こちらは組織的なコンセンサスや承認の話から、静的解析をはじめ環境構築やビルドまで自動化全般を扱っている。
範囲が広い分、記述の抽象度が高くなっている。そのため、トピックによっては物足りなさを感じることもあった。特に気になったのが例のシンプルさ。レガシーソフトウェアとの戦いでは、泥臭い作業が必要で下手したら泥沼化しかねないと思っているから、あんまり例がシンプルだとちょっと不安だ。
おもしろかったのは、ユニットテストの扱い。『レガシーコード改善ガイド』がそれにフォーカスしていたのに対して、こちらでは、誇張だと断ったうえではあるけれど、
リファクタリングする前にユニットテストを書くのは、ときには不可能であり、しばしば無意味である。と書いている。「ときには不可能」というのは、テスタビリティの低いレガシーコードにユニットテストを書くことの難しさを言っている。確かに思い当たる節がある。テスタビリティの低いコードを書いているプロジェクトで、トリッキーなテストコードを書いていけるとは思えない。「しばしば無意味」というのは、しばしばリファクタリングでクラス構造を変えることになり、ユニットテストが用をなさなくなることを言っている。こちらは分からないではないけれど、誇張し過ぎじゃないかな、と思う。
ユニットテストがこんな状態なので、複数のテストレベルで自動化しようと言っている。もう少し具体的に考えるなら、保護したい結合範囲（内部構造をリファクタリングしたい結合範囲）の振る舞いをテストでくるむことになるだろう。それがユニットテストより大きければ、サービス層をくるむSubcutaneous Testなのかシステム全体をくるむEnd-to-End Testなのかは、それこそプロジェクトの目的やシステムアーキテクチャ次第か。
ユニットテストのことだけでなく、他にも考えを整理するための材料がたくさん手に入ったように思う。最近、レガシーコードにどう立ち向かえばいいのかよく悩むのだけれど、もう少し悩んでいよう。
最後に、マインドマップめいた覚書。いろいろなトピックが含まれているので、簡単に整理してみた。
