最近、さまざまな抽象化技術に関連する多くの質問に気づきました。そして、基本的に問題の技術は「あまりにも賢い」と言っている答えがありました。プログラマーとしての私たちの仕事の一部は、解決するために与えられた問題に対する最良の解決策を決定することであり、そのためには賢明さが役立つと思います。

ですから、私の質問は、特定の抽象化手法が賢明さ自体にあまりにも賢明であると考える人たちですか、それとも異議の理由は他にあるのでしょうか？

編集：このパーサーコンビネータは、私が賢いコードだと思うものの例です。これをダウンロードして、約30分間見ました。それから、私は紙の上でマクロ展開を進め、光を見ました。理解できたので、Haskellパーサーコンビネーターよりもはるかにエレガントに見えます。

シンプルなソリューションは、長期メンテナンスに適しています。そして、それは常に言語の親しみだけではありません。特定の言語の専門家であっても、複雑な行（複数の行）を理解するには時間がかかります。ファイルを開いて読み始めます：「わかりました、シンプル、シンプル、わかりました、うん、WTF ?!」あなたの脳は金切り声で止まり、複雑な線を止めて解読しなければなりません。その実装の測定可能な具体的な理由がない限り、それは「あまりにも賢い」です。

複雑さが巧妙なメソッドから巧妙なクラス、巧妙なパターンへと成長するにつれて、何が起こっているのかを理解することは徐々に難しくなります。よく知られているアプローチとは別に、「巧妙な」ソリューションを作成するための思考プロセスを把握する必要がありますが、これは非常に難しい場合があります。

そうは言っても、誰かがそれを理解していないかもしれないという理由だけで、パターンの使用を正当化するときは避けたいです。開発者として学習を続けるのは私たち次第であり、何かを理解していない場合、それを回避するのではなく学習する理由です。

キッスの原理

バカにしてください 賢い解決策は素晴らしいですが、多くの場合、最も単純で単純な解決策が最善です。

「デバッグは、最初にコードを書くよりも2倍難しいです。したがって、コードを可能な限り巧みに記述すると、定義上、それをデバッグするのに十分ではありません。」

ブライアン・カーニガン

愚か者は複雑さを無視します。実用主義者はそれに苦しむ。専門家はそれを避けます。天才はそれを削除します。-アラン・ペルリス

最良のソリューションは、常に最も賢いソリューションではありません。単純な解決策も同様に良い場合があります。

ソフトウェアでは、保守性の観点から常に考える必要があります。コードの一部がそれを維持しようとしている人にとってあまりに賢い場合、私は賢さはそれの価値がないと言うでしょう。

ブライアン・カーニガンを引用するには：

「デバッグは、最初にコードを書くよりも2倍難しいです。したがって、コードを可能な限り巧みに記述すると、定義上、それをデバッグするのに十分ではありません。」

賢さはツールです。それ自体は有害ではありません。必要のない状況でのみ有害になります。

「賢い」は、コードに適用されると、ほとんどの場合、「不必要に複雑な」ためのup曲表現にすぎません。

優れた、明確で、シンプルなコードを読むことは十分に困難です。「賢い」コードを読むことは、ラテン語の詩をもう一度勉強するようなものです。

人の属性としての「賢い」とはまったく異なる意味を持っているため、混乱が生じます。このケースは、実在の人々のためにソフトウェアを設計するのが難しい理由の例として見ることもできます。

また、一部のプログラマーは、コードを「不必要に複雑」であると直接非難することを禁じているほとんどの人が従う社会的プロトコルを理解することに苦しむため、巧妙な言葉の2つの意味を区別するのが難しいと感じるかもしれません。一部の人が考えるかもしれないことに反して、私は最終的に「人々」（共感と内省と忍耐を持っている人々）がより良い開発者になると思います。彼らは誰のために書くべきか知っているからです。

