他のチームメンバーのコードを書き換える、書かれていないルール[終了]

私たちは集団コードの所有権を実践しています。私の理解では、これは開発者がコード行を変更して機能を追加したり、バグを修正したり、バグを修正したり、設計を改善したりできることを意味します。

しかし、まだチームにいる開発者からのコードの完全な書き換えについてはどうでしょうか？最初に彼に尋ねるべきですか？ベストプラクティスは何ですか？

良いコミュニケーションは常にベストプラクティスだと思います。開発者に相談して、それがそのままの形でコーディングされている理由があるかどうかを確認します。それは彼らが何年も前に戻ってそれをリファクタリングすることを意味していたかもしれない、それは彼らが非常に正当な理由でそのようにしたかもしれない、あるいはあなたが二人とも会話から何かを学ぶことができるかもしれない。

事前の連絡なしに行って書き直すことは悪意のレシピです。

この質問のまさに前提は、既存の答えのどれもが適切に対処しようとしているとは思わないという多くの懸念を私に生じさせます。ここでいくつかのフォローアップの質問をさせてください：

1. あなたはリファクタリングではなく書き換えについて話していることを絶対に肯定的に確信していますか？定義により、外部の動作を変更せずに改善された（または単に異なる）実装をもたらすコードスタイルまたは構造の変更は、書き換えではなくリファクタリングです。モノリシックな500行のルーチンを50個のサブルーチンのセットに分割するには、かなりの量の新しいコードを書く必要がありますが、それは書き換えではありません。書き換えという用語は、製品または機能全体を破棄し、最初からやり直すことを意味します。それは軽く取られるものではありません。

2. 元のコードの動作が非常に間違っている場合、または実装が本格的な書き直しを必要とするほどバグがある場合、チームのプロセスに捕らえられず、適切なコンテキストで（つまり、技術的にではなく）対処されなかったのはなぜですか？不良または疑わしいコードは、テスト、コードレビュー、設計レビューなどを通じて健全なチームに迅速に公開されるべきです。これらはありますか？

3. マネージャー/技術リーダーは問題を認識していますか？プロセスの種類に関係なく、コードの品質は通常、開発マネージャーの責任です。彼または彼女は、あなたが尋ねるべき最初の人です-明らかに「そんなにくだらないコードを書いた」という文脈ではなく、単に「ここに大きな問題があると思います。書き換えについて話してもいいですか？」この種の議論が正当化されない場合、おそらく書き換えも正当化されないのでしょうか？

4. 問題のあるコードのサイズと範囲が書き換えの深刻な議論を正当化するのに十分な大きさである場合、なぜそれが1人の開発者によって独占的に所有されているのですか？私がコードを見て「書き直し」を考えたときではないにしても、ほとんどの場合、それは何十人もの異なる人々によって踏みにじられており、その悪さはスタイルの矛盾、誤ったまたは変更された仮定、古き良きの蓄積の直接的な結果です-昔ながらのハック。コードは、所有権が共有されているため、時間の経過とともにいばらになります。

   ここでの私のポイントは、集団所有権を実践していると思われる環境で、ある人がこのような大量のコードを所有するのは奇妙だということです。他の人はこの開発者のコ​​ードに触れることを恐れていますか？彼らは主題を持ち出すことを恐れていますか？おそらく、あなたのグループのダイナミックな根本的な問題、またはこの開発者の具体的な問題があります。ある場合は、無視しないでください。あるいは、このプロジェクトに取り組むのは初めてかもしれませんが、もしそうなら、なぜゲームの早い段階で書き換えを考えているのですか？状況についての何かが私にとっては合わないようです。

5. 質問は、最初の段落で述べていany developer can change any line of code to add functionality, to refactor, fix bugs or improve designsます。リライトはウィルではないこれらの事を行いますか？それとも、何かのでしょう余分を -もしそうなら、何？基本的に、何しているの書き換えをやりたいと思っためのあなたの理由は、あなたは、彼らが製品やチームに利益をもたらすだろうとどのように確信していますか？あなたは私のために答える必要はありませんが、チームとそれを議論することを選択するかどうか、そしていつ選択するかについて、いくつかの客観的なポイントを持っている方が良いでしょう。

この質問には膨大な量の文脈が必要であり、その文脈を非常に明確に理解せずに答えるべきではないと本当に感じています。「正しい」答えは、チーム、製品、組織、性格、プロセス、元のコードの範囲、変更の範囲などに完全に依存します。これは、IMOであり、オンラインQ＆Aサイトではなく、チームで絶対に取り上げる必要がある問題です。

なぜコードを編集しているのですか？

