0

かなり大規模なシステムの書き直しを行ったばかりで、改善されたコードの領域を見つけて特定するように依頼されました。私たちが費やした努力が価値があることを顧客に正当化する方法として。領域を特定することはそれほど難しいことではありませんが、この情報をどのように提示するのが最善かという問題に苦しんでいます。これに関する提案、または誰かが過去に似たようなことをしたことがあれば、よろしくお願いします。

4

3 に答える 3

3

事実上、これは技術的負債の削減です。この種の取り組みから通常得られるすべてのメリットは、ここでも適用されます。いくつかの効果は前向きになります。例えば:

  • より優れた、より明確なAPIの結果として、欠陥率が減少しました。
  • インターフェイスのテストが容易で、統合ポイントが少ないため、開発時間の短縮(およびコストの削減)が可能になります。
  • 古いコードを維持するのが簡単になります。これは、それらが依存するレイヤーがよりクリーンになり、無駄がなくなるためです。

ただし、それらの一部はすぐに実行されます。

  • がらくたが少ないため、ビルドが高速になります。
  • これらの領域の単体テストが難しすぎたため、本番環境まで発見されなかったバグの特定。
  • 層と懸念のより良い分離。

もちろん、これらの種類の利点が適用される程度は、プロジェクトとそのコードベースに固有です。

于 2009-05-08T18:49:52.827 に答える
0

それは顧客によって異なります:顧客は技術的な志向ですか?それらは内部ですか、それとも外部ですか?彼らはどのくらいの詳細を望んでいますか?書き直しを依頼されましたか?もしそうなら、誰が、どのような理由で書き直しますか?

于 2009-05-08T18:49:38.863 に答える
0

非技術者向けなので、棒グラフと円グラフをお勧めします。非技術者が大きなカラフルなチャートのような複雑な主題を把握するのに役立つものはありません。

于 2009-05-08T18:52:09.573 に答える