源核心存储库和便签
最近出现了一个有趣的问题，我一直在思考实现这个问题的“最佳”方式（对于给定的“最佳”值）。
本质上，它是针对源代码的跟踪注释之一。标记此问题的示例是在 SLA 中实时修复问题，以及如何最好地实现这一点。在不讨论所有细节的情况下，归根结底是找到一个在多个地方使用的函数，该函数可能有也可能没有错误，但问题仅在一个位置报告。
满足 SLA 的修复方法只是在报告问题的位置添加检查，而不是调整通用代码并测试涉及该功能的所有内容。
有趣的问题是上游。 “正确”的方法是返回并检查原始函数，验证它在调用的所有地方都是正确的，然后如果确定库函数是错误的，则“正确”地进行更改。
问题是这需要时间，因此上游可能只是采取解决方法等。但是，如果问题在调用相同库函数的另一个位置再次发生（例如六个月后），则没有一种简单的方法可以链接这两个问题一起。您可以搜索错误跟踪数据库，但这并不能保证有帮助 - 这取决于是否添加了注释，说明“此库函数需要更彻底的检查，但现在没有时间调查”。
所以问题是这样的：在一个大型开发团队中（30 人以上，分为支持团队和持续开发团队），您使用什么方法来管理（什么是有效的）针对源代码的“便笺”，简短在可疑函数的源代码中添加注释说“这可能有点狡猾”？
提交评论的问题是过程之一：更改就是更改，因此提交零更改更改（即仅添加注释的更改）并不理想；开发人员甚至可能会犯错误，即使添加注释（按杂散键或其他东西），因此（IMO）最好仅在进行实际更改的地方提交。
现在 wiki 可用于跟踪每个文件的注释，但我们至少有四个分支和不超过几百个文件（SQL 对象、源代码、XML 文件等），因此 wiki 将变得相当难以管理迅速地。
如果 SCM 能够支持这种情况，那就太好了 - 针对文件的元数据位只是注释，但不添加到 SCM 的版本历史记录 - 可以在执行（例如）时显示svn update，或者手动查看。
可能已经有了解决方案——那么如何管理这种类型的知识共享呢？
An interesting problem occured recently, and I've been thinking of the "best" way (for a given value of "best") to implement this.
In essence, it's one of tracking notes against source code. The example that flagged this was getting a problem fixed in live within SLAs, and how to best achieve this. Without going into all the details, it came down to finding a function that's used in a number of places which may or may not be buggy, yet the problem was being reporting only in a single location.
The fix to meet the SLAs was simply to add a check into the location where the problem was reported, rather than tweaking the common code and having to test everything that touches that function.
The interesting issue is then for upstreaming. The "correct" method would then be to go back and check the original function, validate it's correct for everywhere it's called and then make the change "properly" if its determined the library function is wrong.
The problem is this takes time, so upstreaming may simply take the workaround, etc. However if the problem occurs again (say six months later) in another location calling the same library function, there isn't an easy way to link the two problems together. You can search the bug tracking database, but this isn't guranteed to help - it depends if a note's been added saying something along the lines of "this library function needs more thorough checking, but no time to investigate now".
So the question is this: within a large team of developers (30 plus, split into teams of both support and on-going development), what methods do you use to manage (what are effectively) "sticky notes" against source code, short of adding a comment to the suspicious function's source code saying "this might be a bit dodgy"?
The problem with the commiting a comment is one of process: a change is a change, so committing a zero-change change (i.e., one where just comments are added) is not ideal; developers can make mistakes even adding a comment (hit a stray key or something) so it's always (IMO) better to commit only where actual changes are made.
Now a wiki could be used to track per-file notes, but we've got a minimum of four branches and inexcess of a few hundred files (SQL objects, source code, XML files, etc), so a wiki will get unmangable quite quickly.
This is the sort of thing that it would be nice if SCM's could support - bits of metadata against files that are simply notes, but don't add to the SCM's version history - that can be displayed when doing (say) an svn update, or manually viewed.
There may already be solutions out there -- so how do you manage this type of knowledge sharing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，我们现在使用这种方法：在签入 SVN 的每个文件夹中，我们创建了一个
.url快捷方式（这是我们正在开发的 Windows），链接到我们的页面关于该文件夹的开发 wiki。因此，我们可以自由更新 Wiki 信息，并且在签出/更新时，每个人都会获得一个链接，该链接会将他们带到该文件夹/模块的相应 Wiki 页面。我们发起它的时间不长，所以我们必须看看它的长期效果如何——但它比我们以前的更好（即什么都没有:-)）。
Well we're now using this method: in each folder checked into SVN, we've created a
.urlshortcut (this is Windows we're dev'ing on) that links to a page on our development wiki about that folder. Thus we can update the Wiki info freely, and on checkout/update everyone gets a link that will take them to the appropriate Wiki page for that folder/module.We've not long instigated it so we'll have to see how well it works long term -- but it's better than what we had before (i.e., nothing :-) ).