センチメンタルコード[終了]

https://stackoverflow.com/questions/1414969

06-07-2019
|

質問

「コードの賞賛」の問題について議論している記事を見つけました。基本的に、著者は開発者がどのように自分が書いたコードに懐疑的であるかについて話します。「賞賛する」方法コードが多すぎて、自分自身を添付し、目の前にある可能性のあるバグやその他の事故に対して脆弱になります。

この問題についてどう思いますか？また、この問題を回避/認識する方法に関するヒントはありますか？

解決

数年前、私は小さな「趣味」で他の人と仕事をしていました。プロジェクト、そして私は物事を再評価する必要があることに気づきました。私たちはたくさんのコードを書きましたが、それはすべて良いコードではありませんでした。

本当に「捨てる」ことは望みませんでした。私たちが投入したすべての作業。しかし、私は何かに気付きました。最も重要なのは、これから投入する必要がある作業量である。

プロジェクトにすでに多くの作業を投入したという事実を変更することはできなかったため、プロジェクトが必要とする合計作業量を最小化する唯一の方法は、まだ行っていない作業量。

その日以来、私は自分のコードへの執着をやめました。それを捨ててゼロから始めるということは、それを維持して自分のニーズに合わせて調整するよりも作業が少ないと確信できるなら、捨てます。

他のヒント

高校の美術の先生は、私たちが最高の絵と思われるものを取り、それを引き裂くように勧めてきました。彼はこれを「魂の浄化」と呼びました。彼の理由は、アーティストとして私たちは芸術作品を作成するように駆り立てられ、好きなものや満足感を与えるものを制作するたびに、作成を続けるモチベーションが低下することでした。

だから私は彼のアドバイスに従い、私の最高のものを引き裂きました。古い作品を賞賛するのに時間を費やす代わりに、新しいものを作成し、継続的に改善しました。私は自分のコードで同じ原則に従おうとしましたが、実際には機能しません。私のコンピューターには、破ることがほとんど不可能な丈夫なプラスチックシェルがあります。

Jeff Atwoodのブログ毎年吸う量を減らすからフラグメントを投稿します、そして私は100％に同意します。

よく吸うと思ったことがあります毎年、プログラマは謙虚です改善します。あなたは不満に思うはずです 1年前に書いたコード。もし、あんたがそうではない、それはどちらかを意味しますA）あなた 1年で何も学んでいない、B）コードを改善できない、またはC）あなた古いコードを再確認しないでください。これらのすべてソフトウェアの死のキスです開発者。

素晴らしいコードを賞賛したいのですが、賞賛すべきものを知るのは必ずしも簡単ではありません。複雑で精巧なコードは見事なコードと間違われることがありますが、優雅さとシンプルさはむしろ努力すべきものです。

2つの引用符が思い浮かびます：

＆quot;デバッグは書くよりも2倍難しい   そもそもコード。   したがって、次のようにコードを書くと   できる限り賢く、あなたは   定義、デバッグするには十分にスマートではない   it。＆＃8221;

-ブライアン・カーニハン

and

＆quot;すべてをシンプルにする   可能ですが、単純ではありません。＆quot;

-アルバートアインシュタイン

Jonathan Edwardsが印象的な美しいエッセイこのテーマについては、O'Reillyの本 Beautiful Code の研究によって促されました。最後の段落がありますが、エッセイの残りの部分も読む価値があります。

私が学んだもう1つの教訓は、美しさを疑うことです。見過ごされたい現実が侵入するので、デザインへの夢中は必然的に失恋につながるようです。愛は盲目ですが、コンピューターはそうではありません。長期的な関係＆＃8211;システムを何年も維持する＆＃8211;率直さと慣習性など、より多くの国内の美徳を評価することを教えます。美しさは理想主義的なファンタジーです。本当に重要なのは、プログラマーとコード間の終わりのない会話の質です。美しさは幸せな結婚生活にとって十分な基盤ではありません。

この同じ知恵の他のバージョンが他のフィールドに存在します。サミュエル・ジョンソン、執筆について：

作曲を読み、特にすばらしいと思う箇所に出会った場合は、それを取り消します。

William Faulknerのこのバージョンは、もっと簡潔でした：＆＃8220; Kill your darlings。＆＃8221;

