complexity-theory - 複雑なソリューションや設計をどのように防ぎますか?

Question

多くの場合、私たちは問題に取り組んでいることに気づき、作成されたソリューションが問題が必要とするよりもはるかに複雑であることを理解するだけです. 職場での合併症を制御するのに役立つコントロール、ベストプラクティス、テクニックなどはありますか?

score 13 · Accepted Answer

13

新しい人に見てもらう。

于 2008-09-17T18:49:45.350 に答える

score 6 · Accepted Answer

テストが難しすぎる場合は、設計が複雑すぎます。それが私が使用する最初の指標です。

score 5 · Accepted Answer

私の経験では、過度に一般的なケースの設計は、複雑になりすぎる傾向があります。

エンジニアリング文化は、環境に関する仮定を少なくする設計を奨励しています。これは通常は良いことですが、やり過ぎてしまう人もいます。たとえば、あなたの車の設計が特定の引力を想定していない場合、それは素晴らしいことかもしれません。実際に月であなたの車を運転する人は誰もいません。仮にそうしたとしても、作る酸素がないため機能しません。燃料燃焼。

難しいのは、「あらゆる惑星で機能する」設計を開発した人物は、しばしば賢いと見なされることです。そのため、彼の設計が巧妙すぎると主張するには、もっと努力する必要があるかもしれません。

トレードオフを理解して、良い仮定と悪い仮定の間で決定を下すことができれば、不必要に複雑な設計を回避するのに大いに役立ちます。

score 3 · Accepted Answer

設計をよりシンプルにするためのいくつかのアイデアを次に示します。

プログラミングの本や記事を読んで、それを自分の仕事に適用してコードを書く
他の人 (オープンソースプロジェクトなど) によって書かれた多くのコード (良いものも悪いものも) を読み、何が機能し、何が機能しないかを学びます。
セーフティネット (単体テスト) を構築して、コードの実験を可能にする
これらの実験が間違った方向に進んだ場合は、バージョン管理を使用してロールバックを有効にします
TDD（テスト駆動開発）とBDD（ビヘイビア駆動開発）
態度を変えて、どうすれば「簡単に機能する」ようにできるかを尋ねてください(設定よりも規則が役立つかもしれません。または、Apple がどのようにそれを行うかを尋ねてください)。
練習 (ジャズ奏者のように -- コードでジャム、Code Kataを試す)
同じコードを複数回、異なる言語で記述し、しばらくしてから
新しい概念で新しい言語を学ぶ (静的言語を使用する場合は動的言語を学び、手続き型言語を使用する場合は関数型言語を学ぶ...) [年に 1 つの言語が適切です]
誰かにあなたのコードをレビューしてもらい、コードをよりシンプルでエレガントにする方法を積極的に尋ねてください (そしてそれを作る)
上記のことを行うことで、あなたのベルトの下で何年も過ごすことができます（時間はアクティブな心を助けます）

score 2 · Accepted Answer

テスト駆動開発を使用し、Robert C. Martin のTDD の 3 つのルールに従います。

失敗した単体テストに合格する場合を除き、製品コードを書くことは許可されていません。
失敗するのに十分な以上の単体テストを作成することは許可されていません。コンパイルの失敗は失敗です。
失敗した 1 つの単体テストに合格するのに十分な量を超える製品コードを記述することは許可されていません。

このようにして、不要なコードを取得する可能性は低くなります。常に 1 つの重要なことを機能させることに集中し、複雑さの点で自分より先を行くことはありません。

score 2 · Accepted Answer

Michael C. Feathers による「レガシーコードを効果的に使用する」をお読みください。

要点は、機能するコードがあり、設計を変更する必要がある場合、コードユニットをテスト可能にし、コードを小さな断片に分割することほど効果的なものはないということです。

score 2 · Accepted Answer

私はデザインなどを作成し、それを見て、不要と思われるものをすべて (積極的に) 削除しようとします。後でデザインを磨くときに必要になった場合は、それを元に戻します。これを何度か繰り返して、改良を重ねます。

score 1 · Accepted Answer

ここでは最初のテストが役立つ場合がありますが、すべての状況に適しているわけではありません。そして、それはとにかく万能薬ではありません。

小さく始めることも素晴らしいアイデアです。本当に10個のデザインパターンすべてをこのものに詰め込む必要がありますか？最初に「ばかげた方法」でやってみてください。完全にカットしませんか？さて、それは「少し愚かな方法」で行います。等。

