コードへの感情的な愛着
会社の従業員として、コードを書くとき、それに愛着があるように感じますか？コードの所有権があると思いますか？それとも、何か別のものに移った後、何が起こるかを心配することなく、完全に切り離して記述しますか？
編集：私は悪いコードを書いてから実行することについて話していません...
請負業者としての30年後、それは混合されています。
すべて使い捨てです。私は何百ものクライアントと仕事をしてきました。コードが二度と表示されることはありません。なぜ愛着を持つのか？所有感はありません。
とても目立ちます。社内コードよりもコストがかかるため、綿密に調査されます。私はそれを維持するために周りにいないので、それは非常に多くの精査を受けます。コードのウォークスルーとハンドオーバーは非常に重要です。職人の技には誇りがあります。しかし、所有感はありません。
私の記録は17年の生産です。メンテナンスの必要がまったくない12年間。
電話がかかったのでわかります。彼らは彼らの会計システムを改訂していて、私が何年も前に構築した賢いコスト配分アルゴリズムを置き換える方法を知りたがっていました。私はコードを見て、ファイルは12年前の最後の拡張以降変更されていません。 （バグ修正ではありません、AFAIK）。
次に長いこと-私が知っている-は、7年間の完璧な運用でした。ただし、これには重大なY2K問題があり、4桁の年が含まれるファイル名を使用するようにいくつかのやり直しが必要でした。内部アルゴリズムはすべて正しかったが、ログファイルが間違った順序で表示された。
繰り返しになりますが、前回のリリース以降、ファイルは変更されていなかったため、問題がなかったことがわかります。
だから、はい、職人の技には大きな誇りがあります。
しかし、「所有権」はありません。それは私のコードではなく、私のコードです。私はそれを作るだけです。
多かれ少なかれ一人の開発者として、私が書いたものを維持しなければならないことへの恐怖は、恐ろしいコードを書かないようにする私の背後にある主要なドライバーです。
職場では、コードの一部は私のものです。私が座っている椅子が私のものと同じような意味で。私はそれを書きました、私はそれをできるだけ良くしました、私はそれを所有していると感じます、人々は変更について私に尋ねます、そして人々はそれを私のものと呼びます。そして、私の椅子と同じように、会社を辞めると、二度とそれを見ることはなくなり、感情的な愛着もなくなります。
「鉱山」という言葉には、その意味にさまざまなバリエーションがあります。 「私の妻」と「私の歯ブラシ」は厳密には平行ではありません。
自分でコードを書けば、それに対する感情を抱く余裕ができます。ビジネス用のコードを書く場合、可能な限りそれらの感情を悪質にパージする必要があります。優れたプログラマーがコードに感情的になって悲しみを感じるのを見た回数を数えることはできません。
自分に言いなさい：「私はそれを作りました、それは良いですが、それは私のものではなく、私はもっと作ることができます。」あなたが信じるそれなら、劣った製品の営業担当者が昼食時に上司にBJを与えたために人生の6か月が古くなるとき、あなたは彼に夢中になるためにあなたの仕事を失うことはありません。
彼らがあなたに支払っているのを思い出してください。私たちはみんなクールなことをしたいのですが、彼らがディグの穴にお金を払っているなら、それらをもう一度埋めるのが彼らの特権です。 Webアプリを作成し、数か月かけてひどい機能を組み込んでから、数か月かけてmoreコーディングして元の状態に戻したという状況でした。私はSVNリポジトリからプルした最後の2週間分の「作業」を行い、それを新しいバージョン番号で再コミットしました。そして、私はそれで大丈夫です。
いいえ、しかし、私が最初に書いたコードで他の人が導入したバグを修正する必要が本当に嫌いです。そもそも変更が私に割り当てられていれば幸いです。修正が元のデザインから完全に外れている場合は、さらに嫌です。より高いレベルのモジュールで循環依存関係を作成する。
はいといいえ。
はい-これはあなたが作成したものなので、愛着があります。まるで、自動車デザイナーが道路で設計した車を見て誇りに思ったり、恥ずかしく思ったりするのと同じです。
いいえ-所有権に関する限り、通常、会社で働くことで報酬を得ることと引き換えにそれを放棄します。車を製造する工場ラインの従業員は、時間の支払いを受けるため、ラインから離れる従業員一人一人に所有権を与えません。
私が書いたコードは非常に独占的です。これは、特定の問題を解決する方法について私が下した決定を表すものであり、したがって問題を合理的に検討し、論理的でうまくいけばエレガントな解決策を考案する私の能力を反映しています。とはいえ、私が会社の時間に書くことはすべて会社のものです。私はそれが私をかむために戻ってこないことを願っています、そして私は自分のコードを修正するように頼まれたいと思いますが、そうでなければ、そうではありません。 （そして、3か月前にコードを書いていて、私の名前をソース管理に入れていた人はばかげていると付け加えるかもしれません）。
私が書くコードが大好きです。私はそれらを理解し、他の人もそうするようにそれらを調整します。人々が私のところに来て、「おい、私たちはまだあなたのために書いたそのスクリプトを使っています。それはとても安定していてポータブルです」と言うとき、私はその誇りと所有権の感覚が大好きです。
それが最終的にどこに行くのかがわかる場合、つまりコードがすべて社内にあり、誰または何のためにプログラミングしているのかがわかっている場合、コードにアタッチしても害はありません。付属。 Cozは、より多くの輝きを生み出すことだけが大好きです。
一方、コードが最終的にクライアントのプロパティになる場合は（@ S.Lottの発言を繰り返している可能性があることを十分に認識している）、感情的になっても意味がありません。まるで、休暇中に友達の子犬を世話しているようなものです。 ：-/
どういたしまして。チェックインすると、「私のもの」ではなくなります。当然、私はメンテナンスとトラブルシューティングの頼りになる人になりますが、それに対する所有権を感じません。
私は自分のコードに対してveryが独占的であると感じた人がいることを知っています。誰かがバグを修正したり、最初に実行せずに何らかの方法で修正したりするとイライラします。私はそのように感じたことがありません。私が尋ねるのは、私のコードで問題を見つけて修正した場合、問題が何で、どのように修正されたかを教えてください。将来同じ間違いをすることはありません。
コードを二度と見ることがない請負業者やコンサルタントは、おそらくコードに感情的に執着する理想的な候補ではありません。何度もそれを「放棄」しなければならないことは、おそらくしばらくすると貧しいコンサルタントの創造力を損なうでしょう。
請負業者ではなく従業員の観点からそれを見ると、チームメンバー全員に、彼らが書いたコードと作成したすべてのものの所有権を感じてもらいたいと思います。この所有権と誇りは、チーム全体に及ぶはずです。誇りと所有感を感じることで、問題の製品に愛着が生まれ、チームメンバーの仕事に意味と感覚が加わります。これにより、小規模から大規模のチームでパフォーマンスが大幅に向上するのを見てきました。
避けなければならないことと私が嫌いなのは、自分が書いたコードの特定の行に感情的に執着しており、それを墓に擁護している人々です。彼らは変更を望んでおらず、変更や改善のアイデアを軽視して断り、信頼できると思われるものでそれを正当化しようとします。これが私自身の経験からしばしば沸騰するのは、変化への恐怖と未知への恐怖です。問題となっているのは、実際には古いコード行をあきらめることではありません。代わりに、時には自分で書かれていない、何か新しいことを引き受けなければならず、それに失敗する恐れがあります。
コードへのこの種の「病気の」添付ファイルは、私が防止しようと努力するものです。しかし、製品への「健康な」感情的なつながり、ひいては書かれたコードは、私が奨励するものです。
地獄はい、彼はいくつかの変数の名前を変更するのに十分傲慢だったので、私はかつて同僚を殴打しました。
いいえ、そうではありません。私はソフトウェア開発の報酬を得ます。私は認めますが、他の開発者によって私のコードにバグ修正が行われるのを見ることは、-自我-に影響を与えます。
これは興味深い質問で、上記の投稿の1つに同意します。「はい」と「いいえ」ですが、理由は異なります。
コードに執着しますか？絶対そうです。しかし、それはコードではないと思いますitselfではなく、全体的なアーキテクチャとアプリケーション。通常、ビジネスの人々が望むものを実際にコードに組み込む前に、多くのドメイン固有の調査を行う必要があります（IDE-あなたが間違いなく再帰に陥っている場合を除いて） 。
一方で、コードベースの古い部分を捨てることほど好きなものは多くありません。執筆がいかに困難であろうとも。旅は製品よりもはるかに重要です（少なくとも自我にとっては、もちろん製品自体も機能する必要があります）。
所有感はありますか？まあそれはプロジェクトの状況に依存します。コードが二度と表示されない場合（プロジェクトの一部が終了し、次の作業に進むため）、それでなぜそのことについてロマンチックになるのですか？しかし、あなたがそれを（何らかの方法で）サポートし続けるなら、愛着の感じは良いことです！作成している製品に関心がある場合、高品質のアーティファクトを提供しようとする可能性が非常に高くなります。
だから私は全体として、私が書いたコードと実際的な「関係」を採用しようとしています。