従来のコードベースの品質基準の低下に反対する方法 [閉まっている]

ここには、想像できない悪いコードを含む大規模なレガシーコードベースがあります。

現在、いくつかの品質基準を定義し、それらを完全に新しいコードベースだけでなく、レガシーコードに触れる場合でも満たすことを望んでいます。

そして、すでに数千件の違反があるSonar（コード分析ツール）でそれらを実施しています。

ここで、レガシーのこれらの違反を減らすための議論が行われました。レガシーだからです。

議論は読みやすさの規則についてです。ネストされたifs / for ..の数など。

さて、レガシーコードのコーディング品質の低下に反対するにはどうすればいいですか？

コードは目的を達成するための手段にすぎません。その目的はさまざまですが、通常は利益です。

利益であれば; 次に、売り上げの増加、メンテナンスコストの削減、開発コストの削減、賃金の削減、再トレーニングコストの削減などにより、利益を改善することを証明したいことを主張します。利益を改善する; トイレにお金を流す楽しい方法だと言っているだけです。

私、私、そして私は、レガシーコードのプロデューサーであり、メンテナーでもありました。あなたのツールが「数千の違反」（またはその件で数百もの）を生成している場合、そのツールを忘れてください、それは状況に適用できません...

元の開発者はもういなくなっており、議論に参加できないと思います。そのため、設計とコーディングスタイルの理由と理由を理解している人は誰もいません。数百または数千の違反を修正することは、あちこちで数行のコードを書き直すことではありません。代わりに、間違いなくリファクタリング/再機能分解が必要です。現在の設計を十分に理解せずに、既存の大規模なコードベースに対してこれを実行しようとすると、まったく新しいバグ/問題/その他のセットを導入することになります。ワームの新しい缶は、あなたが現在持っているものよりもさらに悪い（またはあなたのツールが今持っていると考える>> <<）。

「数千の違反」に対処するための唯一の賢明なアプローチは、ゼロから書き直すことです。長くて高価な努力であり、経営陣に販売することはほとんど不可能です。そして、この場合、彼らはおそらく正しいです...

通常、レガシーコードには微調整が必​​要です。y2kの場合、または株式が256から10進数になったときのように。私は両方のcr * pをロードしました。そして、他の多くの同様のもの。通常、かなり悪い「スタイル」、「悪い機能的分解」、「悪い」などを「読み通して」、修正が必要な場所のコレクションを見つけることができるという点で、かなり「ピンポイント」です。そして、「それらの場所の間」で起こること、すなわち、より高いレベルのフローは、あなたにとって謎のままです。変更するローカライズされた機能を理解していることを確認してから、テスト、テスト、副作用のテストなどを行ってください。ローカライズされた知識では予測できません。

そのようなコードを自分のやり方で見ることができない場合、あなたはレガシーコードを維持するのに最適な人ではないかもしれません。空白の画面から始めて美しいプログラムを作成できる人もいますが、他の人のコードの大規模なコードベースから始めてそれを維持することはできません。他の人はコードを維持できますが、ゼロから始めることはできません。一部は両方を行うことができます。適切な人がレガシーコードを維持していることを確認してください。

従来のコードベースをゼロから再設計して書き直したい場合は、ビジネス（またはその他の）要件が変更され、パンツの「微調整」が変更された要件に対応できなくなる場合があります。 。そして、その時点で、最初に新しい機能要件ドキュメントを作成することから始めて、すべての利害関係者が参加していることを確認することもできます。それは基本的にまったく新しい球技です。

行うべき唯一の>> wrong <<ことは、新しいコードの開発と同じ方法でレガシーコードのメンテナンスを扱うことです。そして、その間違ったことが、まさにあなたが行きたい道であるように思われます:)あなたがやりたいことではないという私の言葉を受け入れてください。

問題は、そのコードがどれだけ良いか悪いかではありません。問題は、投資額から得られる利益です。

あなたはそれが好きではない何千ものものを見つけるツールを持っています。ツールの結果を無視するか、何千もの物事を変えるために作業に投資するかを選択できます。それはたくさんあります。人々は、変更中、レビュー中、集中しません。また、すべての変更をテストする（または試してみる）方法を見つけるのに時間がかかるため、これは適切にテストされません。したがって、バグがあります。そのため、これらのバグを見つけて修正するまで、多くの時間とお金を投資し、全体としてマイナスの結果をもたらしました。

一方、ツールは、「好きではない」だけでなく、バ​​グまたは潜在的なバグであるものを見つけることができます。レガシーコードがまだ広く使用されている場合、適切なツールは実際にバグを見つけることができます。そのため、コンパイラの警告を1つずつオンにして、それらが有用かどうか（すべてが有用であるとは限らない）を確認し、それらの警告を修正することは価値があります。

壊れていない場合は修正しないでください

これは実際にすべてのソフトウェア開発者とマネージャーに入れ墨されて、決して忘れないようにする必要があります。

はい、それはすべての現代のコーディング規約を破ります。はい、Cのラッパーを使用してFORTRAN-77で記述されているため、Pythonから呼び出すことができます。はい、これらは非構造化GOTOです。はい、3000行のサブルーチンが1つあります。はい、変数名はクロアチア人にとってのみ意味があります。などなど

