チームが作成したクラスと機能をどのように追跡しますか？

コードで作業するとき、チームメートと同じ課題の多くに直面します。また、有用な関数とクラスをいくつか作成しました。良好なコミュニケーションがあれば、誰かがまとめた素晴らしいことを聞くことができます。6か月後に必要になったときにそれを覚えて、その関数を呼び出して時間を節約できます。覚えていない場合、またはまったく知らない場合は、おそらく車輪を再発明します。

これらの種類のものを文書化する特定の慣行はありますか？どのようにしてそれらを見つけやすくしますか？

チームにそのようなドキュメントがない場合、ホイールがすでに存在するかどうかをどのように確認しますか？

編集：

これまでのところ、答えの1つを除くすべてが理想的な状況を扱っているので、これらのソリューションを要約します。ドキュメントとコミュニケーション。wiki、スタンドアップミーティングなどはすべて素晴らしいものですが、ドキュメントを作成し、ミーティングに参加し、メモを取り、すべてを覚える時間（およびスキル）を持つプログラマーに依存しています。

これまでで最も人気のある回答（Calebの回答）は、文書化や会議ができないプログラマーが使用できる唯一の回答であり、プログラミングを1つだけ行います。プログラミングはプログラマーが行うことであり、もちろん、優れたプログラマーはドキュメント、ユニットテストなどを作成できますが、それに直面しましょう-私たちのほとんどはプログラミングよりもドキュメントを好みます。彼の解決策は、プログラマが再利用可能なコードを認識し、それを独自のクラスまたはリポジトリなどに引き出し、それが分離されているという事実によって、それが見つけやすくなり、それを使用するための学習曲線を容易にすることです... 。そして、これはプログラミングによって達成されました。

ある意味では、このように見えます。3つの関数を書いたばかりで、他の誰かがそれらについて知っておく必要があると思います。私はそれらを文書化し、書き、会議で発表することができます-私はできますが、それは私の強さではありません-または....私はそれらをクラスに抽出し、それをうまく命名し、それらをブラックボックス、および他のクラスファイルが行く場所に貼り付けます。その後、それを発表する短いメールは簡単です。他の開発者はコードをスキャンして、完全に理解していないコードで使用されている分離された関数よりもよく理解できます。そのコンテキストは削除されます。

これは、適切な名前のメソッドを備えた適切な名前のクラスファイルのセットを持つことは、優れたプログラミングによって達成される優れたソリューションであることを意味するため、これが気に入っています。会議を必要とせず、詳細な文書の必要性を和らげます。

この流れに他にもアイデアはありますか？

ライブラリ。フレームワーク。バージョン管理。

再利用可能なコードがある場合、最後に望むのは、さまざまなチームメンバーがソースコードをプロジェクトにコピーすることです。もしそうすれば、ここで少し変更して少し調整する可能性があり、すぐにすべてが同じ名前を持っているがそれぞれが少し異なる働きをする数十の関数やメソッドを手に入れることができます。または、おそらく、元の作者がコードの改良を続けてバグを修正したり、より効率的にしたり、機能を追加したりしますが、コピーされたコードは更新されません。そのための技術的な名前は巨大な奇妙な混乱です。

適切な解決策は、最初に構築したプロジェクトから再利用可能なものを引き出し、独自のバージョン管理リポジトリのライブラリまたはフレームワークに配置することです。これにより、見つけやすくなりますが、それを使用している可能性のある他のすべてのプロジェクトを考慮せずに変更を加えることもできなくなります。いくつかの異なるライブラリを用意することを検討してください。1つは変更されそうにない十分にテストされたコード用、もう1つは安定しているように見えるが完全にはテストおよびレビューされていないもの用、1つは提案された追加用です。

そのための1つのアプローチは、その目的のためにWikiを設定し、再利用可能なコンポーネント、問題の解決方法などに関する高レベルのドキュメントを作成することです。

難しいのは、チームの全員がそのWikiを常に維持できるようにすることです。しかし、他の種類のドキュメントでも同じ問題が発生します。

一部のコードは、再利用可能なライブラリに入れるのに十分な場合もあります。これにより、後で再びコードを見つけやすくなります。

