我们可以建议哪种代码审查策略最适合我们管理的项目？

解决方案

回答

无法抗拒：

替代文字http://www.osnews.com/images/comics/wtfm.jpg

回答

很大程度上取决于团队构成。就个人而言，我成功地进行了配对编程并每隔几个小时切换一次配对。如果做得正确，这可能比代码审查更有效。

另一种方法是将几个团队成员与一台投影仪放在一起，并在每个星期五或者其他某个时间范围内检查代码。

回答

通常，尝试拥有而不是不拥有它们。...每次我进行代码审查时，我几乎总是得到一些非常好的建议，以一种好的方式来调整某些内容，或者删除一些我没有看到的重复项，甚至对我的环境使用方式进行了一些优化(shell，IDE，Emacs等)。

一位同事曾经建议我们每周一次在一个房间里聚会，并简要回顾一下我们所做的主要更改。我想这也会有所帮助，但是我无法想象它会取代主要签到的一对一代码审查(即使简短的审查也会被证明是有益的)。

回答

这是我们在工作中使用的代码检查策略：http://www.divmod.org/trac/wiki/UltimateQualityDevelopmentSystem

简短版：变更是在分支机构中开发的，在合并之前要对其进行检查(并检查是否通过了测试)。如果合并的代码导致回归，则将其从主干恢复。

回答

仅检查基本代码中的代码更改，并使用一些免费的文件比较工具。

回答

我们组织中有5位不同级别的开发人员；因此，代码审查本身本身有时更是一种教学工具，而不是审查。但是，通过在开发人员之间共享代码(以及通过勤奋地使用源代码控制)，代码质量得到了显着提高。

我要说的是，使开发人员一起工作并互相学习的一种好方法是使其成为一种共享的体验，而不是一次回顾。这给它带来了另外一个变化，我相信开发人员对他们特定的代码片段会变得更加愿意，并且变得不那么敏感。 YMMV。

回答

我同意SaaS Developer的观点，结对编程可产生良好的结果。但是，这个问题还取决于其他因素，例如团队规模和发展模型。最后，下面的链接将我们带到可能会有用的代码审查Web工具。

里特维尔德

回答

我的团队太小，代码太多，无法通过正式的审核流程进行审核。

相反，我发现有效的方法是在发送电子邮件时使用版本控制系统来发送差异电子邮件。 SVN / CVS->电子邮件发送给部分出于好奇会审核提交内容的所有团队成员。最重要的是，开发人员针对主要模块的代码演示可以有效地展示他们的一些工作。

每次签入都标记有错误ID或者功能请求(用于新代码)，并且允许进行一些回溯。

最后，质量检查人员的参与意味着他们对代码的测试将提供一些验证。

至于代码的效率，由于我们没有时间审查算法，因此在统计上做了一些改进。最终，我想将我们的负载测试仪绑定到该过程中，并让他们更频繁地运行自动负载测试。

回答

"最好"取决于许多因素：

• 产品本身。生命/任务至关重要吗？
• 修复发布后的成本。将一台计算机上PC软件补丁的成本与召回数百万个具有嵌入式代码缺陷的智能卡进行比较。

这些类型的因素应驱动适当的代码审查级别。根据需要，它可以是非正式检查，基于清单的审阅，结对编程或者类似Fagan的密集检查。

回答

我们使用结对编程，我们倾向于不在整个团队参与的情况下进行代码审查，而在体系结构审查中进行。
我还尝试与程序员坐下来，对重要功能或者使用新工具/技术时进行一些常规代码审查。
我们还会在内部Wiki中记录从此评论中摘录的最佳实践和模式。

回答

我们的代码审查过程非常简单。在发布修补程序/功能之前，强烈建议对其进行审查。评论是由"我们左边的人"完成的，他们只是打开了Subversion日志窗口并签出了差异。他们向原始作者发表评论，并在日志消息前加上" +"号，表明已被审阅，然后将姓名首字母放在底部。这使得在发布过程中很容易识别尚未审查的特定提交，并且我们可以在代码发布之前将未审查的提交进行划分。

我们认为，与其说是将人扔在一个房间里，不如说是至少有人看着它更好，因为两双眼睛比一只眼睛好。

回答

如果没有至少一项检查，则不得签入任何代码。起初它将使速度变慢，直到我们意识到空中还有更多的球，但是我们可以避免自己做一些愚蠢的事情，而现在有些人对代码已经很熟悉了。

/艾伦

回答

我们要求尽可能使用工具，主要是为了减少代码审查的开销。借助减轻烦人的语法检查的工具，审阅者可以将精力集中在设计问题上。

Atlassian编写的Cruicble对于"在线"进行代码审查非常棒。

Findbugs / PMD / Checkstyle删除了开发人员必须执行的许多复杂语法检查。

Eclipse / IntelliJ IDEa包含令人难以置信的内联警告。

尽管我希望完全敏捷，但由于种种原因，我不打算进入这里，所以我们不能这样做。但是，我将为我们指出一篇论文，该论文对我们尝试将某些"敏捷"技术结合到"瀑布"项目中提供了一些见识，我认为这是相当合理的成功。

http://www.aswec2008.curtin.edu.au/IndustryReport/Morgan%20-%20Agile.pdf

回答

我们进行分布式开发，因此当我们相距数百英里时，不可能坐在一个房间里。因此，我们设置代码的时间是每周两次，每个人都连接到共享台式机。

任何人都可以对代码进行审查，没有人可以豁免审查，所有代码都应先审查后再放入主线程。从测试软件到测试案例再到源代码，所有内容都可以接受审查。如果值得做，那就值得与团队讨论并值得其他人关注。

我们将逐步讨论所有问题，从简单的bug到源文件组织再到编码标准(我们在项目中还处于初期阶段，这些仍在发展中)。不是正式的检查(尽管我们在小组认为有必要时进行检查)，因此由作者领导。我们会与以前的版本进行比较，有时会在源文件之间反弹，以回答问题。

同时，我们会临时对设计和开发进行配对。随着我们在项目中的进行，结对每天都在变化。同样，由于人们是远程的，所以这是通过共享的桌面连接等完成的。

回答

PSP一

回答

我从事的项目需要在提交之前对所有代码进行另一番研究。提交日志必须指出谁检查了代码。

回答

我们已经将代码审查过程集成为Jira中的工作流步骤。当开发人员提交对主线的更改时，他们将问题标记为jira中已解决的问题，并将其发送给某人进行代码审查。他们可以拒绝或者将其发送进行测试。

在进行代码审查时，总会发现几乎可以做得更好。当我们对代码更加怀疑时，最好在测试之前进行代码审查，以免我们从工作思路入手。

回答

我将Trunk用作"完成"分支(即可发布)，并在"完成的定义"中包含代码查看。换句话说，只要没有被检查，就不能在"完成"分支中合并代码。

回答

我最喜欢的是在每个提交评论中添加[Reviewer：name]。这样，我们可以确保公司中有不止一个人知道自己做了什么。

如果提交有问题，请先请审稿人。这样可以确保审阅者完全了解提交的代码。

回答

rietveld似乎很有趣，它基于Mondrian(一种由Python着名的Guido Van Rossum在Google开发的用于代码审查的网络工具)

它允许代码审查随时发生，并且不需要面对面的联系。

http://code.google.com/p/rietveld/wiki/CodeReviewBackground

在这里演示
http://codereview.appspot.com/