一部の人々は、プログラミングにおいて賢さを有害と見なしているのはなぜですか?


89

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

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

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


116
おそらくあなたは誤解していると思う- 人の賢さは美徳であるが、システムの賢さは悪である。システムとコードは賢いものであってはならず、クリスタルのように明確でなければなりません。そのようなものを作成するには、しばしば賢い個人が必要です。
nlawalker


15
@nlawalker:私は今それを手に入れたと思う。「クリア」または「シンプル」の反意語としてのコードを参照するとき、彼らは本当に言葉を使用することを意味するので、人々は、単語「賢い」を使用している「クリア」または「シンプル」の反意語を。
ラリーコールマン

2
@ラリー:それが何を意味するのか分かりません。以下のように賢い、本発明の元、ingenius、あなたが前に見たことがない方法で物事を使用して暗黙的。時には素晴らしいこともありますが(多くのデザインパターンは賢いのですが)、ソリューションの異質性のために作業が困難になる場合があります。
doppelgreener

2
誰もコメントコードがありませんか?それが賢さを説明する場所ですので、それに続く人々が理解できます。半年であなたのように。
フィルレロ

回答:


207

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

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

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


7
+1いいですね。バランスの問題だと思います。ある程度の知識を持っている人が自分のことを少し考えてコードを理解することを期待できる場合は、賢明な方法でコメントを追加できます。誰かがコーディングスキルを証明したいという理由だけでコードを理解するのに4倍の時間がかかる場合 誰かが賢い解決策を考え出すのに十分賢いなら、彼らはそれが理解できるかどうかを決定するのに十分賢くなければなりません。それ以外の場合は、ただ自慢しています。
アンシュースラー

私が好きな最後の段落。残りは真実ですが、残念です。
Orbling

Zend PHPのソースコードを見たようです:)
ティムポスト

+1単純なパターンは賢いパターンほど性能がよくないかもしれません。あなたが言ったように、開発者はそれを理解することで「賢い」エンベロープをプッシュし続けるのは私たち次第です。
スティーブンフルラニ

3
本当に「最小限、直交的に正しい」ときに何か「賢い」ことを正当化する必要があった人として、正確に何が賢いのかという質問には主観があります。たとえば、一部の人々は常に書きたいとif FuncX() then return true, else return false思うでしょうし、あなたにただ書きたいと思わないでしょうreturn FuncX()。冗談ではありません、文字通りその会話をしました。人々はどこかでブレークポイントをぶら下げたいか、何かをしたいからです。:
ウォーレンP

102

キッスの原理

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

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

ブライアン・カーニガン


8
一方、できる限り巧妙にコードを記述する場合は、デバッグを学習する必要があり、そうすることでより賢くなります。またはそのようなもの。
ジェームズマクネリス

11
@ジェームズ:または、あなたはただ失敗します。;)
ジョシュK

10
@ジョシュK:私は常に KISSを「Keep It Simple、愚かだ!」と知っいました。- en.wikipedia.org/wiki/KISS_principle
Orbling

1
@Orbling:私はそれを違う方法で思い出しました。
ジョシュK

1
ウィキペディアによると、「シンプルに保ち愚かであること」?:)これは、それを単純に保つのは愚かであるか、それを単純に保つには愚かでなければならないということですか?:P
Mateen Ulhaq

83

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


5
素敵な引用と、何かが単純で賢いものにはなりえないという暗黙の仮定なしに最初の答えであることに対して+1
ラリーコールマン

15
重要なのは、コードではなく、賢いはずのプログラマーだということです。
クリストファージョンソン

賢い言葉を巧妙に誤用しているばかより良い方法を引用してください。
デレクリッツ

30

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

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


3
複雑な問題の簡単な解決策は、だれでも手に入れることができるほど巧妙です。
ジェフ

ただし、メンテナーがコーディング(または読み取り)できないからといって、単純化しすぎないように注意する必要があります。
ケンヘンダーソン

@confusedGeek-しかし、メンテナンスプログラマがそれを処理できないことがわかっている場合、賢い解決策は時限爆弾になります。ここではバランスが重要です。これは、メンテナンスチームを知っている場合にのみ適用されます。わからない場合は、賢さを明確にすることが最善です。
マイケルコーネ

