コード「ゴールテンディング」は、開発マネージャーによってどのように処理されますか？
まず、用語を作成できるようにします。
code Goal-Tending：午前中にコードをチェックアウトし、前日に他の開発者が行ったすべての変更をファイルごとに静かにレビューします（特にコード最初に開発したファイル）、およびフォーマット、ロジック、変数の名前変更、長いメソッドのリファクタリングなどを修正し、VCSへの変更をコミットします。
このプラクティスには、私が特定したいくつかの長所と短所がある傾向があります。
- Pro：コードの品質/可読性/一貫性が維持されることが多い
- Pro：他の開発者が元のコードに慣れていないため、いくつかのバグが修正されました。
- Con：多くの場合、目標を設定する開発者の時間の無駄です。
- Con：ときどきバグが発生し、前日にバグのないコードを記述したと考えていた開発者が髪を引っ張る怒りを引き起こします。
- Con：他の開発者は過度の乱雑さで悪化し、ゴールテンダーのコードへの貢献を嫌い始めます。
免責事項：公平を期すために、私は実際には開発マネージャーではなく、実際に「目標管理」を行っている開発者です。
私の弁護では、私は考えます私はこれを正当な理由で（非常に大きなコードベースを十分に油を塗ったマシンに保つため）実行していますが、それがネガティブな雰囲気を生み出していることも非常に心配しています。また、上司がこの問題に対処する必要があることも間違いなく心配しています。
あなたがマネージャーなら、この問題にどのように対処しますか？
更新：これがローカライズされすぎることを意味するわけではありませんが、いくつかの質問に答えたので、おそらく背景が明らかになるでしょう。私は3年前に巨大なプロジェクト（200K LoC）を割り当てられ、最近（1年前）にプロジェクトに追加の開発者が追加されました。その中には、アーキテクチャに不慣れな人もいれば、まだ言語を学んでいる人（C＃）もいます。私は通常、製品の全体的な安定性について答える必要があります。特に、コードベースのコアアーキテクチャ部分に驚くほど変更が加えられたときは、特に緊張します。この習慣が生まれたのは、最初は他の開発者の貢献について楽観的でしたが、彼らはあまりにも多くの間違いを犯し、数週間後まで発見されない深刻な問題を引き起こし、不安定なコードを書くために私に指を向けられました。多くの場合、これらの「驚き」は、まだ学習段階にある熱心なマネージャーまたは同僚によって犯されます。そして、おそらくこれはおそらく答えにつながるでしょう：私たちはコードレビューポリシーをまったく持っていません。
開発者にフィードバックを提供するのではなく、コードレビューで提案するすべての変更を行うことを除いて、あなたがしていることは基本的にコードレビューと同等のようです。あなた（または他の誰か）がコードの品質の問題や明らかなバグについて元の開発者にフィードバックを提供し、元の開発者に修正を依頼する場合は、実際のコードレビューを行うほうが間違いなく良いでしょう。これにより、コードの品質は維持されますが、開発者が元のコードとその落とし穴に慣れ、将来のコード変更を改善するのにも役立ちます。さらに、バグが静かに導入されたり、他の開発者が背後で話し合われていると他の開発者に思わせたりするときに、「髪を引っ張る怒り」を引き起こすという欠点はありません。
正直なところ、私見、これはひどい考えです。
まだそうでない場合、私は士気がガターに落ちることを期待します。
あなたに公平であるために、あなたはこれを認めます。
ピアコードのレビューは問題ありません。「彼らと私たち」のシナリオではなく、開発者にすべて1つのレベルで責任を負わせます。 （それらは管理/リードです）。
他の人よりも目を離さないようにする必要がある開発者もいますが、すべてのコードが最初にあなたを通過するよう強制するのはばかげています。
そして、あなたがどれほどあなたが優れていると思っていても、あなたが間違っている、または「ニットピッキング」となる場合があり、これは事態をさらに悪化させるだけです。
私がマネージャーだった場合、この問題に対処するには：
- チームでコード標準とプラクティスをレビューし、コーディング標準のコピーを渡してください。
- 定期的にコードをピアレビューして、従うべき基準と慣行を強化する
- 開発者が標準に従うことを余儀なくされるように、自動化ツールでニッチピッキング/フォーマットを実施します
- 基準に従うことを拒否する悪いチームメイトを取り除く
- ゴールテンダーになるのをやめる
あなたの意図は良いですが、実装はひどいです、そして、他の人が指摘したように、士気の低下とチームメンバー間の狙撃を引き起こします。
プロジェクトに最初から標準がなかった場合は、スイッチを切り替えるだけでなく、新しい標準を段階的に緩和してみてください。
悪いジュジュ。
私は開発マネージャーではありませんが、開発者が欠陥や機能に割り当てられていないコードに触れないようにしたいのですが。限目。他の人のコードに問題がある場合は、必ず責任のある開発者に注意を向けてくださいしないでください飛び込んで自分で修正してください（特に、最初に他の開発者と調整します。
クリーンアップタスクは、チームによる正式なコードレビューの後、およびそれらのタスクが割り当てられている開発者のみが実行する必要があります。
イニシアチブは一般的には良いですが、時にはお尻に噛みつくことがあります。 が何であったかが機能しているコードにバグを導入した場合、別のキャリアパスを選択したいとすぐに思うかもしれません。