コードのリファクタリング時間を正当化する方法は？

70k LOCを超える非常に大きなプロジェクトがある。

このプロジェクトでは、コアフレームワークやその他の部分でもコードリファクタリングが必要です。プロジェクトの開始時にリファクタリングの時間が設定されていませんでした。しかし、時間の経過とともに40人以上の開発者が共同でプロジェクトを去りました。私の観点からは不可欠です。

適切なソフトウェア開発の原則を主張し、擁護する上であなたの重要なポイントは何ですか？

レガシーまたはブラウンフィールドのアプリケーションで作業するとき、すべてを形にリファクタリングすることを望んで「春の大掃除」をするのは魅力的です。それは決してリソースの正当な使用ではありません。結局のところ、動作中のソフトウェアの開発を停止するにはどうすればよいのでしょうか（動作中のコードのみリファクタリングできます）。ビッグリファクタリングフェーズに費やされた時間が後で成果を上げ、プロジェクトの縮退を引き起こさないことを保証できますか？

象はどうやって食べますか？一度に一口。新しい機能を実装したりバグを修正したりする必要があるときはいつでも、その部分の改善が必要かどうかを確認できます。ボーイスカウトのルールが言うように：「あなたが見つけたよりも常にキャンプ場をきれいにしておきます。」リファクタリングは独立したフェーズではなく、毎日の開発の一部です。

この品質の文化を開発チームに導入すると、品質が向上します。その後、経営者を正当化するものは何もありません。

一般に、リファクタリングは、コードに必要な別の変更を有効にするために、またはコードに変更が加えられた後の自然なクリーンアップ手順として実行する必要があります。その場合、正当化するものは何もありません。リファクタリングは、プロジェクトで作業を行うプロセスの一部にすぎません。時間は、リファクタリングを行ったときに作業していたタスクに請求されます。

それが少しずつ行われていない場合、実際にはリファクタリングされていませんよね？

ここにすべての良い答えがあります-しかし、私はこれにビジネス次元を追加することができます。私はあなたを聞いてみようWHY / SO-何？（あなたのとがった髪のボス（PHB）を考えてください:)

PHB：なぜですか？
あなた：物事を簡単に修正できます
PHB：それで？
あなた：スループットが向上します-新しいビルドがすぐに出ますか？
PHB：それで？
あなた：Err ... Happier customers？
PHB：WTF？
あなた：推奨事項の増加、満足度の向上、 
     ターンアラウンドが低いため、より早く利益を上げる
PHB：ああ！いいね。しかし、それは「音」だけが見られますか？
あなた：WTF？
PHB：お金を見せて！（つまり、数字をください）
あなた：ああ！Brb ...（ケースを作成するために、簡単なスプレッドシートに数字を入力してください）

基本的に、ビジネスケースを作成する必要があります。いくつかの数値を実行して思考プロセスを明確にし、数値が客観的に「メリット」を反映するようにします。また、どれくらいの時間がかかるか、おおよそのコストなどもわかります。それは理にかなっているはずです。それが価値があるなら、あなたは緑のシグナルを受け取り、多分イニシアチブを先導するでしょう:)

どうやってすべてを測定できるのかと思ったら、この本を試して

リファクタリングは、他のアクティビティと同様に、明確な目標を定義する必要があります。その目標が明確になったら、現在のプロジェクトのステータスとライフサイクルの段階を検討します。80％完了し、30％遅れている開発プロジェクトの場合、目標セットに基づいてリファクタリングの努力を正当化する必要があります。この例では、コード部分が単体テストされ、開発環境で正常に動作している場合、リファクタリングを正当化することは困難です。

40人の開発者が去ったという事実は、見た目ほど劇的ではないかもしれません。これらの開発者は、レビューおよびテストされた実用的なコードを提供していると期待しています。したがって、このコードに既知の問題がない限り、そのままにしておきます。アイデアは、あなたのような大規模なプロジェクトでは、標準と手順があり、コードが完全な混乱ではないことを期待しているということです。

リファクタリングを行うと、行われたすべてのテストではなくても多くのテストが繰り返されることに注意してください。また、このサイズのリファクタリングは1〜2人のシニアメンバーが行うことはできないため、リファクタリングは存在しない問題を引き起こす可能性があります。これは無視すべきではないリスクです。

そうは言っても、不測の事態が発生したときにプロジェクトにタスクを追加することは珍しいことではありません。したがって、何らかの理由で開発者が姿を消した場合、それは特別な性質のイベントと見なされ、状況を改善するためのあらゆるアクションを実行する必要があります。火事や地震などのように扱われます。

要約すると、十分な技術的理由がないため、大規模なプロジェクトで大規模な作業コードをリファクタリングすることはありません。特に、ほとんどのプロジェクトは通常後期の状態にあることがわかっています。

あなたが長くて巨大な壁の前にいると想像してください。あなたは反対側に行く必要があります。

ドアを構築するために壁をリファクタリングするか、それを回避します。

両方のソリューションの時間を見積もると、リファクタリングの正当性が得られます。

2番目のソリューションの時間に、壁の向こう側に行く必要がある人数を掛けることを忘れないでください。

私が他の答えの一つで読んだように、この象を一度に一口ずつ食べてください。チームメンバーが地理的に分散している大規模な国際プロジェクトの監査に携わっています。ソフトウェアの最初の2つのバージョンを構築した後、チームは、アプローチ、コーディングのスタイル、およびソリューションの構築に一貫性がないことに同意しました。彼らは、新しいルールと規則に従ってアプリケーションの新しい部分を書くことに同意し、古いコードの一部を変更する必要があるとき（そしてそのときだけ）、新しい規則に合わせて最初にリファクタリングします。すべてがうまく機能しています。リファクタリングプロセスはほぼ5か月目で、コードの一部はリファクタリングされ、一部はまだリファクタリングされていません。新しい機能が間に合うようになり、クライアントは満足し、開発者は満足し、QAチームも満足します。双方にとって好都合な状況:)

リファクタリングの主なポイントは、将来的に物事を簡単にすることです。リファクタリングを頻繁に行ったり、一定のリファクタリングを行わなかったりする複数の長期プロジェクトを比較しない限り、リファクタリングの利益を示すことはできません。一般的に、開発者はリファクタリングによってメンテナンスと変更の実装のコストが削減されることを受け入れていますが、それらをビジネスの観点から証明することは困難です。リファクタリングを実装する主な理由は、技術的負債を減らすことです。

また、リファクタリングは継続的なプロセスであり、リファクタリングに費やされる時間は開発タスク自体に含める必要があります。特別な「リファクタリングタスク」を持つことは良い考えではありません。