あなたが書いたいコードにどのように対処しますか？[閉まっている]

そのため、クライアントからコードを書くように依頼されます。彼はその後、予想どおりに仕様を変更し、あなたは彼の新機能を熱心に小さな若者のように実装します。例外として、新しい機能は古い機能と競合するため、コードは混乱します。あなたは本当に戻ってそれを修正したいのですが、彼は新しいものを要求し続け、あなたが何かを掃除し終えるたびに、それは再び混乱を巻き起こします。

職業はなんですか？OCDマニアであるのをやめて、あなたのコードがあなたが何をしようとしても混乱を巻き起こすことを受け入れるだけで、この怪物に機能を付け続けますか？バージョン2のクリーニングを保存しますか？

別の仕事を取得し、他の人に対処させます。ムアハハハハハハ。

.....

ほんの冗談ですよ。:)

しかし、すべての真剣に：推定パディングはあなたの友人です。私は一般的にまともな現実的な推定を行い、それを倍にします。これは過度に聞こえるかもしれませんが、時には過大評価することもありますが、バグのあるコードを消して常に見積もりを爆破することで悪い印象を残すよりも、少し過大評価して、少し遅く見えることもあります。そしてもちろん、コードベースをハッキングすることで技術的な負債が発生します。

別の（関連する）ヒント：まともなサイズのブロックに対して、一見小さな一見簡単なタスクを常に見積もってください。たとえば、-ほぼ確実なアイテムは、30秒の単純な1行の変更にすぎません-1時間（または、タイムシートまたはCRシステムにある最低時間ブロック、たとえば15分/0.25時間）を与えます。そして、少し大きいがまだ比較的些細なアイテムには半日または1日のブロックを与えます。

この理由は主に心理的です：小さな変更をすばやくハックする習慣を身に付けると、仕事が急がれているように感じ、リファクタリングが必要なものをリファクタリングし、在庫を取り、リファクタリングすることはありません。また、実用的なレベルでは、些細ではないが些細な変更がときどき吹き飛ばされ、スケジュールの遅れやバグの発生を常に感じているとは思われたくありません。これは、コードベースが時間の経過とともにハッキングされる理由の一部です。

最後に、推定値をいくぶんパディングしていることを人々が知る必要がないことを常に覚えておいてください。あなたが有能な開発者であり、まともなペースで作業を進めている限り、このパディングは目立たないでしょう。すなわち、PHBに「最初の見積もりでは2時間かかるが、半日はかかる」と言わないでください。「半日ほどかかると思います」と彼に言ってください。そのままにしておきます。

次の機能に必要な時間を故意に過大評価してください。その余分な時間を使用してクリーンアップします。

メンテナンスを正当化することは不可能であり、クライアントはそれを必要とするので、苦痛の薬（次の機能のコストを少し増やす）を与えると、より良くなることができます。

新しい機能を統合しながら、適切な再設計を試みてください。後でありません。再設計を行わないと、さらなる変更や新機能のために常に摩擦が増えます。

ある時点で、すべてが古くなっているように見える、ほぼ停止した状態になります。ほとんどの企業は、この時点でバージョン2の大幅な書き直しを行っている可能性があります。経済性が非常に悪く、顧客が気が向いた場合に別の開発パーティを試す良い機会です。

適切な再設計/リファクタリングは、顧客の投資を保護し、物事を持続可能にします。これを組み込む必要があります。変化に合わせて最適化してください。

過大評価についてのすべてのコメントで、私は適度な量のポイント（機会）を見逃していると思います。

変更にかかる時間を推定するだけでなく（変更を加えてから）、コードを変更するのに必要な時間を推定して（リファクタリング！）、変更が安全に行われる可能性のあるポイントに至ってから、変更します（おそらく多少の変更が加えられています）。わかりました、これは同じことです...しかし、混乱またはストレッチまたは過大評価の問題はありません、これを行うには、まずそれを行う必要があり、これがどれくらい時間がかかるかということ合計で。ここで重要なのは、変更が依存しているシステムの部分で作業することです-他に恐ろしいコードがある場合は...タフな、そこにいるときにキャッチします。

