書籍名「レガシーコード改善ガイドー保守開発のリファクタリング」
著：マイケル・C・フェザーズ
翔泳社
読もうと思った動機
長期間運用している.NETアプリケーションの保守・改修において、以下の課題に直面していたため。
現状の課題：
- 現行システムの仕様が不明確
- 調査方法が確立されていない
- 結果として修正に多大な時間を要している
印象に残った点
p3 ソフトウェア変更の４つの理由
１．要件の追加とバグの修正
残念ながら、バグ修正か要件追加の議論によって、技術的に重要なことが隠れてしまっています。ソフトウェアで最も大切なのは、「振る舞い」であり、振る舞いこそユーザーの求めるものである。期待される振る舞いを私たちが追加すればユーザーは喜ぶが、ユーザーの求める振る舞いを変更、あるいは削除してしまえば、バグの作り込みになり、私たちへの信頼は失われてしまう。
p5 設計の改善
設計の改善は、別の処理のソフトウェア変更です。保守しやすくなるようにソフトウェアの構造を変更する時、通常は振る舞いを同じに保つ必要があります。
もしその過程で必要な振る舞いを失われてしまえば、それはバグと呼ばれることになります。
多くのプログラマがあまり設計を改善したがらないのは、その過程で振る舞いを失ってしまったり、間違った振る舞いを作り上げてしまいやすいからです。
p11 フィードバックを得ながらの作業
編集して祈るは、「注意深く作業する」に同じに見え、とてもプロらしい方法に思えます。
「注意」が一番最初にあり、難易度の高い変更の場合にはトラブルを起こさないように、特にしっかりと注意を払う方法だからです。しかし、注意をより多く払ったからといった、必ずしもそれに比例して安全して向上するとは限らない。
いくら注意深く仕事をするからといって、バターナイフで手術する外科医を選ぶ人はいないでしょう。効果的なソフトウェア変更は、効果的な手術と同じで、実際には高いスキルが必要です。
優れたテストでコードを保護しておけば、変更を行った後、それがうまくいったかどうかをすぐさま知ることができます。注意を払う点では編集して祈ると同じですが、フィードバックを得られるため、より注意深い変更が可能になります。
p12 ソフトウェア万力
変更を見つけるためにテストを用意することは、コードを万力で固定するのと同様の効果がある。コードの振る舞いはその状態で固定するため、結果として、一度の変更で１つの振る舞いでしか変更していないことを確認できるようになる。
つまり、これは自分たちの作業を制御できることを意味する。
p199ーp200 仕様化テスト
振る舞いを維持するためのテストを私は、仕様化テストと呼んでいます。仕様化テストはコードの実際の振る舞いを明らかにするテストです。
「システムはこうするべきだ」とか「こうしていると思うこと」を確認するテストではありません仕様化テストを書くために、簡単な手順は次のようになります。
１．テストハーネスの中で対象のコードを呼ぶ
２．失敗することわかっていること表明を書く
３．失敗した結果から、実際の振る舞いを確認する
４．コードが実現する振る舞いを期待するようにテストを変更する
５．以上の手順を繰り返す
p223 変更できるほど十分に私はコードを理解していません
何かを理解しようとするために多くの時間を費やすのは時間を費やすのは作業がはかどらず、正しくないやり方に思えるからです。
・メモをとる
・印をつける
・変更の影響の理解
これから行いたい変更の影響を理解したい場合、影響スケッチ作成する代わりに変更しようとするコードに印をつけます。
実践できること or 感想
感想
率直に言えば、現状では本書の内容を実践することは難しいと感じました。そもそもテストコードを書く時間的余裕がない現場では、すぐに適用するのは現実的ではありません。
ただし、本書の内容には価値があると考えています。実践するには、テストによる効果を数値化するなど、経営層やチーム全体に価値を示す工夫が必要でしょう。将来のために知識として習得しておくことは重要だと思います。
実践すること
- 実案件に適用可能なテストフレームワークの調査
- 既存プロジェクトにおける仕様化テストの有無を確認
- データベースを含むE2Eテストの実装方法を調査
- レガシーシステム改善ガイドを読む