私は本質的に衝動的なコーダーであり、プログラミングの難しい方法で忍耐の美徳を学び始めました。私がうまくいかない分野の 1 つは、既存のコードを変更するときです。すべての詳細を目の前に配置していないと、回帰につながることがある特定の方法を必ず見逃してしまいます。私はコーディングは大丈夫ですが、「実装パターン」を読むまでコードのメンテナンスを過小評価していました。
それで、私の質問は、既存のコードを維持している場合、どのようにしてすべてのベースをカバーし、穴を残さないようにするのですか? コードが壊れる可能性がある場所がわからない場合に使用する戦略は何ですか?
簡単に言えば、単体テスト。変更を行ったときにテストを再実行して、何も壊れていないことを確認するには、テスト カバレッジが必要です。
継続的インテグレーションを行っている場合、これはチェックイン時に表示されます。変更が小さいこと、およびバグの原因を簡単に追跡できることを確認するために、早い段階で頻繁にチェックインします。
頭痛の種は、単体テストを既存のフレームワークに改造することです。依存関係の注入とモック化を可能にするために、おそらく既存のライブラリの一部を再設計する必要があります。残念ながら、これらの変更を行うだけでもリスクがないわけではありません。これはすべて、できるだけ早くテストを作成する (およびコードをテストしやすいように設計する) ことを示しています。
いくつかのエッジ ケースを把握できれば、いくつかの単体テストを作成できます。次に、変更後、テストがまだ合格していることを確認できます。
絶対確実というわけではありませんが、何もしないよりはマシです!