元の質問に戻ってビットを来て-年間の多くの後にあなたがいない限り、あなたが何かを実装するときには、私のためにこれに降りてくる知っている（？（容疑者を期待していない、信じられない）、と思わなく、知っていること、追加のものがあります）また、必要な場合は、その要件を実装するために必要なことを実行する必要があります。

次のこと-しばらくして-を実装するようになると、コードベース（およびデータベースなど）を、できる限り整然としたエレガントな方法でその機能を実装するために必要な状態にするために必要な手順を実行します。このリファクタリングは、プロジェクトの発展に伴って自然に発生する混乱に対処する場所です-できれば、混乱の発生を避けてください（または、少なくともレベルの一貫性を維持してください）。

ここでの議論領域の1つは「技術的負債」です。これは当座貸越のように返済する必要があり、長く残すほど関心が高まり（この場合は修正に必要な時間）発生します。技術的な負債を最小限に抑えるために時間を費やすための議論。

また、ユニットテストやその他の自動化されたテストが開始されます（できれば、私は幸せな人になると確信しています！）と適切なビルドサーバー（少なくとも一部を実行できます）あなたのテストの）。それらと組み合わせて-しかしそれ自体で価値がある-依存関係の注入や制御の反転のようなパターンです（これら2つがどれだけ「同じ」かはわかりません）。これらは配管の変更を容易にし、したがって、分離。

最後に-それが壊れていない場合、それを修正しないでください。コードを整頓するために純粋に整頓することは満足できるかもしれませんが、エラーを導入する機会もあるので、変更する必要がなく、それを構築していない場合は痛みを伴う可能性があります単独で-修正または交換する機会が最終的に転がります！

1）適切な変更管理はあなたの友達です

顧客が仕様を変更しても問題ない場合はその通りです。しかし、それは変更であり、料金を請求する必要があります（またはプロジェクトの構造/関係に適した方法で費用がかかります）。

その変更の見積もりには、必要なリファクタリングのコストを含める必要があります。クライアントは高コストのように思われるかもしれませんが、その時点で、コードがすでに半分書かれているため、将来的に堅牢でサポート可能なことを保証するために書き直す必要がある要素があることを彼に説明する必要があります完了していない場合、将来のサポートや変更がさらに高価になり、将来問題が発生する可能性があります。

2）リファクタリングは、クライアントに本物の長期的な利益を提供するように行う必要があります

リファクタリングを検討するときは、実際に必要なものと重要なものを常に検討し、リファクタリング作業が真の長期的価値をお金にもたらすことを保証する必要があります。

結局、これらのことを実行して、コードを中長期的に拡張およびサポートできるようにして、理論上の完全性を追求するのではなく、クライアントの投資が有効であることを保証する必要があります。リファクタリング作業（および対応する推定値）は、これをスコープとして行う必要があります。これは、やや良い方法があるかもしれないと考えるからではありません。

一部のプログラマーは、クライアントでその問題を制御する方法は、クライアントに署名して初期仕様を承認させることだと提案しています。次に、最初の仕様にない要件の変更を要求する場合、追加のコストと時間の遅延を計算するために契約とプロジェクトのスケジュールを確認し、契約の付属書を作成する必要があることを伝えます。どうやら、クライアントが新しい（予測されていない）機能を要求するのを防ぐことに驚かされます。

現在取り組んでいるコードベースに次のコメントがあります：

/*
 * Every time I see this function, I want to take a shower.
 */

あなたが説明している状況をよく知っています。私がやることは、物事が落ち着き、あらゆる種類の「クリープ」がそれがするすべてを「クリープ」するまで待つことを試みることです（私のベスト）。その時までに、おそらく使用可能なものがリリースされているので、少し時間をかけて、物事を整理し、少し異なる方法で実装することができます。

たくさんの小さな混乱を繰り返し掃除することはできません。それはあなたの仕事と欲求不満を3倍にします。それが1つ大きくなるが、ほとんど動かない混乱になるのを待ってから、あなたはそれについて何かをすることができます。