ほとんどの人は、「コードは何をしているのかを理解するには解読が多すぎる」という側面と、それに付随するすべての悪いことの観点から賢さに焦点を当てています。

1. 誰もそれを把握することはできません。ましてや、それを維持/デバッグすることはできません。
2. 書いた人はそれが何をするのかさえ知らない。
3. そもそも、それほど素晴らしいものではないかもしれません
4. 等....

すべての良い点ですが、賢さの別の否定的な側面があり、それは古い自我の問題です。これにより、

1. 他の人のソリューションを使用するには「スマート」すぎる人。同じ猫の皮をむく独自の方法を発明できるのに、なぜ他の人がやったことを探すのですか？
2. 問題に対する最もクールなソリューションを発明したと考える人は、多くの場合、入力を拒否します。
3. 明らかな問題がある場合や些細な変更が必要な場合でも、「自分の」コードを誰にも変更させないでください。
4. 幾分逆に、彼らは彼らが賢いと思っており、彼らがどれだけ賢いかを証明するために「最新の」テクニックを使用する必要があるが、それを重要な部分にロールする前に個人的なプロジェクトまたはそうでなければ非生産コードのいずれかでそれをうまく扱えないシステム。

私たちは皆、エゴが多すぎて有罪になることがありますが、チームの邪魔になると問題になります。

賢い-巧妙なコード行と非賢い代替案の行の比率が高い。20000の記述からあなたを救う20行のコードは非常に賢いです。賢いのは、自分の仕事を節約することです。

悪賢い-書き込まれたコード行と保存されたコード行の比率が低い。5行のコードを記述する手間を省く1行の巧妙なコードが、Bad Cleverです。悪賢いのは、「構文的マスターベーション」です。

ただ注意してください：Bad Cleverは「Bad Clever」と呼ばれることはほとんどありません。多くの場合、エイリアス「beautiful」、「elegant」、「concise」、または「簡潔」の下に移動します。

私は皆の賢い定義について疑問に思う必要があります。

個人的には、許容可能なレベルの効率を維持しながら、難しい複雑な問題を非常にシンプルで簡単な方法で実装したとき、私は賢いように感じます。

tl; drコードレビュー中に、レビュアーが「すごい、これは思っていたよりも簡単だった」と言ったとき、「wtfはこれだけです。」

リストされている理論上の答えは別として、多くの場合、これは他のすべての人にとってあまりにも賢い状況で使用されます。

トップティアのパフォーマンス重視のチームとミディアムティアのメンテナンスチームの間を移動して、「あまりにも賢い」ものの実際の違いを確認してください。

理論の議論を省くと、あまりにも賢いのは、最もスキルの低いチームメンバーが合理的に作業できることに基づいていることが多いため、環境に非常に関連しています。

時々、私はとても賢くて、間違っていることがあります。

性能が高く、保守可能で、タイムリーで安価なのが、ソリューションを測定する方法です。それらの品質に悪影響を及ぼさない限り、賢いものも解決策の一部になり得ると思います。

賢いコード+わかりやすいコード<=シンプルなコードにするために必要なコメントの量であれば、賢いコードに行きましょう。毎回。

問題は、「賢いコード」を書く人が意図的に適切にコメントしなかったときに生じると思います。なぜなら、最初に理解できないことによってのみ、それに遭遇する将来の世代はそれがどれほど賢いかを「評価する」時間を費やさなければならないからです。

良い引用はしばしばそうであるように、私は多くの異なる人々に起因するものを見た引用を思い出します。

言い換えると：

知性のある人なら誰でも、単純な複雑なものを作ることができます。複雑なものを単純にするのは天才です。

複雑な考えを理解しやすくするために単純化することは、コンストラクターの巧妙さを示しますが、単純な考えを取り、複雑にすることは、コンストラクターが巧妙に見えることを望んでいることを示します。

