大規模なレガシーコードベースを更新して特定の品質基準を満たすにはどうすればよいですか？

レガシーコードベースを改善するためのツールとテクニックについては多くの情報がありますが、実際に成功したケーススタディはありません。ほとんどのアドバイスはミクロレベルであり、マクロレベルで役立つ証拠が不足しているため、役立つものの、多くの人々を納得させるものではありません。

大規模なレガシーコードベースを更新して今日の品質基準を満たすようにし、完全に書き直すのではなく、実際に成功することが証明されている段階的な改善を具体的に探しています。

前：

• 大：1MLOCより大きい
• レガシー：自動テストなし
• 品質が悪い：複雑度が高く、カップリングが高く、回避された欠陥が多い

後

• 自動テスト
• より簡単なアップデート/メンテナンス
• 高品質：複雑さの軽減、コードの分離、少数の回避された欠陥

大規模なレガシーコードベースを完全に書き換えずに、上記の品質基準を満たすように正常に更新するために、実際にどのような段階的な手順が証明されていますか？

可能であれば、バックアップの回答に「成功した」品質改善プロセスを経た大規模なレガシープロジェクトの会社または事例の例を含めてください。

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052のような本は、業界で広く、レガシーな低品質のコードベースがどれほど一般的であるかを十分に示すべきです。

なぜあなたが聞いたことも見たこともないのか、そしてもっと重要なことに、自分で作業するまでそれらについて聞いたことがないのではないかと私は推測します。ベースは、些細な影響に直面することなく、上記すべてでした。

これはあなたが話す研究の不足を説明するかもしれません。たとえば、Peter van der LindenのDeep C Secretsなど、十分な数の本を読むと、約100万ドルのバグが表示されます。

注：これをコメントにしたかったのですが、長すぎました。これでは質問に完全には答えられないことを理解しています。

編集：C ++ 11＆GCCの長期的な実行可能性が疑問視されています -開発者がGCCをリファクタリングし、LLVM / clangとしてよりツール化できるようにする場合、それは良い例となるでしょう。ディスカッションでは、ドキュメントが不十分な場合があり、新しい開発者の参入障壁が高くなっている場合があります。

2013年2月3日、LibreOffice開発者の1人であるMichael Meeksが数日以内に「LibreOffice：巨大なコードベースのクリーンアップとリファクタリング、またはなぜそれを書き直すのがさらに悪いのか」 」 それはまさにあなたが求めているもののように聞こえます：彼らが何をするために彼らが何をしたかについての議論 "ユニットテストがなく、複雑なビルドインフラストラクチャ、そして25のドイツ語で広くコメントされている巨大なコードベース未払いの技術的負債の年」とそれを近代化します。

プレゼンテーションはオンラインでストリーミングでき、（おそらく）レコーディングはいつか利用可能になる予定です。

私は実際に、キャリアの中でかなり重要なリファクタリングを3回経験しています。コードは減衰する傾向があるため、コードベースが十分に長い場合、大きなリファクタリングはほとんど避けられません。私の例はすべてプライベートコードベースにあり、パブリックサンプルが見つからない理由を説明している可能性があります。

信じられないかもしれませんが、ドットマトリックスプリンターでのみ機能する基本的なアーキテクチャを備えたアプリケーションが初めてありました。私の会社がリボンを供給するベンダーを見つけることができなくなったとき、彼らは私にそれをレーザープリンターで動作させるように割り当てました。

2回目は、CからJavaへの数百の自動テストスクリプトの移行でした。これは、クロスプラットフォーム機能を改善する必要があったためと、新しいC開発者を雇うことが困難になったためです。

3回目はまだ途方に暮れています。巨大なモノリシックアプリケーションをモジュール化して、結合を減らすことでユニットテストを可能にし、クロスプラットフォームを目的としています。

山に登る努力を比較します。あなたはあなたの前にこの大きな目標を持っていますが、マクロレベルでそれに取り組むことはありません。あなたはそれを一度に一つずつ握り、常に近いフォールバック位置を持ち、次の安全装置が設置されるまで前の安全装置を決して切り離さない。少しずつ改善を始めて、しばらくして振り返ると、突然この美しい景色が見えてきます。

たとえば、高度に結合されたコードのファイルが60,000あるとします。単体テストを開始したいのですが、依存関係によって不可能になっています。どのように修正しますか？1つのファイルを分離します。自動テストを追加します。次に進む前に、安定した地面に戻ります。59,999回繰り返します。

それが単純に聞こえるなら、それはそれが単純だからです。簡単ではありませんが、簡単です。最初はどんな進歩にも気づきにくいです。不可能なリファクタリングのように見えて2年になりますが、完了するまでに何年も先を行く可能性がありますが、振り返ってみると、コードがすでにどれほど改善されているかを突然理解し、新しい機能を提供し続けることができましたその間、お客様に。

他の2回は同じように動作しました。安全な最小ステップを見つけ、それを実行して、アプリケーションを常に動作状態に保ちます。全体像について心配するだけで、正しい方向に進んでいることを確認できます。すべてのアクションは小さく、安定しており、増分的です。

数百万行のコードベースでの個人的な経験から、うまくいくように見えるいくつかの戦略を見つけました。

すべてのバグ（閉じたバグも含む）を調べて、それらをカテゴリーに分類してみてください。具体的には、それらが属しているコンポーネントによってそれらを分解することを試みます。それらが複数のコンポーネントに属している場合は、そうであることに注意してください。これを実行したら、どのバケットが最大であるかを調べ、それを使用してどこから開始するかを決定します。さらに、ファイルの変更履歴を確認して、最も変更されたものを特定し、それをどこから始めればよいかのガイドとして使用できます。基本的にあなたがしようとしていることは、最も壊れているものを見つけて修正し、繰り返すことです。さらに、すべてを同時に修正しようとするとうまくいかないことがわかりました。問題が増えるだけです。

「システム」の問題を示す複数のコンポーネントに属しているものが多く、結合が強すぎるコードまたは更新が必要なAPIを指し示している可能性がある場合。

私が多くの時間を費やしたもう1つの領域は、既存のコードベースのテストです。ここには複数の戦略があり、すべてにメリットがありますが、問題に対する完全な解決策はありません。

• ユニットテストは機能しますが、多くの場合、緊密に結合されたコードにより、ユニットテストできるものに制限されます。ただし、可能な場合はそれを行ってください。
• 外部テストは別の方法です。私はあなたがおそらくすでにこれを持っていると思いますし、そうでなければ私はそれを作成するのにしばらく時間を費やすでしょう。さらに、私にとってうまくいったことの1つは、システムにランダムに障害/イベントを挿入する機能を追加することです。それに加えて、複数の物を同時に注入して、新しい方法で失敗させるようにしてください。