5

G'day、

将来起こりうる変更に備えて過剰設計することについてここでこの質問について考えている間、私は考えさせられました。

「将来のある段階で他の場所で使用したいと思うかもしれない」という理由でデザインを吹き飛ばすことを主張する人々に、どのような理由を提供できますか？

同様に、人々が要件を受け入れてから、あなたが求めていなかった余分な「ベルとホイッスル」がたくさんある肥大化したデザインで戻ってきたとき、あなたはどうしますか？

現在または近い将来に存在する要件または考えられる用途に意味があることがわかっている場合、設計を拡張することは理解できます。そして、私は、要件のリストを簡単に受け入れて、不足していると思われるものについてのフィードバックを提供せずに、それを明示的に実装することを主張しているのではありません。

私は、人々が「将来のある段階でそれをどこかで使用するかもしれない」ために、無関係な機能を追加したり、持ったりすることを主張するときにどうするかについて話している。

4

8 に答える 8

5

ウィキペディアには十分な理由がたくさんあります。

http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

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

参照: http://en.wikipedia.org/wiki/KISS_principle

于 2009-06-29T14:23:20.193 に答える
3

特に組み込みデバイスでは、サイズはお金です (たとえば、より大きなフラッシュ パーツは、より多くの費用がかかり、製造時のプログラミング時間が長くなります。または、より多くの周辺コンポーネント)。

Windows アプリケーションであっても、アプリケーションが大きくなり、機能が増えるほど、開発コストが高くなります。何が必要で何が不要かがわかるまで待ってください。そうすれば、まったく必要とされていないことが判明したものを開発するための無駄なお金を大幅に減らすことができます。

また、機能を追加すると、バグが発生する可能性があります。

何かを開発する前に要件について適切に考えるのは良いことですが、過剰な設計は多くの場合、トラブルを借りているだけです。

于 2009-06-29T14:23:54.107 に答える
3

彼ら：「将来どこかで使用するかもしれません。」

私: 「はい、そうするかもしれません。そうしないかもしれません。そして、今、どのような方法でやりたいのかを知ることはできません。そして、将来のある段階でそれを望んでいる場合は、その時です。そのときこそ自信を持って書くことができます 一方、今日書いたのにまったく必要がなかったとしたら、必要のないものを開発するためにリソースを浪費したことになりますコードの肥大化に加えて、使用中のコード ベースの断片を見つけるのが難しくなっています。なぜなら、この (現在) 不要なコードがすべて有用なものを締め出しているからです。」

于 2009-06-29T14:24:36.383 に答える
3

私たちのチームでは、「YAGNI」とだけ言っています。それは人々に理由を思い出させます。レポートを提供するために照合する必要があると思われる場合は、YAGNI に関する情報がウェブ上に十分すぎるほどあります。

実際、私たちのチームの誰かがあなたに「YAGNI」と言うのは少しカットされます。:)

于 2009-06-29T14:25:17.647 に答える
1

それはバランスです、原則として、私はそうするのが安いところだけをデザインします。たとえば、2 つのパラメーターを受け取ってそれらを追加する関数を作成するのではなく、n 個のパラメーターを受け取ってそれらを追加する関数を作成します。ただし、n パラメータを取り、アセンブリを使用してそれらを追加する関数は作成しません。

于 2009-06-29T14:23:42.063 に答える
1

あなたは言う

現在または近い将来に存在する要件または可能な用途に対して理にかなっていることがわかっている場合、設計を拡張することは理解できます。

そして、あなたにとっては「理にかなっている」が、他の誰かにとっては過度に設計されているかもしれない、この線がぼやけていると見る人もいると思います。

于 2009-06-29T14:24:53.870 に答える
1

オーバーデザイン(必要以上に一般的な方法で問題を解決すること) は、余裕がある場合にのみ、アーキテクチャの特定の部分を受け入れることができます。

余分な機能(一般的にオーバーデザインとは異なります) を受け入れる場合は、それに伴うコスト (時間 ==> お金) を受け入れる必要があります。 )

于 2009-06-29T14:27:04.100 に答える
1

将来の機能を提供することと、将来の機能を追加することには大きな違いがあります。優れた設計には、新しい機能や変更を提供するための「フック」またはその他が必要です。

この状況に対処するには、2 つの方法があります。最初の方法は、彼らが請負業者であり、ソフトウェアを提供している場合です。すべての追加機能への支払いを拒否し、必要な機能に対して非常に厳しい期限を課すことができます。彼らが締め切りに間に合わなかった場合、あなたは彼らが遅れた日ごとに金銭的な罰則を課します.

もう1つの方法は、それらが実際にあなたのために働くかどうかです. このような場合は、それらを削除するか、パフォーマンス レビューでダウングレードすることができます。

于 2009-06-29T14:28:23.647 に答える