悪いコードベースでアプリケーションが構築されていることを証明する方法は？

私は現在、私の仕事で以前働いていたいくつかの開発者によって構築されたシステムをレビューしています。システムはユーザーの観点からはかなりうまく機能しますが、コードレビューを掘り下げると、まったく混乱します。私は、アプリケーションの構築方法が将来の更新に耐えられず、使用量が大幅に増加することはないと確信しています。

問題は、それがどれほど悪いかは知っているが、上司はそうではないということです。マネージャーにそれを証明して問題を実際に確認し、現在のコードベースで最小限のトリアージを行い、近い将来、アプリケーションの次のバージョンの新しい開発ラインを開始できるようにするにはどうすればよいですか？

「しかし、今では機能します」は、ソフトウェアエンジニアの合法的な不満に対する標準的な管理対応です。最初に行うことは、ドキュメント（ある場合）をコンパイルし、それを使用してコードとドキュメントの矛盾を示すことです。

可能であれば、単体テストの包括的なスイートをまとめます。変更ごとにこれらを実行して、既存のコードベースに原因があると思われるリグレッションを文書化できるようにします。

最後に、信頼できる仕事をしている別の部門から開発者を引き入れることができるなら、コードに目を向けてください。「これはがらくただ」と言っている開発者の1人は、しばらくしていた上級開発者が「いいえ、ジム、彼は正しい。これはがらくたクラッカーのがらくたです。」

もちろん、それはすべてあなたの環境、会社の規模などに依存します。

まだ読んでいない方は、The Pragmatic Programmerをご覧になることをお勧めします。すべてのソフトウェアプロフェッショナルが読む必要があるだけでなく、ソフトウェアエンジニアリングをクラフトと見なしていない管理者、同僚、ユーザーなどに対処するための良い提案もあります。

経営者の観点からは、システムに何も問題はなく、単に文句を言っているだけです（単に書き直したい/前のエンジニアが何をしたのか理解できない/仕事を楽にしたい）。少しストローマンですが、トップの誰かが現在物事がうまく機能していることに気付いたとき、彼らはあなたがする危機を見ることに気が進まないでしょう（どこかに気候変動のeg話があると確信しています...） 。

ある程度、彼らはポイントを持っています。経営陣は、リリースが当初の見積もりをはるかに超えると問題を認識し、見積もりは高すぎて「既存のコードベースでは不可能」であり、QAをすり抜けるバグの発生が多いようです。物事がうまく並んでいる場合、最終結果に影響を与えないため、頭を軽く叩いて、最善を尽くすように言うのは簡単です。

何をするかは、組織とソフトウェア自体に依存します。ただし、基本的には、古いレガシーコードの結果として発生するすべての複雑さを文書化することをお勧めします。タスクを見積もる際に、古いコードベースのどの側面がこの余分なコストを追加しているのかについて詳細に説明し、なぜそれほど長くかかると思われるのかを管理者に明確にしてください。バグがコードに導入された場合、このバグが入り込むことができた理由と、古いコードベースの問題がどのように責任を負うかを含めてください。

ソフトウェアが元の設計を超えており、現在も拡張を続けるのに問題があることを示唆する方法で、利害関係者に懸念を表現することをお勧めします。

コードカバレッジとコードレビューを実行できるさまざまなツールがあります。テクノロジーに適したGoogleツール。通常は業界標準のツールです。これらのツールを使用してコード品質レポートを作成し、Managerに提示することをお勧めします。あなたの批判が建設的で非政治的であることを確認してください。

管理が単純な変更要求であると考える場所を理解しやすい例を選択しますが、既存の設計のためにそれははるかに困難です。

特定のリクエストにこだわるのは望ましくありませんが、これは変更のリクエストがどのようなものになるかを伝えてください。誰もアプリケーションで隅に描かれることを望みません。開発者はYAGNIを信じていますが、経営陣はCYAを信じています。

