回答:
請負業者として30年を経て、それは複雑になりました。
それはすべて使い捨てです。私は何百ものクライアントと仕事をしてきました。コードは二度と表示されません。なぜ添付されるのですか？所有権の感覚はありません。
それは非常に目に見える。社内のコードよりも高価なので、多くの精査を受けます。私はそれを維持するために周りにいないので、非常に多くの精査を受けます。コードのウォークスルーとハンドオーバーは非常に重要です。職人技には誇りがあります。しかし、所有権の感覚はありません。
私の記録は17年の生産です。あらゆる種類のメンテナンスがゼロの12年間。
電話がかかったので知っています。彼らは会計システムを改訂しており、私が何年も前に構築した巧妙なコスト配分アルゴリズムを置き換える方法を知りたいと思っていました。コードを調べたところ、ファイルは12年前の最後の拡張以降変更されていません。（バグ修正ではありません、私の知る限り）
私が知っている次の最長の実行は、7年間の完璧な運用でした。ただし、これには深刻なY2K問題があり、4桁の年のファイル名を使用するためにいくつかの手直しが必要でした。内部アルゴリズムはすべて正しいものでしたが、ログファイルは間違った順序で表示されていました。
繰り返しになりますが、前回のリリース以降、ファイルは変更されていないため、問題はありませんでした。
だから、はい、職人技には大きな誇りがあります。
しかし、「所有権」はありません。それは私のコードではなく、彼らのコードです。ビルドするだけです。
職場では、私が座っている椅子が私のものであるのと同様の意味で、コードの一部は私のものです。私はそれを書き、私はそれをできる限り良く作り、それを所有していると感じ、人々は変化について私に尋ね、人々はそれを私のものと呼ぶでしょう。そして、私の椅子のように、会社を辞めた後は二度と見ることはなく、感情的な執着はもうありません。
「私の」という言葉には、その意味に多くのバリエーションがあります。「私の妻」と「私の歯ブラシ」は厳密に平行ではありません。
自分でコードを作成する場合、それに対する感情を持つ余裕があります。ビジネス向けのコードを作成する場合は、可能な限りこれらの感情を慎重にパージする必要があります。優れたプログラマーがコードに対して感情的になることで悲しみを覚える回数を見ることはできません。
自分に言ってください：「私はそれを作った、それは良いが、それは私のものではなく、私はもっと作ることができる。」信じているなら、劣悪な製品の営業担当者が昼食で上司にBJを与えたために人生の6か月が陳腐化しても、彼に夢中になって仕事を失うことはありません。
彼らがあなたに支払っているのを思い出してください。私たちはみんなクールなことをしたいと思っていますが、彼らが私たちに穴を掘るためにお金を払っているなら、それらを再び埋めることが彼らの特権です。私はちょうどその、その後数ヶ月は、ひどい特徴を組み込んだヶ月を過ごした私は、Webアプリを書いた状況、持っていたより元の状態に戻ってそれをコーディングします。最後の2週間分の「作業」はSVNリポジトリから取得し、新しいバージョン番号で再コミットしました。そして、私はそれで大丈夫です。
私が書いたコードが大好きです。他の人も理解できるように、それらを理解して調整します。人々が私に近寄ってきて「おい、私たちがあなたのために書いたスクリプトをまだ使用している。それはとても安定していて移植性がある」と言うとき、私はその誇りと所有権の気持ちが大好きです。
コードがどこに行き着くのかを見ることができれば、コードにアタッチしても害はありません。つまり、すべて社内にあり、誰のためにプログラミングしているのかがわかっている場合、実際にそれは良いことだと思います付属します。Cozは、さらに多くの輝きを生み出すことを愛するでしょう。
一方、（@ S.Lottが言ったことを繰り返しているかもしれないことを十分に承知している）コードがクライアントのプロパティとして終了する場合、感情的になることは意味がありません。友人が休暇に行ったときに子犬の世話をするようなものです。：-/
コードを二度と見ないかもしれない請負業者やコンサルタントは、おそらく自分のコードに感情的に結びつく理想的な候補者ではないでしょう。何度も何度も「放棄」しなければならないので、しばらくすると、貧しいコンサルタントの創造力が損なわれるでしょう。
請負業者ではなく従業員の観点から見ると、チームメンバー全員が、作成するコードと作成するすべてのコードの所有権を感じてほしいと思います。この所有権と誇りは、チーム全体に拡大する必要があります。自尊心と所有権を感じると、問題のある製品への愛着が生まれ、チームメンバーの仕事に意味と感覚が加わります。これにより、小規模から大規模のチームでパフォーマンスが大幅に向上することがわかりました。
避けるべきものと私が嫌いなのは、自分が書いた特定のコード行に感情的に執着しているように見え、それを墓場で守る人々です。彼らは変更を望んでおらず、見下ろし、変更や改善のためのアイデアを断り、信頼できるものでそれを正当化しようとします。私自身の経験から、これがしばしば要約するのは、変化への恐怖と未知への恐怖です。問題は、実際には古いコード行を放棄することではありません。代わりに、自分では書かれていないこともある何か新しいことに取り組む必要があり、それに失敗する恐れがあります。
この種の「病気」のコードへのアタッチメントは、私が防ぐために努力するものです。しかし、製品への「健康な」感情的なつながり、ひいては記述されたコードは、私が奨励するものです。
これは興味深い質問であり、上記の投稿のいずれかに同意します：はいといいえ-しかし、異なる理由があります。
コードに執着しますか？絶対そうです。しかし、コードそのものではなく、全体的なアーキテクチャとアプリケーションだと思います。通常、ビジネスの人々が望むものを実際にコードに入れる前に、多くのドメイン固有の調査を行う必要があります（IDEを書いている場合を除き、間違いなく再帰に行き詰まっています）。
一方、コードベースの古い部分を捨てる以上に、私が気に入っているものはあまりありません。文章がどんなに難しくても。旅は製品よりもはるかに重要です（少なくともエゴにとってはもちろん、製品自体も同様に機能しなければなりません）。
所有感はありますか？まあそれはプロジェクトの状況に依存します。コードが二度と表示されない場合（プロジェクトの一部が終了し、先に進んでいるため）、その内容についてなぜロマンチックになりますか？ただし、（何らかの形で）それをサポートし続けている場合は、愛着の感覚は良いことです！構築している製品に関心がある場合、高品質のアーティファクトを配信するためにハートを試みている可能性は非常に高くなります。
全体として、私は自分が書いたコードと実際的な「関係」を採用しようとしています。