オブジェクト指向のプラクティスを広める方法に関するヒント[非公開]

私は約250人の開発者がいる中規模の会社で働いています。残念ながら、それらの多くは手続き型の考え方に固執しており、実際にはアプリケーションに豊富なロジックが含まれている場合でも、一部のチームは大きなトランザクションスクリプトアプリケーションを常に提供しています。また、設計の依存関係を管理できず、最終的に別の多数のサービスに依存するサービスになります（クリーンな例 Big Ball of Mudの）。

私の質問は、この種の知識を広める方法を提案できますか？

問題の表面は、これらのアプリケーションのアーキテクチャと設計が貧弱であることです。別の問題は、あらゆる種類のテストの作成に反対する開発者がいることです。

これを変更するために私がやっていること（しかし、私は失敗しているか、変更が小さすぎます）

• 設計原則（SOLID、クリーンコードなど）に関するプレゼンテーションの実行。
• TDDおよびBDDに関するワークショップ。
• コーチングチーム（これには、ソナー、findbugs、jdependおよびその他のツールの使用が含まれます）。
• IDEとリファクタリングの話。

私が将来することを考えているいくつかのこと（しかし、それらは良くないかもしれないと心配です）

• オブジェクト指向のエバンジェリストのチームを編成し、オブジェクト指向の考え方を異なるチームに広めます（これらの人々は、数か月ごとにチームを変更する必要があります）。
• 設計を批判し、改善を提案するために、設計レビューセッションを実行します（時間の制約のために改善が行われない場合でも、これは役立つと思います）

。

私がコーチするチームで見つけたのは、チームを離れるとすぐに、古いチームに戻るということです。私は彼らと一緒に多くの時間を費やさないことを知っています。通常は1ヶ月です。だから私がやっていることは何でも、それは固執しません。

この質問にフラストレーションがたまっているのは残念ですが、これを書く別の方法は、気が散るまで壁に頭をぶつけることでした。

OOPをプッシュしようとしないでください。事態を悪化させるだけです。OOPが一般的に悪い考えだからではなく、そうではありません。しかし、そのヘアボールコードの責任者はだれでも、これらの問題を回避するためのツールだけでなく、経験、そしてさらに重要なことに動機も欠いているようです。

きれいなコードを書きたい人は、OOP、手続き、機能など、どのようなパラダイムでもそうします。しかし、すべてのプログラマーがこのようなわけではありません。必要性を理解すると、これらのツールは既に存在するツールと同様に悪用されることになります。クラスにグループ化された無関係なメソッド、無関係なクラスから継承するクラス、意識的な設計ではなく試行錯誤のデバッグに基づいて設定されたメソッドの可視性、静的であってはならない静的メソッド、要するに静的でないメソッド、時間を無駄にします。

代わりに、保守性と優雅さに対する意識を高めることに投資できるかどうかを確認してください。結局のところ、OOPの中心的な目標は、他の複雑さ管理戦略（プログラミングパラダイムが実際にすべてであるもの）とは何も変わりません：カプセル化、モジュール化、疎結合、相互依存性の低さ、可変状態とそのスコープの維持最低限など。OOPは、これを実現するために必要なツールを提供する唯一のパラダイムではありません。

それが最後のポイントに私を連れて行きます：OOPは素晴らしいアイデアであり、特定の種類の問題に対してうまく機能しますが、（そして私はここで自分の経験といくつかの偉大な心の意見の言い換えから話しています）問題、それは完全に不適切です。あなたがOOPに慣れており、セミプロシージャスパゲッティコードがあなたが精通している唯一の選択肢であるとき、OOPは天からの贈り物として自然に現れます（そして相対的な方法で、そうです）、そしてあなたは近づきそうですOOPハンマーの釘としてのすべての問題。それはごく自然なことであり、OOPをその限界まで（およびそれを超えて）駆動することは、OOPスキルを向上させるための良い方法なので、すべてがネガティブではありません。しかし、たぶん（たぶん）この特定のコードベースはOOPを必要としません。たぶん、手続き型アーキテクチャからより多くの恩恵を受けるでしょう、

