スタックオーバーフローでは、多くの場合、人々（特にプログラマー）は、元の問題よりもはるかに複雑なソリューションの問題の解決を過度に複雑にする傾向がありますか？私は決して専門家ではありませんが、最も簡単な解決策を試してみます（そして明らかにこれはどこでも機能しません）が、人々が思われる仕事で簡単な解決策を提案することでかなりの成功を収めましたもっと複雑なソリューションを見落とすことはありませんか？

これはプログラマーにとっては普通のことなのでしょうか.....または、私は正しい見方で考えているだけではありませんか。

明らかに、一部のプログラマーは、誰も理解できない非常に複雑なコードを作成することで、彼らがどれほど賢いかを示すことに熱心です。他のプログラマーは非常に高いレベルで発砲しているため、ソリューションの複雑化は自然な進化です。

私が今まで見た中で最悪のコードのいくつかは、2000行を超えるコードを含むメソッドでした。間違いなくこのコードは複雑でしたが、非常に貧弱でもありました。

優れたプログラマーは、過度に複雑なコードを避けると思います。これには、設計パターンを実際にそれを必要としないソリューションに適合させる誘惑を回避することが含まれます。また、神オブジェクト、魔法のボタン、時期尚早の最適化、時期尚早の一般化、およびその他のアンチパターンの回避も含まれます。

複雑さの成長は有機的なものであるため、私は常にリファクタリングを行い、ソリューションを簡素化する機会を探しています。他の多くの有機物と同様に、使用し続けたい場合は、トリミングして剪定する必要があります。複雑さが増すと、コードが破損する可能性が高くなるため、過度に複雑なソリューションとやり取りする必要はありません。

可読性はコードメンテナンスの最も重要な要素であり、過度に複雑なソリューションはほとんど常に可読性を低下させ、メンテナンスコストを増大させると思います。

必要以上に複雑で、ほとんど常に次の3つの理由で、多くのコードを見てきました。

1）時期尚早な一般化のため、または決して発生しない将来のニーズを予測しようとするため、過剰に設計されている

2）開発者は、以前は使用したことのなかった新しいデザインパターンまたはテクノロジーで学習/実験したいと考え、それが過剰であったとしてもそれをくつがえしました。彼らはそれが彼らの仕事をより面白くして、彼らが何か新しいことを学ぶようになるので、それをします。

3）機能とバグ修正が追加されましたが、同時に既存のコードは正しくリファクタリングされませんでした。それはほんの小さな複製であるか、メソッドに別のフラグ引数を追加するだけかもしれませんが、すべてが加算されます。事実上、ハッキングが追加され、すべてのコードの匂いのためにすべてが複雑になりすぎるのに時間がかかりません。これが最も一般的であり、通常は、より良いことや時間のプレッシャーを知らないためです。

それは絶対に一般的なことです。ほとんどの本が言うように、優れた開発者はそれをシンプルに保つ方法を知っています。見つけたばかりの新しいテクノロジーや「クールな」フレームワークで何かを複雑にするのは簡単すぎるため、問題の観点から考えるのではなく、使用方法を探し始めます。

マーティン・ファウラーが言ったように、新しい技術を学ぶ人は、その「技術」がソリューションを駆動するという短期的な問題を抱えています。

すべてのプログラマーにとってこれは正常なことではないと思いますが、多くのプログラマーがこれを行うことは間違いなく見ています。

一部の人々は、本当にシンプルなものを「簡単すぎる」と考えていると信じており、それは彼らのスキルの良いショーケースではないと思います。そのため、彼らは手元の問題に対する最善の解決策ではないかもしれませんが、「私にできることを見てください！」

私は、プログラマーがしばしば言語に既に組み込まれていることを知らなかったタスクを達成するために数行のコードを書くことを見てきました。これは意図的なものではありませんが、確実に防ぐことができます。

それはあなたが「シンプル」と呼ぶものに依存します。より多くのコードと複数の呼び出しグラフがあるため、一部の人々は高度にリファクタリングされたコードをより「複雑」と見なします。ただし、このコードは変更がはるかに簡単であるという点で、より「単純」です。

