アドバイス：新しく油注がれたチームのリードを、ゼロからコードベースを作成しないように説得する方法

私はかなり有名なMNCで働いており、私が働いているモジュールは新しい「リード」に割り当てられています。コードベースは非常に巨大（130K以上、他のモジュールとの相互依存関係がある）ですが、安定しています-いくつかの部分は長年にわたって醜く成長していますが、おそらく動作状態にあります。（私たちの製品は、新しい製品でも、何年も稼働しています）。問題は、リードが「細かい粒度とプロアクティブな設計」を網羅するようにコードをゼロから書き直したいということです。

私は直感的にそれがあまり良い考えではないことを知っていますが、彼/チームの他のメンバー（何年もの経験より私よりもはるかに年上です）に、自分をあまり見慣れないように説得するにはどうすればよいですか（あなたはすべきではありません） Joel et alはそれを禁止する明確な記事を持っているので、書き換える）？

私は関係者と良好な関係を築いており、それを台無しにしたくはありませんが、今後何年にもわたって間違いなく私たちを悩ませる決定に参加したくもありません!! より穏やかで、まだ効果的なアプローチに対する提案はありますか？あなたがそのような状況にあなたの好みにどのように取り組んだかについての説明でさえ、私を大いに助けてくれるでしょう！

編集：私が話しているコードベースは製品/ GUIではなく、製品のすべての重要な機能を備えたカーネルレベルです。私はなぜあなたが私がそんなに不安に聞こえるのか知っているといいのですが！

彼と一緒に数学をしてください：

借金側：

• 現在持っている機能を再現するのにどれくらい時間がかかりますか。それはいくらかかりますか（開発者+オーバーヘッド）

• 新しい機能やバグ修正を導入できなかった場合、またはそれよりもはるかに遅い速度でしか導入できなかった場合、会社はどれほどの損失を被りますか？

• nか月後に書き換えを完了できず、現在のソースベースにフォールバックするリスクは何ですか？製品を一緒に殺すリスクを含みます。

• 新しいコードベースが現在のコードベースと同じくらい醜くなるまでどれくらい時間がかかりますか？

資産側：

• 書き換え後のコードの改善度（節約されたメンテナンスコスト/月で測定）

それをすべて追加し、おそらく最良/最悪のシナリオ比較を行います。

最後に答えがあります。答えを無視した場合は、上司に相談してください。

必須：してはいけないこと、パート1（あなたはそれを見てきましたが、誰かがこの質問を見つけて、見つけていない場合に備えて）

ゼロから書き直すことは、開発者にとって非常に魅力的です。誰もがレガシーコードに取り組みたくありません。誰もがセクシーな新しいコードを書きたいと思っています。しかし結局のところ、それはビジネスに最適なものについてです。なぜ書き換えが必要なのですか？彼らはビジネスに付加価値を示す明確な方法でそのケースを提示できますか？

リソースを使わないように説得する必要はありません。彼らは会社にリソースを使うように説得する必要があります。

テストアプローチはコードベースをどの程度カバーしていますか？単体テストはどうですか？

そこにまだ到達していない場合は、コードを一度に1つのセクションだけ書き換えるようにし、書き換え中のセクションはほぼ完全（90％+）の単体テストコードカバレッジにすることをお勧めします。これを行うと、コードの一部が定義され、両方とも明確に定義され（テストできます）、既知のインターフェースも含まれます。

その時点で、そのコードを書き換えることははるかに低いリスクです。間違いは単体テスト/その他のテストで捉える必要があり、ソース管理も持っていると仮定すると、簡単に元に戻すことができます。

小さなチャンクで書き換えを行うことで、あなたとあなたのチームの両方が、より正確に完全な書き換えの感触を持つことができます。どちらもあなたが何をしているのか知っていますか？あなたの1人は悲観的/楽観的すぎますか？

考慮すべきいくつかの関連要素があります。

• ユーザーの希望どおりに機能しているという事実は、リライトではなくリファクタリングの兆候です
• 単体テストがある場合は、書き直すのではなく、必ずリファクタリングしてください。そうでない場合は、リファクタリングとリライトの間の労力が平準化されます（最終的なシステムの単体テストを行うことが目標であると想定しています）。単体テストがなく、すべてのコードがGUIレイヤーにある場合、特に機能がほとんど壊れている場合は特に、書き換えが速くなる可能性があります。それが私の経験です。
• プラットフォームを完全に変更することが目的である場合（アンマネージコード-> .NETまたはWindows-> LinuxまたはPHP-> pythonなど）、それは書き換えをサポートする明白な議論です。

いやだっていうだけだよ。" 説得力がありますが、「そのメリットについて間違っているだけでなく、人間の労力を浪費しているので間違っています」と言ってもかまいません。

書き換えのビジネスケースはどこですか？あなたはニーズを満たすコードベースを持っています。確かに、それは完璧ではないかもしれませんが、時間とリソースの面でかなりの投資を表しています。完全な書き換えが保証されるのは、コードの品質が非常に悪いために組織がお金やビジネスチャンスを失う場合だけです。古い格言を覚えておく必要があります。壊れていなければ、修正しないでください。

在庫のショーツをできるだけ多く購入してください。経営者が自殺することに同意する場合、少なくともあなたはそれからいくらかお金を稼ぐべきです。結局のところ、あなたは彼らが戦車に乗った後すぐに通りに出ます。