チームが作成したクラスと関数をどのように追跡しますか？
コードの作業をしているとき、チームメイトがするのと同じ課題の多くに直面し、いくつかの有用な関数とクラスを作成しました。良いコミュニケーションがあれば、誰かがまとめたすばらしいことについて聞いて、6か月後に必要になったときにそれを覚えてその関数を呼び出すことで、時間を節約できます。私がそれを覚えていない場合、またはそれについてまったく知らなかった場合は、おそらくホイールを再発明します。
これらの種類のものを文書化する特別な習慣はありますか？どのようにして見つけやすくするのですか？
チームにそのようなドキュメントがない場合、ホイールが既に存在するかどうかをどのように確認しますか？
編集：
これまでの回答の1つを除いてすべてが理想的な状況を扱っているので、それらの解決策をまとめてみましょう。ウィキ、スタンドアップミーティングなど。これらはすべてすばらしいことですが、ドキュメントを作成してミーティングに参加し、メモを取ってすべてを覚える時間（およびスキル）を持つプログラマーに依存しています。
これまでで最も人気のある回答（Calebの回答）は、ドキュメント作成や会議ができないプログラマが使用できる唯一の回答であり、1つだけのことを行います。それはプログラミングです。プログラミングはプログラマーが行うことであり、そうです。優れたプログラマーは、ドキュメントや単体テストなどを作成できますが、それに直面しましょう-私たちのほとんどは、ドキュメント化よりもプログラミングを好みます。彼の解決策は、プログラマが再利用可能なコードを認識し、それを独自のクラスまたはリポジトリなどに引き出すことであり、それが分離されているという事実によって、それは見つけやすくなり、それを使用するための学習曲線を容易にします...そしてこれはプログラミングによって達成されました。
ある意味、私は次のように見ています。3つの関数を書いたところ、他の誰かがそれらについて知っているべきだと思いました。私はそれらを文書化し、それらを書き、会議で発表するなどすることができました-私にはできますが、それは私の強みではありません-または....私はそれらをクラスに抽出し、よく名前を付け、それらをブラックボックス、および他のクラスファイルが行く場所に貼り付けます。それからそれを発表する短い電子メールは簡単です。他の開発者はコードをスキャンして、完全に理解していないコードで使用される分離された関数よりもコードを理解できます-そのコンテキストは削除されます。
これは、適切な名前の付いたメソッドを備えた適切な名前のクラスファイルのセットを用意することが、適切なプログラミングによって実現される優れたソリューションであることを意味するため、これが好きです。会議を必要とせず、詳細なドキュメントの必要性を和らげます。
この脈絡にこれ以上のアイデアはありますか...孤立した、時間に追われている開発者のために？
ライブラリ。フレームワーク。バージョン管理。
再利用可能なコードがある場合、最後に必要なのは、さまざまなチームメンバーがソースコードをプロジェクトにコピーすることです。そうした場合、可能性としては、ここで少し変更し、少し微調整することです。すぐに、すべてが同じ名前で、それぞれが少し異なる動作をする多数の関数またはメソッドが得られます。または、おそらくより可能性が高いですが、元の作成者はバグの修正、効率の向上、または機能の追加のためにコードを改良し続けますが、コピーされたコードは更新されません。その技術的な名前は巨大な異常な混乱です。
正しい解決策は、最初にビルドしたプロジェクトから再利用可能なものを引き出し、それを独自のバージョン管理リポジトリのライブラリまたはフレームワークに配置することです。これにより、見つけやすくなりますが、それを使用している可能性のある他のすべてのプロジェクトを考慮せずに変更を加えることはできなくなります。いくつかの異なるライブラリを検討することもできます。1つは、変更される可能性が低く、十分にテストされたコード用、安定しているように見えるが十分にテストおよびレビューされていないもの用、提案された追加用です。
そのための1つのアプローチは、その目的のためにWikiを設定し、どの再利用可能なコンポーネントを持っているか、問題をどのように解決したかなどの高レベルのドキュメントを書くことです。
難しいのは、チームの全員にそのWikiを常に維持してもらうことです。ただし、他の種類のドキュメントでも同じ問題が発生します。
一部のコードは、再利用可能なライブラリに配置するのに十分な場合もあります。これにより、後でコードを簡単に見つけられるようになります。
700人の従業員がいる会社で、2〜20人のチームで、ここに私の経験があります。
チームレベルで
「スタンドアップミーティング」を毎日15〜20分ほど開催しています。 「昨日この機能を実行したので、とても大変です」などの一般的な知識をすばやく共有できます。
プロジェクトごとにwikiもあります。つまり、組み込みのカスタムクラス/関数など、プロジェクトで行われたことに関する（技術的な）情報を共有できます。
代理店レベル
代理店レベルでは、4つのツールがあります。
- 別のウィキ。主にハードウェアなどに関する情報を提供するために存在しますが、会社レベルに置く前にレビューする技術情報を共有するために使用することもあります。
- 毎週の会議。彼らは主に各チーム/プロジェクトの進捗状況を知ることですが、私たちは主に技術愛好家なので、クールなものを育てることができます。
- メーリングリスト。代理店の全員にメールを送ります。クールなもの、楽しいもの、便利なものがたくさんあります。
- VCSリポジトリ。各エージェンシーには、私たちが小さなプロジェクト、主に異なるプロジェクトで使用するモジュールがある個人リポジトリがあります。
企業レベルで
会社レベルでは、より組織化されています。
「代理店レベル」のwikiは、実際には会社のwikiの一部です。
そして、wikiはテクノロジーに基づいて分割されます。したがって、誰でもそれを改善し、それを検索し、基本的にwikiに命を吹き込むことができます。
購読可能なメーリングリストもあります。代理店の誰もがサブスクライブでき、ほとんどの人は少なくとも1つまたは2つのテクノロジーをフォローしています。実際、ほとんどの人はそのうちの5〜10個をフォローしています。
そしてもちろんVCSは最高のコード共有システムです。
結論
要約すると、明確な解決策はありません。知識の共有は常に大きな問題であり、おそらく残るでしょう。 ナレッジベース を作成するためのソリューションはたくさんあり、おそらくあなたの要求に合うでしょう。ただし、現在のソリューションは必ずしも非常にスマートではないため、 一部の人々 はさらに優れたKBを取得しようとしています。
まあ、それはすべてコミュニケーションに帰着します。
Wikiはすばらしいので、必ずインストールして使用してください。優れた内部プログラマーのイントラネットは、人々がそれを読んで更新すれば良いので、そこでは人々の問題について話しているのです。全員が集まり、どのような作業が行われているかの概要を説明する、毎週の「チーム更新」会議を提案できます。技術リーダーは（少なくとも！）集まり、各チームが何をしているかについて話し合う必要があります。 「ブラウンバッグ」の非公式セッションは素晴らしいです。昼食時にそれらをスケジュールし、人々に話してもらいます。
また、コードの共有、パッケージ化、バージョン管理、配布方法も必要です。非常によく管理されたソースコードリポジトリがあり、「共通」フォルダーとプロジェクトフォルダーに適切に配置されていると、作業は簡単になります。
このようなことが何も行われていない場合は、上司と一緒に育て、それが会社にどのように役立つかを説明し、次の方法を提案してください:)
コードレビューセッションが役立ちます。チームが定期的に会議を開いて開発されたものについて話し合う場合、ソリューションを思いついた人がその使用方法を他の人に示すことができます。誰かが固執している点を指摘した場合、他のチームメンバーは、既存のコンポーネントの再利用を増やすアプローチを提案できます。
そのようなものを処理するための最良の方法は、いくつかの単純な規則を持つリポジトリー構造を用意することです。これにより、プログラマーとして、関数doXYZがあるかどうか、おおよそその関数を探す必要がある場所がわかります。名前空間、ディレクトリ、モジュール、プラグイン、パッケージなど、どのようなものを使用する場合でも、コードはモジュール化して、同じことをしたり、同じデータソースにアクセスしたりする機能がほとんど同じ場所にあるようにする必要があります。
理想的には、著者以外に少なくとも1人の人物が各チェックインでコードレビューを行う必要があります。コードレビュープロセスは、チェックインされる多くの重複するメソッドの問題を軽減するのに役立ちます。もちろん、レビュー担当者の知識に制約されます。
TL; DR：すべてのチェックインのコードレビュー。