TL; DR：何でも伝道したい場合は、特定のパラダイムや方法論ではなく、（プラットフォームに依存しない）優れたコーディングプラクティスにしてください。

まだ変更したくない人を変更することはできません。あなたがコーチしたチームが以前のやり方に戻ったのはそのためです。

本当にあなたの質問は、「開発者にオブジェクト指向アプローチへの変更をどのようにさせますか？」であるべきです。

シンプルに始め、小さく始め、そこから物事を築きましょう。コード、他の開発者、または会社にとっての抽象的または哲学的なメリットの代わりに、個々の開発者にメリットを示します。

さまざまなオブジェクト指向技術がどのように記述する必要のあるコードを減らし、開発時間を短縮するかを示します。ほとんどすべての開発者は、仕事を楽にする提案を聞きます。

次に、オブジェクト指向技術がどのようにコードをより簡単に維持できるかを示し始めます。このタイプの環境の誰もが、実稼働アプリケーションの3分の1を消滅させる「変更」を行うことを恐れて生活しています。カプセル化はこのリスクを回避するための鍵であり、アプリケーションの各（まもなく）レイヤーが他のレイヤーとの契約を維持できるようにします。

データがどのように受け渡されるかを見ていきます。毎回変数のリストが長い場合は、予備ステップとして、それらの一部を構造内にラップすることを検討してください（または、gasp！a class !!!）。単純にオブジェクト内にデータをラップすることは、レイヤー間のコントラクトの始まりです。

より広いレベルで-まだ管理者の賛同を得ていない場合は、この取り組みを検討してください。管理者は、欠陥の減少と変更を行うことによるリスクの低減の具体的な利点を確認する必要があります。最終的に、リファクタリングプロセスは開発時間の短縮につながるはずですが、それは長期的な利点です。

レビューチームとオブジェクト指向エバンジェリストのアイデアは良いものです。このアジェンダを推進しているのはあなただけではありません。

私の経験では、手続き型の考え方からオブジェクト指向の考え方への切り替えは大きなハードルです。多くの開発者が耐えられない忍耐が必要です。これは主に、オブジェクト指向の基礎が見直されているためです。

オブジェクト指向のエバンジェリストのチームを編成し、オブジェクト指向の考え方を異なるチームに広めます（これらの人々は、数か月ごとにチームを変更する必要があります）。

良いアイデアです。これは徹底的であり、オブジェクト指向は一から話されるべきです。私がオブジェクト指向の歴史的な逸話を学んでいたとき、たくさん助けました。

私もお勧めします、

• 動機付けが鍵であるため、OOが作業、特にコードの保守性をどのように改善できるかを詳細に説明します。
• コードのレビューを行い、構成、継承、ポリモーフィズム、およびパターンを適用してリファクタリングする方法を示します。
• SCRUMなどの優れたプロセスを導入し、開発者を関与させます。
• 「リファクタリング」や「パターンへのリファクタリング」などの本を読むことを必須にします。

Shuvo Naserに同意します。それは大きなハードルですので、もっと登るように扱ってください。OOPを使用してアプリケーション全体を設計する方法を学習するには時間がかかります。

1. OOPを理解している人を特定し、チームリーダー、トレーナー、デザイナー、コードレビュアーなどに近づけます。
2. 既存のプロジェクトをトレーニングリファレンスとして使用します。おそらく、＃1のメンバーがそのチームに所属していました。
3. いくつかの既存プロジェクトをリファクタリングします。これは、一部の人々が手続き型コードとOOコードの間に橋を架けるのに役立ちます。基本から始めましょう。彼らは、いつ、どこで、なぜあなたがこれらの原則を使うのかを見なければなりません。
4. 彼らが何をしているのかを知っている人々とのデザインセッションに参加してください。
5. 設計ガイダンスを提供し、プロジェクトがオブジェクト指向の原則に準拠していることを確認できる人と一緒に開発チームに配置します（最初にこれを行う理由は、開発が改善されるためです）。

