オブジェクト指向の実践を広める方法に関するヒント
私は約250人の開発者を抱える中規模企業で働いています。残念ながら、それらの多くは手続き的な考え方で行き詰まり、実際にはアプリケーションに豊富なロジックが含まれている場合でも、一部のチームは常に大きな トランザクションスクリプト アプリケーションを提供しています。また、設計の依存関係の管理に失敗し、別の多数のサービスに依存するサービスになってしまいます（ Big Ball of Mud の明確な例）。
私の質問は、このタイプの知識を広める方法を提案できますか？
問題の表面は、これらのアプリケーションのアーキテクチャとデザインが貧弱であることです。別の問題は、あらゆる種類のテストを作成することに反対する開発者がいることです。
これを変更するために私がしているいくつかのこと（しかし私は失敗している、または変更が小さすぎる）
- 設計原則（SOLID、クリーンコードなど）に関するプレゼンテーションを実行する。
- TDDとBDDに関するワークショップ。
- コーチングチーム（これには、ソナー、findbugs、jdependおよびその他のツールの使用が含まれます）。
- IDEとリファクタリングの話。
将来的にいくつか考えていること（ただし、それが良くないのではないかと心配しています）
- OO伝道者のチームを形成し、さまざまなチームでOO考え方を広めます（これらの人々は数か月ごとにチームを変更する必要があります）。
- 設計レビューセッションを実行して、設計を批判し、改善を提案する（時間の制約のために改善が行われなかった場合でも、これは役立つと思います）
。
私がコーチしたチームで見つけたものは、私が彼らを去るとすぐに、彼らは古い慣行に戻るということです。私は彼らと多くの時間を費やさないことを知っています。通常は1か月だけです。だから私が何をしていても、それは固執しません。
この質問が欲求不満でいっぱいになって申し訳ありませんが、これを書く代替案は、私が気絶するまで壁に頭をぶつけることでした。
OOPをプッシュしようとしないでください。状況が悪化するだけです。 OOPは一般に悪い考えです：そうではありません。しかし、そのヘアボールコードの責任者は誰でも、これらの問題を回避するためのツールだけでなく、経験も欠けているようです。より重要なのは、動機。
クリーンなコードを記述したい人は、OOP、手続き型、関数型など、どのようなパラダイムでもそうするでしょう。しかし、すべてのプログラマーがこのようなわけではなく、クリーンなコードツールをそうでない人にプッシュすると、必要性を理解すると、これらのツールは、すでに存在するツールと同じように乱用されることになります。クラスにグループ化された無関係なメソッド、無関係なクラスから継承するクラス、意識的な設計ではなく試行錯誤によるデバッグに基づいて設定されたメソッドの可視性、静的であってはならない静的メソッド、および簡単に言えば非静的メソッド、あなたはあなたの時間を無駄にするでしょう。
代わりに、保守性と優雅さのために意識を高めることに投資できるかどうかを確認してください。結局のところ、OOPの中核的な目標は、他の複雑さ管理戦略（プログラミングパラダイムが実際にそうであるものです）と何の違いもありません）：カプセル化、変調、疎結合、低度相互依存性、変更可能な状態とそのスコープを最小限に保つなど。OOP確かに、これを達成するために必要なツールを提供する唯一のパラダイムではありません。
OOPは素晴らしいアイデアであり、特定の種類の問題に対してはうまく機能しますが、私は自分の経験と、ここでいくつかの素晴らしい心）は、多くの種類の問題にとって、完全に不適切です。OOPに慣れてきて、セミプロシージャスパゲッティコードが、慣れている唯一の代替手段である場合、OOP当然天国からの贈り物として（そしてそれは相対的にそうです）表示され、あなたはすべての問題にあなたのOOPハンマーの釘として）近づくでしょう。それは自然なことであり、= OOPに（そしてそれを超えて）制限を加えることは、OOPスキルを構築するための良い方法なので、すべてが否定的ではありません。しかし、おそらく（たぶん）この特定のコードベースOOP結局のところ、必要ありません。適切な設計、適切なプロジェクトレイアウト、適切な抽象化、適切なカプセル化を備えたより構造化されたアーキテクチャであっても、おそらく手続き型アーキテクチャのほうがはるかにメリットがあります。
TL; DR：何かを伝道したい場合は、特定のパラダイムや方法論ではなく、（プラットフォームにとらわれない）適切なコーディングプラクティスにしましょう。
まだ変更したくない人を変更することはできません。これが、コーチしたチームが以前の方法に戻った理由です。
だから本当に、あなたの質問は「開発者にOOアプローチに変更したいのですが、どうすればいいですか？」
単純なものから始め、小さなものから始めて、そこから物事を構築していきましょう。コード、他の開発者、または会社に対する抽象的なまたは哲学的な利点の代わりに、個々の開発者に利点を示します。
さまざまなOOテクニックが、作成する必要があるlessコードにどのようにつながるか、および開発時間を短縮する方法を示します。ほとんどすべての開発者が作成する提案に耳を傾けます彼らの仕事は簡単です。
次に、OOテクニックを使用すると、コードのメンテナンスがより簡単になることを示します。そのタイプの環境の誰もが、「変更」を作成することを恐れて生きていますカプセル化は、このリスクを回避するための鍵であり、アプリケーションの各層（間もなく）が他の層との契約を維持できるようにします。
データがどのように渡されるかを見てみます。それが毎回変数の長いリストである場合は、それらの一部を構造体（またはあえぎ！クラス!!!）内にラップすることを検討してください。オブジェクト内のデータを単にラップすることは、レイヤー間のコントラクトの始まりです。
より広範なレベル-まだの場合は、この取り組みに経営陣の賛同を得ることを検討してください。経営陣は、欠陥の減少と変更によるリスクの低減の具体的なメリットを確認する必要があります。最終的に、リファクタリングプロセスは開発時間の短縮につながるはずですが、それは長期的なメリットです。
レビューチームとOO伝道者のアイデアは良いものです。この議題を推進しているのはあなただけではありません。
私の経験では、手続き型の考え方からOOの考え方への切り替えは大きなハードルです。多くの開発者が耐えられない忍耐力が必要です。これは主にOOの基本が見直されているためです。
OO伝道者のチームを結成し、さまざまなチームにOOの考え方を広めます（これらの人々は数か月ごとにチームを変える必要があります）。
良い考えです。これは徹底的である必要があり、OOは最初から話し合われる必要があります。私がOOを学んでいたとき、歴史的な逸話は大いに役立ちました。
私も提案します
- 動機付けが鍵となるので、OOが作業、特にコードの保守性をどのように改善できるかを詳しく説明して、動機付けをします。
- コードのレビューを行い、構成、継承、ポリモーフィズム、およびパターンを適用してリファクタリングする方法を示します。
- SCRUMのような優れたプロセスを紹介し、開発者を関与させます。
- 「リファクタリング」や「パターンへのリファクタリング」のような本を読むことを必須にします。
Shuvo Naserに同意します。それは大きなハードルなので、登るように扱います。 OOPを使用してアプリケーション全体を設計する方法を学ぶには時間がかかります。
- OOPを理解している人を特定し、チームリーダー、トレーナー、デザイナー、コードレビュー担当者などに近づけます。
- 既存のプロジェクトをトレーニングの参照として使用します。おそらく、＃1のチームがそのチームに属していた可能性があります。
- 既存のプロジェクトをリファクタリングします。これは、一部の人々が手続き型コードとOOコードとの間にブリッジを構築するのに役立ちます。基本から始めます。彼らは、これらの原則をいつ、どこで、なぜ使用するかを理解する必要があります。
- 彼らが何をしているのかを知っている人々とのデザインセッションに参加させてください。
- 設計ガイダンスを提供できる誰かと一緒に開発チームに配置し、プロジェクトがOOの原則に固執することを確認します（これを最初に行う理由は、開発を改善するためです）。 ）。
養子縁組がメリットを目にすることはめったにありません。複雑なデザインについて話しているので、 T.P.S。レポートのカバーシート は使用していません。
あなたはすでに良いアイデアを持っています
あなたが質問で概説するアイデアは素晴らしい音です。あなたが成功を収めていないのは大きな驚きです。それは2012年であり、オブジェクト指向の革命は、最先端から実践に移行して久しい。離職率が非常に低く、採用が非常に少ない場合を除いて、数十人から数百人の優れたソリッドオブジェクト指向のプログラマーを獲得するのに苦労するようです。
アジャイルかオブジェクト指向か？
TDDのようないくつかのアジャイルテクノロジーやいくつかの新しいコンセプトについて言及しているので、一部の管理チームがまだ積極的に戦っているものを受け入れないように人々に過大にしないでください。アジャイルを採用すると主張する人もいますが、彼らがそれについて話すとき、それは彼らが言うことを意味します。組織は、意思決定と適応を行うチームによって特徴付けられるのではなく、強力な階層的な契約スタイルのコントロールによって特徴付けられます。
しかし、オブジェクト指向に戻ります。あなたはオブジェクト指向の分析や設計については言及していませんし、どのプログラミング言語がどのオブジェクト指向プログラミング言語に道を譲っているのかはよくわかりません。私はUMLが多くのオブジェクト指向プログラマーの間で人気の問題を抱えていることを知っています。 OOADで徹底的に訓練されたので、自然言語を学びたい国の文化や歴史を学ぶようなものだと思います。たとえば、ギリシャ語を学びたいなら、アルファベット、語彙、文法を学ぶことができましたが、豊かな歴史や文化を無視してしまうと、多くを失ってしまいます。いずれにせよ、オブジェクト指向プログラミング言語についてすべてを学び、OOADについては何も学ばなければ、重要な機会が失われたと思います。
克服すべき問題？
橋が遠すぎますか？参加者の中で、週に1年間、年に1つの小さなことを学ぶように依頼すると、多くの変化が生じます。あなたが彼らに彼らが知っているすべてを変えるように頼むならば、それは少数によって歓迎されます、多くにとって難しい、そして他のものにとって不可能です。ソース管理などの一部の変更はローカライズされています。あなたは以前にそれをしなかったことから移行し、あなたは記憶の限界に重点を置かない訓練を受け、誰かが初めてあなたにそれを教えてくれました、そしてその後日々はとても簡単でした。
他の変更は広範です。たとえば、CをダンプしてJavaに切り替えるには、新しいIDE、新しいコンパイラ、新しい言語、新しいAPI、新しいものを採用するために、日々の大幅なトレーニング、セットアップ、大きな変更が必要です展開モデルなど。これは、パイロットプログラムや企業の再編に関連して最も頻繁に発生する種類のことです。
革命をリードしていますか？現在仕事をしている人々に報酬が与えられた歴史があり、会社が失敗する危険にさらされていないように見える場合、彼らの変化の動機は何ですか？あなたが方向性を示し、彼らが予測できない結果に責任を負わせたいと思っている部外者のように見える場合、それはすべてのリスクのようであり、報酬はないように見えるかもしれません。
ポジションパワーまたはアイデアリーダーシップ？多くの組織はポジションパワーに基づいて運営されています。マネージャー、セクションヘッド、ディレクター、および副社長からの目に見えるサポートが不足している場合、あなたは単なるアイデアリーダーです。一部の人々は、あるアイデアを持っているという危険な立場にあり、次のアイデアを楽しませることができません。あなたがそれらを告げる代わりにそれらを示すことができるならば、それは懐疑論者を静かにし、有能な同盟国に興味を向けるのに長い道のりを行くでしょう。
サポートのベースが小さすぎますか？それらの250人の間でトリアージを行い、それらを3つのカテゴリに分類します。受け入れる準備ができている、学ぶ意欲がある、および学ぶ意欲がない。変更を加えることに関心のない一部の人々に不満を抱く正当な理由があります。あなたもロープを押しているかもしれません。これは無駄な努力です。誰が変化をサポートするかについての感覚があれば、彼らが何に興味を持っているかを見つけることができます。
倫理的かつ実践的な選択が、助けを借りて成功できる中間層を助けることである医療トリアージとは異なり、あなたは自分の判断と好みに基づいてエネルギーと時間を投資することができます。あなたの成功のために、新しいアイデアを受け入れる準備ができているグループを育ててみませんか？最初は数少ないかもしれませんが、Snowballのように、支持者としてのあなたの可視性と信頼性は高まります。次のトレーニングがいつになるか、すぐに人々はあなたに尋ねます。
長期的には？チャンピオンを育成して物事を運ぶまでは、関係構築に時間を費やす必要があります。指導するチームと1か月以上滞在する必要がある場合があります。チームが自身のために改善されたプラクティスを所有するまで、あなたは単なるテクノロジーまたは方法論の警官です。メンタリングは何年もかかるプロセスです。あなたが重要だと思う、開発者がしたくないことはたくさんあります（特に、ユニットテストについて言及したと思います）。これがもたらす価値の共有ビジョンを構築するには、しばらく時間がかかる場合があります。私はかつて、品質で高い評価を得ているFortune 500企業でコードカバレッジツールを提唱したことがあるので、マネージャーと同僚の両方がそれにコミットすることに警戒していたため、これを経験から知っています。
エキスパートまたはグラスルーツ？メンタリングよりもはるかに速いのは、各チームメンバーからのグラスルーツサポートを促進することです。 10人のソフトウェアスペシャリストのチームから始めて、1人の人が常にプロセスに取り組むか、10人の人がプロセスの10％の時間を費やすかを選択した場合、2人目を選びます。草の根プロセスにより、擁護者はアプローチの影響を感じることができ、アプローチは、作業を所有するチームの問題を最適に解決するように調整できます。
自由の線が見えますか？「ベストプラクティス」を導入することの一部は、人々が共通の方法で物事を行うためにある程度の自由を放棄するようにすることです。多くの選択肢を開発者に任せる機会を探す場合、プログラマーの裁量をあきらめることはより口当たりが良くなります。彼らが選ぶものは、私たちが自由線と呼ぶことができるパーティションによって義務付けられているものから描かれています。組織、地域/サイト固有、チーム、および個人の慣行について、同様の正当な部門に必要な場合があります。
これはコメントであるべきだったのですが、どうやらまだコメントできないので、答えかもしれません。
この種のブレイクスルーでこれまでで最も重要なこと（それがOOPまたはその他のパラダイムシフト、たとえば関数型プログラミングなど、来年登場するものであれ）はコードを実行するレビューとピアプログラミング。一緒に、チームを支援して、チームを支援するさまざまなことを行います。
オブジェクト指向プログラミングへの私の個人的な道のりは、コードレビューを行うランダムなアサルトがモジュール化された方法で物事を行い、完全なC++ OOに行かずに状態を維持するために私を叱責したときに始まりました。コードのように考える
extern float clients_total;
void client_add(float sum);
void client_substract(float sum);
float client_get_total();
（clients_totalは完全に冗長である可能性があり、特に不十分な計画の例であることに注意してください）
そして、私がこれをやったのは、より多くの上級の同僚が画面を指して「同じことを2回以上書いたら、プロシージャまたは関数を使用して繰り返し呼び出すだけだ」と言ったときだけでした。
純粋な好奇心以外にそれを行う本当の動機がないので、話し合いや会議、およびオプションの実践は、彼らがパラダイムシフトを起こしたり、新しい実践を導入したりすることはありません。一方で、それを悪いことをしないようにしたり、一般的に単に嫌悪感を抱かせたりすると、採用率は非常に高くなります。
彼らがやっていることに適切なデザインを組み込むまで続く意地悪でクラス指向の開発に備えてください。あなたは少し死ぬことになるたくさんのものを見ますが、それが学習への道がどのように見えるかです。