より小さなクラス/メソッドを使用するようにチームを説得するにはどうすればよいですか？

免責事項：私は新参者であり（これが私の仕事の3日目です）、私のチームメートのほとんどは私よりも経験が豊富です。

私たちのコードを見ると、次のようなコードのにおいと悪いエンジニアリング手法が見られます。

• 多少矛盾した命名ガイドライン
• 可能な場合、読み取り専用としてマークされていないプロパティ
• 大規模なクラス-何百もの拡張メソッド（多くのタイプ）で構成されるユーティリティクラスに気付きました。2500行以上でした！
• 大規模メソッド-150行のメソッドをリファクタリングしようとしています。

後者の2つは本当の問題のようです。チームメイトに、より小さなクラスとメソッドを使用するよう説得したいと思います。しかし、私はそれをする必要がありますか？はいの場合、どのように？

私のチームは、メインチーム（私たちはサテライトチーム）からメンターを獲得しました。最初に彼に行くべきですか？

更新：いくつかの回答がプロジェクトについて尋ねたので、それが機能しているプロジェクトであることを知ってください。そして、私見、そのサイズの巨大なクラス/メソッドは常に悪いです。

とにかく、チームを怒らせたくありません。それが私が尋ねた理由です-私はそれをするべきですか？

更新：受け入れられた答えに基づいて何かをすることにしました：私は初心者なので、すべてを「新鮮な目」で見るので、見つけたすべてのコードの匂いに注意します（位置、それが悪い理由、どうすればできるかより良い、...）、しかし、現時点では、私はチームから敬意を集めるために一生懸命努力しています：「より良いコード」を書き、人々を知り、なぜそれをしたのかを知っています...新しいコードポリシー（命名ガイドライン、小規模なクラス、小規模なメソッドなど）についてチームに問い合わせ、可能であれば古いコードをリファクタリングします。動作するはずです、私見。

ありがとうございました。

コードを新鮮な目で見ることができます。悪い習慣を発見したことを記録するためにメモを取ります。そして、チームに落ち着いたら、リファクタリングの時など、都合の良いときにメモを引き出します。

Steve McConnellによるCode Completeには、あなたが話しているまさにそのトピックに関する優れた統計がたくさんあります。すべての数字を思い出すわけではありませんが、メソッド/クラスが長くなるとバグの数がどのように増えるか、デバッグにどれくらい時間がかかるかなどについて話しています。

あなたは本のコピーを購入し、あなたの仲間にいくつかの研究を見せることができます...統計は（常に嘘をついていますが）人々を納得させる傾向があります。

免責事項：私は新参者です（これが仕事の3日目です）。私のチームのほとんどは私よりも経験が豊富です。

あまりにも多くの変更を提案する前に、少し遅くして、聞いて、チームから学びたいかもしれません。コードがそのまま構造化されているのには正当な理由がある場合とない場合がありますが、どちらの方法でも時間をかけて最初に耳を傾けて学習することは助けになります。

その後、あなたが行うかもしれない提案は、最も確実に、より積極的に見られ、より少ない抵抗で満たされるでしょう。

最初に同僚から敬意を払うか、少なくとも敬意を失わない限り、変化をうまく導入する可能性が大幅に向上します。

どうですか？「2回カットを1回測定します。」そのようなもの。

チームがコードを記述する方法をオーバーホールするという特定の意図を持って雇用されていない限り、抜本的なオーバーホールに対する熱意を和らげることができます。ほとんどの作業コードは理由があります:)どんなにゴミであっても、時には徹底的なオーバーホールにより、これらの厄介なコーナーケースがさらにくなります。

小さなコードを書く最も簡単な方法は、開発者に単体テストに集中するように頼むことだと思います。それをテストするように求められるような簡潔なコードを強制するものは何もありません。開発者がすべてのテストを作成しなければならないと知ったときに、開発者が突然、グローバルデータ構造に嫌悪感を抱き、あまりにも多くのオブジェクトを多くのレイヤーに渡してしまうのは驚くべきことです。

私はTDDの大ファンではありませんが、開発者がテストをどのように記述するかを検討することを強制するという事実が大好きです。そして、それがしばしばコードが良い理由であり、実際にテストを行うことについての魔法ではありません。（ただし、後で変更を加えるときに役立ちます。）

幸運を祈ります。

チームを納得させるべきではありません。新参者として、あなたは真剣に受け止められないでしょう-したがって、時間を無駄にします。

