コードの再利用とドキュメントを促進する方法は？[閉まっている]

約10人以上の開発者のチームリーダーとして、コードの再利用を促進したいと考えています。私たちは多くのコードを書きました。過去数年間、それらの多くは反復的です。現在の問題は、これらのコードの多くが他のコードの複製またはわずかなバリエーションにすぎないことです。

コードをコンポーネントに変換して将来のプロジェクトで再利用できるようにする方法についての動き（ディスカッション）を開始しましたが、問題は、新しい開発者やコンポーネントを知らない他の開発者が先に進むことを恐れていることです自分のことを書いてください。

とにかく、既存のコードを複製してそれを調整したり、独自に作成したりするのではなく、コンポーネントを再利用する/ドキュメントを改善する/基礎となるコンポーネントに貢献するように開発者に思い出させる方法はありますか？

誰もが使用できるように、コンポーネントを簡単に検出可能、簡単に使用できるようにする方法は？

すべての開発者は再利用可能なコンポーネントの利点を知っており、それらを使用したいと考えています。ただ、それらを発見可能にする方法がわからないだけです。また、開発者はコードを書いているとき、再利用可能なコードを書くべきだと知っていますが、そうする動機がありません。

適切なドキュメントが必要です。簡単に見つけてナビゲートできる必要があります。規律も必要です。再利用可能なコードライブラリで既にソリューションが提供されているが、開発者が（適切な理由なしに）代わりに独自のソリューションを使用することを選択した場合、ソリューションを元に戻し、既存のソリューションを使用するように伝える必要があります。

質問に対するEuphoricのコメントにも同意します。多くの場合、異なるプロジェクト間で何かを再利用することは不可能です（通常、すべてのCRUD操作は同じように見えますが、通常は再利用できません）。

すでに述べた要因「ドキュメント」、「見つけやすく、ナビゲートしやすい」、「規律」、「コードレビュー」に加えて

再利用可能なコードは

• 使いやすい（=ユニットテストなどの例が必要）
• 他のモジュールへの依存関係が多すぎることなく、
• ライブラリを使用するためにアプリケーションを更新する必要がないように、安定したAPIが必要です。

最後の2つの項目がなければ、望まない「コピー＆ペースト継承」を使用する方がはるかに簡単です。

実際にコードを再利用させる最良の方法は、動機付けだと思います。Euphoricが提案したように、再利用可能なコンポーネントを追加のプロジェクトに配置する場合は、多大な労力を費やしてください。私が仕事をしている場所では、構成可能な実行プランで一連の定義済みインターフェイスを実行し、いくつかのサービス（たとえば、DB_interactionの異なるクラス、FTPサービスなど）を提供するプロジェクトを作成しました。私たちの開発者は実際にマイクロフレームワークを使用したいので、プロジェクトは大成功です。なぜなら、同様のプロジェクトの定型コードを書くために多くの時間を節約できるからです。同じことは、リスト、文字列などのユーティリティライブラリにも当てはまりますが、この場合は、既存のものを1回使用する必要があります。（なぜウィールを再発明するのですか？）

結論：十分にテストされた再利用可能なコンポーネントの利点を開発者に体験させてください。しかし、私はAndrzej Bobakの答えにも同意します。多くのものは、似ているが同じではないため、再利用できません。

人々は単純なコンポーネント用の新しいコードを書くのが好きで、彼らは自分のやり方でそれをするのが好きだから、これは難しくなるだろう。既存のソリューションを活用して拡張することは、新しい要件で完全に新しい実装を作成するよりもはるかに困難です。前述したように、チームでコードレビュープロセスを開始して、新しいコンポーネントではなく既存のコンポーネントを使用/拡張する必要がある状況を特定するのに役立ちます。

また、人々が参照して必要なものを簡単に見つけることができるように、非常に優れた完全なドキュメントを維持する必要があります。ドキュメントが不完全または本物と同期していない場合、人々はそれを検索したり強化したりする動機はありません。

