最初にSQLをリファクタリングしますか?あなたのアーキテクチャ?またはあなたのコードベース?言語を変更しますか?すべてを捨ててゼロから始めますか?[リファクタリングではありません]
2 に答える
大規模なレガシー スパゲッティ コードベースに単体テストを追加しています。
私のアプローチは、問題を解決するように求められたとき、コードベースの現在のタスクに関連する部分の周りに新しいラッパーを作成しようとすることです。この新しいラッパーは、TTD を使用して開発されています (最初にテストを記述します)。単体テストされていないレガシー コードを呼び出す場合があります。また、既存のモジュールの新しいコピーを作成し、それに深刻な暴力を加え始めることもあります。機能をゼロから書き直すこともあります。
しかし、私はそれをかなりよくテストし続けているので、かなりコントロールできていると感じています.
あまりにも多くのコピーと貼り付けで開発されたこのコードベースで私が見つけたのは、特定の部分を理解すると、そこからいくつかの機能を抽出することです(テストファーストで行われます)...これら関数は多くの場合、他の多くの場所で使用できることが判明するため、レガシー コードを独自の単体テスト済みライブラリに置き換える割合が増加します。
現在の問題 (通常は修正しようとしているバグ) に影響されていないコードの部分を書き直したり、テストを追加しようとはしません (また、その権限もありません) が、かなり積極的な積極的な姿勢をとっています。触れられ、関連する可能性のあるものすべてについて。
更新 : Penguinix は次のように尋ねました。
今、私は...ええと...おたふく風邪で働いています!しかし、同じ原則はどこでも機能します。
UT に対する私の理解を変えたのは MinUnit でした: http://www.jera.com/techinfo/jtns/jtn002.html
MinUnit を見たとき、それは一種の「禅」の悟りの瞬間でした。ユニットテストは洗練された OO フレームワークを必要とする複雑なものであるなど、私が持っていた誤解を取り除きました。約3分で、好きな言語で自分で書くことができる「ハーネス」。ただ乗ってそれをしてください。
これは本当にコードベースの状態に依存します...大規模なクラスはありますか?メガメソッドを持つ1つのクラス?クラスは緊密に結合されていますか?構成は負担ですか?
これを考慮して、「レガシーコードを効果的に使用する」を読み、問題を特定し、推奨事項を適用することをお勧めします。