13

最新のCodingHorrorブログエントリは、このコンセプトを聞いたのは初めてではありませんが、それを読んでいたので、自分のプロジェクトにそれを適用せざるを得ませんでした。

私が取り組んでいるコードベースは、現在約3年の時点で進行中のプロジェクトであり、プロジェクトの初期段階のコードの大部分は、ほとんど監視されていない開発者によって作成されたため、多くのコードの重複、パフォーマンスの低下など。経営陣との話し合いで、リファクタリングを望んでいるいくつかの主要なコンポーネントがあることを主張しようとしました。そうすることで、新しい機能を追加するときに、将来の反復で多くの時間と頭痛の種を節約できます。これらの重要な領域のバグを修正します。彼らはこれらのコンポーネントのリファクタリングがいいと私を信頼しているように見えますが、彼らは私にそれをする余裕を与えたくありません。コードベース全体の書き直しや劇的なことについて話しているのではなく、2〜3週間程度かかるいくつかのコア領域の書き直しについて話しているだけであることに注意してください。

では、問題は、開発者として、これらの領域に対処する必要があることをマネージャーに売り込み、あちこちで段階的に改善するのではなく、今すぐ対処する時間を確保するためのビジネスケースを作成する方法です。

4

5 に答える 5

8

マネージャーとして、私は、技術サポートの削減、新機能の追加、およびセキュリティの向上という 3 つの具体的なビジネス ケースのいずれかについて、コードのリファクタリング/リライトにオープンです。

開発者として、私がリファクタリング/借金を返済する「近い」ケースをさらに 2 つ目にします。あなたのマネージャーはこれらに対してオープンであることがわかるかもしれませんし、彼はあなたに「そのような見た目」を与えるだけかもしれません。

まず、新しい機能を追加する能力を向上させるためだけにリファクタリングすることが理にかなっている場合があります。たとえば、システムの柔軟性と適応性を高める必要があるビジネスが間近に迫っている場合は、元のアーキテクチャのコミットメントの一部を再考する必要があるかもしれません。借金を返済する絶好の機会です。

第 2 に、既存のコンポーネントに関連する新しいコードが作成されている場合、負債を返済することは理にかなっています。たとえば、論理的に既存のクラスの兄弟クラスである新しいクラスを追加する場合、共通コードを親クラスにリファクタリングすることは理にかなっています。これを行うと、借金を返済する絶好の機会にもなります。

于 2009-03-01T19:08:03.233 に答える
3

いつものように、答えは「お金を見せて」です。たとえば、提案されたソリューションのビジネスケースを見せてください。従来、これは、標準以下のコードに関連するサービスタスクまたはヘルプデスクチケットをカウントすることによって行われました。あなたが本番ではないプロジェクトについて話しているように見えるので、あなたの特定のケースは難しいでしょう。

あなたが書いたものとあなたのプロジェクトがまだ開発中であるという事実に基づいて、私はあなたに「より良いことは完了の敵である」という格言を覚えておくように警告します。（Michael Loppによって造られたか、少なくとも普及したと思います。）プロジェクトのライフサイクルには、コードをリファクタリングするのに適した時期があるかもしれません。

于 2009-03-01T18:26:18.903 に答える
3

管理者が同情的であるが、完全なオーバーホールを行うために2〜3週間を与えることに抵抗がある場合、妥協案は、それらのコンポーネントのバグを修正し、いくつかのテストを作成し、いくつかの限定的なリファクタリングを行い、時間の経過とともに改善することです。コード。

あなたはそれをすることができます、あるいはあなたはその目的のために使われるそれらの領域のバグ/機能の見積もりに10％を加えるように頼むことができます。

于 2009-03-01T18:34:40.987 に答える
2

あなたのリンクからの主要な記事はすでに完璧な答えを持っています。技術的負債のこの説明は非常に良いです：

技術的負債は、ウォード・カニンガムがこの問題について考えるのを助けるために開発した素晴らしい比喩です。この比喩では、物事を迅速かつ汚い方法で行うと、技術的負債が発生します。これは、金融債務に似ています。金融債務と同様に、技術的債務には利息の支払いが発生します。これは、迅速で汚い設計の選択のために、将来の開発で行う必要のある余分な努力の形で発生します。引き続き利息を支払うか、迅速で汚い設計をより良い設計にリファクタリングすることで元本を返済するかを選択できます。元本の返済には費用がかかりますが、将来的には利息の支払いを減らすことで利益を得ることができます。

比喩はまた、迅速で汚いアプローチを行うことが賢明である理由を説明しています。市場機会を利用するために企業がいくらかの債務を負うのと同じように、開発者は重要な期限に達するために技術的債務を負う可能性があります。あまりにも一般的な問題は、開発組織が債務を管理できなくなり、将来の開発努力のほとんどを不利な利子の支払いに費やすことです。

プロジェクトがどこにでも行く場合、プロジェクトのマネージャーはそもそもそれを気にする必要があります。彼が自分のプロジェクトに関心を持っているのであれば、その説明だけで、おそらく彼が考えもしなかったアイデアに目を向けるのに十分なはずです。コードベース内で改善が必要なすべての場所に注意を向ける方法を彼が設定するのを手伝ってください。おそらく、問題追跡システムのグループまたは親のチケットです。そうすれば、説明責任と改善が必要なもののリストを得ることができます。

于 2009-03-01T18:21:38.710 に答える
2

私の謙虚な意見では、技術的負債の返済は、コードを送信するたびに少しずつ行う必要があります。年に2、3週間休むのではありません。

小さなチャンクの継続的な改善は、最終的には驚異的に機能します。

その場合、許可を求める必要はありません。:-)

/ロジャー

于 2011-02-17T15:24:40.687 に答える