大きな関数は、変更が必要になるまで「単純」に見えることがよくありますが、それから複雑になります。

言い換えれば、多くの場合、見る人の目から見るとシンプルです。

問題は、単純な解決策を明確に見ることができない場合（同僚との議論が出番である場合）、またはあまりにも早く一般化しすぎる場合です。

つまり、単純なループを高度なライブラリ関数に作成します。とにかく次のプロジェクトで必要になると思われるからです（この正確な形式を使用しない場合を除く）。これをあまりにも長く行うと、非常に単純なコアを持つ非常に複雑なアプリケーションができます。

また、非常に堅牢なコードが必要であり、すべての堅牢性によりデフォルトで複雑になることがあります。しかし、これはあなたの問題だとは思いません。

場合によっては、クリーンでシンプルなソリューションを考え出すだけの複雑さかもしれません。

私が覚えていない、または何かを見つけることができないという引用があります。

明確性の欠如は、人々がすべての過剰を取り除く能力を妨げます。

最高のエンジニアとは、本当に複雑な問題を取り上げ、それらを実装しやすく、理解しやすいソリューションに変えることができるエンジニアです。簡単に聞こえますが、そのようなエンジニア/開発者はそれほど多くはいません。実際、そのような存在する人は多くありません。現実には、そこに住む大多数の人々はまったく逆のことをしています。彼らは単純な問題を取り、認識できないほど複雑にします。単純な問題に対処し、それらを完全な混乱に変えた人々の例については、政治家をご覧ください。プログラマーはこの点で違いはありません。

個人的に、私は意図的にソフトウェアをより複雑にしようとしたことは一度もありません。しかし、私は何かを終えて「すごい、それは複雑すぎる」と考えて、それに戻ってリファクタリングしました。一部の人々はこれを見て、それが機能し、それが十分であり、リファクタリングしないと思うかもしれません。

賢い人は、あなたができるだけ簡単に物事を保つべきであると述べたが、ないより単純なていると言われています。同じことがコードにも当てはまる場合があります。時には、いくつかは複雑と見なす手法を使用する必要があります（再帰は良い例かもしれません。多くの場合、若いプログラマーを怖がらせます）。

ただし、一般的に、複雑なコードはしばしば有機的に発生すると思います。単純な問題は単純なコードで解決され、スコープが拡張され、コードはあまり考えずに変更されます。新しい問題をカバーしようとするが、実際には別の問題を解決するように設計されたコードが得られます。さまざまなロジックのパッチワークキルトになります。そのようなコードは、問題が必要とするよりもはるかに複雑に見えることがよくありますが、当時は小さな変更がコードを機能させる最も簡単な方法であるように思われたため、そのようになりました。

ほとんどの開発者は故意にコードを複雑にしようとは考えていません（自分のスキルを証明するために何らかのテクニックを使用する奇妙なショーを披露しますが）。 。

まだ提起されていないもう1つの理由は、提供されたソリューションを過度に複雑にして、これらのソリューションをサポートするために後でサービスが必要になることを保証することです。言い換えれば、仕事のセキュリティのためです。

たぶん、古典的な間違いの問題ですか？

30.開発者の金メッキ。

開発者は新しいテクノロジーに魅了されており、言語や環境の新しい機能を試したり、別の製品で見た滑らかな機能の実装を自分の製品で必要とされているかどうかに関係なく作成したい場合があります。不要な機能を設計、実装、テスト、文書化、およびサポートするために必要な作業により、スケジュールが長くなります。

• ラピッドディベロップメント、スティーブマッコネル。

はい、私たちは自分自身を楽しませるためにコードを過度に複雑にします。ほとんどの場合、コードが過度に複雑であるという認識は、プロジェクトの無知なまたはジュニア参加者から来ています。

はい...そして、私は何度も代価を支払った。

私のホワイトボードには、最上部にアスタリスクの文があります。

「それが単純でない場合、それは正しくありません」

...そして、ホワイトボード上で何かをプロトタイピングするたびに、常に注目を集めています。

私の複雑なデザインがよりシンプルになり、よりクリーンなコードに変換されるので、本当にうまくいきます。