負荷テストの提案は良いアプローチかもしれませんが、使用上の懸念が現実の世界の成長の可能性を満たすことを確信していないかもしれません（会社は1年で2倍になることはありません）。

すべては相対的です。彼らはあなたの時間を費やすより重要なプロジェクトの計画があるとき、彼らはこのプロジェクトにリソースを入れたくないかもしれません。全体像が見えないというラベルを付けないでください。

何かを証明することについて話すとき、すべての科学的方法が作用します、そしてそれが意味することの一部は、あなたが真実を決定する客観的な基準を受け入れようとするなら、あなたは、調査時に、それらの迷惑な事実の可能性を受け入れなければならないということですあなたの側にいないことが判明。

あなたの場合、2つの証明すべきことがあると思います。

まず、現在のコードベースが「不良」であること。おそらく証明できるのは、「このコードを検討するほとんどすべての開発者の専門的な意見は、それが悪いということです」ということです。

第二に、会社はコードベースを書き直したほうが良いだろう。これは問題です。最初の点が真であっても、2番目の点は真ではないかもしれないからです。また、この決定を下すのに十分な知識がありません。これは経営陣の仕事であり、最初の点についての専門的な判断を尊重する場合は、2番目の点について彼らの判断を尊重する必要があります。

しかし、彼らはあなたが提供する情報なしでは二番目の点について決定することはできません。コードの問題がビジネスに与える影響について知っていること、および書き換えがビジネスに与える影響について知っていることを伝える必要があります。どちらも、多くの不確実性のある未来の予測を伴うため、これは困難です。

しかし、ビジネス用語で問題を述べることを試みることができます。変更とリグレッションにどのくらいの余分な時間がかかりますか？書き換えコストはいくらですか？書き換えられない場合、現在のシステムのコストは時間の経過とともにどれほど速く上昇しますか？使用量が増えた場合、現在のコードが保持されていると災害の可能性はどうなりますか？これを本当に知ることはできませんが、他の誰よりも良い推測をすることができます。これらのことを予測できると思う範囲を伝えるか、何かを伝えてください。

ほとんどの開発者は、お粗末なコードを維持することを好みません。開発者の観点から書き直すのが簡単なコードがビジネスの観点から書き直す価値がないのは残念なことです。

たとえば、書き直しが利益を上げたとしても、会社の他の場所でお金を使う機会費用よりも価値が低い場合があります。または、悪いコードベースは変更に時間がかかり、より多くのリグレッションが発生する可能性がありますが、リライトを収益化するには不十分です。彼らは今後数ヶ月で買収されることを期待しているかもしれず、書換えにお金を使うことは本に現れますが、バグのあるソフトウェアは現れません。

ビジネスの観点からそれについて考えてみてください、そしてあなたが望むものを得るために数字を調理しないでください。大規模な書き直しは、ビジネスの観点から見れば簡単なことではありません。直接証明できないものを証明したい場合は、それを反証するために最善を尽くしてください。あなたが方法を考え出すために最善をしようとし続ける場合ではないゼロから書き直しませんが、あなたが作る感覚を思い付く何もする、多分それから、それは本当にゼロから書き換えるための時間です。そして、その努力をすることは、あなたの経営者にあなたがあなた自身ではなく会社の利益を代表することに真剣であることを示します（あなたはあなた自身ではなく会社の利益を代表していますよね？）。

コードベースのどこが悪いのかによると思います。「自分のやり方ではない」ということは、それが悪いコードベースであることを意味するものではありません。

実際に悪いコードベースを作るもの：

• セキュリティホール

  サーバー、アプリケーション、および/またはデータを脆弱にする問題。特に、機密の会社、クライアント、または顧客データを危険にさらすもの。これらは簡単に文書化できるはずです。

