私は大学を出たばかりで、この会社で約8か月間働いていますが、開発者の称号を与えられましたが、ほとんどの時間は他の人のコードの修正とデバッグに費やされていました。

なぜ元の開発者が自分のコードを修正する責任がないのか、いつも疑問に思っています。元の開発者が存在しない場合、他の開発者が仕事を引き継ぐ必要があることを理解していますが、開発者が会社の従業員としてまだ働いている場合はどうなりますか？

新しい開発者が学習する機会と見なすことは有益であると主張する人もいるでしょうが、私はそれに同意しますが、コードの問題/問題の複雑さが非常に急な場合はどうでしょうか。私の場合、彼らが修正するように彼らに割り当てたコードのほとんどは重要な問題であり、コードに関する元の開発者の質問を常に私自身に尋ねることになります。なぜそれを作成した開発者は、コード化してからそれをよく理解していると、既存の問題を修正できないのでしょうか？そして、私が言及している問題は、1〜2日で修正できるようなささいな問題ではなく、解決策を見つけるためにコードを深く理解する必要がある問題です。

これの背後にある理由は何ですか？それはソフトウェア業界で一般的ですか？

このようなことを最も広い意味で正当化する主な理由は、「バス要因」だと思います。同じ人が永続的にコードの一部を記述して保守している場合、その人以外には誰もそれがどのように機能するかについての手がかりを持たず、その人が去るときに問題になります。したがって、新しい開発者がバグを修正して開始することは、多くの場合、その根拠で正当化されます。

個人的には、正当化が推論と一致する可能性は低いと思います。これが新しい開発者で発生する実際の理由は、部署が正直に何をすべきかを本当に知らない、本当に包括的なトレーニングプログラムを持っていない、そして主要な機能を備えた彼らにタスクすることについて緊張しているためだと思います。ですから、何を言われても、何かを処理できることを証明し、できれば途中で1つまたは2つのことを学べるのは、おそらくデフォルトの方法でしょう。

私は個人的にこれを達成するためのより良い方法があると思いますが、それは方法であり、それは方法の後でうまくいくと思います（緑の牧草地をやめるために初心者を退屈させるリスクがあるにもかかわらず）。

他のコメンターはすでにいくつかの重要なポイントをカバーしています-私は、特に出荷されたコードのメンテナンスを担当する開発チームでしばらく働いた誰かの立場から話しています。あなたの質問のほとんどすべてが何度も何度も何度も出てきました。

起こっている可能性がある多くのものがあります。あなたは1つ指摘しました-元の開発者が退職した可能性があります。もう1つの可能性は、元の開発者がまだ会社にいる間、彼/彼女は長い間他のものに移り、作業メモリにそのようなものをもう持っていないことです（特に、作業して以来コードがかなり変更されている場合）その上）。

たとえば、私たちが対処しなければならないのは、製品チームが製品の次のバージョンを提供するための非常に積極的なスケジュールを持っていたことです。彼らが既存のバージョンのバグにも取り組む必要があったとしても、少なくとも推論が進んだとしても、彼らは彼らのスケジュールを満たすことができなかっただろう。この点については議論の余地があると思いますが、企業ソフトウェアの世界の現実は、ソフトウェアエンジニアリングのすべてのベストプラクティスを常に観察することを含め、ドアから物を取り出すことが他のすべてに勝るということです。「トレードオフ」とは、開発者が遅かれ早かれこれらの環境で行わなければならない不快な妥協のすべてに当てはまる曖昧な用語です。

ただし、一方で、重要なバグを修正するには、コードベースについて多くのことを本当に学ぶ必要があります。それは痛みを伴い、時には意気消沈し、しばしば圧倒されます。しかし、ソフトウェアプロジェクトの主題の専門家になると、どの程度正確に思いますか。教育のためにコードを読むのに何日も費やすことができますが、その種のコードの閲覧は、問題を解決するためにコードと「戦う」必要があったほど上手く行きません。研究は、私たちが行うことによって学んだモットーを絶えず上回っています。悲しいことに、あなたがスタートアップや新しいチームにいない限り、これは通常、いくつかのリリースで使用されているソフトウェアプロジェクトに参加していて、対処する必要がある実際の不満を持つ実際の顧客がいることを意味します。これは、まずバグを修正することを意味します。

