アドバイス：コードベースを最初から作成しないように、新しく無邪気なチームリーダーを説得する方法
私はかなり有名なMNCで働いており、私が働いているモジュールは新しい「リード」に割り当てられています。コードベースはかなり巨大です（〜130K以上、他のモジュールへの相互依存関係があります）が、安定しています-一部の部分は何年にもわたって醜くなりましたが、おそらく動作状態です。 （私たちの製品は、新しいものでさえ、何年もの間それらで実行されています）。問題は、私たちのリードがコードを書き直したいということですゼロから、「より細かい粒度とプロアクティブな設計」を網羅するように。
私は自分の内臓でそれがあまり良い考えではないことを知っていますが、彼/チームの他のメンバー（何年もの経験よりもはるかに私よりもはるかに年上です）を説得するにはどうすればよいでしょうか。 Joel et alがそれを禁止する明確な記事を持っているので、書き直してください）？
私は関係者と良好な関係を築いており、それを台無しにしたくはありませんが、yearsが来るのを確実に悩ませる決定に参加したくもありません!!より穏やかで、しかし効果的なアプローチのための提案はありますか？あなたがこのような状況にあなたの好みにどのように取り組んだかについての説明でさえ、私を大いに助けてくれるでしょう！
編集：私が話しているコードベースは製品/ GUIではなく、カーネルレベルであり、製品のすべての重要な機能を備えています。なぜ私がとても心配そうに聞こえるのかをあなたが知っていることを願っています!!
彼と一緒に数学をしてください：
借金側：
現在の機能を再作成するのにどのくらい時間がかかりますか。それはいくらかかりますか（開発者+オーバーヘッド）
新しい機能やバグ修正を展開できなかったり、もっと遅い速度でしか展開できなかったりすると、会社はどれほどの損失を被りますか？
nか月後に書き換えを完了できず、現在のソースベースにフォールバックできないリスクは何ですか？製品を一緒に殺してしまうリスクを含みます。
新しいコードベースが現在のコードベースと同じように醜く見えるまで、どのくらい時間がかかりますか？
資産側：
- 書き換え後のコードはどれだけ良くなるか（1か月あたりの節約されたメンテナンスコストで測定）
それをすべて追加し、おそらく最良/最悪のシナリオ比較を行います。
最後にあなたは答えを持っているでしょう。彼が答えを無視した場合は、上司に相談してください。
必須： 絶対にしてはいけないこと、パート1 （あなたはそれを見てきたが、誰かがこの質問を見つけて、見つけていない場合に備えて。）
ゼロから書き直すことは、非常に開発者にとって魅力的です。誰もレガシーコードに取り組みたくないし、誰もがセクシーな新しいコードを書きたいと思っている。しかし、結局のところ、それはビジネスにとって何が最善かということです。なぜ書き換えが必要なのですか？彼らはビジネスに付加価値を示す明確な方法でそのケースを提示できますか？
あなたはそれらにリソースを費やすことを説得する必要はありませんではありません。彼らは会社にtoリソースを使うよう説得する必要があります。
テストアプローチはコードベースをどの程度カバーしていますか？ユニットテストはどうですか？
そこに記載されていない場合は、コードを一度に1つのセクションのみで書き換え、書き換え中のセクションでほぼ完全な（90％以上）単体テストコードカバレッジを実現することをお勧めします。これを行うと、コードの一部が定義され、両方とも明確に定義され（テストすることができます）、既知のインターフェースも含まれます。
その時点で、そのコードを書き直すことはリスクがはるかに低くなります。ユニットテスト/その他のテストで間違いを見つける必要があります。ソース管理もあると仮定すると、簡単に元に戻すことができます。
小さなチャンクでリライトを行うことで、あなたとあなたのチームの両方が完全なリライトの感触をより正確に得ることができます。あなたは両方ともあなたが何に入っているのか知っていますか？あなたの一人はあまりにも悲観的/オプティミスティックですか？
考慮すべきいくつかの関連する要因があります：
- ユーザーの希望どおりに機能しているという事実は、書き換えではなくリファクタリングの兆候です
- 単体テストがある場合は、書き直すのではなく、必ずリファクタリングしてください。そうでない場合は、リファクタリングとリライトの間の労力が平準化されます（結果のシステムの単体テストを行うことが目標であると想定しています）。単体テストがなく、すべてのコードがGUIレイヤーにある場合、特に機能がほとんど壊れている場合は、書き直しが速くなる可能性があります。それが私の経験です。
- プラットフォームを完全に変更することが目標である場合（アンマネージコード->。NETまたはWindows-> LinuxまたはPHP-> pythonなど））、それは書き換えをサポートする明白な議論です。
断ってよ。"説得力がありますが、「あなたはその利点について間違っているだけでなく、人間の努力を無駄にしているので間違っている」と喜んで言います。
在庫のショーツをできるだけ多く購入してください。経営陣が自殺に同意した場合、少なくともあなたはそれからいくらかのお金を稼ぐべきです。結局のところ、彼らは戦車に突入した後、すぐに通りに出ます。
書き換えのビジネスケースはどこにありますか？ニーズを満たすコードベースがあります。確かに、それは完璧ではないかもしれませんが、時間とリソースの面でかなりの投資を表しています。完全な書き換えが保証されるのは、コードの品質が非常に悪く、組織がお金やビジネスチャンスを失う原因となっている場合だけです。古い格言を覚えておく必要があります。壊れていない場合は修正しないでください。