「賢い」ソリューションを理解するのが難しい場合は、使用しないでください。たとえば、副作用によって複雑な計算を1行に縮小できる場合、それは賢いことです。しかし、他の誰かがあなたが世界で何をしたかを理解するのに1時間かかる場合、それはあまりにも賢いです。

私の意見では、賢さ自体は問題ではありません。通常、「巧妙な」（皮肉なし）コードと「洞察に満ちた」コードについて混乱することがあります。私が問題と思うのは、通常、「賢い」（皮肉な）コードには暗黙の目に見えない要件が含まれているため、時間の経過とともにデバッグや保守が難しくなるという事実です。

賢いアルゴリズムはいくつか知られています。クイックソートはIMOです。

「賢い」（皮肉な）コードは通常、設定されている変数と、「賢い」コードから事実上切断されているシステムの状態（以前に開いたファイル、ネットワーク接続、データベースなど）について仮定します。

「賢い」コードを正しく維持するために脳にロードしなければならないデータの量は、通常、費用対効果の比率を大きくするには大きすぎます。

「賢いコード」とは、プログラマーが本当に一生懸命に考えたり、高度なスキルを使って記述したりする必要があるコードのことです。Brian W. Kernighanが最もよく表明する、特定の「賢明なマージン」の必要性を無視するという問題。

「デバッグは、最初にコードを書くよりも2倍難しくなります。したがって、コードをできる限り巧みに書くと、定義上、デバッグするのに十分ではありません。」

創造性の爆発で開発者にとって賢さのように見えるものは、単に混乱として通過し、他の人にとっては読めない、維持不可能な謎のブロックになるだけだからです。

それでも、巧妙で優れたパフォーマンスの謎のブロックですが、経験がある場合は、媒体でそのことを維持するためにビジネス（あなたではなく、開発者）に多くのコストがかかることにしばしば気付くでしょう。または長期。ですから、仲間の開発者が熱中するとき、あなたは仲間の開発者の熱意を静めることを好みます。

もちろん、賢さを正当化する理由がある場合を除きます。そして、あなたが今書いた難読化されたものと一緒に来る良い文書があれば。その賢いコードをコメントしましたよね？それが意図である理由、それがなぜそうである必要があるのか​​、そしてどのように振る舞うのかを説明してください

正当化がない場合、それはおそらく早すぎる最適化、過剰なエンジニアリング、またはYAGNIのような問題のいずれかです。単純な操作を行うのに15レベルの間接参照が必要な場合は、以前のカテゴリにも該当する可能性が高くなります。そして、それが文書化されていなければ、それはただのトラブルです。

優れたコードでは、メンテナーが常に100％であることを理解する必要はありません。良いコードは賢いです。優れたコードはほぼ同じくらい効率的ですが、他の多くの面では優れています。優れたコードでは、アプリケーションの設計に従うために15のビューを持つIDEを必要としません。

注：ちょっと、賢いと思ったものをいくつか書きましたが、それがWTFを引き付けましたか？うち-私の共同開発者でなければ-私のマネージャーの口。彼らの観点からそれを見なければなりません。

私は賢い傾向がありますが、エレガントになるように努めています。

コードを開発し、今他の人が試してみて、避けられないだろうことを、後で。

これは私の経験と他の答えに基づいた問題の私の理解です：

1. 書くのに賢さを必要としたが、読みやすく保守可能なコードは有害とは見なされません。ただし、ほとんどの開発者は、この種のコードを「賢い」とは呼びません。「エレガント」などの別の用語を使用する場合があります。このようなコードが存在するかどうかについては、議論がある場合とない場合があります。
2. 言語に精通したベテランの開発者であっても理解するのにかなりの時間と労力を必要とする本番コードは「賢く」、誰もが有害であると見なされます。
3. 経験の浅い開発者がかなりの時間と労力を必要とする本番コードは、一部の人からは有害と見なされています。私はどちらの方法でも答えを見てきました。そして、すべてを「最も一般的な分母」に保つことを好むと明示的に言った開発者と協力しました。

