他の人のコードをリファクタリングする政治的に正しい方法は何ですか？

Question

私は現在、大企業の地理的に分散したチームで働いています。誰もが今日のタスクに集中し、物事を成し遂げるだけですが、これは時には物事を迅速に行わなければならないことを意味し、それが問題を引き起こします...あなたは、同じ古い、同じ古い。

私は次のようないくつかの匂いでコードにぶつかっています：大きな関数の無意味なユーティリティ関数/メソッド（本質的にはWordの書き込みを保存するためだけ）、複雑すぎるアルゴリズム、異なるファイル/クラスに分解する必要がある非常に大きなファイル（1,500行以上）、など.

他の開発者に提案された改善について悪意を抱かせたり間違ったりさせずにコードを改善する最良の方法は何でしょうか？

haylem · Accepted Answer

コードを確認して注釈を付ける

DO review、できればコードレビューツールを使用します。 ^{（それ以外の場合は電子メールですが... meh）。}
コメントやコメントを正当化してください。
それについて雌犬しないでください。

コードを修正する

修正してください：
- 彼らが自分でそれを行う時間がない場合、
- 後で作者とそれを話し合った後、またはいくつかのメンバーに何かを修正したいというあなたの願いを正式に伝えました。
修正することについてテストを行う ^{（できれば単体テストと統合テストを使用）}
自分で正当化する。
DO優先順位付け：
- 最初に、習慣に入るいくつかのマイナーなものから始めて、注意していることを示します。
- しかし、何百もの小さなものではなく、最初に大きなものを完全に修正してください。
完全に理解していない不明確なコードパスは修正しないでください。
テストされていないコードパスを修正しないでください。
コードパスを盲目的に修正しないでください。簡単な修正は簡単ですが、シンボルのタイプミスやブレインファートがあり、ブール条件の反転が常に発生します。あなたのものをテストします。
それについては、ビッチしないでください。
他人を困らせたり、自分に正直に説教したりしないでください。
無関係または重要でない問題を修正しないでください ^{（最初は）}。それがあまり重要でない場合、あなたはより良いことをしている可能性が高いです。
一貫性を犠牲にしないでください。

本質的に、個人の好みに基づいて空白やブレースのスタイルを変更するだけで、コードベースの他の部分との一貫性を考慮せず、マイナーを修正しながらビルドを中断することさえある、この迷惑な人にならないでください単純だが深く隠されたバグを導入することによるコード違反。

コミュニケーション

作者に連絡してください。
あなたの変更を他の人（必ずしも著者ではない）と話し合ってください。
他のユーザーからの独自の変更についてレビューを要求する。この：
- 謙虚さを示す
- バンドワゴンにジャンプするように他の人を招待し、
- これは流動的なプロセスであることを示しています。
この問題を回避してコードベースを時間の経過とともに拡大および不自由にすることを避けるために、同僚と規則および規則を確立してください。
迅速に問題に取り組みます。

尋ねる

聞いてください。「Xのためにこれを修正している」と言うのではなく、「なぜこのようにしたのですか、そしてどのように改善できると思いますか」と直接尋ねます。彼らがもっと良いものを思いついたら、それから始めて、もっと良いものに一緒に取り組む。そうでない場合は、提案を行います。彼らがより良いものを思いついた場合、またはそれがなぜ間違っていたのかわからない場合は、2番目の質問を説明してもう一度質問してください。

チームの取り組みにする

あなたのチームが実際に参加すれば、バンドワゴンに飛び込む可能性が高くなります。これがコードベースがやや老朽化している大規模なプロジェクトである場合、彼らはコードが腐敗している状態も嫌いである可能性がありますが、おそらくそれについて何かをすることに煩わされることはありません。

あなたが力を持っている（またはそうする人のサポートを持っている）場合は、コード品質の向上に特化した小さなスプリントを編成することをお勧めします。コードアナライザーをセットアップしてコードのにおいを検出し、着実に減少を監視しながらリファクタリングすることも、チームにとってかなりやる気を起こさせます。

もちろん、実際に共同作業をせずにそのようなことについての熱意を伝えることは少し難しいので、リモートチームにとっては少し難しいかもしれません。

それはほとんどすべてそれに帰着します。

意味論

また、「政治的に正しい」と「外交的」を混同しないでください。：

前者は、最も否定的である可能性が高いことを言っている間、人々を怒らせないために茂みの周りを殴ることについてです。
後者は、感情的な背景があるかもしれないので、人々を怒らせないで問題に取り組むことについてです。

