一部の人々は、賢さをプログラミングにおいて有害と見なしているのはなぜですか？
最近、さまざまな抽象化手法に関連する多くの質問に気づきました。基本的に、問題の手法は「賢すぎる」と答えています。プログラマーとしての私たちの仕事の一部は、私たちが解決するために与えられた問題の最善の解決策を決定することだと思います。
だから私の質問は、特定の抽象化手法が賢さに対抗するのが賢すぎると思う人はper seですか、それとも反対の理由が他にあるのでしょうか？
編集： このパーサーコンビネーター は、私が賢いコードであると考えるものの例です。私はこれをダウンロードして、30分ほど見ました。それから私は紙の上でマクロの拡大を進め、光を見ました。理解できたので、Haskellパーサーコンビネーターよりもはるかにエレガントに見えます。
長期的なメンテナンスには、シンプルなソリューションの方が適しています。そして、それは常に言語の親しみやすさだけではありません。特定の言語の専門家であっても、複雑な行（1つまたは複数）は理解するのに時間がかかります。あなたはファイルを開いて読み始めます：「OK、シンプル、シンプル、それを得た、うん、WTF ?!」あなたの脳は金切り声を上げて止まり、複雑な線を止めて解読する必要があります。その実装の測定可能な具体的な理由がない限り、それは「あまりにも賢い」です。
巧妙なメソッドから巧妙なクラス、そして巧妙なパターンへと複雑さが増すにつれて、何が起こっているのかを理解することは次第に難しくなります。よく知られているアプローチとは別に、「賢い」ソリューションを作成するために行った思考プロセスを理解する必要がありますが、これは非常に難しい場合があります。
とは言っても、誰かが理解できないかもしれないという理由だけで、パターンが（その使用が正当化される場合に）回避するのは嫌いです。学習を続けるのは開発者としての私たち次第であり、私たちが何かを理解できない場合は、それを回避するのではなく、学習する理由です。
キッス原理
シンプルに、愚かにしてください。巧妙な解決策は素晴らしいですが、多くの場合、最も単純で簡単な解決策が最善です。
「デバッグは、そもそもコードを書くより2倍難しいです。したがって、コードをできる限り巧妙に書くと、当然、デバッグするほど賢くはありません。」
ブライアン・カーニガン
愚か者は複雑さを無視します。実用主義者はそれに苦しみます。専門家はそれを避けます。天才はそれを削除します。 -アラン・ペルリス
最良のソリューションが常に最も賢いソリューションであるとは限りません。シンプルなソリューションも同様に良い場合があります。
ソフトウェアでは、常に保守性の観点から考える必要があります。コードを保守する人にとってコードが賢すぎる場合、その賢さは価値がないと言えます。
ブライアン・カーニハンを引用するには：
「デバッグは、そもそもコードを書くより2倍難しいです。したがって、コードをできる限り巧妙に書くと、当然のことながら、デバッグするほど賢くはありません。」
賢さは道具です。それ自体は有害ではありません。必要のない状況でのみ有害になります。
「賢い」は、コードに適用される場合、ほとんどの場合、「不必要に複雑な」ことの単なる冒涜です。
優れた、明確で、単純なコードを読むのは十分に困難です。 「賢い」コードを読むことは、ラテン詩を何度も勉強するようなものです。
人の属性としての「賢い」は全く異なる意味を持つため、混乱が生じます。このケースは、実在する人々のためにソフトウェアを設計することが難しい理由の例と見なすこともできます。あいまいであるためです。
また、一部のプログラマーは、ほとんどの人が従うソーシャルプロトコルを理解するのに苦労し、コードを「不必要に複雑」に直接非難することを禁じているため、Wordの2つの意味を区別するのが難しい場合があります巧妙。一部の人が思うかもしれないこととは逆に、私は最終的にはより良い「人」（つまり、共感と内省と忍耐を持つ人）がより良い開発者を作ると思います。彼らは誰のために書くべきか知っているからです。
ほとんどの人々は、「コードが何をしているかを理解するために解読が多すぎる」という側面とそれに伴うすべての悪いことから、賢さに焦点を合わせています
- 他の誰もそれを理解することはできません、それを維持/デバッグすることは言うまでもありません。
- 書いた人はそれが何をするかさえ知りません。
- そもそも、最初はそれほど素晴らしいことではないかもしれません
- 等....
すべての良い点ですが、賢さにはもう1つの否定的な側面があり、それが古いエゴ問題です。これはの線に沿って問題を引き起こします
- 他人のソリューションを使用するには「スマート」すぎる人。あなたが同じ猫の皮を剥ぐ独自の方法を発明できるとき、なぜ他の人が何をしたかを探すのですか？
- 問題に対する最もクールな解決策を発明したと考える人は、多くの場合、入力を拒否します。
- 明らかな問題がある場合や、ささいな変更が必要な場合でも、「自分の」コードを誰にも変更させないでください。
- やや逆に、彼らは自分が賢いと思い、「最新の」手法を使用して自分がどれほど賢いかを証明する必要があるが、個人的なプロジェクトまたはそれ以外の非本稼働コードでそれを重要な部分にロールする前にうまく処理することができないシステム。
私たちは皆、エゴが多すぎるという罪を犯しますが、チームの邪魔になると問題になります。
良い賢い-賢いコード行と非賢い選択肢の行の間の高い比率。 20000を書く手間を省く20行のコードは、非常に優れています。 Good Cleverは、自分の作業を節約することです。
悪い賢い-書かれたコード行と保存されたコード行の比率が低い。 5行のコードを書く手間を省く賢いコードの1行は、Bad Cleverです。悪い賢いのは「統語オナニー」です。
注意：Bad Cleverが「Bad Clever」と呼ばれることはほとんどありません。多くの場合、「美しい」、「エレガント」、「簡潔」、または「簡潔」というエイリアスで移動します。
みんなの賢い定義について不思議に思っています。
個人的には、許容できるレベルの効率を維持しながら、困難で複雑な問題を取り、非常に単純で簡単な方法で実装したとき、私は賢く感じました。
tl; drコードレビュー中に私のレビュー担当者が「すごい、これは思っていたよりも簡単だった」と言ったとき、「wtfはこれだけです」とは対照的に、私は賢く感じます。
時々私はとても賢いので間違っていました。
リストされた理論の答えは別として、多くの場合、これは他の誰にとっても賢すぎるという状況で使用されます。
最上位層のパフォーマンス集約型チームと中位層のメンテナンスチームの間を移動して、「あまりにも賢い」ものの実際の違いを確認します。
理論の議論を省くと、あまりにも賢いのは、ほとんどの場合、最もスキルのないチームメンバーが合理的に作業できるものに基づいているため、環境に非常に関連しています。
私がソリューションを測定する方法は、パフォーマンスが高く、保守可能で、タイムリーで安価です。これらの品質に悪影響を及ぼさない限り、賢い方法もソリューションの一部になると思います。
賢いコード+理解しやすいコードにするために必要なコメントの量<=単純なコードの場合、私は賢いコードに行くと言います。毎回。
「賢いコード」を書いている人が意図的にそれを適切にコメントしないと、問題が発生すると思います。なぜなら、それが最初は理解できないことによってのみ、それに出会った次世代は、それがどれほど賢いかを「理解」する時間を費やす必要があるからです。
良い引用がしばしばそうであるように、私が多くの異なった人々に帰されたのを見た引用を思い出します。
言い換えると：
賢い人なら誰でも単純なものを複雑にすることができます。複雑なものを単純にするのには天才が必要です。
複雑なアイデアを取り、それを単純化して理解できるようにすることで、コンストラクターの賢さを示しますが、単純なアイデアを取り込んで複雑にすることで、コンストラクターを賢く見たいと思っています。
私の意見では、賢さ自体は問題ではありません。通常、「賢い」（皮肉なしの）コードと「洞察に満ちた」コードを混同することがあります。私が問題として見ているのは、通常、「皮肉な」（皮肉を伴う）コードには暗黙的な見えない要件が含まれているため、時間の経過とともにデバッグおよび保守が困難になるという事実です。
賢いいくつかの既知のアルゴリズムがあります。 Quicksort は1つ、IMOです。
「皮肉な」（皮肉を使った）コードは通常、設定されている変数と、（以前に開かれたファイル、ネットワーク接続、データベースなどとして）「頭が良い」コードから実質的に切断されたシステムの状態についての仮定を行います。
「賢い」コードを正しく維持するために脳にロードしなければならないデータの量は、通常、費用対効果の比率が高いほど大きくなります。
「賢い」ソリューションを理解することが難しい場合は、使用しないでください。たとえば、副作用を介して複雑な計算を1行に縮小できる場合、それは賢いです。しかし、誰かがあなたが世界で何をしたかを理解するのに1時間かかるなら、それはあまりにも賢いです。
私は男を知っています。彼はおそらく私が今まで会った中で最も素晴らしい人です。彼は間違いなく信じられないほどのコーダーで、純粋なプログラミングチョップの点で、私の人生でこれまで以上に優れているでしょう。彼はWord文書を入力しているようにコードを記述し、信じられないようにリンクリストを逆にすることができます。非常に複雑なコードの記述について話したい場合は、彼はあなたの男です。私が信じられないほど難しい問題に遭遇した場合は、常に彼に頼ります。しかし、チーム環境で彼と一緒にプロジェクトに取り組むのは大変なことです。彼はビジネス問題を直接対象とし、それに論理的で効率的で簡潔なソリューションを提供することはできません。彼にとって、1000行のコードリストは100よりも優れています。IDEまたはフレームワークを介して提供されたツールを使用する代わりに、彼は独自の超最適化ツールをロールします。これは他のチームメンバーが何かを完了するのを待っているとき、または期限がある場合を除いて、すべて順調です。
私は彼がこれらの複雑なことを行う能力に感心していますが、私に必要なのは問題を解決して先に進むことができる人です。言ったり認めたりするのは素晴らしいことではありませんが、ビジネス環境では時々すべてが問題であり、問題を解決して人生を進める必要がある場合は、いつでも戻って問題をリファクタリングして改善することができますあなたのコード。賢いこととお尻の痛みの間には微妙な境界があります。私のチームのモットーは、常に、この状況で機能し、そこから進むことができる最も簡単なことは何ですか。時には単純なものが必ずしも答えであるとは限らないかもしれませんが、それは開始するのにとても良い場所です。
この文脈での「賢い」とは、「自分の利益にはあまりにも賢い」、つまり現在は機能するが、後で理解して変更するのは悪夢になるものを意味します。
特に、プログラミング言語のあいまいな機能を悪用したり、奇妙な副作用を利用したり、ターゲット言語の問題を解決するための本当に奇妙な方法である場合。
巧妙さのように見えるものは、創造性の急増で開発者に単純にmessとして渡され、単に判読不能、メンテナンス不可他の人のための曖昧ななぞなぞのブロック。
それでも、なめらかで巧妙でパフォーマンスの高いなぞなぞのブロックですが、経験を積んでいると、媒体を維持するためにビジネス（開発者ではなく）に多くのコストがかかることに気付くでしょう。または長期。ですから、仲間の開発者たちが運ばれるとき、彼らの熱心さを落ち着かせる方が好きです。
もちろん、賢さの正当化がある場合を除いて。そして、あなたが書いたばかりの難読化されたものに付随する優れたドキュメントがある場合。その賢いコードにコメントしましたよね？それが意図であり、なぜそれが似ている必要があるのか、そしてどのように振る舞うのかを説明してください。
根拠がない場合、それはおそらく時期尚早な最適化、オーバーエンジニアリング、またはYAGNIの種類の問題のいずれかです。単純なことを行うのに15レベルの間接参照が必要な場合は、前のカテゴリにも該当する可能性が高くなります。そして、それが文書化されていなければ、それはただの問題です。
優れたコードでは、メンテナーが理解するために常に100％である必要はありません。良いコードは賢いです。優れたコードはほぼ同じくらい効率的ですが、他の多くの点で優れています。優れたコードでは、アプリケーションの設計に従うためにIDE 15ビューを必要としません。
注：ちょっと、賢いと思ったものをいくつか書きましたが、それによってWTFが発生しましたか？私の共同開発者でない限り-私のマネージャーの口から。彼らの視点からそれを見る必要があります。
私はcleverになる傾向がありますが、elegantになるように努力しています。
他の人が試して回避しないコードnow後でを開発します。
「賢いコード」とは、プログラマーが真剣に考えたり、高度なスキルを使ってコードを記述したりする必要のあるコードのことです。 Brian W. Kernighanによって最もよく表現されている特定の「賢さのマージン」の必要性を無視するという問題があります。
「デバッグは、最初にコードを書くよりも2倍困難です。したがって、コードをできる限り巧妙に書くと、当然、デバッグするほど賢くありません。」
これは私の経験と他の回答に基づいた、問題の私の理解です：
- 書くのに賢明でしたが、読みやすく保守可能であるコードは、有害とは見なされません。ただし、ほとんどの開発者はそのようなコードを「賢い」とは呼びません。彼らは「エレガント」のような異なる用語を使用するかもしれません。このようなコードが存在するかどうかについては、議論がある場合とない場合があります。
- 言語に精通している経験豊富な開発者であっても理解するのにかなりの時間と労力を必要とする製品コードは「賢い」ものであり、誰にとっても有害であると考えられています。
- 経験の浅い開発者による多大な時間と労力を必要とする量産コードは、一部の人にとって有害であると考えられています。私はどちらの方法でも答えを見てきましたが、すべてを「最も低い共通項」に保つことを好むと明示的に言った開発者と協力しました。
通常、「賢い」必要がある場合は、コードの問題を回避します。回避策であり、それほど簡単ではない場合、特定の条件を想定すると、混乱した顔や奇妙な副作用がたくさん発生します（コードの記述時に100％正しい場合があります）。
したがって、巧妙な==混乱する==悪い:(しかし、制限された問題の実用的な解決策としてそれらを使用したので、それも素晴らしいです。
私はシンプルなソリューションが好きです。Ruby wayが好きです。たとえば、リストの最初の2つの要素を合計したい場合は、最初にリストをカットしてsize = 2にし、次にそれを合計します。
3つではなく1つのリストを使用して、維持/変更が非常に困難な1つの大きな関数を作成したことを覚えています。
今日の世界では、パフォーマンスのためにコードの明確さを犠牲にする必要はありません（C++を除いて、そうする必要はありませんが、そうするでしょう）。
コンテキストとより簡単な理解のための再引用：
「デバッグは、最初にコードを書くよりも2倍難しいです。したがって、コードをできる限り巧妙に書くと、当然、デバッグするほど賢くありません。」
ブライアンカーニガンがここに書いたのは明らかに畳み込みに関するものであり、彼は誤って賢い言葉を使用しました。
「デバッグは、最初にコードを書くよりも2倍難しいです。したがって、コードをできるだけ[複雑]に書くと、当然、デバッグするほど賢くありません。」
畳み込み：
A thing that is complex and difficult to follow.
賢い：
Showing intelligence or skill; ingenious
教育を受けたプログラマーは、単純なコードが独創的であることを知っています。可能な限り賢いコードは、定義上、単純でなければなりません。教育を受けたプログラマーは、ペストのような複雑なコードの操作や記述も避けます。また、複雑なコードを機会があればいつでも巧妙なコードに変換します。ドメインについての知識とプログラミングにおける人間の認知能力の理解は、経験と共有された知識によってよりよく理解されるため、コードは通常複雑に始まり、賢さに近づきます。
この引用の人気と業界でブライアンカーニハンが非常に人気があるため、この単語の誤用は社会に悪影響を及ぼします。正直に言って、男性自身が対処したいと思います。この記事を書く前に、彼に電子メールを送信できるかどうかを確認しようとしましたが、理解できる電子メールの連絡先情報は見つかりませんでした:(。
私が見たマイナスの社会的影響は、他のプログラマーがより賢い仲間を追放していることです。彼らは今、賢さを問題と見なしているからです。本当の問題は、新しい一義的な方法で物事を実行し、より大きなコミュニティを理解してできるだけ賢いアイデアを再利用する代わりに、利点がないときに常に新しいことを発明することで賢いと考えている愚かな仲間です。
しばしば理解することはあなた自身のものを発明するよりも難しいことを明確にする必要があります。業界では一般的な非現実的な締め切りの問題があるため、小さなニッチな問題のために独自の期限を考案することで、時間を節約できます。これは、有用で再利用可能なものが通常より大きなニッチを対象とする、または発明に有用な抽象化を提供するという観察に基づいています。それはまた、人々がより多くのお金を稼ぐために大きなニッチをターゲットにするfactに基づいています。これは、何かを広範囲のアプリケーションで使用できるようにすることの複雑さのためにツールを非常に使いにくくすることがよくあります。
他の負の社会的影響は、これが進歩を妨げ、理解したいという欲求です。私たちのエゴセントリックな世界では、自分の理解が不足していることをすぐに否定し、たとえいったん理解すれば、アイデアが実際にはかなり賢い。
TODOいくつかの参照を引用したいと思いますが、情報の共有機能を妨げないように参照の欠如もしたいので、私の情報源として覚えていることをすばやく引用し、実際の情報をいくつか見つけることができます日（または私のためにそれを見つけることができます！:)
- Guido Van Rossumによるイベントループとそのループについての話
- Y-Combinatorで賢い人を雇うことを避けると述べたGitHub従業員
- Pythonコミュニティで行われているディスカッションと学習の多く。Pythonコミュニティは、新しいアイデアに対して特に重要ですが、彼らが行う新しいアイデアを却下していません手に負えないことは理解できません。通常、最初は複雑であると見なされていた機能を見ることができますが、日の目をコア言語の機能/パッケージとして見ることができます。
- 10000フィートの観察に基づく、私自身の経験と専門家の意見。でも、ここまで啓蒙すべき具体的なことは本当にわかりません:(うまくいけば、あなたの経験と観察が同じことを教えてくれ、誰かが以下にコメントしてこの答えにいくつかのメリットを与えることができます。
引用を自由に追加してください！また、テキストにカンマを追加してもかまいません。英語でのカンマの使い方の知識をかなりの時間でリフレッシュしていません...