技術チームのリーダーとして、チームメンバーのコーディングの間違いや悪い習慣をどのように処理すればよいですか？
私は、約5人の開発者のチームの技術チームリーダーです。チームメンバーは定期的に他のプロジェクトに向けて出発し、他のプロジェクトからチームに参加するため、チームの規模はやや動的です。
定期的にチームメンバーのコードに遭遇しました。コードを変更したり、近くに何かを書いたり、コードをレビューしたりするときです。時々（この投稿を書くのに十分なほど、私は推測します）、小さな間違い（2つのDateオブジェクトを文字列に変換して比較するなど）または大きな間違い（2つ以上のほぼ同じ中規模から大規模なものを書く）のいずれかでコードが不十分に書かれている両方のケースを処理できる1つの関数ではなく、行が1つだけ異なるサイズ関数。）
彼らのスキルを向上させ、これらの間違いを彼らに指摘する最良の方法は何ですか？時々私はこれらのコードのセグメントを一緒に調べて、なぜそれらを異なるように書く必要があるのかを説明します。しかし、私は一生懸命になりたくはありません。コードをレビューするために頻繁に訪問してもらいます。コードレビューはここで答えですか？もしそうなら、彼らはどのように組織されるべきですか？彼らはすべてのチームメンバーを含むべきですか、それとも個人的なものですか？どのくらいの頻度で開催する必要がありますか？他に何かアドバイスは？
別の質問 には似ていますが、実際には異なります。コードレビューに興味があるだけでなく、チームメンバーのコーディングスキルを向上させるために考えられる他の方法も知りたいからです。 。また、次回のバージョン配信の前または後にコードを簡単に確認および/または修正できるため、私の質問では締め切りは関係ありません。
この状況でできることはいくつかあります。まず、ルールブックを参照するためにできることを行います。つまり、こういうことが出てきたら、「スタイルガイドの6ページをご覧ください」と言うのが一番です。または、「私があなたに知ってほしいことを説明するWebサイトへのリンクがあります」と、そのリンクをライブラリに保存します。技術リーダーとして、技術的負債を回避することはあなたの仕事の一部なので、それは彼らに対するあなたの義務です。
次に、彼らが間違ったことを指摘するのではなく、自分のコードについて質問します。たとえば、メンターが配列をコピーする必要がないときにキャッチしたので、「このコードが実際に何をしていると思いますか？」私たちは相互に敬意を払う文化を持っていて、そのような質問は一生懸命というよりは刺激的でした。
ポリシーから統治し、ゲートキーパーとしての役割を維持し、人々を丁重に扱う場合、良い従業員はそれを愛し、悪い従業員は別の仕事を見つけるでしょう。公に称賛することを忘れないでください。そしてフィードバックは贈り物です。優れたコーダーは、あなたが彼らに尋ねれば、あなたがどうやっているかを教えてくれます。
これがコードレビューに関する私の考えです。
理論的には素晴らしいアイデアですが、慎重に管理する必要があります。プログラマーは独創的で自己中心的であり、非常に薄い肌を持つことができます。オープンなチームコードレビューは、簡単にローマコロッセオに変わる可能性があります。コーダーは、お互いの作業を悪質かつ非生産的に分割することができます。 1対1で行っても、ネガティブな体験に変わる可能性があります。プライベートで批判することについてのギャビンのアドバイスは素晴らしいアドバイスであり、オープンなコードレビューがあると維持するのが難しいものです。
Gavinが（再び）スタイルガイドやコーディング標準のドキュメントを書くことについての提案は素晴らしいですが、それを実施する権限が必要です。オンラインで適切なモデルを見つけて、同じ行にオープニング「{」を配置した派閥と独自の行に配置した派閥の間で血が混じるように調整することを強くお勧めします。チェックインワークフローに組み込まれたコマンドラインコードフォーマットツールは、会社のスタイルを適用するために（良い-多分）、同じ会社の反逆者コーダーが同じツールを使用して異なるスタイルパラメータでコードを「自分の方法」にフォーマットするのを見ました。チェックアウト時（あまり良くない）。
新しいコンテンツについては、プログラミングに関する優れた書籍のライブラリを購入してください。 「Clean Code」、「Clean Coder」、および「Code Complete」を使用して、学習と改善の文化を開始してください。
私はチームのリーダーではないので、実際には使用していません。
しかし、私の見解では、健全なコンテストが進むべき道です。
開発者に仕事とは無関係の課題を解決してもらいます。すべての開発者にとって同じ課題です。
優れた解決策となるもの（短い関数、意味のある名前、効率など）を事前に説明してください。
全員が完了したら、最高の実装に投票します。
全員が同じ問題に取り組んでいるという事実は、誰もが解決策について考えているため、より深い議論を可能にします。
それが仕事に関連していないという事実は、失敗の不安を減らし、人々が批判に対してより敏感になるでしょう。
このようなコンテンツを伝統にすることにより、コードレビュープロセスを行う必要なく、チーム全体のコーディングスキルが徐々に向上します。