「レガシーコード改善ガイド」のススメ 第2回：コードを理解するため、仕様化テストで文書化する

増え続けるレガシーコード この記事を読んでいる皆さんの多くは、これまでたくさんのシステム開発に関わってきたことでしょう。仕様変更と闘い、納期に追われ、やっとのことで稼働したシステムも数多いはずです。厳しい状況になればなるほど、実際にコードを動かすことが最優先になり、「コードを保護する」ための単体テストの整備は後回しになってしまいがちです。 ところが、システム開発はシステムが完成して無事に稼働した時点で終わりではありません。ユーザーが実際に使い始めると、保守開発としてさまざまな仕様変更や機能追加が発生するのが常です。それらに対応するためには、厳しいスケジュールの中で、やっつけ仕事で間に合わせたコードに対して改修や機能追加をする必要があります。では、このような仕事にどうやって取り組めば良いのでしょうか？ さて、前回の記事では、『レガシーコード改善ガイド』におけるレガシーコードの定義を紹介しまし

[iga_k]

「仕様化テスト」 テストを書いて仕様を把握していく手法 by レガシーコード改善ガイド

[inouetom]

仕様化テスト

[yuki_2021]

テストがないのは悪いコード

[bobbyjam99]

"コードを「あるべき姿」に変更することより、まずは現状を受け入れてテストを整備することが重要"

[matsutakegohan1]

まあ、これしかないよね。