利点が見られる前に採用されることはめったにありません。TPSレポートカバーシートを使用せずに、複雑なデザインについて説明しています。

あなたはすでに良いアイデアを持っています

あなたの質問であなたが概説したアイデアは素晴らしいように聞こえます。成功していないのは大きな驚きです。それは2012年であり、オブジェクト指向の革命は最先端から実践へと移り変わってから長い間経ちます。離職率が非常に低く、雇用が非常に少ない場合を除き、数十、または100の優秀なオブジェクト指向プログラマーを獲得するのに苦労するようです。

アジャイルまたはオブジェクト指向？

TDDなどのいくつかのアジャイルテクノロジーやいくつかの新しいコンセプトについて言及しているため、一部の管理チームが積極的に戦っているものを受け入れないことに対して、人々にあまり厳しくしないでください。アジャイルを採用すると主張する人もいますが、それについて話すとき、それは彼らが言う意味を意味します。組織は、意思決定を行って適応するチームではなく、強力な階層的な契約スタイルの制御によって特徴付けられます。

しかし、オブジェクト指向に戻ります。オブジェクト指向の分析や設計については言及していませんが、どのプログラミング言語がどのオブジェクト指向プログラミング言語に取って代わっているのかはよくわかりません。UMLが多くのオブジェクト指向プログラマーの間で人気の問題を抱えていることは知っています。OOADで徹底的に訓練されたことは、自然言語を学びたい国の文化や歴史を学ぶことに似ていると思います。たとえば、ギリシャ語を学びたい場合、アルファベット、語彙、および文法を学ぶことができますが、豊かな歴史と文化を無視すると、多くを見逃します。いずれにせよ、オブジェクト指向プログラミング言語についてすべてを学び、OOADについては何も学ばなければ、重要な機会が失われたと思います。

克服すべき問題？

橋が遠すぎる？ 参加する人々の中で、1年に1週間に1つの小さなことを学ぶように人々に求めると、多くの変化があります。あなたが彼らに知っているすべてを変えるように彼らに頼むならば、それは少数によって歓迎され、多くのために激しく、そして他のために不可能です。ソース管理などの一部の変更はローカライズされています。前にやらないことから移行し、記憶の限界に重点を置かないトレーニングを受け、誰かが初めてそれを説明してくれたので、日々はとても簡単でした。

その他の変更は広範囲に及びます。たとえば、CをダンプしてJavaに切り替えるには、新しいIDE、新しいコンパイラ、新しい言語、新しいAPI、新しい展開モデルなどを採用するために、日々の大幅なトレーニング、セットアップ、および大きな変更が必要です。パイロットプログラムまたは企業の再編に関連して最も頻繁に発生すること。

革命をリードしていますか？ 現在仕事をしている人々が報われた歴史があり、会社が失敗の危険にさらされていない場合、変化の動機は何ですか？あなたが方向を示し、彼らが予測できない結果に責任を負わせたいと思っている部外者のように思えるなら、それはすべてのリスク、報酬なしのように見えるかもしれません。

権力とアイデアのリーダーシップの位置付け 多くの組織は、地位に基づいて運営されています。マネージャー、セクション長、ディレクター、副社長からの目に見えるサポートが不足している場合、あなたは単なるアイデアリーダーです。一部の人々は、1つのアイデアを持ち、2番目のアイデアを楽しませることができないという危険な立場にあります。伝えるのではなく見せることができれば、懐疑論者を静かにし、才能のある同盟者に興味を持たせることができます。

