6
オブジェクト指向のプラクティスを広める方法に関するヒント[非公開]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 4年前に閉鎖されました。 私は約250人の開発者がいる中規模の会社で働いています。残念ながら、それらの多くは手続き型の考え方に固執しており、実際にはアプリケーションに豊富なロジックが含まれている場合でも、一部のチームは大きなトランザクションスクリプトアプリケーションを常に提供しています。また、設計の依存関係を管理できず、最終的に別の多数のサービスに依存するサービスになります（クリーンな例 Big Ball of Mudの）。 私の質問は、この種の知識を広める方法を提案できますか？ 問題の表面は、これらのアプリケーションのアーキテクチャと設計が貧弱であることです。別の問題は、あらゆる種類のテストの作成に反対する開発者がいることです。 これを変更するために私がやっていること（しかし、私は失敗しているか、変更が小さすぎます） 設計原則（SOLID、クリーンコードなど）に関するプレゼンテーションの実行。 TDDおよびBDDに関するワークショップ。 コーチングチーム（これには、ソナー、findbugs、jdependおよびその他のツールの使用が含まれます）。 IDEとリファクタリングの話。 私が将来することを考えているいくつかのこと（しかし、それらは良くないかもしれないと心配です） オブジェクト指向のエバンジェリストのチームを編成し、オブジェクト指向の考え方を異なるチームに広めます（これらの人々は、数か月ごとにチームを変更する必要があります）。 設計を批判し、改善を提案するために、設計レビューセッションを実行します（時間の制約のために改善が行われない場合でも、これは役立つと思います） 。 私がコーチするチームで見つけたのは、チームを離れるとすぐに、古いチームに戻るということです。私は彼らと一緒に多くの時間を費やさないことを知っています。通常は1ヶ月です。だから私がやっていることは何でも、それは固執しません。 この質問にフラストレーションがたまっているのは残念ですが、これを書く別の方法は、気が散るまで壁に頭をぶつけることでした。