最近发生了一个有趣的问题，我一直在考虑实现这一点的“最佳”方式（对于给定的“最佳”值）。
从本质上讲，它是针对源代码的跟踪记录之一。标记此问题的示例是在 SLA 中实时修复问题，以及如何最好地实现这一点。在不深入所有细节的情况下，它归结为找到一个在许多地方使用的功能，这些地方可能有问题也可能没有问题，但问题只在一个位置上报告。
满足 SLA 的修复只是简单地在报告问题的位置添加检查，而不是调整通用代码并且必须测试与该功能相关的所有内容。
有趣的问题是上游。然后“正确”的方法是返回并检查原始函数，验证它在任何地方调用的正确性，然后如果确定库函数错误，则“正确”进行更改。
问题是这需要时间，因此上游可能只是采取解决方法等。但是，如果问题再次发生（比如六个月后）在另一个调用相同库函数的位置，则没有一种简单的方法可以将这两个问题联系起来一起。您可以搜索错误跟踪数据库，但这并不能保证有帮助 - 这取决于是否添加了注释，说明“此库函数需要更彻底的检查，但现在没有时间调查”。
所以问题是这样的：在一个庞大的开发团队中（30 多名，分为支持团队和持续开发团队），你使用什么方法来管理（什么是有效的）针对源代码的“便签”，简短在可疑函数的源代码中添加注释说“这可能有点狡猾”？
提交评论的问题是过程之一：更改就是更改，因此提交零更改更改（即仅添加注释的更改）并不理想；开发人员甚至可能会犯错误，甚至添加评论（点击杂散键或其他东西）所以总是（IMO）更好地只在进行实际更改的地方提交。
现在可以使用 wiki 来跟踪每个文件的注释，但我们至少有四个分支和数百个文件（SQL 对象、源代码、XML 文件等），因此 wiki 将变得非常难以处理迅速地。
如果 SCM 可以支持这种事情，那就太好了 - 元数据位针对只是注释的文件，但不添加到 SCM 的版本历史 - 可以在执行（比如说）时显示svn update，或者手动看过。
可能已经有解决方案了——那么您如何管理这种类型的知识共享？