バグはありますか、それともより基本的な設計上の欠陥ですか？

前者の場合、コードのマイナーなバグを修正するための書き直しが心配です。

後者の場合、「自分の」コードが書き換えられる可能性があるというヘッズアップを期待していましたが、それが実現することは完全に幸せです。

それが集合的なコードの所有権のポイントです-あなたが書いたコードは、より良いものが出てきた場合に修正したり置き換えたりするためのものです。

一般に、コードにすべての責任があることに同意する場合、コードが改善されていればコードを書き換えても構いません。最初に礼儀として他の開発者と話し合ってください。特定の方法で書かれている正当な理由があるかもしれません。個人的なレベルでは、多くの開発者は自分が生産するものに感情的に投資します。

具体的には、チームのダイナミクスにある程度依存します。ジュニア開発者のコ​​ードを書き直そうとしている上級開発者は、単純に書き直す前に、おそらく彼らとコードレビュー（私のサイト）を実行する必要があります。そのようにして、ジュニア開発者は状況から学ぶことができます。

元の開発者がチームに所属しているかどうか、あるいはあなたが元の開発者であるかどうかは、実際には関係ありません。完全な書き換え任意の共有コードは次のような理由から、あなたのチームによって実行されなければなりません。

• かなりの時間がかかります。他の誰かが関連する変更に取り組んでいる場合、時間を無駄にしたくありません。
• 他の人々は異なる視点を持っています。20年プログラミングしていても、めったに触れないコードとのやり取りについて他の人が知っているかもしれません。
• 他の開発者は、ソースコードの「顧客」です。ソースコードは、他の開発者が読むことができるように書かれています。それらには、アーキテクチャ要件、スタイルに関する入力、またはそのコードで必要としていた機能要求がありますが、時間がありませんでした。別の方法でリファクタリングする必要がある別の開発者を見つけるためだけに、リファクタリングを終了する必要はありません。

マシュー・フリンが言ったように、最初に開発者と話す必要があります。最初の開発者は、機能について重要なことを伝え、このソリューションまたはそのソリューションが提供された理由を説明する場合があります。

ただし、コードをリファクタリングまたは再作成する前に、そのコードを含むバックアップまたはブランチを作成してください。古いコードが正常に機能する場合、復元される可能性が残ります。

ソース管理システムを持っている場合（私はあなたが持っていると思います）、可能であれば、コード全体をリファクタリングし、その後のみ、正常に動作することが確認できたら、チェックインします。

少なくとも新しいコードが正常に機能することを確認するまでは、古いコードを削除しないでください。しかし、古いコードを永久に残しておくのも良いことではありません。テストに合格した1か月後など、しばらくしてからコードを削除することをお勧めします。

それの範囲は何ですか？

• より効率的にするために数行をやり直している場合は、それを行ってください。微妙な振る舞いを消してしまう危険性があるかどうか尋ねてください。本当に些細な（タイプミスを修正する）場合を除き、スクラム中または変更が完了したら電子メールで変更を報告します。

• 適切なサイズのクラスを作り直す場合は、おそらく設計/動作を理解しているかどうかを確認する必要があります。同じエリアで働いているかもしれない誰でもあなたと気づき、調整できるように、事前に人々に知らせてください。

• 大規模なシステムを作り直す場合は、チームと協力して変更を認識させ、設計を計画する必要があります。

あなたの元の作家がそこにいる場合、彼らと通信します。あなたが知らないケースや状況がある場合に備えて、エチケットのためだけではなく、追加情報のために。時には、彼らはあなたに何か貴重なことを伝えるでしょう。

ひどいコード制御があります。現在、レビューとメンテナンスが必要なものが山ほどあり、コードレビューを行う人すらいません。以前のライター（moiを除く）は、コードをコメントすることを気にしませんでした。そして、彼らは会社を去りました。コードについて尋ねる人はいません。

書き直すときは、コメントアウトしたコメント、コメントアウトした日付、名前/イニシャル、およびコメントアウトした理由をコメントアウトします。名前やイニシャル、日付、理由が追加されたなど、新しいコードをコメントします。

追加のコメントがパッケージヘッド（通常は）で作成され、どの関数/プロシージャ/ SQL /などが示されます。日付とともに変更されました。変更されたセクションを簡単に検索でき、それらのセクションには完全なドキュメントがあります。

コメントは安いです。日付は、何が変更されたかを示す指標であり、x日後（日数/改訂数/新規採用者数/退職者数）にコードから古いコメントを削除でき、残りは新しいベースラインになります。

私の観察から、一般的なプラクティスは次のとおりです。コードを削除しないでください。コメントアウトして保管してください。