私の好みは、そもそもこの状況を避けることです。

それはすべて、仕様の読み方に依存します。それらを石版と考えるのは簡単ですが、実際にはほとんどの仕様が変わります。コードを設計するときは、仕様の各部分がどの程度変更される可能性があるかを確認してください。時間が経つにつれて、これを予測するのがかなり上手くなります。

混乱に陥った経験と判断は非常に重要です。このスパゲッティコードのために新しいバグを書いていますか？実装に時間がかかりますか？これらは戦術的なリファクタリングを行うことを指し示します。

将来的には、顧客と協力して仕事をする必要があるようです。彼らに言って、「この製品は元の仕様を大幅に超えているように見えます。元のデザインはそのレベルには適していましたが、X方向とY方向に拡張するには設計に多少の再構築が必要です」それを支払う顧客。

1時間ごとに料金を請求し、変更を希望する場合は問題ないことを伝えますが、式に適切なコードを書き込むのに必要な時間を組み込みます。また、きちんとしたコードを書くことは、それを維持しなければならないときに、長期的に見返りがあることを忘れないでください。時間を節約することは、後でコストがかかる可能性があります。

ソフトウェアの作成は、ビジネスニーズと密接に連携する必要があると思います。使い捨てプロジェクト（1週間でビルドする必要があり、毎日新しい入力が必要なプロトタイプなど）の場合、コードの保守性などを心配する必要はありません。時間が重要です。コードをできるだけ早くドアから押し出します。

しかし、長期的なアプリを作成している場合、新しい機能の構築、既存のバグの修正、他のアプリケーションや他のものとの統合にかかる時間にかなりの影響があるため、これらすべてを考慮することは理にかなっています。これはビジネスへの影響につながります（後により多くの時間と費用が必要になるため）。

したがって、必要に応じてコードをリファクタリングしない実際のコストに意思決定者を敏感にする方が良いです-私の経験では、両方のオプションのコストと時間の影響が決定的な意味で意思決定者に説明されている場合、意思決定は非常に簡単、考える必要のない。「2倍の時間がかかり、追加のメリットはありませんが、美しいコードを書きましょう」と人々が言うことを期待しないでください。それだけでは機能しません。

それをあなたのプロセスの一部にしてください、私はそれを「極端なリファクタリング」と呼びます、そしてそれは大きくなるでしょう！;）すぐに作業を行い、瘢痕組織がある十分な新しい機能が追加されたら、それをリファクタリングします。続けて「今からゼロから始めたなら、どうやってやるのか」と自問してください。

前もってすべてを設計し、考えることができると思う人はほとんど自分自身をだますので、あなた（そしてあなたのクライアント）はあなたが進むにつれて常に物事を学びます。これらのレッスンを使用してください。

あなたが優れたプログラマーであれば、リファクタリングを非常に迅速に行うことができ、それを継続的に行うと、コードは「適切な形式」になります。つまり、依存性が少なく、より柔軟になります。

あなたは、あなたが「時間を浪費している」ものをやり直していることを知っていれば、クライアントは困惑するかもしれません。

この方法で開発されたコードは、最終的に時間を節約し、新しい機能を追加することをますます簡単にします。

また、悪いコードの最大の理由の1つは、一部のプログラマーがより大きな構造リファクタリングを行うことに対する恐怖であり、長く待つほど悪化することです。

より高い電力に依存

祈るつもりはありません。つまり、あなたとクライアントの間にパディングとして配置できるビジネスマン（プロジェクトマネージャーまたはそれに相当する人）がいることを確認してください。クライアントがあまりにも多くを要求している場合、ビジネスマンに足を下ろさせて、「実行可能ですが、仕様の範囲内に収まるかどうかはわかりません。[ビジネスマン]」を参照してください。

通常のプロジェクトフローでは、深刻な開発が行われる前に一般仕様を凍結する必要があります。