1
@Michael、パフォーマンスの制約により、コードを巧妙にする必要がある場合があります。学ぶことはメンテナーの仕事であり、もしできなければ、新しいメンテナーを雇います。
スティーブンフルラニ

@Stephen、コードが賢明である必要がある場合、プログラマーはなぜそれが必要なのかを説明するために細心の注意を払う必要があるため、メンテナーはゼロから始める必要はありません。

26

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

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


「...賢明な正しい定義を使用し、コードが実際に理解しデバッグするのが簡単でない限り。」
デレクリッツ

親指辞書に依存していると思います。私の経験では、理解しやすいかどうかに関係なく、「賢い」コードはすべて、仕様の幸運な組み合わせを活用しています。明らかな場合でも、そのような仮定が変更される可能性があり、コードのさまざまな部分に漏れてはならない場合は、マークする必要があります。
peterchen

あなたは正しいですが、言語と実装がどれほど簡単に読んで理解できるかに依存するという警告を付け加えたいと思います。あなたのコメントは役に立つものではなくコードのノイズかもしれません。そして、その反対を意味するために巧妙に使用することは一般的ですが、他の人が自分の利益のために物事を誤解できないように、より明確になるよう努力する必要があります。
デレク・リッツ



16

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

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

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

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


5
あなたが社会的プロトコルと「人民」について説教をしていなければ、私はこれを支持したでしょう。
ジェイソンベイカー

2
大丈夫です。思い出させてくれてありがとう。私は説教しすぎる傾向があります。しかし、私は、(多くの?)プログラマーが普通の人間の振る舞いに対処できない、および/または私たちの分野で見られる共感と内省の一般的な欠如に悩まされています。たぶん、イタリック体の代わりに引用符で「人」を入れるべきでした。英語は私の第一言語ではありません。短いことを理解する方法を知りませんでした。優れた開発者になるには、コードだけでなく人も理解する必要があります。私見では。
fzwo

私の答えを編集しました。今より明確/少ない攻撃?
fzwo

最初のいくつかの答えを得た後に私が実際に結論付けた最初の文に対して+1。
ラリーコールマン

はい、このコンテキストで愚かな人々によって巧妙に使用されている方法を明確にしていただきありがとうございます!
デレクリッツ

9

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

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

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

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

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


8

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

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

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


おもしろい答えですが、問題のコードを書いた人以外は、「悪い賢い」と呼ぶコードは実際には「美しい」などと呼ばれていますか?
ラリーコールマン

2
依存します。Objective-C / C ++ / Cでは、現象は通常、個人に限定されます。PerlやRubyでは、多くの場合、コミュニティ全体が「美しい」、「エレガント」などという悪い賢いについての共有価値を持つことになります
user8865

1
@ user8865:また、「Good Clever」コードは、元のコードよりもデバッグがはるかに簡単になります。これは、定義により3桁少ないからです。
ラリーコールマン

2
ああ、だからPerlプログラムは-今ではほとんど定義によって-非常に賢い:)知ってうれしい!

7

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

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

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


1
tl; drについてのLOL、プログラマーはどれくらい遅いと思いますか?はい、私はここでの実際の正反対を意味するために、ここでの巧妙な誤用を絶対に軽deしています。愚かな/無視する/悪の開発者と管理者は、実際にこれを使用して、「賢すぎる」と思われる人を雇わないことを正当化します。
デレクリッツ

6

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

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

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


優れた:「巧妙すぎると、最もスキルの低いチームメンバーが合理的に作業できることに基づいていることが多い」
Orbling

お住まいの地域に応じて、この回では「優秀」よりもやや小さいです:-)
ビル

誰がチームの最もスキルの低いメンバーを気にしますか?ほとんどすべてのチーム(私はいくつかの例外があると確信していますが)に、自分をプログラマーと呼ぶビジネスがまったくない少なくとも1人のメンバーがいます。
dsimcha

