「コードの賞賛」の問題を論じている記事を見つけました。基本的に、著者は、開発者が自分が作成するコードについてより懐疑的になる方法について語っています。コードを「賞賛」しすぎて、コードに自分自身を結びつけ、目の前にある可能性のあるバグやその他の事故に対して脆弱になる方法。
この問題についてどう思いますか。また、この問題を回避する/意識する方法について、さらにヒントはありますか?
「コードの賞賛」の問題を論じている記事を見つけました。基本的に、著者は、開発者が自分が作成するコードについてより懐疑的になる方法について語っています。コードを「賞賛」しすぎて、コードに自分自身を結びつけ、目の前にある可能性のあるバグやその他の事故に対して脆弱になる方法。
この問題についてどう思いますか。また、この問題を回避する/意識する方法について、さらにヒントはありますか?
数年前、私は別の人と一緒に小さな「趣味」プロジェクトに取り組んでいましたが、物事を再評価する必要があることに気付きました。私たちはたくさんのコードを書きましたが、すべてが良いコードではありませんでした。
投入したすべての作業を「捨てる」ことは本当にしたくなかったのですが、あることに気付きました。最も重要なのは、これから投入する必要がある作業の量です。
プロジェクトにすでに多くの作業を投入したという事実を変えることはできませんでした。そのため、プロジェクトに必要な作業の総量を最小限に抑える唯一の方法は、まだ完了していない作業の量を最小限に抑えることです。
その日以来、私は自分のコードに執着するのをやめました。それを捨ててゼロから始める方が、それを維持して自分のニーズに合わせて調整するよりも手間がかからないと確信できるなら、私はそれを捨てます。
私の高校の美術の先生は、私たちが最高の絵だと思ったものを引き裂くように勧めていました。彼はこれを「魂の浄化」と呼んだ。彼の理由は、私たちは芸術家として芸術作品を制作することに駆り立てられており、気に入ったものや満足できるものを制作すると、制作を続けるモチベーションが低下するというものでした。
それで私は彼のアドバイスに従い、私の最高のものを引き裂きました、そしてそれはうまくいきました. 古い作品を賞賛することに時間を費やす代わりに、新しいものを作成し、継続的に改善しました。コードで同じ原則に従おうとしましたが、実際にはうまくいきません。私のコンピューターには、破ることがほとんど不可能な頑丈なプラスチック製のシェルがあります。
Jeff Atwood のブログ、Sucking Less Every Yearの一部を投稿しますが、100% 同意します。
謙虚なプログラマーは年々口数が減ることで上達すると、私はよく考えてきました。1 年前に書いたコードに不満があるはずです。そうでない場合は、A) 1 年間何も学んでいないか、B) コードを改善できないか、C) 古いコードを再訪したことがないかのいずれかです。これらはすべて、ソフトウェア開発者にとって死の接吻です。
私たちは確かに私たちの素晴らしいコードを賞賛したいのですが、何を賞賛するかを知ることは必ずしも簡単ではありません。複雑で手の込んだコードは、見事なコードと間違われることがありますが、優雅さとシンプルさはむしろ努力すべきものです。
2つの引用が思い浮かびます:
「デバッグは、そもそもコードを書くよりも2倍難しいのです。したがって、コードをできるだけ巧妙に書くと、定義上、デバッグするのに十分賢くなりません。」</ p>
-ブライアン・カーニハン
と
「すべてを可能な限りシンプルにしますが、シンプルではありません。」
- アルバート・アインシュタイン
ジョナサン・エドワーズは、オライリーの本Beautiful Codeの作業に触発されて、この主題について印象的な美しいエッセイを書きました。これが最後の段落ですが、エッセイの残りの部分も読む価値があります。
私が学んだもう 1 つの教訓は、美を信用しないことです。デザインに夢中になると、見過ごされがちな醜い現実が押し寄せてくるため、必然的に失恋につながるようです。愛は盲目ですが、コンピューターはそうではありません。長期的な関係、つまり何年にもわたってシステムを維持することは、率直さや慣習など、家庭内の美徳をより高く評価することを教えてくれます。美しさは理想主義的なファンタジーです。本当に重要なのは、プログラマーとコードの間で終わりのない会話の質です。それぞれがお互いから学び、適応します。美しさは幸せな結婚の十分な基盤ではありません。
これと同じ知恵の別のバージョンが他の分野に存在します。サミュエル・ジョンソン、執筆について:
あなたの作文を読んで、特に素晴らしいと思う一節に出会ったら、それを消してください。
これについてのウィリアム・フォークナーのバージョンは、はるかに簡潔でした:「最愛の人を殺せ」</p>
私の義父は映画編集者として働いており、映画が撮影されているセットを慎重に避けています。訪問しなければならないとき、彼はできる限り目を覆います。これは、最終的な映画にシーンを含めるかどうかを決定するときに、そのシーンを撮影するのにどれだけの労力がかかったかに影響されたくないためです。重要なのは、最終的な映画でシーンがどれだけうまく機能するかです。
私のエッセイ「プログラマーとしての私の進化」(私が新しいユーザーでない場合はリンクします)は、主に、私が書いたコードについて懐疑論を学ぶことに関するものです。 (ペアプログラミングは、ここでの本当のモーニングコールでした). それは難しい!
彼には良い点があると思います。これが多すぎる人々と一緒に仕事をするのはイライラします。チームワークや問題の最善の解決策にたどり着くのを本当に妨げているからです.
私は少し妄想的になりがちなので、現実にしっかりと根をおろすための実践を心がけています。コードについては、
単体テスト: これらは、抽象的な「美しさ」とは対照的に、コードが何をすべきかにより集中させてくれます。
コード所有権の共有: ここには 2 つの陣営があります。コードの所有権を増やしてプライドが引き継がれることを期待するか、所有権を減らして仲間からの圧力に任せるかです。人々に所有権を与えることが、このコードへの賞賛につながると私は信じています。私たちは共有コードの所有権を実践しているため、誰かが私の完璧なコードをより良くするために (彼らの心の中で) 書き換えるのを常に見なければなりません。あまりにも賞賛するのは時間の無駄であり、感情的に難しいことにすぐに気付きました.
ペアプログラミング: 誰かと並んで作業することで、あなたは現実的になります。
その他のフィードバック: これらはすべてフィードバック ループですが、他にもあります。何かが機能するかどうかを確認するには、誰かがそれを使用する (しようとする) のを見るよりも良い方法はありません。あなたの作品をできるだけ多くの人に見せてください。コードレビューがあります。他の人のコードを読む。静的コード分析ツールを実行します。
私は自分のコードを賞賛したことはありません。私は他の人のコードを「借りて」、それらをエミュレートしたり、より良いものにしたりすることに感心します。特にコーディングについて、知れば知るほど、知らないことがわかります。価値のある唯一のものは、仲間のプログラマーが私のコードを賞賛し、それを借りることです。
自分のコードを称賛することは何も悪いことではありません。これは、将来、より多くの、より良いコードを書くように動機づける正の強化プロセスの一部です。
ただし、賞賛の場所を間違えたり、誤って使用したりすると、問題が発生する可能性があります。コードが本当に良くない場合、または単体テストやその他のテストで明らかにされていないバグがある場合、またはリファクタリング/再設計/置換が必要な場合は、この見当違いのアドミラトインが問題になります。また、コード レビューなどのプロセスの一部をスキップする言い訳として賞賛を使用したり、コードに対して懐疑的な態度をとったりすることは、賞賛の誤用です。
他の優れたものと同様に、コードへの賞賛は見当違いや誤用の可能性があります。それ自体が悪いというわけではありません。それは、「宗教は人々の間に争いや戦争を引き起こすから悪いものだ」と言っているようなものです。
私は PurplePilot を使用しています - 私は自分のコードを賞賛していません。そのため、同じことを行うための新しい、より効率的な (地獄、より簡単な) 方法を常に探しています。私はEffective c#の本が好きで、そこから私が賞賛する多くの有用なコードを取り上げています.
コードを捨ててやり直すことをためらうことはありませんが、必ずしもゼロから始める必要はありません。つまり、特定のシナリオ用のコードを書いてから捨てることで、おそらくシナリオをよりよく理解できるでしょう。言い換えれば、それは「邪悪な問題」であるか、エジソンのように機能しない別の方法を見つけたということです。
コードが破棄されない、または少なくとも再検討されない場合、停滞しつつあるライブラリで開発することは良いことでしょうか?
より健全な視点を持つ方が良いかもしれません - 私たちはロケット科学者ではありませんし、癌を治しているわけでもありません - それはただの仕事です.
(はい、あなたが建築家であれば、あなたが建設を手伝った建物全体を誇りに思うのは理にかなっていますが、彼らは本当に個々の設計図や設計した3階のクローゼットに包まれた多くの自尊心を持っていますか?彼ら自身?)。
2 つの言葉: コード レビュー。
2 人以上の仲間の開発者を集めて、コードのレビュー/批評/コメントを依頼してください。あなたのコードに(確かに厳しい)光を当てます。