レガシーコードベースの品質基準の低下に反対する方法は？
ここには、想像もできない悪いコードが含まれている大きなレガシーコードベースがあります。
私たちは今、いくつかの品質基準を定義し、完全に新しいコードベースだけでなく、レガシーコードに触れた場合にもそれらを実現したいと考えています。
そして、数千の違反がすでにあるソナー（コード分析ツール）でそれらを強制します。
次に、レガシーに対するそれらの違反を減らすための議論が行われました。それは遺産だからです。
議論は読みやすさのルールについてです。入れ子になったifs/for ..がいくつ入れられるかなど。
さて、レガシーコードのコーディング品質の低下に反対する方法を教えてください。
コードは目的を達成するための手段にすぎません。その目的はさまざまかもしれませんが、通常は利益です。
利益なら・・・次に、利益を改善することを示すために必要なすべてのことをうまく主張します。販売の増加、メンテナンスコストの削減、開発コストの削減、賃金の削減、再トレーニングコストの削減などにより、利益が向上することを証明できない場合それからあなたは主にそれがトイレにお金を流す楽しい方法だと言っているだけです。
私、私、そして私は、レガシーコードのプロデューサーであり、メンテナーでもあります。あなたのツールが「数千の違反」（あるいは、それに関しては数百の違反）を生成している場合、そのツールを忘れると、その状況には適用できません...
私は元の開発者が長い間いなくなっており、議論のために利用できないと思います。したがって、デザインとコーディングスタイルの理由とその理由を理解している人は誰もいません。数百または数千の違反を修正することは、あちこちに数行のコードを書き直すだけの問題にはなりません。代わりに、間違いなく、リファクタリング/再機能分解が必要です。現在の設計をよく理解せずに、既存の大規模なコードベースに対してそれを試み、まったく新しい一連のバグ/問題/その他を導入することになります。今あるワームよりもさらに悪いワームの新しい缶（または、ツールが考えるよりも悪い<<今持っているワームよりも悪い）。
「何千もの違反」に対処するための賢明なアプローチは、ゼロから書き直すことだけです。長くて費用のかかる作業であり、経営者に販売することはほとんど不可能です。そして、この場合、彼らはおそらく正しいです...
従来のコードは通常、微調整が必要です。 y2kのように、または株価が256から10進数になったとき。私はそのcr * pの両方をロードしました。そして、他の多くの同様のもの。時々悪いスタイル、悪い機能分解、悪いなどを「読み通し」、変更する必要のある場所のコレクションを見つけることができるという点で、それは通常かなり「ピンポイント」です。そして、「それらの場所の間」で何が起こるか、つまり、より高レベルの流れは何であるかは、謎のままである可能性があります。変更するローカライズされた機能を理解していることを確認してから、テスト、テスト、副作用のテストなどを行ってください。そうしないと、ローカライズされたナレッジでは予測できません。
このようなコードを使用して方法を確認できない場合は、レガシーコードを維持するのに最適な人物ではない可能性があります。一部の人々は空白の画面から始めて美しいプログラムを書くことができますが、他の人々のコードの大きなコードベースから始めてそれを維持することはできません。他の人はコードを保守できますが、ゼロから始めることはできません。一部は両方を行うことができます。適切な人々があなたのレガシーコードを維持していることを確認してください。
レガシーコードベースをゼロから再設計して書き直すことが必要になる場合は、ビジネス（またはその他の）要件が変更されて、ズボンのシートを調整するだけでは変更された要件に対応できなくなる場合があります。 。そして、その時点で、最初に新しい機能要件ドキュメントを作成して、すべての関係者が参加していることを確認することから始めてもよいでしょう。基本的にはまったく新しい球技です。
唯一の>>間違った<<すべきことは、レガシーコードのメンテナンスを、新しい開発と同じように扱うことです。そして、その1つの間違ったことは、まさにあなたが下りたいと思う道のようです:)私の言葉を取ってください、それはあなたがやりたいことではありません。
問題は、そのコードの良し悪しではありません。問題は、どれだけの投資からどれだけの利益を得るかです。
それで、あなたはそれが好きではない何千ものものを見つけるツールを持っています。ツールの結果を無視するか、何千もの物事を変えるための作業に投資するかを選択できます。それはたくさんのものです。人々は、変更を加えている間やレビューしている間ではなく、集中することはありません。また、すべての変更をテストする方法（または試してみるだけ）を理解するには時間がかかり、バグが発生するため、これは適切にテストされません。そのため、これらのバグを見つけて修正するまでは、多大な時間とお金を費やして、全体的にマイナスの結果が出ました。
一方、ツールは、「気に入らない」だけでなく、バグまたは潜在的なバグであるものを見つけることができます。レガシーコードがまだ広く使用されている場合、適切なツールで実際にバグを見つけることができます。したがって、コンパイラの警告を1つずつオンにし、それらが有用かどうか（すべてが有用ではないかどうか）を確認し、それらの警告を修正することには価値があります。
壊れていない場合は修正しないでください
これは、すべてのソフトウェア開発者およびマネージャーが実際に忘れないように、入れ墨をする必要があります。
はい、それはすべての現代のコーディング規約を破ります。はい、Cのラッパーを使用してFORTRAN-77で記述されているため、Pythonから呼び出すことができます。はい、それらは非構造化GOTOです。はい、1つのサブルーチンが3000行あります。はい、変数名はクロアチア語にのみ意味があります。などなど.
ただし、10年以上にわたって怒りの中でテストされ、合格した場合は、そのままにしておいてください。必要な変更が小さい場合は、可能な限り小さくローカルにしてください。それ以外のものは、修正する必要のない何かを壊すリスクが高くなります。
もちろん、それは実際には保守不可能なクルージであり、「小さな」変更に対応する唯一の方法は、ゼロから書き直すことであることに気付くこともあります。その場合は、変更を求めている人のところに戻って、変更にかかる費用（ドルまたは書き換えの場合は工数と、避けられない新しいバグの場合は汗と涙）を伝える必要があります。
昔、Digitalのディスクドライブの1つに障害が発生しました。彼らは結局、それらすべてを思い出して交換することになり、どの費用がかかるかを知っています。どうやら、HDA内にフィルターを保持する接着剤の塊があった。エンジニアリングマニフェストは、接着剤について「ノンパラメトリックに指定され、受け入れ可能な代替物はありません」と述べました。 Beanカウンターは、他の接着剤を調達することにより、ディスクドライブあたり1セント未満で「節約」されました。それはHDA内部の蒸気を放出し、数年の使用後にドライブを殺しました。彼が修正するまで壊れませんでした。間違いなく「それはほんの小さな変化だった...」
レガシーコードの品質レベルを下げる意味はありません。警告をすぐに修正する必要もありません。プロジェクトのすべてのコンポーネントのすべての「新しい」変更が高品質の基準に従っていることを確認してください。つまりコミットによって警告数が増えることはありません。
これは、統一された非常にシンプルなアプローチです。
これにより、古いレガシーコードがそのまま機能します（不要な変更が行われないため）。新しいコードが高品質であることを保証します。追加費用はかかりません。
リスク管理…。
- 大規模なレガシーコードベースのコードは、少なくともソフトウェアの実際の使用によってテストされています。
- 大規模なレガシーコードベースのコードが自動化された単体テストでカバーされているのは非常に嫌です。
- したがって、大規模なレガシーコードベースでコールドに変更を加えると、リスクが高くなります。
コスト…。
- コードを書いている最中にコードチェッカーを通過させるのは安いです
- 後でそれを行うと、はるかにコストがかかります
メリット
コーディング標準を守ることが、コードのより良い設計につながることを望んでいます。
しかし、誰かがコーディング標準のチェックツールから警告を削除するためだけに何週間もコードを変更することで、コードの設計が改善されることはほとんどありません。
- 単純なコードはより明確であり、理解しやすくなる傾向があります複雑なコードがそれを理解しない誰かによって短いメソッドに分割されない限り..。
推奨…。
- コードのセクションに多くのバグがあることが示されている場合、または追加の関数を追加するために多くの変更が必要な場合は、時間を費やしてその機能を理解してください。
- また、コードのそのセクションに優れたユニットテストを追加する時間も費やしてください。
- 次に、コードをリファクタリングすることを検討し（これで理解できるようになりました）、新しいコードのチェックにも合格しました。
個人的に体験…
- プログラマーとして働いている他の20年間で、新しいコーディング標準チェッカーからすべての出力を削除するように盲目的に古いものに変更することで、そうするように指示された請負業者の収入を増やすこと以外に利点があるケースを見たことがありません。
- 同様に、古いコードをコードレビューに合格させる必要がある場合（TickIt/ISO 9001は正しく行われません）、古いコードが新しいコーディング標準のように見える必要がありました。
- 新しいコードでコーディング標準のチェックツールを使用すると、継続的なコストを削減できるという大きなメリットがある多くのケースを見てきました。
- 多くの顧客がいる製品で使用されている古いコードを維持するコストに会社が失敗するのを見たことがありません。
- 市場投入が遅すぎて顧客から収入を得られないために会社が失敗するのを見てきました…。
ツールのしきい値を下げることについての議論はありますか？ ...または私はそれを誤解しましたか。わかりにくい方法で書かれています。そうでない場合は、私の答えを破棄してください。
私見では、ツールの感度を下げることをお勧めします。どうして？最も毛深いコードを強調するからです。代わりの方法は、何千もの違反を含むレポートを作成することです。
...それ以外は、関係者と話し合い、その理由も聞いてください。
古いコードを新しいクリーンなコードから分離しようと思います。たとえばEclipseでは、互いに使用する異なるプロジェクトにそれらを配置することでこれを行うことができます。 'clean'-projectおよび' legacy'-project。
このようにして、品質基準の異なるソナーで両方のプロジェクトを分析できます。基準はルールの重要性においてのみ異なるべきです。ルール自体は同じでなければなりません。このように、'legacy'-projectで、' clean'-projectの標準を満たすために「修正」する必要があるものを確認できます。
レガシーコードをより高い標準に引き上げることができた場合はいつでも、それを「クリーン」プロジェクトに移動できます。
毎日の作業では、時間のずれがあるため、すべてのクラスを「クリーン」プロジェクト標準に引き上げることはできません。ただし、レガシーコードに触れるたびに少しずつ改善することにより、少しのステップでそこに到達するようにしてください。