チームリーダーとして、同様のコンポーネントが存在するかどうかを確認してから、独自のドキュメントを作成してドキュメントを参照できるようにしてください。誰かが既存のコンポーネントを見逃した場合、コードレビュープロセスはそれをキャッチしますが、自分の実装にすでに10時間の開発を入れている場合はどうでしょうか？チームで適切な研究行動を実施することにより、これらの状況を回避する必要があります。

現在取り組んでいる大きなプロジェクトでこの問題に直面しました。過去数か月にわたって開発者のローテーションがありました。また、非常に大規模なコードベースであり、最初からプロジェクトに携わってきた人でも、そのすべてを知らないのです。

多くの場合、コードは適切に記述され、単一の責任で小さな部分に分割され、ドキュメントがありますが、行われたことを逃すのは非常に簡単です。一貫性のある命名規則は、IDEで何かを簡単に検索できるため、非常に役立ちます。ドキュメントは包括的かもしれませんが、長くなるにつれて、それを読むのは少し苦痛です。

私がしたことの1つは、私の意見では、状況を大幅に改善したことで、Lightning talksと呼ばれるものが導入されました。チームに知られるべきだと信じているコードを誰かが書くたびに、短い（通常5〜15分）プレゼンテーションが行われます。毎週1回これを実行しようとします。話題は、最近登場した新しい機能や複雑な問題の処理方法から、テスト/コーディングアプローチ、再利用可能なコンポーネント、アプリの基礎やそのリファクタリングについての話までさまざまです。

特定のテーマは、同様の全社的な講演で言及されています。知識の共有を促進する非常に効率的な方法であることがわかりました。短いプレゼンテーションを見て覚えて、追加のドキュメントを探す場所や助けを求める相手を知るのは、非常に長くまれに開催されるトレーニングセッションに参加したり、ドキュメントのカバーを読んで座ったりするよりもはるかに簡単です。

全社的な協議が実際に最初に行われました。プロジェクト固有の知識共有のためにこのアプローチを採用しましたが、うまく機能していると思います。

ペアプログラミングは、知識の循環を大幅に高速化します。

これは実際には2つの質問だと思います-両方に答えようとします。

1）コードベース内の重複コードをどのように削減しますか。
これを行うことの利点を思い出すのに役立ちます。ビジネスロジックの重複によるバグが少なくなり、維持する必要のあるコードが少なくなります。他の回答で述べたように、これを起こさないようにする最善の方法はコミュニケーションを介することです。知識を適切に広めるためには、コードレビューの責任を平等に共有する必要があるという追加の注意事項とともに、コードレビューを使用することを強くお勧めします。開発者が既存の有用なコードが存在する問題を誰かが解決しようとしていることを認識できるように、毎日のスタンドアップも使用する必要があります。また、知識の共有を増やし、プログラマーの規律を保つのに役立つため、コードのペアリングも検討する必要があります。

また、できれば同じ部屋で開発者をできるだけ近くに置くことをお勧めします。共有ホワイトボードとスペースがたくさんあります。その後、一緒に食事に出してください。開発者が「結合」するほど、お互いのコミュニケーションが向上します。

ウィキまたはドキュメントコードに類似したものを使用することをお勧めします。規律ある開発者がどのようにドキュメントを作成しようとしても、元のコードからはずれます。より効果的なアプローチは、例のスタイルテストによる仕様の使用です。これらは、コードの使用方法を明確にする方法でコードを文書化します。誰かが例を変更せずにコードを変更すると、テストは失敗します。

すでに大量の重複コードを含む大規模なコードベースがあるため、おそらくこれをリファクタリングする作業を行う必要があります。カットアンドペーストされていない重複コードを見つけるのは難しい場合があります。それではなく、変更履歴を分析することをお勧めします。同時に頻繁に変更されるファイルを探します。これは、実際の重複コードを示さず、とにかくクリーンアップする価値がある場合、カプセル化の問題を示している可能性があります。コードの変更に対してバグ修正履歴を分析できる場合は、修正が必要になることが多い特定のホットスポットを見つけることができます。これらのホットスポットを分析すると、おそらくそれらの多くは重複するビジネスロジックが原因であることがわかります。