• 壊れた

  データを処理し、アプリケーションのメンテナンスをほぼ継続的に実行して、それが機能し続けるためにのみ機能します。あなたが去り、誰もスラックを取り上げなかった場合、それはもはや機能しません。-これに費やした時間を記録します。そして、どれだけ節約できるかに注意してください。多くの場合、これらのプロセスはユーザーにとっても非効率的であり、文書化することもできます。

• 実際には機能しません

  動作しているように見えますが、結果は正しくありません。これは通常、数字が一致しない、高い不良率などの問題を引き起こします。

悪いコードベースではないもの（ちょうど良くない）：

• 時代遅れのサポートされていない技術に書かれています。（VB6、COBOL、.net1.1など）

新しいテクノロジーに移行する利点に注意してください。リスクを最小限に抑え、ユーザーと管理の信頼を構築できるように、一度にピースを移動する移行パスを見つけてください。ロジックが元のロジックと基本的に同じように機能することを確認してください。

• 文書化されていない/フォーマットが不十分なコード

一般に、実際にコードに影響を与えずにコメントを追加し、フォーマットを修正できるため、これが最も簡単に修正できます。ただし、書き換える必要はありません。これが他の問題と組み合わされていると感じた場合、最初にすべきことはこれを修正してコードの実行可能性をよりよく評価できるようにすることです。

ある方法であなた自身の質問に答えました。

システムにお金を使うように彼らを説得する方法は、ユーザーにとってうまく機能しなくなるまで待つことです。スケールしないと思われる場合は、それが起こるのを待つか、負荷テストを行ってそれを証明します。

これは、これをスケーリングしてX時間かかるという単純な提案です。

これは困難な状況です。ユーザーの観点からすれば、すべてが現在許容できる安定したポイントにあるからです。主に非技術系の管理者にとっては、現時点では心配する必要はありませんが、コードベースの書き直しを求めることは非常に大きな決断であり、特に独身者（自分）の意見や努力について軽視すべきではありません。

ですから、技術的な負債が圧倒的であるため（あなたの意見では、例はなく、あなたの言葉を受け取らなければならない）、タフな場所にいるため、書き換えを主張しようとするタフな場所にいますこのシステムに機能を維持したり追加したりするのが難しいこと。

新しい機能の見積もりは高く、これらの高い数値を事実で正当化し、これらのことは実際にかなりの時間がかかることを証明します。これを適切に伝えない場合、上司はあなたを無能だと思っているだけかもしれません。彼が高い見積もりに疑問を呈したとき、蓄積された技術的負債が現在のソフトウェアに迅速かつ安価に機能を追加する能力を妨げていると感じる理由を説明します。マネージャーが一緒にこする2つの脳細胞を持っている場合、マネージャーはすぐに理解し始めます。

重要なのは、マネージャーを説得しようとするのではなく、書き換えが受け入れられるコースであることを自分自身に納得させることができる適切な（そして慎重に選択された）情報でマネージャーを操作することです。マネージャーに、自分の考えだと思わせる必要があります。

まず、コードベースに蓄積された技術的負債を判断します。次に、この質問と回答を見てください。さらに先に進む前に、経営者に技術的負債を返済するよう説得する方法が説明されています。

すべての成熟したソフトウェアが混乱のように見える理由があります：

1. すべての混乱は、ビジネスが依存している重要なロジックをエンコードしています。それなしでは機能しません。ユーザーの問題を解決するには、そのすべてが必要でした。
2. 少し時代遅れの技術を使用しています。現在のプログラマーは、テンプレートマジックを使用しない場合、それは単なる混乱であると考えているようです。これは壊れたビューです。より大きなプロジェクトに遅れて来る人は、すべての詳細を学びながらこの段階を迎えます。
3. しばらく前に重要だった要件は、それほど重要ではなくなりました。これは、ソフトウェアがすでにこれらの問題を修正したためです。プロジェクトに遅れて来ると、ソフトウェアは正当な理由もなく複雑であるように見えるかもしれません-問題はもはや存在しませんが、コードの複雑さはまだそこにあります。