8

ソフトウェアの設計担当者は、非常に複雑なアーキテクチャを思いつきます。

ユーザーが決して知らない難解な機能をすべて備えていて、すべての雑誌の記事が最新のクールなことだと言っていることをしているときにその達成感を得るのは、すべて問題なくダンディーですが、私たちはお金を費やすつもりです.私たちの巧妙さの記念碑であるエンジニアリング時間の半分であり、ユーザーが必要とする実際の製品ではなく、上層部の経営陣が合理的な、または少なくとも制限された時間枠内で完了することを期待しています。

そして、時間がなくなり始めたとき、つまりその機会があれば、とにかく単純なソリューションに戻らなければならないでしょう.

Keep It Simple, Stupid™ というフレーズを聞いたことがあるでしょう。

チーム内の過度の複雑さとどのように戦っていますか?

私が最近繰り返し取り組んだ例の 1 つは、RDBMS ではなく、完全に非正規化されたデータベース設計に移行するという決定が下されたときです。「速いから！」完全に非正規化されたデータベースを正しく作成するのは非常に難しく、Flickr や ebay などの非常に特殊なデータの問題にのみ適しています。また、開発の残りの部分に比べて開発者の時間が非常に高くなる可能性があります。

4

14 に答える 14

12

歯と爪、時には失うこともあります。問題は、何かクールなものを構築したいという誘惑に駆られやすいことです。

複雑で素晴らしいものになる可能性があるのに、なぜシンプルで効率的なものを構築するのでしょうか?

動作する可能性のある最も単純なものを構築するという XP のルールを人々に思い出させるようにしてください。

于 2009-03-02T16:38:18.687 に答える
6

私はどこかでこの式を見ました：

スキル=問題の複雑さ/ソリューションの複雑さhttp://img39.imageshack.us/img39/1586/whatisskill.png

言い換えれば、複雑な問題に対する簡単な解決策を作成するにはスキルが必要です。誰かが意図的に設計し、複雑な過剰設計されたソリューションに誇りを持っている場合、彼は無意識のうちに無能です。

個人的には、デザインをシンプルに保つのに役立つのはTDDサイクルです。まず、到達しようとしているものを指定するテストを作成してから、「機能する可能性のある最も単純なもの」を作成します。そして時々、あなたが生み出したものを振り返り、それをよりシンプルにする方法を考えてください。

現在持っているもので必要になるまで、システムに余分な柔軟性と抽象化レイヤーを構築しないでください。優れた単体テストスイートがあれば、コードの変更は簡単です。そのため、必要が生じた場合は、後でそれらの抽象化レイヤーを追加できます。そうでなければ、「あなたはそれを必要としないだろう」。

設計が複雑すぎる場合のいくつかの症状は、テストの作成が複雑な場合です。テストに長いセットアップコードが必要な場合は、依存関係が多すぎるか、他の方法で複雑すぎる可能性があります。並行性のバグに遭遇した場合は、並行性がクラスの絶対最小数に制限されるようにシステムを設計する方法を検討する必要があります。おそらく、アクターモデルなどのメッセージパッシングアーキテクチャを使用して、システム全体がマルチスレッドであっても、実質的にすべてのコンポーネントをシングルスレッドにします。

于 2009-05-30T17:16:40.980 に答える
6

あなたが持っているアイデアを他の誰かにぶつけてください。多くの場合、私たちは特定の方法で物事を行うことに夢中になり、あなたを正しく設定するには別の目が必要です. 他の誰かに「本当にそれが必要なの？」と言ってもらうことで、難しい問題を解決したことが何度もありました。これにより、コードが単純になります。

あなたが同意しない人々に対処するという点で、ウォード・カニンガムは良い点を持っています:

すべての議論に勝つ必要はないことに気付いたのは、私のプログラミング キャリアのターニング ポイントでした。コードについて誰かと話していると、「それを行う最良の方法は A だと思います」と言うでしょう。そして彼らは、「それを行うための最良の方法はBだと思います。私は、「いや、それは本当にAです」と言い、彼らは「まあ、私たちはBをやりたい」と言うでしょう. 「いいよ。B を実行します。私が間違っていても、それほど害はありません。私が正しく、あなたが B を実行しても、私たちはそれほど傷つくことはありません。なぜなら、私たちは間違いを修正できるからです。それで、それが間違いかどうかを調べてみましょう。... 通常は C であることがわかります。これは、私たち二人にとって学習経験です。経験なしで決定した場合、私たちのどちらも実際には学びません。ウォードが勝ったが、他の誰かが勝てなかった。またはその逆。戦いすぎです。「まあ、コードを書いてどうなるか見てみましょう。うまくいかない場合は、変更します」と言ってみませんか。

私のアドバイス？何かを改善したい場合は、それがより優れていることを示す簡単なプロトタイプを考え出してください。意見は素晴らしいですが、コードは話します。

于 2009-03-02T17:38:35.233 に答える
4

少なくとも私にとっては、より大きな問題は、流行語に親しみやすく、雑誌のようなエンタープライズ向けの優れた機能が含まれているため、どの機能が含まれているのか、将来的に役立つ柔軟性のレベルが追加されるため、どの機能が含まれているのかを判断するのが難しいことが多いことです.

一般に、人々は将来の複雑性や現在の決定の副作用を予測するのが苦手であることが示されています。残念ながら、これは常に最も単純なものが最善であるとは限りません。私の場合、最初は複雑すぎると思ったことがたくさんあり、かなり後になるまでその価値がわかりませんでした (ええと... 春)。また、私が理にかなっていると思っていたことが、非常に複雑であることが判明しました (EJB1)。ですから、これらのことについての私の直感が間違っていることを私は知っています。

最善の策 - 追加される柔軟性と追加される開発の複雑さの値をサポートする引数を使用して、あらゆる種類の間接レイヤーをサポートする必要があります。

しかし、抽象的な根拠に基づいて独断的に特定のデータベース設定を維持している人々は、おそらく「それが正しいことだと読んだのでそれを構築する」キャンプにいます。それは非現実的かもしれませんが、テスト バージョンとベンチマークを構築すれば、特にパフォーマンスの大幅な向上につながるより多くの努力が結果に示されている場合は、納得する人もいるでしょう。

于 2009-03-02T16:48:33.480 に答える
3

ユーザーが決して知らない難解な機能をすべて備えているのは、すべて問題なくダンディです...

これは機能クリープであり、不必要に複雑な設計ではありません。データベースの例とは異なります。

私が最近繰り返し取り組んだ例の 1 つは、RDBMS ではなく、完全に非正規化されたデータベース設計に移行するという決定が下されたときです。「速いから！」

この場合、いくつかのことが起こっている可能性があります。そのうちの 1 つは、あなたが間違っている可能性があり、これらの人々は非常によく似た例を扱っているため、彼らの言っていることを本当に理解している可能性があるということです。もう 1 つは、彼らが間違っている可能性があることです。つまり、彼らの設計は、彼らが主張する速度の利点を提供していません。この場合、2 つの異なる状況が考えられます。(1) 設計で速度を重視しすぎているか、(2) 速度が非常に重要です。速度が本当に重要である場合、チームは仮定だけに頼るべきではありません。さまざまなプロトタイプを試して、クリティカル パスでの速度を評価する必要があります。「速いから」という理由だけで F1 カーを作るのではなく、代わりの設計ソリューションをいくつか試して、メンテナンス コストをそれほど増加させない最速のものを選びます。

議論して合意に達することもあれば、そうでないこともあります。それは人生です。

ただし、最後に一言。複雑さと戦わない。あなたはそれを扱います。あなたは本当に重要なことを特定し、それに応じて行動します。

于 2009-03-02T17:01:25.773 に答える
2

私が見つけた最善の方法は、「私たちが解決しようとしているビジネス上の問題は何か」と「この決定がその問題の解決にどのように役立つか」を何度も何度も尋ねることです。