サポートのベースが小さすぎますか？ 250人の人々の間でトリアージを行い、3つのカテゴリーに分類します：受け入れる準備ができている、学ぶ意欲がある、学ぶ意欲がない。あなたは、変化を起こすことに興味のない人々の何人かにイライラする正当な理由があります。ロープを押すこともできます。これは無駄な努力です。誰が変化をサポートしているかについての感触があれば、何に関心があるのか​​を知ることができます。

倫理的かつ実践的な選択が助けを借りて成功する中間層を助けることである医療トリアージとは異なり、判断と好みに基づいてエネルギーと時間を投資できます。あなたの成功のために、新しいアイデアを受け入れる準備ができているグループを育ててみませんか？最初は数少ないかもしれませんが、雪だるま式のように、支持者としてのあなたの可視性と信頼性は高まります。すぐに、次のトレーニングがいつ行われるのかと聞かれます。

長期的には？ あなたが後のものを運ぶためにチャンピオンを養うまで、あなたは関係を築くのに時間を費やすことを期待すべきです。コーチするチームに1か月以上滞在する必要がある場合があります。チームが改善されたプラクティスを自分で所有するまで、あなたは単なる技術または方法論の警官です。メンタリングは何年もかかるプロセスです。開発者がやりたくないことは、重要だと思うことはたくさんあります（具体的には、ユニットテストについて言及していると思います）。これがもたらす価値について共通のビジョンを構築するには、時間がかかる場合があります。私はかつてフォーチュン500社でコードカバレッジツールを提唱していましたが、これは品質で高い評価を得ていましたが、マネージャーや同僚も同様にコミットすることに慎重でした。

エキスパートまたは草の根？ メンタリングよりもはるかに速いのは、各チームメンバーからの草の根のサポートを促進することです。10人のソフトウェアスペシャリストのチームから始めて、1人が常にプロセスを担当するか、10人が10％のプロセスを担当するかを選択した場合、2番目を選択します。草の根プロセスにより、支持者はアプローチの影響を感じ、作業を所有するチームの問題を最適に解決するようにアプローチを調整することができます。

フリーダムラインが見えますか？ 「ベストプラクティス」を導入することの一部は、一般的な方法で物事を行う自由を人々に放棄させることです。開発者に多くの選択肢を残す機会を探しているなら、プログラマーの裁量を放棄することはより好ましいでしょう。彼らが選ぶものは、自由線と呼ぶことができるパーティションによって義務付けられているものから線引きされています。組織、地域/サイト固有、チーム、および個人の慣行について、同様の正当に正当化された部門が必要になる場合があります。

これはコメントであるはずでしたが、私はどうやらまだコメントすることができないので、答えかもしれません。

この種の突破口で最も重要なことは（OOPやその他のパラダイムシフト、たとえば関数型プログラミングなど、来年登場するもの）は、DOコードレビューとピアプログラミングです。彼らに同行し、チームを助けて彼らを助ける別の方法を実行します。

オブジェクト指向プログラミングへの私の個人的な道は、コードのレビューを行うランダムな攻撃が、完全なC ++ OOを実行せずにモジュール方式で状態を維持することで私を非難したときに始まりました。のようなコードだと思う

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

（clients_totalは完全に冗長であり、特に計画が不十分な例であることに注意してください）

そして、より多くのシニア同僚がちょうど私の画面を指して、「同じことを複数回書いたら、プロシージャまたは関数を使用し、何度も何度も呼び出してください」と言ったときだけ、私はこれをしました。

純粋な好奇心以外にそれを行う本当の動機はないので、トークとミーティング、およびオプションのプラクティスは、それらをパラダイムシフトさせたり、新しいプラクティスを導入したりしません。一方で、悪いことをしないか、一般的には眉をひそめているだけで、採用率は本当に良くなります。

彼らがやっていることに適切なデザインを組み込むまで続く、泣き言とクラス指向の開発に備えてください。少し死ぬようなものがたくさんありますが、それが学習への道のようです。