本当に重要なことは、マネージャーと定期的に連絡を取り、仕事から得たいことを表明し、ビジネスが現時点で実際に目標に対応できるかどうかを確認することです。うまくいけば、答えはイエスになります。しばらくこだわり、現在のチームから可能なすべての経験を集めてください。答えが「いいえ」であることが判明し、優れた開発者である場合、多くのオプションがあります。しかし、バグを修正することで得られる経験を軽視しないでください。私は今、3番目のソフトウェアの仕事に従事しており、大量のコードを書かなければなりません。幸いにも、バグの特定、修正、防止に多くの時間を費やしてきたため、最初から多くのことが機能しています。

ソフトウェア開発者は、コードを作成するよりもコードを読んだり理解したりすることに多くの時間を費やすことを認めなければなりません。そして、私の個人的な経験から、より多くのコードを読むために働いている会社はより良いです。ですから、他人のコードに対処しなければならないという事実は、あなたを驚かせたり、混乱させたりするべきではありません。

そして、これはかなり自然なことのようです。何かを学ぶためには、それがどのように行われたかを見なければなりません。ペアプログラミングを実践している企業は多くなく、初心者はこのように教えられます。ほとんどの場合、他の人のコードを読むことによって、新しいテクニック、パターン、会社のコーディングスタイルなどを学びます。

そして、コードを理解する最も効率的な方法は、実際にコードを操作することです：デバッグ、リファクタリング、バグの修正。これは、コードの所有権を取得する場合の一般的な方法です。

元の開発者が自分のバグを修正しない理由として考えられるのは、

• バグの優先度は低く、開発者の現在のタスクはより重要または緊急です。
• 開発者はそのコードを長い間使用していなかったので、いずれにしても、古いコードを呼び出すにはしばらく時間がかかります。
• 開発者は何か複雑で忙しいので、中断する必要はありません。

PS元の開発者があなたの質問に答えてくれるのは幸運だと思います。

教育的な理由とリスク要因の理由がありますが、ほとんどは単なる数学です。ほとんどのプログラミング作業はメンテナンスであり、会社で最も長く働いている人は、メンテナンスが必要なほとんどのコードを生成しています。

一人のソフトウェア会社を考えてみましょう。10年後、彼は彼を助けるために誰かを雇います。利用可能な作業の90％がメンテナンス作業である場合、古い男のコードに触れられない場合、新しい男は何に取り組む予定ですか？大規模なチームでは、効果を定量化するのは困難ですが、それが存在しないという意味ではありません。

だから、誰がどのコードの責任者なのかわからないようにしてください。人々は「彼らの」コードに執着し、軽くあきらめないでください。数年後には、自分の責任を守りたいコードがありますが、あなたには時間がありません。

エリックはその場にいます。

また、経営陣は、すべての開発者にコードの特定の側面をよく知ってもらうことで、賭けをヘッジしたいと考えています。ある人がいくつかのコードを書いたからといって、彼らがそこで働いている間、自動的に責任を負わせるわけではありません。正反対に、それを維持する開発者が増えるほど、バグが発見され、mnetnetが改善される可能性が高くなります。誰もが自分の印を残すのが好きです;）私が何を意味するか知っているなら。別の見方は、コードは会社ではなく開発者によって所有されているというものです。特定のタスクについてより多くの開発者が選択できるようにすれば、プロジェクトマネージャーの生活が少し楽になります。彼らはたぶんあなたを彼らのコードライブラリに楽にさせ、同時にあなたの能力をテストしています。彼らは会社の費用がかかる可能性のあるものの近くに新入社員を任せて、最初の6か月ほどは間違いなく夢中になります。

すべて良い答えです。ここに別の角度があります-

それは単純な経済学かもしれません

元の開発者よりも問題を発見して修正するのに5倍時間がかかる場合がありますが、その間、元の開発者が行っている作業は、会社にはるかに多くの収益をもたらします