義理の父は映画編集者として働いており、映画が撮影されているセットを熱心に避けています。彼が訪問しなければならないとき、彼はできる限り彼の目を保護します。これは、彼が最終映画にシーンを含めるかどうかを決定するときに、シーンを撮影するのにどれだけの労力がかかったかに影響されたくないからです。重要なのは、シーンが最終映画でどれだけうまく機能するかです。

私のエッセイ、「プログラマーとしての私の進化」（私が新しいユーザーではない場合にリンクします）、主に私が書いたコードについて懐疑論を学ぶことについてです：それが機能するかどうか、それが有用かどうか、それが理解できるかどうか（ペアプログラミングは本当のウェイクアップコールでした）ここに）。難しい！

自分のコードを賞賛することはありません。私は「借りる」という他の人々のコードを賞賛します。そして、それらをエミュレートするか、それらを改善してみてください。特にコーディングについて知っているほど、私は知らないことがわかります。価値のある唯一のものは、ピアプログラマが私のコードを賞賛し、それを借りることです。

彼には良い点があると思う。チームワークを実際に妨げ、問題の最善の解決策を得るのを妨げるので、これが多すぎる人と仕事をするのはイライラします。

少し妄想的になりかねないので、私は現実に根ざし続けるためのプラクティスを導入しようとしています。コードについては、

単体テスト：これらは、抽象的な「美」とは対照的に、コードが何をすべきかにより集中し続けます。
共有コードの所有権：ここには2つの陣営があります。コードの所有権を増やしてプライドを引き継ぐことを望みます。人々にもっと所有権を与えることは、このコードへの賞賛につながると信じています。私たちは共有コードの所有権を実践しているので、誰かが自分の完璧なコードを（彼らの心の中で）改善するために書き換えることを常に強制されています。私はすぐにそれを賞賛するのは時間の浪費であり、感情的に難しいと気付きました。
ペアプログラミング：誰かと一緒に作業することで、現実的になります。
その他のフィードバック：これらはすべてフィードバックループですが、他にもあります。誰かがそれを使用する（試す）のを見るよりも、何かが機能するかどうかを確認するより良い方法はありません。できるだけ多くの人の前にあなたの仕事を置きます。コードレビューがあります。他の人のコードを読んでください。静的コード分析ツールを実行します。

PurplePilotを使用しています-自分のコードを賞賛することはありません。そのため、同じことをするための新しい、より効率的な（地獄、より簡単な）方法を常に探しています。 Effective c＃bookが好きで、そこから私が賞賛する多くの便利なコードをピックアップしました。

コードを捨てて再び始めることをためらうことはありませんが、必ずしも最初からではありません。つまり、特定のシナリオ用のコードをいくつか書き、それを捨てることで、おそらくシナリオをよく理解できるでしょう。言い換えれば、それは「邪悪な問題」であるか、エジソンではうまくいかない別の方法を見つけたということです。

より広い質問があります：コードが破棄されない場合、または少なくとも再訪されない場合、停滞しているライブラリでの開発は良いことですか？

コードを賞賛することには何の問題もありません...これは、将来より多くのより良いコードを書くように促す積極的な強化プロセスの一部です。

ただし、見当違いまたは誤用の称賛が問題になる可能性があります。コードが本当に良くない場合、またはユニットや他のテストで公開されていないバグがある場合、またはリファクタリング/再設計/交換が必要な場合、この見当違いのアドミラトインは問題です。そして、コードレビューなど、プロセスの一部をスキップする言い訳として賞賛を使用したり、コードに対して懐疑的な態度を持たないことは、賞賛の誤用です。

他の良いものと同様に、コードへの賞賛は置き忘れられたり誤用されたりする可能性があります-それ自体が悪いという意味ではありません。それは「宗教は悪いことだ」と言っているようなものだ。なぜなら、それは人々の間で対立や戦争を引き起こすからだ。

2つの単語：コードレビュー。

2人以上の開発者を集めて、コードのレビュー/批評/コメントに招待します。 'あなたのコードに（明らかに厳しい）光を当てないでください。

おそらく、より健康的な視点を持つ方が良いでしょう-私たちはロケット科学者ではなく、がんを治していません-それはただの仕事です。

（はい、あなたが建築家であるなら、あなたが助けた建物全体を誇りに思うのは理にかなっていますが、彼らは本当に個々の青写真または3階のクローゼットに包まれた彼らの自尊心の多くを持っていますか？自分で設計しましたか？）。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow