同僚にコードの品質についてどのように連絡しますか？
私は大規模なエンタープライズソフトウェア会社（3000人以上のプログラマー）で新しいベンチャーに取り組んでいます。私のグループでは、たくさんのプロジェクトがあり、通常、1年の間に複数のプロジェクトに取り組んでいます。
私はいくつかの機能を追加するために、以前私の仲間（3年以上私たちと一緒にいるコンサルタント）によって維持されてきたプロジェクトに取り組み始めました。私はコードに入りましたが、品質は本当にかなり悪かったです。 UIフロントエンドであろうとサービスバックエンドであろうと、コードはインデントされておらず、明確な理由もなくコメントアウトされた何百行もあり、ドキュメントは基本的に存在せず、コーディング標準は一貫して適用されていません（例：camelCaseおよびunder_scored_variables）、変数名が判読できない、データ型の選択が間違っているなど。
私は非常に非対立的な人間なので、同僚を攻撃したくありませんが、上司のところに行って彼のパフォーマンスについて不平を言いたくありません。コードの構造が不十分であることを丁寧に説明すると、どのようなことが言えるでしょうか。
編集：
私は理解していますが、次のようなものを見ると、すべてのプログラマにとって「他の人のコードはうんざりする」という要素があることを明確にしたいと思います（名前は意図的に選択されており、一部の詳細はこの例では省略/変更されています）。
public void doCalculate(Object argument) {
if (argument instanceof String) {
String argument2 = (String) argument;
if (argument2 == "DataBase") {
// do something
} else {
long argument3;
try {
argument3 = Long.parseLong(argument2);
} catch (Exception e) {
argument3 = -1;
}
// do something completely unrelated
}
}
}
これがnotであると言うのは客観的には公平だと思います。さらに、私はここでは初心者を扱っていません（私は今3年だけコーディングしています）。彼は私にたぶん20年の経験があります。これまでに皆さんからのアドバイスは素晴らしいものです。ここで「細い線」について話しているのではないことを確認したいだけです。
彼にコードを説明してもらう
Xがそのようにプログラミングされたのを見たことがないことを彼に伝え、なぜXがそのようにコーディングされているのか尋ねてください。コーディングの方法を示し、なぜそのようにするのかを説明します（ベストプラクティス、パフォーマンスの向上、エラーの可能性の低下、他のプログラマによる読み取り/保守の容易さなど）。
必ず事前にすべての引数を準備し、メソッドが最も悪い理由ではなく、メソッドが最も優れている理由に焦点を当ててください。その後、彼がまだ自分の方法をサポートしているかどうかを確認します。
改善の余地がある場合は、コーディング方法を変更する可能性があります。彼があなたよりも彼のコーディングスタイルを使用することを好む場合、あなたは彼の意見を変える可能性は低いです。
これは、私が質問に対して出した答えとまったく同じです 上司にプログラミングスタイルが本当に悪いことを伝える方法 。私は当初、この質問を重複として閉じることを投票しましたが、十分に多くの人がそれをもう一度やり直すには十分違うと思っていました。上司や同僚に話しているかどうかにかかわらず、私の答えは同じです。
個人的に彼にアプローチするのではなく、チームにアプローチし、完全に中立的な方法で、異なるチームメンバーがお互いのコードをより効率的に作業するための方法として、コーディング基準/ガイドラインを「チーム」に提案します。
それが整ったら、あなたが懸念しているコードは、それ自体ですべて上に浮かび上がると思います。
ピアコードレビューもこの分野で役立ちます。誰もコードを見ていない場合、コーディング標準はあまりメリットがありません。ただし、ピアコードレビューには他にも多くの利点があり、主な知識の伝達が1つあるため、どちらの場合でもプッシュして紹介する必要があります。
3000人以上のエンジニアがいる場合でも、ユニットとして連携する非常に小さなサブチームがいると仮定しています。
まず、誰もが他の人のコードは駄目だと思っています。
第二に、多分彼は誰か/どこか他の人からコードを継承したかもしれませんORこれは実際のプロジェクトで使用されるコードを意図したものではありませんが、もちろんそれが最終的に使用されたものです。
第三に、多分彼のコードは本当に面倒ですが、それは以前の開発者を悪口を言うあなたの仕事ですか？会社を尊重するという評判を築いていない限り、他の人のコードについて愚痴をこぼしたとしても、友人ではなく、見た目が悪くなるのはあなただと思います。コードについて人々に悲しみを与えるときは、コードレビューが行われるときです。少なくとも、それはあなたの仕事の責任の一部です。
彼のコードが気に入らない場合は、好みに合わせて修正することをお勧めします。次に、次の開発者がやって来て、あなたのコードについて文句を言い、おそらくあなたの友人がしたようにより近いコードに変更します。
あなたの同僚はおそらくあなたの会社の問題の根本的な原因ではありません。低品質のコードが本番環境に入るのは、会社で自動的に測定可能なコーディング標準がないためです。この場合、日光が最良の薬です。
グループへの自動化されたソースコード品質指標の実装については、テクニカルリードと話し合う必要があります。システムは少なくとも毎週実行され、コーディング標準違反のファイルごとのリストをチームの全員に電子メールで送信し、エグゼクティブサマリーを上司に送信する必要があります。概要には、プロジェクトごとの違反の数を含める必要があります。
私の経験では、測定されて上司に報告されるものはすべて、時間とともに改善されます。
...コードはインデントされていませんでした。明確な理由もなく、コメントアウトされた数百行がありました。ドキュメントは基本的に存在せず、コーディング標準が一貫して適用されていませんでした（例：camelCaseの混合）およびunder_scored_variables）、変数名が判読できず、データ型の選択が間違っていました...
私の知る限り、上記の一致は＃12、＃9、＃5、＃2、そしておそらく＃7の クリンゴンプログラマ（アーカイブ）がいる場合に耳にする可能性が高い上位12の事柄 [ 元のリンク ]：
12.仕様は弱くて臆病な人向けです！
11。このマシンはGAGHの一部です！このコードと戦うには、デュアルPentiumプロセッサが必要です。
10。元のクリンゴン語で読んだことがなければ、ディルバートを本当に感謝することはできません。
9。インデント？ -あなたの頭蓋骨をインデントするときにインデントする方法をお見せします！
8。この「リリース」の話は何ですか？クリンゴンはソフトウェアを「リリース」しません。私たちのソフトウェアは「エスケープ」し、その結果、デザイナーと品質保証担当者の血の跡を残します。
7。クリンゴンの関数呼び出しには「パラメータ」がなく、「引数」があり、常に勝つことができます。
6。デバッグ？クリンゴン語はデバッグしません。私たちのソフトウェアは弱点を甘やかしません。
5。私は品質保証チーム全体にバットレスコンテストに挑戦しました。彼らは再び私たちに関係することはありません。
4。真のクリンゴン戦士は彼のコードにコメントしません！
3。このPTRを申請することで、あなたは私の家族の名誉に異議を申し立てました。死ぬための準備！
2。私のコードの価値に疑問がありますか？私はあなたが立っている場所であなたを殺すべきです！
1。私たちのユーザーは私たちのソフトウェアの前に恐れと恐怖を知っています！それを出荷！発送して、犬のように逃げさせましょう！
対立を回避する唯一の方法は、別の象限への ワープドライブ である可能性が高いです。
このプロジェクトが作成されたときに、会社とチーム内で何が起こっていたかについての背景を入手してください。この開発者に、プロジェクトがどのように進んだかについてのフィードバックを求めてください。彼のスタイルは変わりましたか？機会が与えられた場合、彼は何を別の方法で行いますか？
彼はあなたの基準に同意するかもしれませんが、このアプリの作成中にそれらを適用する贅沢がなかった、またはそれらについて知らなかっただけです。
グループに標準またはコードレビューポリシーがないか、施行に重大な問題があります。あなたは1つの意見を持っているかもしれません。
私はそれを認めます、私は時々その人です。私がいるとき、私には理由があります。通常、時間の制約、死のプロジェクト、「今は完璧ではない」などの指示などです。非常にまれに、それは悪い日が原因です。私はどんな問題についても尋ねられて幸せです、それは私がより良い開発者になる機会を与えてくれます。提供されるa）何が変更されるかについて合理的であり（それはひどく壊れていて、修正しないことに同意します）、b）あなたのやり方が唯一の方法であると信じるあなたの独り言ではない独裁者です。
それについて私に近づくために、「なぜ」と尋ねないでください。なぜ戦いの言葉、挑戦であり、最終的に破壊的です。 Whyを使いすぎた場合は、Iに変更してください。「なぜこれをxと呼んだのか」は、「インデックスを使用したので、xよりもわかりやすい」になります。
最善の方法は、あなたが何をしたか、または優先したかを述べることです。表示されているものが特定の基準を満たしていないこと、およびそれが改善されることを望んでいることを説明します。私の推測では、99％の場合、「私もそうですが……」という応答になります。
コードの作者が純粋な善意からあなたのために彼のコードを修正するために戻ってくること、またはあなたの雇用主が彼にそれをするように支払うことはほとんどありません。したがって、どちらにしても、あなたはscr * wedです。
コードが含まれている混乱が作業中にパフォーマンスに深刻な悪影響を与えると思われる場合は、元のコードのバックアップをどこかに保存して、コードが配信されたときに混乱したことを証明できるようにしてください。君は。したがって、あなたの雇用主があなたの悪いパフォーマンスについて後であなたに直面した場合、あなたはあなたのお尻をカバーできます。
それでも、それは言い訳のようにあなたの雇用主に見えるかもしれないので、可能であればそれが起こらないようにしてください。
彼が悪いコーディングスタイルを持っていることを彼に言及することはあなたや彼に何をするでしょうか？
おそらく、会社のQA手順を改善しようとする方が良いでしょう。
あなたは2つのことを見つける必要があります：あなたの目標は何ですか？どのように自分にアプローチしたいですか？
20年以上のプログラミング経験を持つ同僚が本当にオープンマインドである場合は、彼に話しかけて具体例を指摘し、彼らがあなたに間違っていると思った理由を伝え、代替案について話し合うことができます。彼は本当に、とてもオープンマインドで、学びたがっているので、彼は耳を傾け、議論が続き、あなたのポイントを理解し、あなたは二人とも幸せに暮らします。
けれども私の経験では、同僚はスタイルを気にしていないので、おそらくそのようなプログラミングをしているでしょう。それは、彼が本当に間違った仕事をしているためか、20年以上のプログラミングで、彼がそれについて心配する理由を見つけられなかったためかもしれません。
後者の場合は、あなたと彼の時間を無駄にするだけであり、それが議論になると、あなたはあなたの関係に凹みを作るかもしれません。ここであなたの目標は何ですか？
より良いコードで作業できるように、彼にコードを整理してもらいたいですか？彼に学び、改善してもらいたいですか？あなたはより良いコーダーであることについて気分がいいですか？上司にあなたが彼よりも優れたコーダーであることを知らせたいですか？
最初の問題は発生せず、3番目の問題はすでに確立されていますが、おそらく彼にもそれを認識させたいと思います。
あなたが本当に彼に学び、上達させたいなら、あなたが逆の状況でどのようにアプローチされたいかを考え、同じようにしてください。そして、何があなたを困らせるかを理解し、あなたがそれをしないことを確認してください。
4つ目は簡単です。給与を上げて、次のフィードバック会議でそれを要求するだけです（この業界でどれだけ上手かは関係ありません）。もっと責任を負って、続けます。あなたがそれを得るまで良い仕事。
あなたがいくつかのクレイジーなコードを見てきたことを上司に提案し、すべての可能なスタッフをいくつかのプログラミングコースに参加させるように彼に依頼してください。私は彼のアプリが安っぽいコードで満たされていることに気づくべきだと思います。