将来の変更に備えて設計するか、手元の問題を解決する[終了]

コードの作成中または設計中に、最初のインスタンス自体で問題を一般化しようとしますか、それとも非常に具体的な問題を解決しようとしますか。

問題を一般化しようとすると物事が複雑になる傾向があるため（これは必要ではないかもしれません）、一方で、要件に変更があると特定のソリューションを拡張することは非常に困難になるため、私はこれを求めています。

解決策は、言うよりも簡単な中間パスを見つけることだと思います。この種の問題にどのように取り組みますか？どのくらいの時点で一般化を開始したら、これだけの一般化で十分であることがわかりますか？

将来のために設計しようとすると、あまりにも頻繁に、将来のニーズに関する予測が間違っていることが判明します。通常、ニーズがどのように変化したかを実際に知っているときにリファクタリングする方が、初日にシステムを過剰設計するよりも優れています。同時に、自分自身を足で撃たないでください。確かに妥協点があり、それがどこにあるかを知ることは科学よりも芸術です。

それを1つの経験則に要約するために：少ないことは多いです。

アジャイルに精通していますか？アジャイルの大きな原則の1つはYAGNIです。それが物事にアプローチする最良の方法だと思います。

「あなたはそれを必要としません」 ...は、プログラマーが必要だと思われるまで機能を追加すべきではないという極端なプログラミング（XP）の原則です。ロンジェフリーズは次のように書いています。

... YAGNIは、「動作する可能性のある最も単純なことを実行する」（DTSTTCPW）のXPプラクティスの背後にある原則です。継続的なリファクタリング、継続的な自動化された単体テスト、継続的な統合など、いくつかの他のプラクティスと組み合わせて使用​​することを意図しています。継続的なリファクタリングを行わずに使用すると、厄介なコードと大量のリワークが発生する可能性があります。連続的なリファクタリングは、セーフティネット（予期しないバグを検出するため）としての自動化された単体テストと、広範な統合の問題を防ぐための継続的な統合に依存しています...

YAGNIは、サポートプラクティスと組み合わせても、有効な原則として広く受け入れられているわけではありません。スタンドアロンで使用するのではなく、サポートプラクティスと組み合わせる必要性は、XPの元の定義の一部です...

"YAGNI"と "PYIAC"（Paint Yourself Into A Corner）の境界線を歩く必要があるため、これはおそらくソフトウェア開発の最も難しい部分の1つです。

「必要でない限り、機能を記述しないでください」と言うのは非常に簡単です。難しい部分は、後で必要なときに簡単に機能を追加できるようにコードを設計することです。

重要なのは、現在必要なコード以上のコードを記述しない拡張可能なアーキテクチャを設計できるようにすることです。これを上手に行う能力は、本当に多くの経験（および痛み）から来ています。

設計の一般的な方向性について前もって考えるのに少し時間を費やします-それほど多くはありませんが、基本的に高レベルの概要をスケッチするには十分です。次に、TDDを使用したスト​​ーリーベースのアジャイル手法に従って、個々のストーリーのソリューションを開発します。TDDを使用して実装しているため、高レベルの概要を念頭に置き、（a）特定の実装に高レベルの概要に従うよう指示するか、（b）に基づいて高レベルの理解/方向をリファクタリング（および改善）しますテスト/実装中に学んだこと。

前もって計画を立てないのは間違いだと思いますが、やりすぎるのはおそらくもっと大きなことです。可能な限り、全体像を案内し、アプリケーションをどのように開発するかを心に決めた線に沿ってデザインを有機的に成長させてください。TDDを使用すると、設計自体がより良い設計原則（分離、単一の責任など）に追い込まれ、全体を先取りして開発をそれに合わせようとする場合よりも、変更に関してより順応性があることがわかります。

優れたデザインは将来の変化に対応し、間違いなく価値があります。UNIXオペレーティングシステムとその「すべてがファイルの哲学」を検討してください。この設計上の決定は、当面のニーズを満たすためではなく、将来の要件を考慮して行われました。「アジャイル」設計に基づいたオペレーティングシステムがどのようになるかを考えると、身震いします。

対処しようとしているのは、再利用（つまり、現在処理している問題を一般化して、将来作業（コード）を再利用できるようにすること）に関係しています。前に言ったことがありますが、再度リンクします。

私は他の人が次の効果について何かを言うのを聞いたと思います：

最初に問題を解決します。初めてソリューションを繰り返すとき、私はそれを書き留めます。もう一度繰り返すと、リファクタリングします。

「今+ 1」の設計。つまり、当面の問題を解決し、次に変更を要求するときに十分な機能を組み込み、すでに半分（またはそれ以上）完了し、a）すぐに解決するか、または後でリファクタリング、またはb）「今+ 1」を再度解決する（「今」の半分を完了）

これはプロジェクトに依存します。要するに、経験は「+1」が何であるかを教えてくれます。

YAGNIの哲学、あなたはそれを必要としません、と要約できます（記事から）：

YAGNIアプローチを支持する人々によると、現時点では必要ではないが、将来的には必要になる可能性があるコードを記述する誘惑には、次のような欠点があります。

• 費やされる時間は、必要な機能の追加、テスト、または改善に費やされます。
• 新機能は、デバッグ、文書化、およびサポートする必要があります。
• 新しい機能は将来何ができるかに制約を課すため、不要な機能により、必要な機能を後で実装できなくなる可能性があります。
• その機能が実際に必要になるまで、何をすべきかを完全に定義してテストすることは困難です。新しい機能が適切に定義およびテストされていない場合、最終的に必要になったとしても、正しく機能しない可能性があります。
• コードが肥大化します。ソフトウェアがより大きく複雑になります。
• 仕様とある種のリビジョン管理がない限り、この機能はそれを利用できるプログラマーには知られていません。
• 新しい機能を追加すると、他の新しい機能が提案される場合があります。これらの新機能も実装されている場合、クリープ機能に雪だるま効果が生じる可能性があります。

私は、「いつか必要になるかもしれない」という理由から、あなたが対処しなければならないすべてのケースを推測しようとして、手元の問題に合わせて設計し、設計を吹き飛ばさないことを大いに信じています。

基本的に、特定の要件のリストが与えられている場合、それに対して設計しますが、これは次のことを行うべきではないという意味ではありません。

• 設計の側面をソリューションでハードコーディングするのではなく、構成可能にします。実行時に渡されるパラメーターを介して、または起動時に（またはHUP後）に読み取られた外部構成を介して。
• コードをマジックナンバーでレースします。
• おそらく、既存のソリューションを適応させて、既存の状況と新しい要件に適したアプローチを提供した後、再利用できるものがすでに書かれているかどうかを確認しないでください。

「可能性のある未来」のために設計することの主な問題は、常に推測していることです。おそらく経験に基づいた推測を行いますが、「プッシュが突き出たとき」は、まだ単なる一連の推測です。

これを行うことにより、既知の要件で定義された特定の問題を解決するのではなく、一般的なケースに合うようにソリューションを絞る可能性が非常に高くなります。

どういうこと？「持っているのがハンマーだけだと、すべてが釘のように見え始めます。」

誰かが言うのを聞くたびにポンドがあればいいのに、「しかし、それは将来見られるかもしれない一般的なケースにより適応できるソリューションだ」と。