経験豊富なC ++エンジニアのチームにOOP / OODを「導入」する最良の方法

私は、OOPの概念を既存のチームメンバーに紹介するための、efficient辱としても抜け落ちない効率的な方法を探していますか？私のチームメイトはオブジェクト指向言語に慣れていません。私たちは長い間C ++ / C＃を行ってきたので、テクノロジー自体はよく知られています。

しかし、私は周りを見回し、努力の大きな注入なしで（主にコードレビューの形で）、私たちが作り出しているのはクラス内にあるCコードです。いくつか例を挙げると、単一の責任原則、抽象化、結合を最小限に抑える試みはほとんど使用されていません。コンストラクターはないが、インスタンス化されるたびにmemsetを0にするクラスを見てきました。

しかし、私がOOPを立ち上げるたびに、誰もがうなずき、私が話していることを正確に知っているように見えます。概念を知ることは良いことですが、実際の作業の提供に関しては、私たち（他の人よりも）を適用するのは非常に困難です。

コードレビューは非常に役立ちましたが、コードレビューの問題は、事実の後にのみ発生することです。そのため、一部の人にとっては、書き直されたコード（ほとんどはリファクタリングですが、多くの時間がかかります）になります。また、コードレビューは、チーム全体ではなく、個々のエンジニアにのみフィードバックを提供します。

私は、プレゼンテーション（またはシリーズ）を行うというアイデアをいじり、OOPを、より良く記述でき、リファクタリングできる既存のコードの例とともに再び表示しようとしています。誰ももう所有していないいくつかの本当に古いプロジェクトを使うことができたので、少なくともその部分は微妙な問題ではないはずです。ただし、これは機能しますか？私が言ったように、ほとんどの人は長い間C ++をやっているので、a）彼らはそこに座って、なぜ彼らがすでに知っていることを言っているのかを考えているか、b）彼らは実際にそれをin辱として取るかもしれません数十年ではないとしても、長年やってきた仕事をどうやってやるのかわからないと伝えます。

コードレビューよりも幅広い聴衆に到達するが、同時に罰の講義のように感じない別のアプローチはありますか？

私は、完全に設計されたコードの理想的な理想を持っている大学の新鮮な子供ではありません。誰にも期待していません。私がこれを書いている理由は、紙の上にまともな高レベルのデザインを実際に持っている人のレビューをしたからです。ただし、クラスを想像する場合：A-> B-> C-> D、コードB、CおよびDはすべてほぼ同じパブリックインターフェイスを実装し、B / Cには1つのライナー関数があるため、最上位のクラスAは絶対に実行します主に4つのmongoメソッドでのすべての作業（メモリ管理、文字列解析、セットアップネゴシエーションなど）、およびすべての意図と目的のために、ほとんど直接Dを呼び出します。

更新：私は技術リーダー（この役職で6か月）であり、グループマネージャーを完全にサポートしています。私たちは非常に成熟した製品に取り組んでおり、メンテナンスコストは間違いなく知られています。

SOLIDの原則に関する短いトレーニングを開発し、このトレーニングを提供してみませんか？私の現在の組織では非常にうまく機能しているようで、短いトレーニングを行うのは実際には楽しいです（関係者全員にとって）。

トレーニングを行ったとき、既存のコード（さまざまなプロジェクト）の病理学的な「悪い」例を検索し、原則を使用して段階的にプレゼンテーションでリファクタリングしました。これにより、

1. これらのリファクタリングを行うことはそれほど難しくありません
2. 時間がかからない
3. 最終結果（慎重に選択された;-)）は、元のコードよりも明らかに優れています。

コードレビューは非常に役立ちましたが、コードレビューの問題は、事後のみに発生することです。

1つのプロジェクトで、設計レビューを行いました。

15分。ホワイトボードで。コーディングの前に設計について話し合います。

最も重要な部分は、実装作業の前に設計レビューをスケジュールすることです。

また、「Critical Design Reviews」もありましたが、これは大変で汗臭い取引でした。多くのドキュメントと長いプレゼンテーションが含まれていました。それらはスケジュールするのが難しく、ほとんどの場合、コーディングが開始されるまでプッシュされ、値がゼロになりました。

コーディング前の非公式の設計レビュー-プレッシャーなし-文書化なし-責任の割り当て方法とオブジェクトのコラボレーション方法についてのより良い議論を可能にします。

私はあなたが開発者の何人かより若いが、食物連鎖の上位にいると仮定しています。

ダウン票に埋もれてしまうリスクは、「経験豊富なエンジニア」が実際に正しいことをしていることである可能性があります。

古いコードは、当時のハードウェアで迅速に実行されるように最適化される傾向がありました。とりわけ、これは継承のレベルを削減し、簡単な操作のための関数/メソッド呼び出しを回避することを意味します。

コンパイラーは長年にわたってずっと賢くなってきたので、かつては真実だったすべてがそうであるわけではありません-例えば、コンパイラーは小さな関数をインライン化することを選択するかもしれません。

おそらく、今後の道筋は、異なるアプローチを採用することです-開発者に、どのように/なぜ彼らの方法が教えられた理論よりも優れているのかを説明してもらい、それについて誠実であることです。

新しい/変更されたメソッドごとに100％の分岐カバレッジで単体テストをプッシュしても、メソッド間の結合は最小限になりません。

Gang of Fourの「Design Patterns」ブックを選択することもできます。C ++に固有のものではないため、同僚のC ++の知識を公然と批判することはありません。しかし同時に、あなたが関連性があると考えるトピックを扱っています。また、この本は関連性があるとして広く受け入れられているため、理論的または非実用的であると簡単に却下することはできません。

一方、C ++は設計上も実際上も、純粋なオブジェクト指向言語ではないことを考慮してください。コンストラクター/メモリセットのストーリー全体は、RAIIを導入する必要があるように聞こえますが、これはオブジェクト指向技術ではありませんが、C ++に固有のものです（残念ながら-。ここで関連する書籍は、（詳細）効果的なC ++および（詳細）例外的なC ++です。