1
うまくいけばうまくいくと思いますが、それがうまくいかなくても、チームメンバーとして彼らに対処する必要があり、彼らはいくつかの仕事に参加できる必要があります。私は現在、ラムダ式でこれを見ています。私が一緒に働いている多くの人々はまだそれらを取得していないので、彼らはあまりにも賢いように見えます。これは多くの問題を非常に効率的かつエレガントに解決するので残念ですが、中間層の人が誰もそれらを取得しない場合、サポートされていないソフトウェアの管理に行きます。
ビル

@ビル:ラムダ関数??? 簡単なことを理解できない人は、それらについて学ぶように明示的に求められた後でも、プロのプログラマーになることはできません。
dsimcha

6

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


1
それは起こり得ます。そして時々、何かがとても間違っている、その権利。
ボボボボ

彼らはそれらの理論をジョンと呼んでいます。理論はときどき間違っている可能性があり、またそうあるべきです:)、それは私たちが賢くなり、可能な限り賢くなるように努力するのをやめるべきだという意味ではありません。この世界で他にどのようにリーダーになりますか?「ああ、しかし、人間の手の届く範囲は彼の握りを超えるはずです-それとも、天国は何のためですか?」
デレクリッツ

4

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


開発に関するポジティブとして「安い」を使用するための+1
ゲイリーロウ

パフォーマンスが良くない「賢い」コードを見すぎました!
HLGEM

より価値のある指標がありますが、それらはプロジェクトによっては良い指標になる場合があり、多くの場合それらは互いに対立するため、成功するためには一方を他方より強調する必要があります。
デレクリッツ

3

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

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


まあ、または、彼らは次の男について何も考えていないからです。思考のないナマケモノや悪い習慣によって何が適切に説明できるのか、知的エゴ主義に帰せられるかどうかはわかりません。しかし、実際には、コードが一目で理解できない場合はコメントが必要であり、コード+コメントが(LOCまたは時間で)別の方法よりも長い場合、必要以上に一生懸命働いています。
ダン・レイ

良い答えです(+1することはできません。残っているものはありません。後であります)。賢いコードを書くのに時間を費やさず、他の人がそれを理解するのに時間を費やさない場合、効率が悪くても、単純なコードほど複雑ではありません。その後、スキルの向上は行われません。
Orbling

ベストアンサー。マントラ:シンプルなベースラインを作成し、すべてが立ち上がると頭がおかしくなり遅くなるスターターコードを書き、それを読み込めないワンライナーにまとめるとコメントにします。それがあなたの言語のすべての汚いトリックを学ぶ方法です!
Droogans

あなたの巧妙な使い方を複雑な意味で使用する場合、私はログをとることによって理解できるようにした複雑なコードを個人的に書きました。複雑なコードを書く予定はありませんでしたが、当時は多少の時間を節約できましたが、大幅に変更する必要がある場合はおそらく簡単に書き直すべき#TODOを追加しました。
デレクリッツ

3

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

言い換えると:

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

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


はい、それはあなたのコードベースを複雑にするのは賢くなりたいというエゴセントリックなアイデアです。あなたは賢い、または賢くない。悲しいことに、初期の学習段階では、人々は自分よりも賢いと思っています。後で、彼らはどれほど賢くないかを理解し、実際に知識のギャップを埋めてから賢いコードを書きます。
デレクリッツ

2

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


2
十分ですが、コードを理解できない人が言語のすべての機能に精通していない場合、答えは変わりますか?
ラリーコールマン

2
少なくともIMOは違います。人が言語の機能に精通していない場合、何が賢いかを判断する立場にありません。
ジョーD

@ラリー:必ずしもそうではありません。私はそれを読んでいる人が基本的/低レベルの習熟度にあると思います。そして、取り返しのつかない複雑さが生じ始めたら、コードが何をすべきかを説明するブロックコメントを入力します。これは、実際に何をしているのかを理解するための参照フレームを確立するのに役立ちます。ただし、コメントはハイレベルでなければなりません-計算を書き、プロセスを説明してください。コードを繰り返さないでください。の人は、(理想的には)コードを読んで理解できるはずです。とにかくそれが目標です。
マイケルK

