経験豊富なC ++エンジニアのチームにOOP / OODを「導入」するための最良の方法
OOPコンセプトを既存のチームメンバーに紹介するために、侮辱として外れない効果的な方法を探していますか？チームメイトはOO言語私たちはC++/C＃を長い間使用してきたため、テクノロジー自体は使い慣れています。
しかし、私は周りを見回し、大きな労力を注ぎ込むことなく（主にコードレビューの形で）、生成しているのはたまたまクラスの中にあるCコードであるようです。ほんの数例を挙げると、単一の責任の原則、抽象化、またはカップリングを最小限に抑える試みはほとんど使用されていません。コンストラクターはないがインスタンス化されるたびにmemsetが0になるクラスを見てきました。
しかし、私がOOPを呼び出すたびに、誰もが常にうなずき、私が話していることを正確に理解しているように見せかけます。概念を知ることは良いことですが、実際の仕事を提供することになると、私たち（他の人よりも）はそれらを適用するのが非常に難しいようです。
コードレビューは非常に役に立ちましたが、コードレビューの問題は、事実の後にのみ発生するため、作成されたばかりのコード（ほとんどがリファクタリングですが、まだ時間がかかる）を書き直してしまうように見える人もいます。また、コードレビューは、チーム全体ではなく、個々のエンジニアにのみフィードバックを提供します。
私はプレゼンテーション（またはシリーズ）をするという考えをいじって、OOPをもう一度紹介し、既存のコードのいくつかの例と一緒に書き直して、リファクタリングできるようにします。私はもう誰も所有していない本当に古いプロジェクトを使用することができたので、少なくともその部分はデリケートな問題ではないはずです。しかし、これはうまくいきますか？私が言ったように、ほとんどの人は長い間C++を行ってきたので、私の推測はa）です彼らは、なぜ私が彼らがすでに知っていることを彼らに言っているのか、またはb）彼らが実際に侮辱として受け入れるかもしれないと考えてそこに座ります。私が彼らに彼らが何年もやってきた仕事をする方法を知らないので彼らに言っているからです数十年ではないとしても。
コードレビューよりも幅広い聴衆に到達するが、同時に罰の講義のように感じられない別のアプローチはありますか？
私は、完全に設計されたコードのユートピア的な理想を持っている大学生ではありませんが、誰からもそれを期待していません。私がこれを書いている理由は、私が紙の上にまともな高レベルのデザインを実際に持っていた人のレビューをしたからです。ただし、クラスを描く場合：A-> B-> C-> D、コードB、C、Dはすべてほぼ同じパブリックインターフェイスを実装し、B/Cは1つのライナー関数を持っているため、最上位のクラスAは完全にすべての作業（メモリ管理、文字列解析、セットアップネゴシエーションなど）は主に4つのmongoメソッドで行われ、すべての目的と目的のために、ほぼ直接Dを呼び出します。
更新：私は技術主任（このロールで6か月）であり、グループマネージャーを完全にサポートしています。私たちは非常に成熟した製品に取り組んでおり、メンテナンス費用は間違いなく彼らに知られています。
[〜＃〜] solid [〜＃〜] の原則で短いトレーニングを開発して、このトレーニングをしてみませんか？私の現在の組織では、それは非常にうまく機能しているようで、短期間のトレーニングを行うことは（関係者全員にとって）本当に楽しいと感じています。
私がトレーニングを行ったとき、（さまざまなプロジェクトの）既存のコードで病理学的な「悪い」例を探すために少し時間をかけ、原則を使用して、プレゼンテーションで段階的にそれらをリファクタリングしました。これは
- これらのリファクタリングを行うことはそれほど難しくありません
- 時間がかからない
- 最終結果（慎重に選択された;-)）は、元のコードよりも明らかに優れています。
コードレビューは非常に役に立ちましたが、コードレビューの問題は、それらが事実の後でのみ発生することです。
1つのプロジェクトで、デザインレビューを行いました。
15分。ホワイトボードで。コーディングの前に設計について説明します。
最も重要な部分は、設計レビューpriorを実装作業にスケジュールすることです。
また、「Critical Design Reviews」もあり、汗をかきました。彼らは多くの文書と長いプレゼンテーションを含んでいました。それらはスケジュールするのが難しく、コーディングが始まるまでほとんど常に押し出され、その値をゼロに減らしました。
非公式の設計レビュー-コーディングの前-プレッシャーなし-ドキュメントなし-は、責任がどのように割り当てられ、オブジェクトがどのように連携するかについてより良い議論を可能にします。
あなたは一部の開発者より若いが、フードチェーンの上位にいると思います。
反対票に埋もれるリスクがある場合、「経験豊富なエンジニア」が実際に正しいことを行っている可能性があります。これは、何十年も前から存在していた成熟した製品であるため、かつては正しいことでした。
古いコードは、当時のハードウェアですばやく実行するように最適化されている傾向があります。とりわけ、これは継承のレベルを削減し、簡単な操作の関数/メソッド呼び出しを回避することを意味します。
コンパイラーは長年にわたって非常に賢くなっているため、現在かつて真実だったすべてがそうであるとは限りません。例えば、コンパイラーは小さな関数をインライン化することを選択する場合があります。
おそらく、別のアプローチを採用する方法が考えられます。開発者に、自分の教えた理論よりも方法が優れている理由と理由を説明してもらい、誠実に説明してください。
各new/changedメソッドの100％ブランチカバレッジで単体テストをプッシュすると、メソッド間の結合が最小限になりません。
ギャングオブフォーから「デザインパターン」の本を手に入れたいかもしれません。これはC++に固有のものではないため、参照するときに同僚のC++の知識を公然と批判することはありません。それと同時に、あなたが関連すると考えるトピックに対処します。また、この本は関連性が高いとして広く受け入れられているため、理論的または非現実的であるとして簡単に却下することはできません。
一方、C++は純粋なOO言語ではなく、設計上も実際にもありません。コンストラクタ/ memsetストーリー全体で、RAIIを導入する必要があるようですが、これは=ではありません。 OOテクニックはC++に固有ですが、残念ながら.NetのIDisposeは、RAIIが後付けであるときに何が起こるかを示しています。関連する本は、（もっと）効果的なC++と（もっと）例外的なC++です。