私は男を知っています。彼はおそらく私が今まで会った中で最も素晴らしい人です。彼は間違いなく信じられないほどのコーダーであり、おそらくプログラミングのチョップの点で私の人生でこれまで以上に優れているでしょう。彼は単語文書を入力しているようにコードを書き、信じられないようなリンクリストを逆にすることができます。真剣に複雑なコードを書くことについて話したいのなら、彼はあなたの男です。信じられないほど難しい問題に出くわしたら、私はいつも彼に頼ります。しかし、チーム設定で彼とプロジェクトに取り組むことは耐え難いものです。彼は、ビジネスの問題を直接ターゲットにし、それに論理的、効率的かつ簡潔なソリューションを提供することはできません。彼にとって、1000行のコードリストは100よりも優れているでしょう。IDEまたはフレームワークを介して提供されたツールを使用する代わりに、彼は独自の超最適化ツールをロールします。

私は彼がこれらの複雑なことを行う能力を賞賛していますが、私が必要とするのは、問題を解決して先に進むことができる人です。言うまでもありませんし、認めることもできませんが、ビジネスの設定時にすべてが問題になる場合があり、問題を解決して人生をやり直さなければなりません。あなたのコード。賢いということと、お尻が痛いということの間には微妙な境界線があります。私のチームのモットーは常に、この状況で機能し、そこから進む最も簡単なことです。時には、単純なものが常に答えとは限りませんが、開始するのに非常に良い場所です。

この文脈での「賢い」とは、「それ自体の利益のためにあまりにも賢い」、つまり現在は機能しているが、後で理解して変更するのは悪夢である何かを意味します。

特に、それがプログラミング言語のあいまいな機能を活用するトリックである場合、または奇妙な副作用を利用する場合、またはターゲット言語の問題を解決する本当に奇妙な方法である場合。

私はシンプルなソリューションを好む、私は本当にルビーの方法が好きです。たとえば、リストの最初の2つの要素を合計する場合。最初にリストを切り取り、size = 2にしてから、合計します。

一度3つではなく1つのリストを使用して、保守/変更が非常に難しい1つの大きな関数を作成したことを覚えています。

今日の世界では、パフォーマンスのためにコードの明快さを犠牲にする必要はありません（c ++を除き、そうする必要はありませんが、そうします）。

通常、コードの問題を回避するには、「賢い」必要があります。回避策であり、あまり簡単ではない場合、特定の条件を仮定すると、多くの混乱した顔や奇妙な副作用が発生します（コードを書いている時点で100％正しいかもしれません）