私の練習は、交換しながらコメントアウトすることです。（主に参照用）。次に、作業中の変更の最後のコミットで削除します。（これには、バージョン管理と、変更を元に戻す方法の理解が必要です。）

古いコメント付きコードを見つけたら、適切なコメントを付けて別のコミットで削除しようとします。これにより、必要に応じて変更を元に戻したり検査したりしやすくなります。

すべての変更について、改訂履歴を使用して、コードを作成した開発者を決定できる必要があります。（注釈付きの改訂履歴がここで役立ちます。）可能であれば、連絡して、コードがそのままの理由を確認してください。多くのプロジェクトでは、クリーンアップ時間は発生せず、物事は取り残されます。バグトラッカーをチェックして、必要なクリーンアップの記録があるかどうかを確認します。場合によっては、リリースを1〜2回クリーンアップする必要があります。

コードを変更する場合は、そのコードで作業している理由があるはずです。元の開発者に問い合わせて、コードがそのようなものである理由を確認してください。修正しない正当な理由がある場合は、修正されなかった理由、または修正すべきでない理由を説明するコメントを追加します。これにより、次の開発者の時間が節約されます。

FixMe、ToDo、Bug、Hackなどのタグを使用して、後で変更できるコードを示すことができます。（制限をバグとしてタグ付けし、必要な条件下でトリガーされない場合は修正しないことは許容されます。）ホームアカウンティングプログラムが2000万ドルでオーバーフローした場合、バグになる可能性がありますが、修正に多くの時間を浪費しませんそれ。

コードを変更することが適切な場合は、元の開発者がコードレビューの変更を行う必要があります。

おそらく、書き換えが必要な理由に依存します。書かれたものに問題があり、常に問題があったためである場合、将来コードを修正する必要がある頻度を最小限にするためだけに、それについて話すことが求められます。

この場合の私の提案は、コードを修正するときにペアにすることです。このように、中間状態の良い例を提供し、（できれば）書き換えられたコードが優れている理由に関するコンテキストを提供します。また（個人的な演習としてのみ）、完全に書き直さずにコードをリファクタリングしてみてください。難しくなりますが、あなたにとっては良いことです。

一方、リライトが必要になるのは他にもいくつかあります。

• チームは、コードが書かれてから多くのことを学びました。コードを書いた開発者は、あなたの入力がなくても、今とは異なる方法でそれを書くでしょう。

• 新機能の要件により、ターゲットを絞ったミニリライトが適切になるように状況が変わります。

これらの場合、私はおそらく会話を気にしません。

それについて考えると、コードが長く存在するほど、会話が必要になる可能性は低くなるように思えます。

@aaronaughtはいくつかの良い点を示したと思いますが、それは本当に私が与えたかった答えにつながります。つまり、誰が変更を加えたのか（そしてなぜ）誰がコードを書いたのかによって異なります。

私の個人的な経験では、コードは通常、意図したとおりに機能しないか、実際に機能するものを拡張する必要があるために変更されます。

チーム開発環境では、元のコーダーと話す必要はありません（できなくてもかまいません）。コードからすべてを明確にする必要があります。

それは私の時間のほとんどを消費する質問につながります。これは元のプログラマーが意図したものであり、それが最も頻繁にコードが削除される原因となり、なぜすべてをコメントする必要があるのか​​、そして経験の浅いジュニアプログラマーが最も多い場所ですしばしばファウルになります。

他の人のコードを変更（リファクタリング）するプログラマーは、礼儀と練習の問題として、既に配置されているコードの同じコーディングスタイルをコピーし、最初に元のコードがどのように機能し、何をしようとしているかを把握するための手順を実行する必要があります達成し、実際に達成します。多くの場合これはそれ自体でバグを特定しますが、確かに、次の人があなたのコードを見ている痛みに耐えることを人々に強います。

私のチームでは、誰でも何かを削除、リファクタリング、または書き換えることができます。私は「所有権」を怠nessを生む慣行と考えています.1人の人が変更の通知を確実に受け取るように、なぜ彼らはコードを読みやすくする必要があるのでしょうか？

つまり、いや、あなたはコードの元の作者に尋ねる必要はないはずです、そしてあなたがするコードを見ると、それは彼のコードが十分に読めないか、改善する必要があるかの兆候ですあなたの技術。ただし、書き直しの際に必要な機能を誤って削除しないことが確実になるまで、元のコードをそのままにしてコメントアウトしておくのが良いと思います。誰も完璧ではありません。

多くの場合、コードはある理由で特定の方法で記述されます。著者に変更を伝えることは、常に最善を尽くします。