2

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

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

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

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


1

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

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


1

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

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

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

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

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

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


答えてくれてありがとう。あなたは、「賢い」とは私が思った通りではないと言う他の人たちに同意しているようです。
ラリーコールマン

1

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

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


1
さあ...賢いはエレガントの同義語であり、あなたの脳は販売されています。はい、私はその言葉を作り上げました、それはあなたの脳が真実の代わりにマーケティングの影響を受けていることを意味します。
デレクリッツ

エレガント:シンプル賢い。@DerekLitz +1で、何でも変装します。
ケブピー

1

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

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

現代の西洋文化全体はLCDです。つまり、プログラミングも必要だと思います。良くない。
11

@Orbling:はい、でもすぐに満足することを忘れないでください。
ラリーコールマン

あなたの経験のポイントが好きです。人々が知識と理解を共有することによって、反復的な改善とお互いへの投資に努力していないのは悲しいことです。代わりに、彼らはむしろ私たちが車輪の歯車になって欲しいので、時間が来たら簡単に交換することができます。これを行うことで、進歩を妨げています。我々はまた...短い自分自身を販売している
デレク・リッツ

1

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

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


ごめんなさい、複雑なものをコーディングできるようになったこの人の質にもかかわらず、彼は愚かです。他の特性に関係なく、人々は愚かになる可能性があります。あなたが本当に開発から何を望んでいるかについてのあなたの声明は、才能のある人には明らかです。彼が本当に頭が良いなら、あなたは彼に彼の才能で愚かなことをさせるのではなく、彼に恩恵を与え、彼に立ち向かうべきです。あなたは彼と彼の周りのすべての人に、怠idleで彼の背中の後ろで不平を言うことによって傷つけています。彼が頭が良くないなら、あなたは彼を解雇するべきです、そして多分彼はそれを手に入れるでしょう。
デレク・リッツ

私は何十年もの間、毎日知的な人々を扱ってきた主要なリソースと関係があり、彼らの一部はチーム環境で生産的であるためにいくつかの知識を失っています。あなたが少なくとも問題について彼らに知らせるならば、彼らは彼ら自身でそれを理解することができます。
デレクリッツ

1

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

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


0

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

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

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


0

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

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


0

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

「デバッグは、最初にコードを書くよりも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
私は確かにこれに同意しません(-1の価値はありませんが)。この議論により、メンテナが学校を卒業したばかりで何が起こっているのか理解できなかったため、Undo / Redoトランザクションスタックを処理するCommandパターンを実装しないと言うことができます。ある時点で、あなたは彼らがそれを知らないなら、彼らはそれを学ぶ必要があると言う必要があります。
ケンヘンダーソン

@confusedGeekまったくその通り、無知についてどこで線を引きますか?
オーブリング

@Orbling、正直なところそれは難しい部分であり、ある程度は状況に依存します。私が使用する傾向がある一般的なガイドは、適度にベテランの開発者(使用されている技術に精通している)がそれを理解できれば、おそらく大丈夫です。それができない場合は、リファクタリングする必要があります(または雇用慣行を確認します)。
ケンヘンダーソン

@confusedGeek Aye、賢明に聞こえます。リトマステストは、おそらく、自分と同じ口径の開発者が、あなたが十分に迅速に行ったことを簡単に理解できるかどうかです。そうでなく、より簡単な方法がある場合は、変更する必要があります。簡単な方法がない場合があります。
10

-1。最小公分母のコードを作成しないでください。 不要な複雑さは悪いですが、少し賢くすることでコードを大幅にDRYにするなどの価値がある場合があります。
dsimcha

-1

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

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

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

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


「士気が向上するまで殴打は継続されます」
ブヨ

@gnat意味?少し物事をクリアするために。私は規律を開発者に押し付けられるものとして受け止めません。それは良い性格特性です。通常、ソフトウェアをメンテナンスした後、賢い人々によって開発されたもの。問題は、メンテナーの立場に十分にいなく、他の人が見つけられるように巧妙な爆弾をいたるところに残す賢い人々にあります。
dkateros
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.