過去にSoftwareEngineering.SEでこのテーマについて多くのことを書いてきましたが、私自身も同様の状況にありました。したがって、いくつかのヒントを示し、質問を読んだときに気付いたいくつかの問題を強調するようにします。
しかし、最初に、重要な側面について話しましょう。会社でのあなたの役割です。
あなたの役割
物事を強化するために、上司からの明確な委任があり、また、他の開発者があなたの注文に耳を傾けなければならない階層内の場所もあります。または、同じ役割と同じ権限を持ち、あなたの選択肢は...まあ... 意見です。
どちらの場合も、重要なのは階層内の自分の位置よりも少ないことです。
他の開発者があなたをどう思うか。彼らがあなたを彼らに愚かなことを尋ねる迷惑な男として扱うなら、あなたは遠くに行かないでしょう。技術リーダーやプロジェクトマネージャーがチームにまったく影響を与えないケースが多く見られました。チームは、それらの「リーダー」が自分の決断を下すのに必要な技術的背景を持たないことを知っていた（考えていた）からです。一方、私は実際に彼らの仲間に耳を傾けられたいくつかの開発者を見てきました。
あなたのチームはどれほど堅固で、何が彼らを動機付けていますか。すべての開発者がKLOC /月の支払いを受ける会社を想像してください。スタイルについて何か言いたいことが同僚にありますか？おそらくそうではありません。なぜなら、より少ない給料を望む人はまれだからです。一般に、これがチームではなく、同じプロジェクトで作業している人のグループである場合、何も改善することはできません。
それに応じて、変更する努力に値するかどうかを決定できます。声がなく、チームの結束がない場合は、別の仕事を探してください。才能があり、尊敬されている開発者として知られ、強いチームフィーリングがある場合、上司や他のチームからの敵意に直面しても、物事を比較的簡単に改善することができます。
すべての場合において、チームに圧力をかけないことが不可欠です。彼らに対してではなく、彼らと協力してください。命令するのではなく、目標に向かって誘導します。
今、ヒント。
スタイル
私はかつて、既存のコードの大部分のコーディングスタイルとフォーマットに従うようにきちんと要求しました（残念ながら、正式なコーディングスタイルのドキュメントはありません）。しかし、うまくいきませんでした...
もちろん、そうではありませんでした。これは、それが行われるべき方法ではないからです。
スタイルは退屈です。
次のスタイルは退屈です。
コーディングスタイルのドキュメントを書くのは退屈です（そして非常に困難です。10年以上この言語で作業したことがない限り、やろうとしないでください）。
スタイルドキュメントを読むのは退屈です。
スタイルの間違いについてコードを確認するのは退屈です。
私のスタイルがあなたのスタイルよりも優れているというトローリングは、特にあるスタイルが他のスタイルよりも客観的な利点がない場合に刺激的です。真剣に、すべての正気の人が書き込みに正しい方法を知っているif (x)私は、それを書いていない方法ですif(x)かif ( x )！
したがって：
スタイルのレビューをしないでください。これはスタイルチェッカーの仕事です。これらのかわいいアプリケーションには、脳に対していくつかの利点があります。数時間または数日ではなく、ミリ秒単位でプロジェクト全体をチェックし、ミスをせず、スタイルエラーを見逃しません。
独自のスタイル標準を作成しないでください。とにかくあなたはそれを間違ってします、そしてあなたの同僚はあなたが悪い選択をしたことをあなたをだまします。
開発者に2000のスタイルエラーの修正を強制しないでください。
コミット時にスタイルを自動的に強制します。スタイルに誤りがあるコードには、バージョン管理の場所がありません。
プロジェクトの最初からやります。既存のプロジェクトでスタイルコントロールを設定することは不可能または困難です。
詳細については、SE.SEに関するこの他の回答の最初のセクションをお読みください。
また：
- 厳しすぎないでください。たとえば、
jslint準拠コードの作成は非常に面倒なので、どうしても必要な場合（またはチームのメンバー全員がそれを使用して満足している場合）にのみ行う必要があります。静的チェックツールについても同じことが言えます。たとえば、最大レベルでの.NETのコード分析は、非常に抑圧的で気のめいるようですが、ほとんどメリットはありません。一方、中程度のレベルで設定された同じツールは、非常に役立つことが判明しています。
コードレビュー
コードレビュー中にスタイルを気にする必要がなくなったので、ソースコードを強化する（修正する）より興味深いものに集中できます。
コードレビューに対する反応は人によって異なります。機会だと考える人もいます。他の人はそれを嫌います。一部の人はあなたが彼らに伝えるすべてを聞き、メモを取り、たとえたとえ彼らが正しいかもしれないとしても、議論しない。他の人はあらゆる点で議論しようとします。すべての開発者の性格に応じて対処する方法を見つけるのはあなた次第です。通常、次のことに役立ちます。
特に開発者が後輩であり、本当に悪いコードを書いている場合は、プライベートでコードレビューを行ってください。
個人的なものは何もないことを示します。あなたはその人のスキルではなくコードをレビューしています。
コードレビューの実際の目標を示します。目標は、開発者がどれほど悪いかを示すことではありません。目標は、改善の機会を提供することです。
議論することはありません。説得するためではなく、専門知識を提供するためにここにいます。
レビューから何かを学ぶことができるのは、レビュー対象者だけだと思い込まないでください。コードを読んだり、理解できない部分について説明を求めたりすることで、あなたもここで学びます。
コードのレビューが完了したら、その人が実際にコードを改善していることを確認してください。実際の会議が終了すると、コードレビューが終了すると開発者が考えるいくつかのケースがありました。彼らは去り、新しい機能に戻り、共有したものを新しいコードにのみ適用しようとします。コードレビュー用の適切な追跡ツールがあると役立ちます。
会社での特定の役割や他の人と比較した専門知識とは別に、コードもレビューの対象となることに注意してください。他人のコードをレビューするのはあなただけではないはずです。
私が技術リーダーとして働いていた最近のプロジェクトでは、同僚を含め、お互いのコードのレビューを行うことが自分の役割であることを同僚に説明するのに苦労しました。技術リーダーのコードをレビューしようとしているインターンの恐怖は、コードの最初の問題を見つけるとすぐに消えます。
トレーニング
コードレビューは、プログラミングとソフトウェア設計のいくつかの側面を教え、学ぶ絶好の機会ですが、トレーニングが必要なものもあります。
同僚を訓練できる場合は、それを行います。トレーニングのアイデアに経営陣が敵意を抱いている場合は、非公式に行います。私はそのようなトレーニングセッションを非公式の会議の形で、または時には単純な議論として、時には経営者によって中断され、後に追求する形で行いました。
直接的なトレーニングは別として、McConnel's Code Completeなどの本を十分に理解し、それらの本について同僚に話してください。オープンソースプロジェクトのソースコードを読むように提案し、高品質のコードの具体例を示します。そして、明らかに、高品質のコードを自分で書いてください。
人ではなくコンテキストに焦点を当てる
「悪い企業文化」や「経験の浅い卒業生」などに焦点を合わせずにこの状況に対処するにはどうすればよいですか。
これらの卒業生には目標があります：経験を積む、物事を学ぶ、より熟練する。年々、彼らがくだらないコードを書き、プログラミングについて何も知らないのは、おそらくあなたのチームや会社が彼らにこの機会を与えていないからでしょう。
チームに経験の浅い卒業生がいるという事実に注目している場合、これは役に立ちません。代わりに、あなたが彼らのために、そして彼らと共にできることに集中してください。コードのレビューとトレーニングは、状況を改善するための2つの手法です。
悪い企業文化は別の獣です。時々、変更することができます。時々、それはできません。すべての場合において、あなたはこの会社の一員であることを忘れないでください。あなたは会社の文化の一員です。それを変更できず、遅かれ早かれ本質的に悪いことがわかった場合は、離れなければなりません。
メトリックを正しく取得する
現在、どのくらい正確にコードを測定していますか？開発者ごとに1日あたりのコミット数を測定しますか？それともプログラマあたり月あたりのKLOCですか？それともコードカバレッジですか？または、発見され修正されたバグの数は？または、回帰テストで検出された潜在的なバグの数は？または、Continuous Deploymentサーバーによって行われた復帰の数は？
チームメンバーは、測定された要因に作業を適合させるため、測定するものは重要です。たとえば、数年前に仕事をしなければならなかったある会社では、測定された唯一のことは、オフィスで過ごす時間だけでした。言うまでもなく、これは、より良いコードを提供したり、よりスマートに動作したり、...まったく動作したりすることを奨励するものではありませんでした。
肯定的および否定的な強化を理解し、測定された係数を経時的に調整することは、基本的にチームメンバーに対するレバレッジです。適切に行うと、単純な階層では達成できない結果を達成できます。
あなたを悩ますものは、それらを測定可能にします。それらを測定し、結果を公開します。次に、他のチームメンバーと協力して結果を改善します。
たとえば、チームメンバーがクラス、クラスメンバー、変数の名前のスペルを間違えすぎていると考えてみましょう。これは面倒です。それをどのように測定できますか？パーサーを使用すると、コードからすべての単語を抽出し、スペルチェッカーを使用して、ミスやタイプミスを含む単語の割合、たとえば16.7％を特定できます。
次のステップは、目標比率についてチームに同意することです。次のスプリントでは15％、次のスプリントでは10％、6週間で5％、2か月で0％になります。これらのメトリックは、コミットするたびに自動的に再計算され、オフィスの大画面に表示されます。
目標比率を達成できない場合、チームはスペルミスの修正にさらに時間を費やすことを決定する場合があります。または、開発者ごとの比率を計算し、この情報を大画面に表示することをチームが検討する場合があります。または、あなたのチームは、目標が楽観的すぎて、それを確認する必要があると感じるかもしれません。
目標比率を達成したら、次のステップは、ミスやタイプミスの数が時間の経過とともに増えないようにすることです。そのために、スペルミスをチェックするビルドで追加のタスクを作成し、少なくとも1つのミスが見つかった場合にビルドを失敗させることができます。この問題を取り除いたので、新しい関連する統計を表示するために大画面を再利用できます。
結論
あなたの質問で言及されたすべての側面は、私が答えに含めたテクニックを通して解決できると信じています：
他の開発者がプロジェクトに参加したとき、異なるコーディングスタイル（時には完全に異なるスタイル）を使用していることに気付きました
あなたは強制しなければならなかったスタイルをコミット時に自動的に。
多くの場合、プロパティアクセサのような最新の言語機能は使用しません（Objective-Cでは比較的新しい機能です）。
言語の知識を伝えるために、コードレビューとトレーニングの両方があります。
フレームワークの同様の機能を使用する代わりに、独自の自転車を発明することもありました
フレームワークの知識を伝えるために、コードレビューとトレーニングの両方がここにあります。
または、他のプログラミング言語または彼らが学んだパターンをコードベースに転送します。
これは素晴らしいことです。あなたは彼らから学ぶ機会のようです。
多くの場合、悪い英語のためにメソッドや変数に適切な名前を付けることができません
コードレビューは、適切な命名にも焦点を当てるべきです。一部のIDEにもスペルチェッカーがあります。
IDE用でない場合は、インデントや書式設定を一切行わずにすべてのコードを記述すると思うことがあります。
もちろんそうです。スタイルは退屈で、自動化する必要があります。
基本的に、私は彼らが書いたコードが嫌いです。
コードレビューの部分から思い出してください。「目標は、開発者がどれほど悪いかを示すことではありません。目標は改善の機会を提供することです。」
フォーマット/構成が不適切で、プロジェクトの他の部分とは根本的に異なる場合があります。
自動スタイルチェック。
彼らがスパゲッティを私の作品に加えたとき、私はとても怒っています
ちょっと待って！？芸術作品？！何だと思う？一部の人（6か月以内にあなたを含む）は、あなたのコードが芸術品ではないことに気付くかもしれません。一方、あなたの作品を芸術作品として、そして彼らの作品をがらくたとして考えることは誰にも役に立たないことを理解してください。あなたを含みます。
学習することや気にしないことはますます難しくなっているように感じます。彼らは彼らから求められていることをして、家に帰るだけです。
もちろん、彼らは彼らから要求されることをします。覚えておいてください：コンテキストではなく、個人と右のあなたのメトリックを取得します。コンテキストが彼らから彼らがすることで最高になることを要求する場合、彼らはそれをします。コンテキストが1か月あたりできるだけ多くのKLOCを生成する必要があり、それ以上を生成しない場合は、それも実行します。