レビューを取得します。他の誰かが書いたように、2つの目がより良いです。さらに良いのは2つの頭脳です。あなたの仲間は、単純化の余地があるか、ハッキングに何時間も費やしたからといって問題のある領域が問題ないと思っているかもしれません。

無駄のない言葉を使う。JavaやC++などの言語は、厄介で複雑なソリューションを奨励しているように見えることがあります。単純なものは複数行のコードにまたがる傾向があり、3つの外部ライブラリと大きなフレームワークを使用してすべてを管理する必要があります。Python、Rubyなどの使用を検討してください。プロジェクトに使用しない場合は、個人的な使用に使用してください。それはあなたの考え方を変えてシンプルさを支持し、シンプルさが可能であると確信することができます。

score 0 · Accepted Answer

あらゆる段階で他のプログラマーと話してください。デザインに目を向けるほど、コードベースで骨が折れる前に、過度に複雑な側面が早期に明らかになる可能性が高くなります。
現在取り組んでいるものをどのように使用するかを常に自問してください。答えがわからない場合は、やめて自分がしていることを考え直してください。
私が現在取り組んでいることを潜在的に単純化する方法についての考えを書き留めておくと便利だと思いました。そうすれば、実際に機能させたら、まだ機能していないものをいじるよりも、必要に応じて戻ってリファクタリングまたはやり直しする方が簡単です。

score 0 · Accepted Answer

これは微妙なバランスを取る行為です。一方では、設計と実装に時間がかかりすぎるものは必要ありませんが、他方では、来週の問題に対処するのに十分なほど複雑でないハックは必要ありません。またはさらに悪いことに、適応するために書き直す必要があります。

私が役立つと思ういくつかのテクニック：

何かがあなたが望むよりも複雑に見える場合は、それについて考え終わったらすぐにそれを実装するために座ってはいけません。その日の残りの時間に何か他のことをしてください。多くの場合、私は問題の初期の部分に対する別の解決策を考えてしまい、後で複雑さの多くを取り除きます。

同様に、アイデアを跳ね返すことができる誰かがいます。複雑さが正当化される理由を彼らに説明できることを確認してください！

将来的に正当化されると思われるために複雑さを追加する場合は、将来いつそれを使用するかを確立してみてください。（現実的に）1、3年の複雑さの必要性を想像できない場合は、今すぐ支払うのはおそらく正当化されません。

score 0 · Accepted Answer

時間をかけてシステムの概念に名前を付け、関連する名前を見つけてください。これにより、システムがより親しみやすくなります。概念の名前を変更することを躊躇しないでください。あなたが知っている世界とのつながりが良くなればなるほど、あなたの脳はそれとうまく連携できるようになります。

クリーンでシンプルなソリューションからキックを得る人々からの意見を求めてください。

現在のプロジェクトに必要な概念のみを実装します（将来の保証または汎用システムへの要望により、設計が肥大化します）。

score 0 · Accepted Answer

タスクを一連の小さなタスクにシリアル化することで、処理するデータの量を減らします。ほとんどの人は、コーディング中に頭の中に半ダース (プラスまたはマイナス) の条件しか保持できないため、それを実装の単位にします。達成する必要のあるすべてのタスクを設計しますが、モジュールを介して半ダース以上のパスをいじる必要がないように、設計を容赦なくハックします。

これは、Bendazo の投稿に続きます - 簡単になるまで単純化します。

score 0 · Accepted Answer

なぜ機能が必要なのかを顧客に尋ねます。私は彼らの要求の真相を突き止め、彼らが経験している問題を特定しようとします。これは、多くの場合、私 (または彼ら) が考えるよりも簡単な解決策になります。

もちろん、クライアントの仕事の習慣と、彼らが取り組まなければならない問題を知っていれば、最初からクライアントの問題をよりよく理解できます。そして、あなたが彼らを「知っている」なら、彼らのスピーチをよりよく理解できます。そのため、ユーザーと緊密な協力関係を築いてください。エンジニアリングのステップゼロです。

score 0 · Accepted Answer

プログラマーになったら、これが起こるのは避けられません。労力を真剣に見積もっていなかったり、ソリューションが機能しないという問題に遭遇した場合は、コーディングをやめて、プロジェクトマネージャーに相談してください。私はいつも会議に解決策を持っていくのが好きです。問題は A です。3 日かかる x を行うか、6 日かかる y を試すことができます。自分で選択しないでください。

complexity-theory - 複雑なソリューションや設計をどのように防ぎますか?

14 に答える 14

Related

Reference