最近发生了一个有趣的问题,我一直在想实现这个问题的“最佳”方法(对于给定的“最佳”值)。
实际上,它是对源代码的跟踪注释之一。标记这一点的示例是在sla中实时解决问题,以及如何最好地实现这一点。如果不深入了解所有细节,我们可以找到一个在许多地方使用的函数,这些地方可能有问题,也可能没有问题,但问题是只在一个位置报告。
满足sla的修复方法只是在报告问题的位置添加一个检查,而不是调整公共代码,并且必须测试与该函数相关的所有内容。
有意思的问题是叛逆。“正确的”方法是返回并检查原始函数,验证它在调用的所有地方都是正确的,然后在确定库函数是错误的情况下“正确地”进行更改。
问题是这需要时间,因此向上处理可能只需要解决方法等。但是,如果在调用同一库函数的另一个位置再次出现问题(例如六个月后),则无法轻松地将这两个问题链接在一起。您可以搜索bug跟踪数据库,但这并不能提供帮助—这取决于是否添加了一个注释,说明了“这个库函数需要更彻底的检查,但现在没有时间进行调查”这样的内容。
所以问题是:在一个庞大的开发团队中(30多人,分成支持团队和正在进行的开发团队),除了在可疑函数的源代码中添加一个注释“th is”之外,您使用什么方法来管理(什么是有效的)针对源代码的“sticknotes”是不是有点狡猾?
提交注释的问题在于过程:更改是一个更改,因此提交零更改(即只添加注释的更改)是不理想的;开发人员甚至添加注释(点击一个散乱的键或其他东西)都可能出错,因此提交总是(imo)更好。
只有
进行实际更改的位置。
现在一个wiki可以用来跟踪每个文件的注释,但是我们至少有四个分支,不能访问几百个文件(sql对象、源代码、xml文件等),所以wiki很快就会变得不可连接。
这是一种如果scm可以支持的事情-对文件的元数据位,这些文件只是注释,但不添加到scm的版本历史记录-可以在执行(比如)一个
svn update
,或手动查看。
可能已经有了解决方案——那么您如何管理这种类型的知识共享呢?