代わりに、コンパクトでクリーンなコードを自分で作成してください。その後、しばらくしていくつかのコードレビューを行った後、チームメイトがあなたのスタイルを模倣し始めることを願っています。

そうでない場合でも、生産性は向上し、最終的には努力を重ねることで、これらのルールの一部を施行できる上位の位置に移動できます。

そして、はい、すべての人にCode Completeからのものを必ず表示します。

ここにいくつかのトリックがあります：

• チームの現在の状態と履歴を学習します-メンターがいるように聞こえますが、メンターはどの程度の影響力を持っていますか？また、メンターはどのくらい新しく、メンターのいない長い時間がありましたか？問題コードはいつ発生しますか？現在のチームの赤ちゃんを批判することは、誰も実際に書いたことを覚えていない古いコードを批判することとは大きく異なります。

• 一度に一つのこと-チームミーティングであなたの考えすべてに爆弾を落とさないでください。特定の観点からの暫定的な質問から始めます。たとえば、「ねえ、新しい男として、ユーティリティクラスのいくつかが本当に大きいことに気付きました。その理由はありますか？」

• 赤ちゃんの手順を提案する-すぐに完全なオーバーホールを行うことはほとんど不可能なので、これが良い計画であることに全員が同意する場合に提案するためのいくつかの開始手順を見つけてください。

• 将来の防止メカニズムを提案します。たとえば、チームは上位2、3の最大クラスには決して追加しないが、さらに成長させる必要がある場合はリファクタリングするという目標に同意できます。

• リスクに関する懸念に耳を傾けます。これが本当にレガシーなコードである場合、リファクタリングが非常に危険なほど十分な未知数と依存関係があるかもしれません。これはリファクタリングを回避する理由ではないかもしれませんが、実際のリワークに取り組む前に、より良いテスト戦略またはリスクを軽減する他の方法が必要になることを意味する場合があります。

• ボディーランゲージに注意し、ゆっくりしてください。経験の浅いコードベースで問題を引き起こしています。現在、新しいガイウィンドウがあります。ここでは、素朴な質問をして有益な回答を得ることができます。これらの質問を使用して、チームを調査し、独自の設計選択を検討できます。しかし、それは両方の方向に行きます-新しい男として、あなたはまだたくさんの「信用」も持っていないので、ゆっくりして、閉じた顔や姿勢に注意してください。人々がシャットダウンを開始する場合、決定を遅らせる方法を提案し、それらに勝つ方法を探します。

私はマネージャー兼チームメンバーとして、New Guy Insightsを喜んでいます。私は新しいチームメンバーが私に与えた建設的な解説のすべてを受け入れませんでしたが、批判が正直な関心と好奇心として表明され、講義として提供されなかった場合、私は一般的に耳を傾けていました。新しい男への敬意の印は、洞察力を発揮し、一歩下がって来たものすべてを処理できるようになったときです。あなたの決定を聞いて受け入れたときは気分が良くなります。まだ正しいかもしれませんが、次は何をすべきかを考え出すのがコツです。通常は少し待って詳細情報を探すのが、このような場合の次のステップです。

より小さなクラス/メソッドを使用するようにチームを説得するにはどうすればよいですか？

しないでください。

自分でResharperライセンスを購入し、例を挙げてリードしてください。[「抽出方法」リファクタリングに重点を置いています。]

時間が経つにつれて、他の人はあなたのより読みやすいコードに感謝し、同様にやるように説得されるはずです。

• はい-彼らが説得されない可能性があります。しかし、それはあなたの最善策です。

IMO- より良いプログラマーになるようにチームメイトを説得し、「コード完了」を読み、@ Uncle Bobをフォローすることは、あなたの音節の価値がありません。の堅実な原則であり、まだ説得されていなければ優れたプログラマーになります。

要確認：ロジックを使用して、そもそもロジックを使用していない立場から誰かを主張することはできません。

これは技術的な質問というよりも経営上の質問のようです。あなたが言ったことはすべて有効です。あなたのチームが本当に必要とするのは、誰もが単一の設計パターンに順応し、それを実施できるようにする優れたアーキテクトです。チームはコードを絶えず定期的にリファクタリングする必要があります。

