今はシンプルに保つか、将来を念頭に置いてプログラムしますか？
私は現在、かなり複雑な会社の新しいアプリケーションをコーディングしています。締め切りに間に合うように、機能を大幅に削減して、何かをリリースする準備ができているようにしました。
私は、月末までにバージョン1を起動して実行するタスクを与えられました。私は開発の半分くらいのところにいて、ようやく終わりが見えてきました。
昨日、私はいくつかの時間を費やして、要件の1つに対する非常に素晴らしい簡単な解決策を考え出しました。今朝、バージョン2のドキュメントが送信されました。その中には、昨日書いたコードを根本から変更するか、大幅に変更する必要があるという要件があります。そのままにしておくと、将来的には大変な作業になるでしょう。現在のソリューションをより堅牢にして、v2機能をより少ない労力で追加できるようにするために、もう1日かかる可能性がありますが、それによって、必要な追加のコーディングが少し遅れます。
私がv2をするかどうかわかりません。それは私かもしれませんし、同僚かもしれませんし、インターンかもしれません。
もしあなたが私の立場にあるなら、あなたは将来にそれをより簡単にするために今時間を費やしますか、それともあなたの解決策を残して時が来たらそれに対処しますか？
期限が石に刻まれている場合は、それを満たす必要があるものを終了します。新しい要件に対応するコード変更に対応するために、v2の見積もりを膨らませてください。また、新しいv2機能を変更するために何を変更する必要があると思うかを簡単に文書化し、他の人に割り当て直された場合に同僚がそれを選択できるようにしてください。
締め切りに十分な柔軟性がある場合（1日、その音で、2.5日の延長を目指してください）、確認して、既知の将来に向けてコードを作成してください！
第2のシステム効果 の餌食に（早い段階で）落ちないようにします。適用するいくつかの良いテクニックは次のとおりです。
- バージョン2で発生することがわかっているという理由だけで、バージョン1の脱線を完全に回避してください事前の計画は問題ありませんが、v2の失敗はv1ではなくv2仕様の作成者が責任を負う必要があります。
- （可能であれば）大きな変更を今は必要としないバージョン2の要件を作成者がやり直すことができるかどうかを確認し、後で、おそらくv3のために計画を立てます。
- [〜＃〜] yagni [〜＃〜] を念頭に置いてくださいが、拡張性を念頭に置いてコードを作成するようにしてください-マジックナンバー、ハードコードされた値を避け、適切な単位を記述してくださいテストやコードコントラクトなど。早い段階で適切な手法を適用すると、リファクタリングやコードの変更が途中で簡単になります。
都市のように成長するであるほとんどのソフトウェアプロジェクトは、長期的には成功しています。限られた将来にのみ進化する計画を立てることで、ソフトウェアを予定どおりにリリースし、リリース時に必要な機能を追加してリリースすることができます。カールセーガンからのこの抜粋をご覧ください。
すべての市民システムが並行して構築され、定期的に交換された場合、[都市の]配置はより効率的になる可能性があります（このため、ロンドンやシカゴなどの大規模な大火事が都市計画に役立つこともあります）。しかし、新しい機能のゆっくりとした増加により、市は多かれ少なかれ何世紀にもわたって継続的に働くことができます。
- カール・セーガン、コスモス： http://www.eridanus.info/genesis.html
来月の要件のためにコードを今日追加しないでください。今日、あなたはあなたがあなたの必要条件のためにできる最もクリーンなコードを書くべきです。私は1日の仕事が数日後に節約できるかどうか懐疑的です。私はそのような主張を聞いたことがあり、それが真実であった単一の事例を思い出すことはできません。いくつかのコードを表示することで私を納得させることができるかもしれませんが、私の経験ではそうは思われません。
そのままにしておきます。
開発者は実際には、本来の目的を果たし、それ以上は行わないレガシープロジェクトを承認します。
今日、コードベースを「ステージング」して「将来」の要件を満たすための良いアイデアのように見えるものは、おそらく、将来のコードを理解する上での障害となるでしょう。部分的に実装された機能や忘れられたファントム要件の痕跡に対処することを好む人はいません。そうだとは言いませんが、最善の意図にもかかわらず、物事はしばしばそのようになります。
良い答え。私は追加するだけです-このような場合に私がすることは、私がやったことをキャプチャして安全な場所にそれを追い出すことができるように、良い差分を取ることです。そうすれば、次のバージョンで再びそれを行う機会があれば、それは簡単です。
一般に、優れた開発者は将来の要件を予測しますが、締め切りが迫っているときは、「ボートを揺さぶる」のではなく、すでに入手したバグに対応するときです。
場合によります。古き良きルールがあります。自分で扱いたいように他の人を扱います。それがあなた自身のプロジェクトであり、すべての優先事項を知っていたらどうしますか？
V2が確実に必要で、締め切りが厳しい必要ではなく単なる願いである場合は、技術的な負債を生み出さず、天候が良いときにセールを修正しないでください。他の誰かがv2を実行する場合でも、その先見性は高く評価されます。
V2の必要性について疑問がある場合は、YAGNIを使用してください。また、あなたがスペクトルの反対側にいて、彼らが形成する前にアイデアを常にスパムしているそれらのクライアントの1人がいて、メールを1日に2〜3回だけチェックし、アクションで急いでいない場合、あなたは驚かれることでしょうあなたがそれらを読む前にどれだけの「問題」と要求が無関係になるか。