我称之为flash会议,但也许还有另一个更合适的名称。
有一段时间(有时更频繁),我的一位开发人员来到我的办公桌,询问他应该如何编写特定的代码。
代码本身并不是直接回答某个功能,这意味着它不是在需求期间设计的,而是功能内部行为的一部分。
讨论了5分钟后,我们找到了解决方案。我的问题是我应该如何记录这个讨论,以便将来当别人看到那段代码时,那个人会理解为什么它是以这种方式开发的而不是那种方式?
我是否应该要求开发人员直接在代码中编写讨论摘要,或者我应该打开Word模板并将讨论写下来,就好像是2小时的会议一样?有什么建议吗?
答案 0 :(得分:3)
这是开发维基真正得到回报的地方。您只需为Flash会议创建一个Wiki页面,并将其链接到相关的其他页面。写下讨论的内容,然后让其他程序员检查并根据需要进行更新。有一个地方可以记录所有内容,您可以将其链接到您需要的任何其他内容,例如SVN urls到代码分支或链接到其他相关人员的wiki页面,正在处理的代码库。稍后,如果您需要查找,您还可以搜索专门放入维基页面的关键字,以便日后查找。
答案 1 :(得分:0)
我会用代码来做,只要它不是一篇文章。一段简短的段落,你已经完成了。
除了查看一段代码然后不得不去寻找一个可以解释它的word文档之外,没有什么比打扰我更困扰我了。
只要它的一个小功能相关讨论。很有可能,大型设计应该进入自己的元文档。答案 2 :(得分:0)
历史信息可以进入版本控制签入评论
在可以简单捕获的信息中,然后一个选项是开发人员在他/她将文件检入版本控制时描述评论中的讨论。如果您不相信开发人员在有问题的情况下查看源代码管理,请在签入之前在源代码的注释中添加“请参阅mm / dd / yy上的此文件的签名注释”。