最近、興味深い問題が発生しました。私は、これを実装するための「最良の」方法（「最良」の特定の値に対して）を考えてきました。
本質的に、これはソースコードに対するメモの追跡の1つです。これにフラグを立てた例は、SLA内のライブで問題を修正することと、これを最もよく達成する方法でした。詳細に立ち入ることなく、バグがあるかどうかわからない多くの場所で使用されている関数を見つけることになりましたが、問題は1つの場所でのみ報告されていました。
SLAを満たすための修正は、共通のコードを微調整してその機能に関係するすべてのものをテストするのではなく、問題が報告された場所にチェックを追加することでした。
興味深い問題は、アップストリームです。「正しい」方法は、元の関数に戻ってチェックし、呼び出されたすべての場所で正しいことを検証し、ライブラリ関数が間違っていると判断した場合は「適切に」変更することです。
問題は、これには時間がかかるため、アップストリームで回避策などが必要になる場合があります。ただし、同じライブラリ関数を呼び出す別の場所で問題が再び発生した場合（たとえば、6か月後）、2つの問題をリンクする簡単な方法はありません。一緒。バグ追跡データベースを検索することはできますが、これが役立つことは保証されていません。「このライブラリ関数はより徹底的なチェックが必要ですが、今すぐ調査する時間はありません」という行に沿って何かを示すメモが追加されているかどうかによって異なります。
だから問題はこれです：開発者の大規模なチーム（30人以上、サポートと進行中の開発の両方のチームに分かれています）内で、ソースコードに対する「付箋」を管理するためにどのような方法を使用しますか？疑わしい関数のソースコードに「これは少し危険かもしれない」というコメントを追加するのですか？
コメントのコミットに関する問題はプロセスの1つです。変更は変更であるため、変更なしの変更（つまり、コメントのみが追加される変更）をコミットすることは理想的ではありません。開発者はコメントを追加する（迷いキーなどを押す）ことでさえ間違いを犯す可能性があるため、実際の変更が行われた場所でのみコミットする方が常に（IMO）優れています。
これで、Wikiを使用してファイルごとのメモを追跡できますが、少なくとも4つのブランチがあり、数百のファイル（SQLオブジェクト、ソースコード、XMLファイルなど）が不足しているため、Wikiは非常に不安定になります。早く。
これは、SCMがサポートできるといいと思います-単なるメモであるが、SCMのバージョン履歴には追加されないファイルに対するメタデータのビット-（たとえば）を実行するときsvn update、または手動で表示することができます表示されました。
すでに解決策があるかもしれませんが、この種の知識共有をどのように管理しますか？