それが正しいとき
編集によってプログラムの機能が向上したり、コード自体が読みやすく、保守しやすくなったりする場合。
それが間違っているとき
編集がプログラムの機能を損なう場合、または編集者に忙しい仕事を提供する以外の目的を果たさない場合。
コードの所有者は誰ですか？会社ですか、それとも開発者ですか？
所有者が（いつものように）会社である場合、あなたまたは同僚によって書かれたコードの編集に違いはありません（特定のコード保守ポリシーがない限り）。
お互いのコードを編集することは、コードが進化するにつれて行われるべきであり、あなたが集合的なコード所有権を持つように、練習として奨励されるべきです。
コードはチーム全体が所有する必要があります。 1人の開発者だけが編集する（したがって実際に理解するだけの）コードを持つことは悪い考えです。自分で変更を加えるコードを使用していない場合は、おそらくそれを理解していないでしょう。他の開発者が会社を辞めるか病気になるまで待つことは、コードを学ぶのに間違った時期です。
詳細な単体テストを実施し、ソース管理を使用することは、この方法が低リスクであることを意味するはずです。
チーム全体にボブおじさんの「ボーイスカウトルール」に従うように促し、常にコードをチェックアウトするよりも少しクリーンにチェックインしようとすることは、コードが時間の経過とともにクリーンな状態を保ち、判読不能にならないようにするための良い方法です。 、維持不可能な混乱。
これの唯一の欠点は、この慣行が編集戦争に変わり、開発者が絶えず互いの変更を元に戻す場合です。これはおそらく、編集戦争を引き起こしているもののコーディング標準を決定していないことを示しているので、これを作成する良い機会になるでしょう。
あなたが取り組んでいることが変更を必要とするとき、それは正しいと思います。あなたがバグを修正するように割り当てられていて、バグがそのコードにあるとき、それは正しいです。
コードが作業内容とは関係がないが修正が必要な場合は、チームリーダーに提示し、修正の優先順位を割り当て、修正する人（あなたではない可能性があります）を割り当てますそれ。彼がそれにあなたの時間を費やさないと言った場合、それはその時点で修正するために身に着けられています。あなたは、あなたが働きたいものではなく、あなたが取り組むように割り当てられたものに取り組むために報酬を支払われています。どうしても変更が必要だと言われますが、優先順位の設定はマネージャーの仕事であり、あなたの仕事ではありません。
個人的な好みのために作業コードを変更するのは間違っています。
コードが修正するように設計された問題を理解していない場合、またはコードを理解している場合でも、それは間違っています。それがあなたのニーズに合わないからといって、あなたがそれをいじっても何かを壊さないという意味ではありません。自分がしていることを機能させるために変更する必要がある場合は、元のプログラマーに、彼が行ったことを行った理由と、ニーズに合わせて変更した場合に影響を受ける可能性があることについて話してください。動作しない場合を除いて、理解できないコードは絶対に変更しないでください。これは、コードを修正しないという意味ではありません。時間をかけて完全に理解するまで、特にすでに本番環境にあるコードの場合は、コードを変更しないことを意味します。
同僚が書いたコードを編集するのはいつ正しいですか？
これは、製品がどのフェーズにあるかによって異なります。製品がすでに安定していて、すでにリリースされている場合、本当に醜いコードに必要な大きな変更がない限り、必要のない変更は行いません。
同僚が書いたコードを編集するのが正しいのはどの問題ですか？
コーディングのフォーマットについては気にしないでしょう。コードが非常に複雑で、とにかく変更する必要がある場合、または問題を引き起こしていて正しく機能していないように見える場合は、リファクタリングする必要があります。
Stackexchangeやwikiと同様に、コードを共有し、変更がグローバルな設計と目標に適合する限り、誰でもコードを変更できるようにする準備ができている必要があります。しかし、自分自身に質問してください。デバッグ用でないのに、なぜ誰かが他の誰かのコードを変更しなければならないのでしょうか。プロジェクトを明確に細かく分割して、複数のプログラマーが同時にコーディングを並列化できるようにしましたか？
同時に、異なる機能のために、同僚と同じコードを変更することを余儀なくされた場合、コードの絡み合いと悪い「関心の分離」があります。各プログラマーがソフトウェアコードベースのさまざまな部分で作業できるように、設計を修正する必要があります。