悪いコードを書いているチームメンバーに対処する方法
私たちのチームは、ジュニアおよびシニア開発者で構成されています。私が直面している問題は、高齢者が書いたコードにあります。それらはMINIMUMコーディング標準に従っていません。私もまだ学習していますが、インラインスタイルを宣言したり、変数やコントロールに不適切な名前を付けたりしません。間接的に言及しようと試みましたが、後で取り上げることができ、アジャイルなので、次に進む必要があります。しかし、私の問題は、自分の仕事に取り掛かったときに気分が悪くなり、自分の仕事ではなくリファクタリングに集中することです。この状況にどう対処すればよいかわかりません。
PS：この質問は何度も尋ねられたと思います。しかし、アドバイスは大歓迎です。
いくつかのこと。
あなたの先輩が彼らが何をしているのかを知らないと仮定しないでください。彼らは彼らがした決定をした非常に良い理由があるかもしれません。理由を尋ねます（非引数のの方法で）。
すでに記述され、単体テストに裏打ちされ、上司が機能的に完全であると宣言しているコードは安全に無視できます。それでそれを行う必要があります：無視してください。何らかの理由でそれをさらに維持する必要が生じるまで。
おおざっぱな説明に基づいて、あなたのチームはかなりの時間のプレッシャーにさらされているようです。これらの状況では妥協が行われます。仕方ないよ。
賢くあなたの戦いを選択してください。戦う必要のある人だけと戦ってください。
それらはMINIMUMコーディング標準に従っていません。
他人のコーディングを監視するのがあなたの仕事ではないなら、それをしないでください。これは、ジュニアが自分のために悪い名前を付けるための古典的な方法です。
同様の議論についてはこの質問を参照してください： https://softwareengineering.stackexchange.com/questions/78100/how-do-i-tell-a-senior-programmer-that-i-disagree-with-him
関連：私が不同意について書いたブログ投稿。その一部はあなたの場所を知っていること、そして不同意が適切な場合とそうでない場合： 不快にならずに同意しない方法
他の人が述べたように、上級開発者の選択について非対立的な方法で尋ねるべきですが、いくつかのことを検討することも価値があるかもしれません。
まず第一に、プロジェクトが従うコーディング標準はありますか？コーディング標準が定義されていない場合、誰もコーディング標準を破っていません。 「標準」は、単に新しいコードを古いコードに似せることです。それは残念な立場ですが、アドホックコーディング標準はまだコーディング標準です。
コーディング標準がある場合：誰がその実装を保証しますか？すべての開発者に責任がありますか、レビュー期間中に処理されますか？.
私の例を挙げましょう：まだ始まったばかりのプロジェクトに行きました。シニアのメンバーがいますが、ほとんどがジュニア（私も含む）です。結局のところ、コーディング標準について最も心配したのは私でした。私たちの会社とQAのポリシーは、私たちには標準があることを定めており、私がそれを育てたのは私だったので、それを見つけることが私の仕事でした。
それは非常に簡単であることがわかりました。 Javaの標準があるため、それが明らかな選択になります。次に、Javaと呼ばれるCheckstyleのツールが見つかりました。あなたが変更を加えてファイルを保存するたびに、Checkstyleはあなたが持っているコーディング標準の違反についてファイルを実行し、警告のようにすべての違反をハイライトします。さらに、いくつかの静的分析タスクを実行します：N-パスの複雑さ、循環的複雑さなど。その後、Eclipseのフォーマッターを調べたところ、コーディング標準にも準拠させることができたので、最小限の設定で、次のようなツールができました。
- コーディング規約違反のハイライト
- で呼び出すことができるフォーマッタ ctrl + shift + F
- メンテナンス不要
- 些細なコーディング標準の問題のコードレビューに時間を費やす必要はありません（ここにタブ、そこにスペース、ここにコメントが必要など）
したがって、最終的に、コーディング標準を維持しながら、本当にdealを実現するには、次のようにします。
- 現在の標準とは何か、それはどこかで定義されているのか、そしてすべての開発者がそれを知っているのか尋ねてください
- 計画を立てる-宿題をして、プロジェクトの言語で、私がしたことを行うのに役立つツールを探します。真剣に：誰もが従うコーディング標準を整備するのは素晴らしいことです。私は、誰もそれに追随する理由notを持たないほど簡単にできるようになりました。
- 計画を立てたら、上司に相談してみてください。彼らにあなたの計画を伝え、そしてもっと重要なことは、コードの欠陥を少なくすることで、将来どのように時間を節約できるかを伝えてください。
プロフェッショナルな環境でオープン性を実践する-彼らのコードが改善される可能性があり、彼らが別の方法で行うべきであると主張する正当な理由がある場合、それを提案する方法は何もないはずです（あなたがそうでない限り、降順などではありません）。あなたが開放性が嫌われる場所で働いているなら、私はそれが特に健康であるかどうかわかりません。彼らはなぜ彼らがあなたが気づかなかった何かをしているのか、またはその逆についていくつかの優れた洞察を持っているかもしれません-誰かが質問をするだけで何かを学ばなければならない:)