問題が何であるかを明確にするのではなく、解決策に飛びつく人が多すぎることがわかりました。

したがって、データベースを編成する方法の例では、私の質問は「今日、来月、来年、今から5年後のこのプロジェクトのトランザクション要件は何だと思いますか」です。データモデルを正しくするために多くの時間を費やすことは理にかなっているかもしれません、それは時間の無駄かもしれません。問題の定義を明確にするまで、パラメータが何であるかはわかりません。

于 2009-03-02T18:45:19.613 に答える
2

リレーショナル モデルは、正規化されているかどうかに関係なく RDBMS によって管理されるため、「正規化された (たとえば、第 3 正規形または第 4 正規形) モデルではなく、完全に非正規化されたデータベース設計」という意味だと思います。

自分の要件、自分の能力、チームメイトの能力について詳しく知らなければ判断できません。

この場合、あなたの KISS の忠告はうまくいかないのではないかと心配しています。

この種の問題をどのように解決しますか？コミュニケーション、説得、より良いデータ、代替技術と技術のプロトタイプ。これがソフトウェア開発を難しくしている原因です。これらのことを行う方法が 1 つしかなく、全員がそれに同意した場合、それをスクリプト化するか、誰かにシステムを開発してもらい、それで完了させることができます。

いくつかのデータを取得します。あなたの言葉では足りないかもしれません。簡単なプロトタイプで要点を実証できる場合は、それを作成してください。

「強い意見、控えめ」がモットーです。

技術的なポイントがチーム全体を遠ざける価値がない場合があります。時々そうです。あなたの電話。

于 2009-03-02T16:43:23.867 に答える
1

「チームにアーキテクトが多すぎる」症候群に苦しむかもしれません。せいぜい 1 人か 2 人が、5 人から 10 人のチームによってコーディングされるシステムを設計/構築する必要があります。誰からの意見も歓迎しますが、アーキテクチャの意思決定者は少数で経験豊富であるべきです。

(数字は半ランダムであり、他の要因によっても異なる場合があります)

于 2009-03-02T16:39:16.483 に答える
0

関係者には、単純な解決策を見つけるのに十分な時間と動機がありますか? 注意を怠ると、複雑さが増します。可能な限り迅速なバグ修正や機能追加を行うことにほとんどの時間を費やしている場合、「シンプルに保つ」というだけでは十分ではありません。

チームには、大規模なプログラムを維持するために戦争の傷を負った人や、リファクタリングの経験がある人がいることを確認してから、ソフトウェアを整理する時間を与えてください。特定の機能と機会が範囲外になるように調整できれば、不要なコードを削除するのに役立ちます。メトリックが必要な場合は、コード行を減らすことを目指してください。しかし、それに執着しないようにしてください。テスト範囲を改善します。テストが難しいコードの一部を削除することを検討してください。

于 2009-03-02T17:24:35.330 に答える
0

物事について話し合うときは、オープンになるようにしています。しかし、単純に見えることと別の複雑なことの間で誰かと話し合っているとき、私はできる限り頑固になります。ある決定から別の決定へと非常に首尾一貫している限り、それは非常に役立ちます。

于 2009-03-02T16:39:29.603 に答える
0

あなたの例は実際には複雑な設計ではなく、同意しない設計の選択です。あなたはコードに取り組んでいるので、これらの決定の多くは記事の記事を読んでそれが良い目標のように聞こえると考える人々によって行われるため、簡単に正しい可能性があります。以前に問題が発生し、再発を防止しようとしていました。

個人的に、私は多くのことを簡単な方法で行い、多くのことを難しい方法で行ってきました。困難な方法よりも簡単な方法で何かを行うことを選択したとき、私は決して幸せではありません. 今では、「ネイキッド コレクションを渡すのではなく、常にビジネス クラスでラップする」などのトリックを学びました。

同じ経験をしたことがない人にその理由を説明すると、「楽な道」と「大変な道」を何度か比べてみないとわからないでしょう。

于 2009-03-02T17:18:12.240 に答える