2〜20人のさまざまなチーム内で、700人の従業員がいる会社にいることが、私の経験です。

チームレベルで

毎日15〜20分間「スタンドアップミーティング」があります。「昨日この機能を実行しましたが、非常に難しい」などの一般的な知識をすばやく共有できます。

プロジェクトごとにwikiもあります。つまり、組み込みのカスタムクラス/関数など、プロジェクトで行われていることに関する（技術的な）情報を共有できます。

代理店レベルで

代理店レベルでは、4つのツールがあります。

• 別のウィキ。それは主にハードウェアやものに関する情報を提供するためにありますが、会社レベルで公開する前にレビューする技術情報を共有するために使用することがあります。
• 毎週の会議。彼らは主に各チーム/プロジェクトの進捗状況を知っていますが、私たちはほとんどが技術愛好家なので、クールなものを育てることができます。
• メーリングリスト。代理店の全員と郵送します。たくさんのクールなもの/楽しいもの/役に立つものがそこを通り抜けます。
• VCSリポジトリ。各機関には個人用リポジトリがあり、そこには小さなプロジェクトがあり、ほとんどが異なるプロジェクトで使用するモジュールです。

会社レベルで

企業レベルでは、より組織化されています。

「エージェンシーレベル」wikiは、実際には会社のwikiの一部です。

そして、ウィキはテクノロジーに基づいて分割されます。したがって、誰でもそれを改善し、それを検索し、基本的にウィキに命を吹き込むことができます。

購読できるメーリングリストもあります。代理店の誰でも購読でき、ほとんどの人は少なくとも1つまたは2つの技術を使用しています。実際、ほとんどの人は5〜10の技術を使用しています。

そして、VCSはもちろん最高のコード共有システムです。

結論

要約すると、明確な解決策はありません。知識の共有は常に大きな問題であり、おそらく残るでしょう。知識ベースを作成するための解決策はたくさんありますが、おそらくあなたの請求に合うでしょう。ただし、現在のソリューションは必ずしも非常にスマートではないため、一部の人々はさらに良いKBを取得しようとしています。

まあ、それはすべてコミュニケーションに帰着します。

Wikiは素晴らしいので、必ずインストールして使用してください。優れた内部プログラマーのイントラネットは、人々がそれを読んで更新すれば良いので、実際には人々の問題について話しているのです。毎週開催される「チームアップデート」ミーティングを提案し、全員が集まり、進行中の作業の概要を説明することができます。技術リーダーは（少なくとも！）集まって、各チームが何をしているかについてチャットする必要があります。「ブラウンバッグ」非公式セッションは素晴らしく、昼食時にスケジュールを立て、人々に話をさせます。

また、コードを共有し、パッケージ化し、バージョン管理し、配布する方法も必要です。よく管理されたソースコードリポジトリがあり、「共通」フォルダーとプロジェクトフォルダーにうまく配置されていれば、物事は簡単になります。

このようなことを行っていない場合は、上司に報告し、会社にどのように役立つかを説明し、今後の方法を提案してください:)

コードレビューセッションが役立ちます。チームが定期的に会議を開いて、何が開発されたかを話し合うと、ソリューションを思いついた人が他の人にその使用方法を示すことができます。誰かが固執している点を取り上げた場合、他のチームメンバーは既存のコンポーネントの再利用を増やすアプローチを提案できます。

そのようなものを処理する最良の方法は、プログラマーとして関数があるかどうかを知るために、いくつかの簡単な規則を持つリポジトリー構造を持つdoXYZことです。名前空間、ディレクトリ、モジュール、プラグイン、パッケージなどを使用しているかどうかに関係なく、コードはモジュール化して、同じことを行う関数や同じデータソースにアクセスする関数がほぼ同じ場所にあるようにします。

理想的には、各チェックインでコードレビューを行う著者以外に、少なくとも1人の他の人がいるべきです。コードレビュープロセスは、多くの重複したメソッドがチェックインされる問題を軽減するのに役立ちます。もちろん、レビュー担当者の知識に制約されます。

TL; DR：すべてのチェックインのコードレビュー。