しかし、10年以上にわたって怒りの中でテストされ、合格した場合は、そのままにしておいてください！必要な変更が小さい場合は、できるだけ小さく、できるだけローカルに保ちます。それ以外のものは、修正する必要のないものを壊すリスクが高くなります。

もちろん、それは実際には維持不可能なものであり、「小さな」変更に対応する唯一の方法はゼロから書き直すことであることがわかります。その場合は、変更を求めている人に戻って、変更の費用を伝えなければなりません（書き換えにはドルまたは工数で、不可避の新しいバグには血の汗と涙で）。

ずっと前に、Digitalのディスクドライブの1つに障害が発生しました。彼らは最終的にリコールし、すべての人を交換して、費用を知っています。どうやら、HDA内にフィルターを保持している糊の塊があったようです。技術マニフェストは、接着剤について「ノンパラメトリックに指定され、受け入れられる代替物はありません」と述べています。Beanカウンターは、他の接着剤を調達することにより、ディスクドライブあたり1セント未満で「保存」されました。HDA内で蒸気を発し、数年の使用後にドライブを殺しました。彼がそれを修正するまで、それは壊れませんでした。疑いなく「それはほんの小さな変化でした...」

レガシコードの品質レベルを下げる意味はありません。また、警告をすぐに修正する必要もありません。プロジェクトのすべてのコンポーネントのすべての「新しい」変更が、高品質の標準に従っていることを確認してください。つまり、コミットは警告カウントを増やすべきではありません。

これは統一されたシンプルなアプローチです。

古いレガシコードをそのまま使用できます（不必要な変更が行われないため）。新しいコードが高品質であることを保証します。追加費用はかかりません。

リスク管理…。

• 大規模なレガシーコードベースのコードは、少なくともソフトウェアの実際の使用状況でテストされています。
• 大規模なレガシーコードベースのコードが自動化された単体テストでカバーされていることは非常に珍しいことです。
• したがって、大規模なレガシーコードベースでコールドを変更すると、リスクが高くなります。

コスト…。

• コードを書いている間にコードをコードチェッカーに渡すことは安価です
• 後の状態でこれを行うと、はるかにコストがかかります

便益

• コーディング標準に従うことが、コードのより良い設計につながることを願っています。

• ただし、コーディング標準のチェックツールから警告を削除するためだけに誰かがコードを変更するのに何週間も費やすことで、コードの設計が改善されることはほとんどありません。

• 単純なコードは、複雑なコードが理解できない人によって短いメソッドに分割されない限り、より明確で理解しやすい傾向があり ます。

勧告…。

• コードのセクションに多くのバグがあることが示されている場合、または追加の機能を追加するために多くの変更が必要な場合は、コードの機能を100％理解するのに時間を費やします。
• また、コードのそのセクションに適切な単体テストを追加するのに時間を費やしてください。それらのコードの必要性が実証されています。
• 次に、コードをリファクタリングすることを検討できます（これで理解できました）。新しいコードチェックにも合格します。

個人的に…。

• プログラマーとして働いた他の20年間で、新しいコーディング標準チェッカーからすべての出力を削除するために古いものを盲目的に変更して、そうするように指示された請負業者の収入を増やすこと以外に利点があるケースを見たことはありません。
• 同様に、コードレビューを渡すために古いコードを作成する必要がある場合（TickIt / ISO 9001の誤り）、古いコードが新しいコーディング標準のように見える必要がありました。
• 新しいコードでコーディング標準チェックツールを使用すると、継続的なコストを削減することで大きなメリットが得られる多くのケースを見てきました。
• 多くの顧客がいる製品で使用されている古いコードを維持するためのコストに失敗する会社を見たことはありません。
• 市場に出回るのが遅すぎて、顧客から収入を得られないために会社が失敗するのを見てきました…。

ツールのしきい値を下げることについての議論はありますか？...または私はそれを誤解しました。わかりにくい方法で書かれています。そうでない場合は、回答を破棄してください。

私見では、ツールの感度を下げることをお勧めします。どうして？それはコードの最も毛むくじゃらの部分を強調するからです。別の方法は、数千の違反を伴うレポートを作成することで、その規模によっては役に立たなくなります。

...それ以外は、関係する人々と話をして、その理由も聞いてください。

レガシーコードを新しいクリーンコードから分離しようとします。たとえば、Eclipseでは、互いに使用する異なるプロジェクトに配置することでこれを行うことができます。「clean'プロジェクトと」legacy'プロジェクト。

このようにして、異なる品質基準のソナーで両方のプロジェクトを分析できます。基準の違いは、ルールの重要性のみです。ルール自体は同じでなければなりません。あなたが見ることができるこの方法 「legacy'プロジェクトに固定する必要があるものは、 『』の基準満たすために clean'-プロジェクト」を。

いくつかのレガシーコードをより高い標準に引き上げることができた場合はいつでも、「クリーン」プロジェクトに移行できます。

毎日の仕事では、時間の遅れのため、「クリーン」なプロジェクト基準に触れるすべてのクラスを持ち上げることができません。ただし、レガシーコードに触れるたびに少しずつ改善することで、少しのステップでそこに到達しようとする必要があります。