しかし、別の「あなたはそれを必要としません」というプリンシパルがあります。これまで存在していたものが、どれほどくても機能する場合、それを変更することは常に良い考えではありません。代わりに、チーム全体を再構築するか、その一部を再構築する必要がある場合は、コーディングを実行する前に、悪い習慣と問題の文書を蓄積してください。

一部のチームは、適切なツールがわからないため、コードの品質管理を一切行いません。チームコードの改善に役立つツールは多数あります。

Visual Studioには、命名規則に役立つ「コード分析」があります。

また、循環的な複雑さのようなコードメトリックも使用できます。これは、複雑すぎるクラスとメソッドを指摘するのに役立ちます。

記録を残すこともお勧めします。チームのメンバーが何をする必要があるかを口頭で表明するだけであれば、人々は忘れてしまいます。人間には非常に弱い記憶があります！=）

私はこれについてあまり騒ぎません...プログラマの開発チームは彼自身の家族のようです...間違いを指摘すると、人々はあなたに腹を立てることができます。この種の文化の変化は、多くのコーディングを必要とするだけでなく、人間との繊細なタッチも必要とします。

マネージャーとして追加したいのは、チームに初めて良いコードを書いてほしいということです。コードレビュー、TDDなど。しかし、運用環境で機能するようになったら、私たちに戻ってもらうために強力な主張をする必要があります。

ボブおじさんのアドバイスに従って、あなたが見つけたよりも常に良いコードを常に残すようにします。そのため、修正するバグや小さな機能拡張がある場合は、クリーンアップの一部を行っていたと思います。

しかし、現状では、ビジネスは本当にお金を監視しています。リファクタリングは、チームに時間とリソースを提供するのに十分なメリットがあると主張する必要があります。コードの見た目が好きではないだけでは不十分です。

ですから、もしそれが機能するなら、あなたがそれを嫌うかもしれないのと同じくらい、あなたはそれを放っておかなければならないかもしれません。

今、新しいコード、それは違います。それは良いコードです。

150行のメソッド... 10.000行のコードを持つメソッドを見てきました。

あなたの2つの問題は外部ツールで解決できます：

• 多少矛盾した命名ガイドライン
• 可能な場合、プロパティは読み取り専用としてマークされません

C＃では、Resharperは両方の問題をチェックできます。ガイドラインに従わない名前はエラーとしてマークされます。読み取り専用としてマークされていないプロパティもエラーとして表示されます。FxCopも役立つ場合があります。

これらのツールは、リファクタリングのおかげで、巨大なメソッドを複数の小さなメソッドに分割するのにも役立ちます。

大規模なクラスが適切な名前のメソッドで適切に構造化されている場合、それが常にそれほど悪いということはわかりません。私はIDEとしてEclipseを使用しているため、「アウトライン」ビューと呼ばれるものがあります。これは、すべてのIDEに異なる名前が付けられたもので、おそらく、クラス内の各メソッドへの名前とリンクを提供し、これを使用すると、大きなクラスを簡単にナビゲートできますが、本当に長いメソッドを持っているのは悪いでしょう、あなたが本当に慣れていない限り、そのメソッド内でインテリジェントにナビゲートするのは難しいからだと思います。長いクラスを提唱しているわけではありませんが、場合によっては管理しやすく、必ずしも複数のクラスに分解する必要はないと思います。

あなたのチームメンバーの何人かに主題を持ち込み、メソッドのサイズについて意見をもらいます。あなたは彼らがあなたに同意していることに驚くかもしれません。あなたが見ているのは、以前の悪い慣習、以前の開発者が会社にいなかった、またはその部分が急いでいた仕事の結果である可能性があります。

あなたはまだ新しい男です。やりがいのある課題を引き受け、バグなしで迅速に完了することで、評判を高めます。仲間の尊敬を得る前に物事を変え始めようとすると、買収に苦労する可能性があります（そしておそらく同僚を疎外します）。

開発時間を短縮し、より堅牢なソリューションを実現する方法を効果的に実証する、より良いコーディング習慣を自分の仕事に導入する方法を見つけることができる場合は、それを達成する方法を確認してもらうこともできます。

他のすべての優れた答えに加えて、1つの石で2羽の鳥を殺し、コードベースの理解を得るためのプロジェクトとしてコードクリーンアップを行うことができます。学習の機会としてチーム/マネージャーに販売することができます。また、変更を検討する際に同僚からフィードバックが得られます。これは、貧弱なデザインの問題に取り組むための最善のアプローチを導きます。