今それをシンプルに保つか、将来を念頭に置いてプログラムしますか？

現在、かなり複雑な会社向けに新しいアプリケーションをコーディングしています。期限に間に合うように、機能はかなり打ち上げられており、起動する準備ができています。

私は今月末までにバージョン1を立ち上げて実行するタスクを与えられました。私は開発のほぼ半分であり、終わりが見えてくるようになりました。

昨日、要件の1つに対する非常に優れた簡単なソリューションを思いつくのに時間を費やし、その結果を非常に誇りに思っています。今朝、バージョン2のドキュメントが送信されました。そこには、昨日書いたコードを破壊するか、大幅に変更する必要があるという要件があります。そのままにしておくと、将来多くの作業が必要になります。現在のソリューションをより堅牢にするためにもう1日かかるため、v2機能をはるかに少ない労力で追加できますが、必要な追加のコーディングには少し遅れが出ます。

v2を実行するかどうかはわかりません。私の場合もあれば、同僚の場合もあれば、インターンの場合もあります。

あなたが私の靴を履いていたら、将来それをより簡単にするために今時間を費やしますか、それともあなたのソリューションを残して、時間が来たときにそれを処理しますか？

締め切りが石で刻まれている場合、あなたがそれを満たすために持っているものを終えてください。新しい要件のコード変更に対応するために、v2の見積もりを確実に膨らませてください。また、新しいv2機能のために変更する必要があると思われるものを簡単に文書化し、他の何かに再割り当てされた場合に同僚がそれを取得できるようにしてください。

締め切りに十分な柔軟性がある場合（1日、その音により、2.5日間の延長を目指してください）、確かに、先に進み、既知の未来のためにコーディングしてください！

セカンドシステムエフェクトの餌食（早期）に陥ることは避けてください。適用するいくつかの優れた手法を次に示します。

1. バージョン2で 予定されていることを理由に、バージョン1の脱線を絶対に避けてください。先の計画は問題ありませんが、v2仕様の作成者は、v1ではなくv2の障害に責任を持つ必要があります。
2. （可能であれば）現在大きな変更を必要としないバージョン2の要件を作成者に再作成してもらうことができるかどうかを確認し、後でv3向けにそれらを計画します。
3. YAGNIを念頭に置いてください。ただし、拡張性を念頭に置いてコーディングしてください。マジックナンバー、ハードコードされた値を避け、適切な単体テストやコードコントラクトなどを作成してください。早い段階で適切な手法を適用すると、リファクタリングやコード変更の苦痛が軽減されます。

都市のように成長するほとんどのソフトウェアプロジェクトは、長期的には成功しています。限られた未来に向けた進化的計画により、ソフトウェアを予定どおりにリリースでき、リリース時に必要な機能が追加されます。Carl Saganからの次の抜粋を参照してください。

[都市の]配置は、すべての市民システムが並行して構築され、定期的に交換される場合、より効率的である可能性があります（これにより、例えばロンドンやシカゴの大火災などの悲惨な火災が都市計画の助けになることがあります）。しかし、新しい機能のゆっくりとした付加により、何世紀にもわたって都市は多かれ少なかれ継続的に働くことができます。

• カールセーガン、コスモス：http : //www.eridanus.info/genesis.html

来月の要件のために、今日コードを追加しないでください。今日、あなたはあなたが持っている要件にできる限りきれいなコードを書くべきです。私は、1日の仕事で数日後には節約できるのではないかと疑っています。私はそのような主張を聞いたことがあり、それが真実だった単一のケースを思い出すことはできません。いくつかのコードを表示することで私を納得させることができるかもしれませんが、私の経験ではそうは思えません。

そのままにしておきます。

開発者は実際に、本来の目的を果たすだけで、それ以上のレガシープロジェクトを評価します。

今日、「将来の」要件を満たすためにコードベースを「ステージング」するための良いアイデアのように思えるかもしれませんが、おそらく将来のコードを理解する上で障害となるでしょう。部分的に実装された機能や忘れられたファントム要件の痕跡を扱うのが好きな人はいません。私はそれが事実だとは言っていませんが、最善の意図にもかかわらず、物事はしばしばそのようになります。

良い答え。私は追加するだけです-このような場合に私がすることは良い差分を取るので、私がやったことをキャプチャし、安全な場所にそれをリスニングすることができます。その後、次のバージョンで再びそれを行う機会が来れば、それは簡単です。

一般的に、優れた開発者は将来の要件を予測しますが、締め切りが迫っているときは、「ボートを揺さぶる」のではなく、すでに持っているもののバグに対応するときです。

場合によります。古き良きルールがあります。他の人を自分のように扱われたいように扱ってください。自分のプロジェクトで、すべての優先事項を知っていたらどうしますか？

v2が絶対に必要であり、締め切りが難しい必要性ではなく単なる願いである場合は、天候が良い間は技術的な負債を作らずに帆を修理しないでください。他の誰かがv2を実行する場合でも、先見性に感謝します。

v2の必要性に疑問がある場合は、YAGNIを使用してください。また、あなたがスペクトルの反対側にいて、彼らが形成する前にアイデアを絶えずあなたにスパムするクライアントの1人を持っているなら、あなたのメールを毎日2〜3回だけチェックし、アクションに急いでいない場合、あなたは驚かれることでしょうあなたがそれらを読む前に、いくつの「問題」とリクエストが無関係になるか。