コードのクリーンアップを推定するための最良/倫理的な方法は何ですか？
私は大学4年生から現在の雇用主のために製品ラインに取り組んでいます。大学を卒業して数年になりますが、私はこの同じ農産物ラインでの変更リクエストの見積もりを提示する立場にあります。当社のソフトウェアリードは引き続き見積もりを承認しますが、プロセス中に引き渡されることに注意してください。
私のスキルセットが成長し続けるにつれて、私は自分が改善できることを見続けています。問題は、これらの変更に資金を提供する方法です。私の現在のプロセスは、アクティブな変更要求がある領域にコードが接触した場合、コードをクリーンアップ/リファクタリングすることです。ただし、アクティブなCRの一部ではないコードのダーティセクションは無視され、製品ラインが成熟するにつれて、ますますバグが発生します。
明確にするために、新しい要件を満たすために実際にそうする方が安い場合を除いて、お客様がソフトウェアの完全な書き換えに料金を支払う必要があるとは思いません。コードのビットをクリーンアップするために、増分変更を好みます。
見積もり/見積もりを提出するとき、倫理的にコードのクリーンアップのコストを取り戻そうとする最善の方法は何ですか？
さらに詳しく説明すると、一般的なメンテナンスではどのような種類のパディングが一般的ですか？コード行、プロジェクトの複雑さ、またはその他のメトリックに基づく必要がありますか？
技術的負債のビジネス上の問題
私がここで見ている問題は、技術的負債というよりも技術的負債に関するビジネス上の問題です。私はあなたの質問に別の適切なもので答えます。
- なぜ顧客は以前と同じ仕事をするコードを書き直すためにあなたにお金を払う必要があるのですか？
顧客への技術的負債の認識の難しさ
顧客に技術的負債を認めさせようとすることは、せいぜい困難であり、多くの場合、「今、私にもっと費用がかかるのに、なぜそもそもそのように書いたのか」というケースになってしまいます。
技術的負債を認識し、システムの一部に段階的に触れるときに技術的負債を修正することは、大規模な負債の削減を行うことをお勧めする方法とほぼ同じです。
新しい作業については、ビルドを段階的に修正することを考慮して、見積もりをパディングすることもお勧めします。ソフトウェアが複雑になるほど、メンテナンスのコストが高くなると考えるのは自然なことです。技術的負債のリファクタリングと削減は、メンテナンスの積極的な部分であり、できるだけ早く支払う必要がありますが、メンテナンスコストを、顧客にとってより小さく、より口当たりの良い部分に分割します。
Robert "Uncle Bob" Martinが倫理とソフトウェアの職人技について言っていること
ロバートCマーチンは、パートIVでの彼の講演で、まさにこのトピックに取り組むことについてこれと同じ推奨をしていると思います。申し訳ありませんが、長い時計ですが、それだけの価値があります。
編集
技術的負債を計算するための指標は、有給の仕事を実行する時間を見積もる場合とほとんど同じです。トリックは、最も痛みを与える部分を特定し、それらを徐々に削っていくことです。常に動作するように常にリファクタリングしますが、動作が遅くなり、操作が簡単になり、保守が容易になります。
実例
DALが約80％NHibernate2であるソフトウェアのオフィスに技術的負債のバックログがありますが、レガシー部分はSPに書き込まれたドメインロジックを備えたストアドプロシージャと手動プロキシを使用しています...（悪夢）。
ただし、すべてのメンテナンスプロジェクトについて、2週間のスプリントごとに10枚のメンテナンスチケットがあり、それらのチケットの1枚または2枚が技術的な負債項目になります。また、これらはメンテナンスアイテムであり、メンテナンススプリントの一部としてサインオフしてもらうため、お客様はこれに満足しています。
したがって、各技術的負債項目を1人の開発者が2週間のスプリントで処理できるチケットに効果的に分割します。これにより、顧客にかかる費用に関する指標が得られ、進行状況が表示される2、3のスプリントを通過するときの速度も示されます。
リファクタリングの目標は、コードをよりクリーンにし、長期的にはメンテナンスと拡張のコストを削減することです。経営陣やクライアントに技術的負債の概念を理解させることは非常に困難であるため（常に不可能ではありませんが）、できれば必要なコード変更に関連して、少しずつ行う方が適切であり、より実用的です。したがって、コードの一部に触れる必要がある場合は、具体的なタスクのサイズに比例して、コードをいくらかきれいにします。つまりバグを修正するために1行のコードを変更する必要がある場合、含まれている100行のメソッドを完全にリファクタリングすることはおそらく不均衡です。しかし、例えば一部のローカル変数の名前を変更して目的を明確にするか、親メソッドを理解しやすくするためにいくつかの小さなメソッドを抽出することは問題ありません。したがって、たとえば、根本原因を特定し、単体テストを記述し、バグを修正し、すべての回帰テストを実行するための3時間の作業のうち、リファクタリングに費やした30分は問題ありませんが、2時間は問題ありません：- ）
OTOH-見た目が醜くても古くても-長い間触れられておらず、うまく機能し、プログラムの他の部分のメンテナンスにも支障がない場合、おそらくそのままにしておくのが良いでしょう。それはいいですが、コードの残りの部分と同じくらい光沢のあるクリーンで完璧なものにするのは私たち自身にとって感じやすいでしょう（私はあなたがどのように感じているかを正確に知っています。ただし、これを行っても、メンテナンスコスト（関連する機能要求がないため）、バグ率（既知のバグがないため）には影響しないため、クライアントにメリットはありません。
全体として、実際のプロジェクトでは、リファクタリングリソースは限られているため（多くの場合、厳しく）、私たち（およびクライアント）が努力と時間の投資から最大の利益を得る分野に焦点を当てることが最善です。これは、クライアント/管理に対するリファクタリングの価値を証明するための最良の方法でもあり、長期的には、より多くの時間を稼ぐのに役立ちます...
アプリケーションのメンテナンスに必要な部分だと思います。進行中のプロジェクトの場合、リファクタリングの時間を拡張見積もりに織り込むことは容認できないとは思いません。負荷や負荷ではありませんが、プロジェクトのサイズが大きくなるにつれて、保守性が高まります。あなたはいつでもそれを正当化することができます：書き換えの必要性を回避（または少なくとも延長）しているので、実際には長期的にクライアントのお金を節約しています。
ガレージに行って車の部品を交換し、整備士が小さなもの（ナットが壊れているかどうか）の問題に気付いた場合、彼はそれを修正します。彼はそれを請求しません、それは彼のプロ意識の一部です。ただし、あなたへの彼の最初の引用には、これらのものを見つけること、問題を思い付くことなどに対して自分自身を保証するための少しのパディングがあります。それらが壊れるまでより長く。