したがって、巧妙な==混乱==悪い:(しかし、限られた問題の実用的な解決策としてそれらを使用したので、それも素晴らしいです。

コンテキストおよび再理解を容易にするための再引用：

「デバッグは、最初にコードを書くよりも2倍難しくなります。したがって、コードをできる限り巧みに書くと、定義上、デバッグするのに十分ではありません。」

ブライアン・カーニガンがここで書いたものは明らかに畳み込みに言及しており、彼は誤って賢い言葉を使っていました。

「デバッグは、最初にコードを記述するよりも2倍困難です。したがって、可能な限り[複雑な]コードを記述すると、定義上、デバッグするのに十分ではありません。」

畳み込み：

A thing that is complex and difficult to follow.

賢い：

Showing intelligence or skill; ingenious

教育を受けたプログラマーは、単純なコードが独創的であることを知っています。可能な限り賢いコードは、定義上は単純でなければなりません。また、教育を受けたプログラマーは、ペストのような複雑なコードの操作や作成を避けます。また、可能であれば、複雑なコードを賢いコードに変換します。通常、コードは複雑な状態から始まり、プログラミングに関する領域と人間の認知能力の知識が経験と知識の共有を通じてよりよく理解されるため、巧妙さに近づきます。

この引用の人気と業界で非常に人気のあるブライアン・カーニガンのために、この言葉の誤用は社会にマイナスの影響を与えます。この記事を書く前に、私は彼に単純にメールを送信できるかどうかを確認しようとしましたが、理解できるメールの連絡先情報を見つけることができませんでした:(。

私が見た負の社会的影響は、他のプログラマーがより賢い仲間を追放していることです。なぜなら、彼らは現在、賢さを問題として見ているからです。本当の問題は、新しいユニディオマティックな方法で物事を行い、より大きなコミュニティを獲得して理解し、賢いアイデアを可能な限り再利用するのではなく、利益がないときに絶えず新しいものを発明することによって賢いと考える愚かな仲間です。

ただし、理解することは、自分で発明するよりも難しい場合が多いことを明確にする必要があります。業界では非現実的な締め切りの共通の問題があるため、小さなニッチ問題に独自の期限を設定することで、時間を節約できます。これは、有用で再利用可能なものは通常、より大きなニッチを対象とする、または発明の有用な抽象化を提供するという観察に基づいています。また、人々が大きなニッチを狙ってより多くのお金を稼ぐという事実に基づいていますが、これは多くの場合、広範囲のアプリケーションで何かを使用できるようにするのに伴う複雑さのためにツールを非常に使いにくくします。

他の負の社会的影響は、これが進歩と理解の欲求を妨げることです。なぜなら、私たちのエゴセントリックな世界では、私たちはすぐに理解の欠如を否定し、一度理解されたとしても、複雑なコードを書き留めるからですとても賢い。

TODOいくつかの参考文献を引用したいと思いますが、情報を共有する能力を妨げないように参考文献が不足しているので、私の情報源として覚えていることをすぐに引用し、実際の情報を見つけます日（または私のためにそれを見つけることができます！:)

• イベントループについてのGuido Van Rossumの講演と、それらを理解する方法
• Y-Combinatorで賢い人を雇うことを避けると述べたGitHubの従業員
• Pythonコミュニティで行われている議論と学習の多く。Pythonコミュニティは特に新しいアイデアに批判的ですが、彼らが手に負えない新しいアイデアを却下することはありません。通常、複雑なものとして最初に見られていた機能をコア言語機能/パッケージとして見ることができます。
• 10000フィートの観測に基づく、私自身の経験と専門的な意見。しかし、あなたの経験と観察があなたに同じことを伝え、他の誰かがこの答えにいくつかのメリットを与えることができることを願っています。

自由に引用を追加してください！また、テキストにカンマを自由に追加してください。英語でのコンマの使用に関する知識をかなり更新していません...

多くの場合、人々は言語、イディオム、パターンを知らないからです。彼らは本を取り、それを学ぶことができますが、彼らはしません。そして、それらの人々のために、あなたは簡単なコードを書くべきです。

それは賢さではありません。それは知識です。

私が投稿したくない。私はこの辺りのどこに述べた言葉の規律を見つけることができませんでしたので、私はチップよ元の質問を念頭に置いていなかったことを多分1つ、答えを、しかし問題に関するさまざまな洞察を共有します。

賢い開発者は良いことです。

しかし、賢さの前に他の特徴があります。あなたが気付いたかもしれないように、私は規律について話します。賢明で規律のない開発者は、システムの長期的な保守性にとって非常に悪い場合があります。

バグが発生したり、新しい要件が発生したとしましょう。賢明な開発者は、2つのローカル修正で2分で作業が完了することにすぐに気付くかもしれません。その開発者が規律を守れば、それらの修正をソースコードに適用することを抑制し、代わりに、システムに望ましい動作を構成する意味のある方法を見つけます。この方法では、次に特定のコードを変更する必要が生じたときに、メンテナーはコードを理解し、何も壊さずに新しい変更を簡単に実装できます。そうでない場合、よくあなたは写真を取得します。