2）他のプロジェクトで使用できる共有ウィジェット、コンポーネント、ライブラリなどの作成にどのように取り組むべきか。
この場合、ビジネスロジックをラップするのではなく、有用なフレームワークコードを共有する必要があります。共有コンポーネントのセットを作成および保守するコストが非常に大きくなる可能性があり、どのインスタンスで実行する価値があるかを予測するのが困難になる可能性があるため、これはトリッキーなバランスになります。ここで提案するアプローチは、3つのストライキルールです。同様のコードを2回記述することを心配する必要はありませんが、3回目は共有コンポーネントにリファクタリングする必要があります。この時点で、それが有用であることを合理的に確信することができ、コンポーネントのより広範な要件についての良い考えを持っています。ここでは明らかに、開発者間のコミュニケーションが不可欠です。

共有コンポーネントをできるだけ多くオープンソースにすることを検討してください。ビジネスロジックではないため、競合他社に大きな利点はありませんが、追加のレビュアーとメンテナーを無料で獲得できます。

IMMOキーはドキュメントやツールではありません。キーはCOMMUNICATIONです。10人以上の開発者はそれほど多くの人々ではなく、このコミュニケーションを改善するいくつかのこと：

• ペアプログラミング：2人で、プロジェクトの別の部分で既に解決された問題が再利用されることを2人のうちの1人が知っているより多くの変更があります。

• 集合的なコードの所有権：すべての人がシステムのさまざまな部分で作業するため、プロジェクトの別の部分で既に行われていることを知っている方がはるかに簡単です。私にとってこれはチームの基本的なプラクティスです。

• 水平プロジェクトの作業に時間を与えます。たとえば、月に1〜2日で、この時間の開発者は、会社のプロジェクトに適用できる独自のプロジェクトで作業できます。このようにして、開発者は再利用可能なライブラリとコンポーネントを作成できます。時にはそのコードは既に存在しますが、いくらかのクリーニングとドキュメントが必要です。

• 話し合いやワークショップを行う：開発者の話し合いやワークショップのための時間を確保します。開発者は自分のライブラリについて話すことができます。

ドキュメンテーションはおそらく必要ですが、それはあなたが必要とする本物のほんの小さな部分です：チーム内のコミュニケーションを改善します。

Luceneなどのローカル検索エンジン（またはソースコードに固有の何か）を使用してコードのインデックスを作成するのはどうですか？誰かが（たとえば）新しいクラスまたは新しい関数の作成を開始すると、自分のコードを作成する前に（内部ポリシーとして）いくつかの検索を試行する必要があります。これにより、やりすぎを避けることができ、適切なコメント、メソッド、クラス名に頼ることができます。私はインターネット上で利用可能なオープンソースの検索エンジンでこれをやっていることに気づきました：メソッドやクラスの名前や名前を誰が書いたのかわかりませんが、いくつかの検索や同義語で私は常に必要なものを見つけます。

開発者がシームレスな方法でそれを行うのに役立つツールが必要です。開発者が、コードスニペットを再利用することで（コードの作成だけでなく、明らかに品質保証、統合などのために）どれだけの時間を節約できるかを発見した場合、使いやすく効率的なツールが役立ちます。開発環境に直接統合されているため、このようなツールを採用するようにPRAYされます！

多くの場合、コードの再利用のためにライブラリを実現しても、大きな利点が得られないことに注意してください（それらは非常に強力で大きくなる傾向があります...）。代わりに、単純なスニペット、つまり特定のタスクを効果的に解決する数行のコードに焦点を当てたいと思います。

このようにして、プログラマーが直接使用できる実際の例を提供することで、ガイドラインとベストプラクティスの使用を強制できます。

スニペット管理用のツールがいくつかありますが、これをお勧めします：http : //www.snip2code.com。

（免責事項：私はSnip2Codeの創立者の1人であり、共同創立者と一緒に-少し前に同じ考え方でした：これが、このプロジェクトを開始することに決めた理由です。上記、つまり、スニペットをチーム間で共有する、Visual Studio、Eclipse、IntelliJ、Notepad ++などのIDEに統合する