推进代码评审和单元测试实践

Question

作为一个团队领导管理一组在代码评审和单元测试方面没有经验(也没有必要)的开发人员，您如何推进代码评审和单元测试实践？

您将如何创建一种方法，以便代码评审和单元测试能够自然地适应开发人员的流程？

这两个方面的阻力之一是“我们总是紧盯着日期线，所以没有时间进行代码评审和单元测试”。

代码评审的另一个阻力是，我们目前不知道如何进行。我们应该在每次签入时检查代码，还是在指定的日期检查代码？

Answer 1

您的团队成员是否真的同意代码评审和单元测试是好事，只是没有时间进行这些工作？

还是他们只是用这个借口来拒绝这个想法呢？

在第一种情况下，解决方案是现在就开始执行。(好吧，如果你在一个重大里程碑之前的最后几天，也许你可以等到之后-但不会再有了。)在我以前的工作场所，我是质量工程师，负责改进编码实践和整体质量。我们一直把代码评审的开始推迟到下周。有一天，我意识到我们已经做了一个月左右的事情，除非我尝试一些不同的东西，否则很可能会一直持续到最后。所以我宣布了那周的第一次代码评审。我告诉大家，“如果它不完美，或者我们还不知道该做什么，那就没问题了--我们会开始去做，看看它是如何进行的，并在我们学习的过程中改进事情”。至少在我离开公司之前。

在第二种情况下，您可能需要更多的教育和开放的讨论与团队。讨论代码质量问题，询问他们认为开发过程中的问题(或缺乏这些问题)/代码/测试中的问题等等，并就如何解决这些问题集思广益。最终目标不一定是进行代码评审--它们只是一种手段，而目标是改进开发过程及其输出的质量。结果很可能是，还有其他更痛苦的问题可以更容易地改善，更快地带来更多的利益，然后把这些放在第一位。它们甚至可以是环境或过程中微不足道的变化；所有这些都将提高团队士气，建立相互信任，并帮助团队纽带。

底线是，你不能强迫任何人质量-你只能消除创造质量的障碍。通过在没有团队共识的情况下强制执行严格的规则和强制实践，您可能会疏远团队，并最终阻止您所追求的质量改进。OTOH通过公开讨论，并就团队面临的最紧迫问题以及如何改善情况达成一致，您更有可能获得团队支持。从长远来看，这将对保持质量改进的努力产生重大影响。

Answer 2

经典的问题。永远不要有足够的时间去做正确的事情，总是有足够的时间重新做工作。在人们开始做最好的实践之前，似乎永远没有足够的时间去做最好的实践。特别是因为发展之外的人看不到胜利。

代码评审的关键是您希望尽可能少地检查代码，并尽可能地立即检查。这样就更容易得到时间来审查它，代码在人们的头脑中是新鲜的，实现建议的改进将更容易。在极端情况下，您希望检查每一个签入。一个很好的自动化工具是http://code.google.com/appengine/articles/rietveld.html。它是Google内部使用的工具的一个变体，它强制每次签入时都会进行代码评审。

几十年前，在经典的“计算机编程心理学”中描述了代码评审的挑战。问题是程序员倾向于将自己的形象与编程技巧联系起来。这意味着，任何时候，程序员面对的证据，他们的技能是不合格的，有一种倾向，把它视为个人。这可能造成严重的冲突。如果您选择Steve的经典“快速开发”()，他为如何设置代码评审过程提供了许多建议，以减少发生这种冲突的可能性。(一个关键因素是确保管理层从未参与过这一过程。)请注意，这降低了冲突的几率，但并不能防止冲突的发生。

尽管如此，收益远远大于成本。仅举一个指标，IBM就发现代码评审是发现和消除bug最有效的方法。这不会以任何方式取代您的QA部门。但这使得他们发现的问题要少得多。这是在你获得利益之前，它能在多大程度上加速学习，传播知识等等。

Answer 3

别给他们选择。使测试和评审成为强制性的。如果他们不合作，你可以采取一些强硬的策略，如拒绝未经测试或未经审查的晋升。如果事情真的很糟，炒了你最坏的罪犯。

我看到过这样的情况:团队总是落后于计划，因为他们总是在修复那些应该被测试和评审捕获的bug。从长远来看，更多的工作可以节省更多的钱，而且你越早让你的团队排好队，你的团队就会得到更好的结果。

不幸的是，这需要时间才能真正看到结果。为了鼓励这种做法，您可以开始绘制错误报告的比率、修复错误的平均时间和特性实现的速度。我通常会发现，经过大约六个月的测试和评审，这些指标将得到改进，您的团队最终会得到它。