それらは非常に異なるものです。

最初に話す！

誰か他の人が気分を害して元に戻すだけの変更を加える意味はありません。それはあなたの政治的資本とあなたの時間の無駄です。あなたがボスであり、新しい標準を適用できる場合は、新しい標準についてチームに相談して実装してください。そうでない場合は、変更を加える前に、同僚や上司に相談してください。

各チームメンバーと1対1で話す場合、チーム全体の前で火を点ける前に、どれだけの政治資本を費やすかを決めることができます。チームミーティングは、1対1のミーティングを通じて達成したプライベートコンセンサスの公的な承認として、また実装する前に人々が新しいコーディングポリシーについてコメントする機会として、まだ必要な場合があります。

グループの合意により、誰もがコードを改善することを求められています。世界に対するあなただけではありません。合意が得られない場合は、必然的に戦う時間を無駄にすることはありません。

Jason · Answer

このような状況で何をすべきかを説明するのは難しいです。リファクタリングが得意なほとんどの人はすでに答えを知っており、質問する必要はありません。私はあなたがまだ学んでいると思います、そしてそれがそうであるなら、あなたはより長く、キャラクターを構築する旅に出ています。

小さなものから始めましょう。海ではなく、カエルを沸騰させます。

リファクタリングのためだけにリファクタリングするべきではありません。ランダムにリファクタリングすることで、学習速度が大幅に向上しますが、環境はそのように育まれていません。代わりに、あなたは「正当な理由なしに私のコードを変更する」ことになります、そしてそれはあなたを分裂的な人としてブランド化するのに役立つでしょう-ジャーク。私はあなたがすでにこれについて学んでいると思います、そしてそれがあなたが尋ねた理由です。

邪魔をしているコードをリファクタリングします。「バグを修正したり機能を追加したりする必要があったため、これを変更しました。」それが問題ないようになったら、彼らがこれがあなたのやり方だと理解したら、間違いなく邪魔になるコードをリファクタリングに切り替えます。「バグの修正や機能の追加が簡単だったので、これを変更しました。」これは、あなたがキャンプサイトのルールに取り掛かり、それを他の人に説明し始めたとき、そしてこれが彼らが機能する方法であると考える理由です（かなり砂糖を上に置いてください）。コードをいじって輝かせるコラボレーターを探してください。

これらの3つのタスクだけで、長い間忙しくなります。

いつの日か遠い将来、壊れたウィンドウズ現象を説明するようになるかもしれませんが、期待を上回らないようにお勧めします。あなた自身の正気のために、このチームがそこに着くとは決して思ってはいけません。代わりに、次の仕事のために、またはその後の会話のために、その会話を保存することを計画する必要があります。面接プロセスでは、情報に通じた消費者になる。それはあなたがこのシナリオを回避するのを助けます、そして彼らはあなたがあなたの技術について真剣であると見るでしょう。

幸運を！

KeithS · Answer

分散チーム環境のコードベースは、ウィキペディアによく似ています。彼らが言うように、「あなたの投稿が他の国々によって冷酷に編集されることを望まないのであれば、投稿しないでください」。

特定のコードを記述するためのより良い方法があり、その方法で記述する必要がある場合は、そのように記述します。誰かが不満を言う場合は、その不満を聞いてください。しかし、それが主に「それがMYコード」の行に沿っている場合は、彼が全体としてコードベースに取り組んでいるチームのメンバーであり、誰も本当に所有権を主張することはないことを説明してください。また、彼が雇われたときに彼が署名した書類のために合法的に言えば、それはnot "彼の"コードであり、それは会社のものであり、あなたもその会社で働いていることを指摘します。

現在、最初にチームに相談することなく、コードの「インターフェース」（コードオブジェクトが表示され、他のコードと相互作用する方法）を変更することについて、正当な不満が存在する可能性があります。誰かが作業コピーを持っている場合、古いインターフェイスに大きく基づいて、独自の大きな変更を加えており、あなたがその鼻の下でそれを変更すると、彼らは多くのリファクタリングを行う必要があります。これには簡単な解決策があります。チームチームに「このコードを変更する必要があります。変更した場合、ビルドを中断させるようなローカルで何かを行っている人はいますか？」とメールを送信します。数分待ってから、反対意見が出た場合は、より個人的なコミュニケーションチャネルで解決してください。そうでない場合は、リファクタリングしてください。