『レガシーコード改善ガイド』再入門〜 技術的負債とダンスを(5) – 時を超えたプログラミングの道

前回までは、『レガシーソフトウェア改善ガイド』を参考に、改善のゴールのすり合わせや設計改善の進む道のヒントとなるリファクタリング、リアーキテクティング、ビック・リライトを紹介しました。今回からは、『レガシーコード改善ガイド』を取り上げていきます。 テストがないコードはレガシーコード『レガシーコード改善ガイド』は、コードや設計の腐敗が始まったコードへの向き合い方を著者の経験をもとに整理されています。「テストがないコードはレガシーコード」の力強い言葉とても有名です。 テストコードがなければ、修正の際に期待通り動作するか否かや今までの振る舞いが壊れたのか否かの判断が難しくなります。日々の小さなリファクタリング活動も怖くて実施困難です。ユニットテストを考慮した設計となっていないためユニットテスストの実施が難しくなりがちです。その結果、機能修正や障害解析に苦痛と共に多くの時間を割く羽目になります。

[hate7bookmar9]

自動テストがあることのメリットについて。

[amapyon]

「レガシーソフトウェア改善ガイド」と「レガシーコード改善ガイド」で何を対象としているかの違いが分かりやすい。

[flowz]

"テストがないコードはレガシーコード"