0

非常に古いコードを持つ仕事で仕事を始めたばかりで、基本的な警告を有効にしてこのコードをコンパイルすると、何千もの警告が生成され、それらの多くは本当に怖いものです。このコードの多くは 80 年代に書かれたものであるため、経営陣は、新しいエンジニアが修正を試みることに興奮していません。

私の意見では、これらの警告を取り除くことは最優先事項であるべきですが、私を裏付けるデータはありません。すべての警告を修正することは重大な仕事であり、そのままでは機能するように見えるコードに取り組む価値がないかもしれないという経営陣の考えを理解しています。バグや警告などを指摘している調査を探しているので、その調査に行って次のように言うことができます:「200,000 件の警告があり、調査 X から、そこには 2,000 件のバグが隠されている可能性があります。 "

ここでの非常によく似た議論: https://softwareengineering.stackexchange.com/questions/111616/handling-false-positives-and-legacy-code-warnings-in-static-analysis-of-c-code

これは、「プログラミングの専門家に固有の実用的で、答えられる問題」であるため、トピックから外れたために閉じられるべきではないと思います。

これはトピックから外れたために閉じられましたが、調査を見つけました: http://institute.lanl.gov/isti/irhpit/presentations/ensuring-sq.pdf http://collaboration.csc.ncsu.edu/laurie/論文/TSE-0197-0705-2.pdf

4

4 に答える 4

4

そのような研究はないと思います。私はまた、ここで手足を踏み出して、管理が正しいと言いたいと思います.これらの警告をすべて修正しようとすること、単にそれらすべての警告を修正することは悪い考えです.

警告を修正することで問題が解決します! 現時点では、おそらくそのコードには多くの間違いがありますが、多くの正しいこともあります。そして、「動作中の」コードで問題を引き起こしたとしても、うまくいくとは限りません。

あなたの立場で言えば、私は必要な変更や修正に取り掛かることができます。その過程で、触れるすべてのものに対して単体テストを作成し、触れるすべてのものの警告をクリアします。

あなたのビルドシステムが何であるかはわかりませんが、可能であれば、警告をオンにして触れたものすべてをビルドし、古いものの警告をオフにして、変更したコードを新しい「クリーンコンパイル」ファイルに移動します。

あなたはそれをすぐに手に入れるつもりはありませんが、ただ飛び込んでたくさんのものを変えることはできません. エンド ユーザーのために何かを壊すことなく、進歩できる作業方法を見つける必要があります。

更新:これはコメントとして開始しましたが、回答の一部に値すると思います。

クリーンなコード (警告のないコード、単体テストのあるコード、理解しやすいコード) は、現実の世界で実際に物事を成し遂げなければならない開発者の目標ではありませんし、決してすべきではありません。

クリーン コードは、製品をより良くし、私たちの生活 (および私たちの足跡をたどる人々の生活) をより簡単にするために使用するツールです。それは良いツールです、いや、素晴らしいツールですが、ただのツールです。

実際の目標 (機能するソフトウェアを作成すること) を見失うと、プロセスに関連するトリビアに行き詰まる可能性があります。それは気分が良いかもしれませんが、一般的にはユーザーを満足させたり、製品を予定どおりに出荷したりしません。

于 2013-02-23T20:56:32.963 に答える
1

Michael Khoneの言うことのほとんどに同意しますが、ここにはかなりの製品/開発管理が含まれており、評価はこれに依存します。あなたが自分自身に尋ねるべきいくつかの（すべてではない）主要な質問：

  1. この製品の開発モードは何ですか？それは時々マイナーな機能強化を加えた単なるバグ修正ですか、それとも常に新しい機能を開発していますか？
  2. 適切な十分なテストカバレッジがありますか？あなたがまともな回帰スイートを持っていない場合、これは自殺であるため、大規模な書き直しを行うこと。それでも、いくつかのバグはすり抜けますが、何もないよりははるかに優れています。
  3. ツールチェーン/プラットフォームを更新する必要がありますか？多くの警告は、この「問題のある」動作が予測可能である（そしておそらくコードに対して正しい）と確信している同じ環境に固執する限り、実際には問題を示さないものであるため、これは重要です。ただし、これらのいずれかを大幅に変更したい場合は、これらすべての警告の解決に時間を費やすことをお勧めします。

したがって、警告->バグは実際の製品に大きく依存します。

于 2013-02-23T21:14:58.307 に答える
1

警告は欠陥を意味するものではありません。十分にテストされていないすべての製品には欠陥があります。製品が十分にテストされている場合、欠陥はありません。

多くの警告は他の理由で悪いです。警告は、新しい警告 (新しく作成された欠陥を示している可能性がある) をメンテナンスから隠します。そのため、多くの警告を伴うコードのメンテナンスはより高価です。

警告の修正や、場合によってはメモリ リークなどの実際の欠陥の修正も慎重に行う必要があります。決して機械的に行ってはいけません。それはおそらく動作中の製品を壊します。実際に何十回も見たこと。

于 2013-02-23T20:51:22.793 に答える
0

悲しいことに、古いコードを修正することは、多くの場合、実りのない冒険です。多くの場合、古いコードには単体テストがなく、コードを書いた人は長い間会社を離れています。コードに奇妙なことが見られる場合、それは特定の理由で実行された可能性がありますが、それ以降、非常に多くの要因が変更されたため、影響分析を行うことは困難です. 古いコードを書き直すと、うまくいかないことが多すぎます。代わりに、新しいコードを適切なスタイルで書くことに集中する必要があります。

もう 1 つの問題は、経営陣がコードを書き直す必要がある理由をまったく理解していないことです。

于 2013-02-23T21:17:11.630 に答える