多くのクライアントは、許可する限り、変更/改善/改善を推進し続けます。多くの人は、その能力を最大限に悪用します。それは、彼らがお金を最大限に活用しているように感じるためです（たとえプロジェクトが妨害されたとしても）。

早い段階で仕様を完成させて凍結し、後で強制することに専念する人を用意します。

クライアントと少し良いカルマのために少し余分なことをすることは何の問題もありませんが、彼らが手に負えなくなったとき、より高い力に先送りする準備ができています。仕様にとんでもない量の変更が必要な場合は、ビジネスループに戻って契約を再評価し、および/または契約に追加を追加する（公正な金銭的補償を伴う）かもしれません。

この問題が発生しているという事実は、コーディング方法とはほとんど関係ありません。これは、プロジェクトマネージャーがプロジェクトで十分に活用されていないことを示しています（あなたのせい、彼のせい、またはその両方）。

他の人が多くの答えで言ったように、プロジェクトには不測の事態のための時間バッファを追加することも必要ですが、仕様が凍結されてPMによってクライアントに配信される前に、密室で決定する必要があることを決定します。

初期の適切な設計は、問題の回避に役立ちません。そして、将来のすべての「多分」要件を考慮することはほとんど不可能です（または非常に難しい）。そのため、しばらくするとビッグリファクタリングが始まります。そして、最善の解決策はすべてを書き直すことです。

簡単に言うと、赤いフェラーリに砲塔を取り付ける代わりに、要件を再検討して戦車を構築します。

火で殺します。

別名リファクタリング：いコードが締め切りを急いでくる場合など、既存のコードがメンテナンス可能になるまで機能を追加できない（または少なくとも追加すべきではない）ため、締め切り後にリファクタリングします将来のコードをデバッグするのがずっと難しくなります。

現在の状態をテストし、時間があるときにリファクタリングするプロジェクトの単体テストを作成します。こうすることで、クリーンアップ中にプロジェクトが破損することを回避できます。

最も簡単な答え。彼が今の時点でまさに望んでいるものの最終仕様を得るまで、私はあらゆる種類のコーディングを停止します。

次に、機能のリストなどに優先順位を付けて、現在必要なアイテムと、後で実行できるアイテムを確認する必要があります。

あなたの経験を使用して各機能の時間/コストを決定し、彼らにこれを望んでいる場合、x時間とお金がかかります。

機能範囲の大きな犯罪への対処は忍び寄って、何も成し遂げられないか、まさしく成し遂げられなくなるまで、彼らは機能を際限なく追加し続けます。

最終リストができたら、彼らが好むように将来の修正を行うが、今持っているべきトップ15/20に集中する必要があることを伝えます。

次に、完了までの時間に基づいて、これがリリースされた後、次のバージョンについて話し合ったりブレインストーミングしたりできることを伝えます。

現在のバージョンで何を行うかについて最終決定が下されたら、すべての議論/アイデア/提案を100％停止する必要があります。

アイデアを際限なく入手できる場合は、次のバージョンの機能リストにそれらを書き留めて、今必要な最も重要な機能の提供に集中できるように伝えます。

彼らがあなたの時間を無駄にし続けるなら、彼らの心を変え続けてください。その後、プロジェクトの決定を確定するまで、プロジェクトの作業をやめて、他のプロジェクトに取り組みます。

するのは難しいですが、機能範囲のクリープは時間、エネルギー、動機、明確な思考を破壊します。

プロジェクトの完全な観点から：

チームでコードから学び、次回リファクタリングして再利用できるものを確認してから、ビールを飲みましょう。

開発中の観点から：

開発が停止した理由を辛抱強く説明し、すべての仕様がテーブルに載って理解されるまで継続できない理由を説明します。次に、ビールを飲みに行きます。

計画の観点から：

すべての仕様を事前に要求し、全員と協力して、開発パスを明確に理解してください。全員が同じページにいることを確認するために、クライアント/利害関係者をできる限り密接に関与させます。その夜遅くに、みんなにビールをもらう。明日、プロジェクトを開始します。