关于在组内促进代码评审和自动化测试的想法

石骞

2016年3月17日

13124781413

现状和建议概述

目前观察到的情况是开发人员之间的技术交流较为欠缺、代码的自动化测试水平不高，这两者又会影响开发人员产出的质量。

日常工作中开发人员之间的交流不多，即使有也多数是关于如何出成果的，关于出成果的方式，出的成果的质量，改进的方面、方式等方面的讨论还比较少，积累下来的知识也非常少。交流无疑能帮助开发人员进步，如何促进交流是问题所在。

另一方面是目前开发人员的代码的测试的量少、自动化程度低。具体表现在代码逻辑测试不够严谨、UI测试靠测试人员手点、性能测试较原始（使用的指标非常有限，可能多数都是计时和看任务管理器的内存占用）。

促进开发人员之间的技术交流应当从从新人培养开始，通过引导团队成员结对进行代码评审培养技术讨论的氛围，以小组内代码评审进一步活跃气氛，再通过专题技术交流升华。将此过程中的收获整理进新人培训的教材，亦可作为部门的知识库，不断积累，不断深化，形成一个从新人到专家再反馈给新人培训的良性循环。

提高测试覆盖率主要考虑”用代码来测试代码”。其主要实现方式有：

l  鼓励开发人员编写单元测试并尝试向测试驱动开发过渡

l  进行自动化UI测试方面的尝试

l  探索性能测试工具

下面将展开讨论如何促进交流。提高测试的自动化程度的内容了解得还比较少，将放到专题交流一节中简要讨论。

促进交流

活跃的技术讨论氛围不是一天就形成的，可以考虑以两两结对的代码评审为入口，多次结对评审有助于撒下交流与合作的种子，逐步扩大到小组内可以进一步巩固、活跃已有的氛围。讨论的内容可从具体的代码评审开始，逐步扩大到大家关心的各种技术、思路。在这条逐步推进的路上，新人培训是第一站。

新人培训

对于每年的新入职开发人员的培训的建议主要有：

1.        逐步优化讲课的教材

2.        给新员工多一些时间去向自己的导师学习，尤其是如何写代码。

逐步优化讲课的教材

以下问题的存在会影响对开发人员进行集中培训的效果：

l  在工作中要用到的知识种类繁多，要掌握的水平也各不一样，

l  上课的新员工的基础各不相同，对知识的接受能力各异

l  讲师不清楚课上的学生的水平，即使知道了也还是难以选择合理的讲课深度

一份实用的教材能为日后新人的自学提供明确的指导。教材中应当提供：

l  集中培训时讲到过的内容：公司的部门组成及各自的职责与合作方式，公司的产品体系、相互之间的关系，部门内的开发流程、代码规范、常用工具、共享资源的存储位置等

l  较合理的大纲，为新人们指出经过以后的学习，各门技术应该达到的水平（类似岗位定级标准）；

l  参考资料：博客、论坛地址、书单（如：

n  《代码大全》

n  《重构:改善既有代码的设计》

n  《测试驱动开发的艺术 (图灵程序设计丛书 59)》

n  《单元测试的艺术(第2版)》

n  公司里相关领域的高手的名字等信息

l  公司员工的知识积累

教材有多方面的作用：

1.        规范新人培训工作，

2.        每年的讲课内容都可以在去年的基础上有所优化，可以稳步提高新人培训的质量，

3.        教材中还可以加入员工们在平常工作中总结出来的技巧、发现的知识，经过长时间的积累后，教材不光可以给新人培训用，还可以充当开发人员手册，这样我们不光有了ADF这样的代码库，还有了关于开发工作的知识库。

跟导师一起评阅代码

新人的编码习惯、编码风格、技术能力等都有较大的塑性，有效的培训能较大幅度地提高他们的能力，而新人能力水平、学习能力、学习方式的差异是对新人的培训强调一对一或者”小班”教学的主要原因。因此，新人在集中培训后跟导师学习的经历十分重要。而且这意义不只体现在新人的进步上，对导师来说，最好的学习是讲课，讲清楚一杯水的内容需要一桶水的知识储备，能带好新人才是其真正具备相关能力的证明，用心带新人的导师肯定也会有所斩获的。

程序员最直接的产出就是代码，代码水平是其能力的直接证明就是其代码水平。新人向导师学习的最直接方式是新人与导师结对编程，具体地有3种做法：

1.        一起写新的功能；

2.        一起评阅并修改新人自己的代码；

3.        一起评阅别人写的代码

一起写新代码的过程中新人可以看到高手是怎样一步步展开并表达自己的思路的。

一起评阅自己的代码的过程中可以直观地看到自己的问题，观摩导师分析、修改代码的过程就是学习的过程。有效修改后的代码往往可读性更好，代码逻辑更清晰，执行时也更流畅，这些方面的体验的提升能让新人直接感受到优秀的代码的威力，对于提高其追求优质代码的热忱当有所助益。

一起评阅别人的代码则可以让其学会分析、理解别人的代码，从中发现可借鉴之处、可改进之处。

结对评审

新人与其导师一起评审代码是结对评审的一种。另一种结对评审发生在能力相近的两位同事之间，地点就在其中一位的工位上，评审的方式类似于新人与其导师一起评审。这两位同事应当对代码重构、面向对象的设计等知识有所了解，并且也兴趣进行这样的实践。找到一对或者多对这样的同事并引导他们进行评审，需要管理层的配合。

对于评审时机的选择：应当鼓励开发人员多进行结对评审，磨刀不误砍柴功，交流的过程能提高彼此的代码水平，编写优秀的代码能节约时间。

只选2位同事是保持评审活动轻便可控。

要求两者能力相近是希望在能力差距不大的情况下，参与评审的两位都能畅所欲言而不用因为怕在对方面前出丑而不敢说话。

让他们在工位进行讨论，一方面是当两人出现分歧时可以很容易地在周边找到第三方加入以尽量解决分歧，另外，就在工位上进行讨论，更容易带动周围的其他同事。

小组评审

在小组内的成员都多多少少地参与过结对评审，对代码评审的作用有了认识，对其认可度也提高了之后，可以考虑让小组内经验较为丰富的开发人员发起组内的代码评审。

小组评审的流程和时长、人数等问题可以留待开发人员自行探索。

一般来说，结对评审的代码选择参评人自己的代码会比较有针对性。而小组评审的时候，考虑到如果代码被找出很多不好的地方，负责的开发人员可能会觉得不好意思所以评审代码时可以考虑匿名评审也就是说不让参评人知道被评代码出自谁手。另外，为了提高大家的参与积极性选择评审代码时可以考虑从小组成员用得较多的代码开始，比如系统的框架代码，甚至是ADF的代码，也欢迎开发人员主动提出要小组评审自己的代码。

评审过程中大家意见不统一很正常，如果主持会议的“专家”能提出较权威的解决方案是极好的，即使不能也很正常，重要的是这个过程中大家都在积极地思考与总结。

在小组评审的过程中，可能会出现一些”跑题”的情况，比如从对当前代码的评审跳跃到工具的选择上或者某种新方法、新技术的适用性等。刚开始小组评审时，适当包容这些”技术性”的跑题，这样的一些”题外话”能活跃气氛，也能为以后开展专题技术讨论搜集议题。

可以请参评的某位成员将评审过程中用到的技术、方法记下来，在评审结束后，尽快将其更新到教材的相应章节中去。（教材的更新维护可能需要一位专家从整体上把控内容还需要普通员工完成日常维护，可能会花去不少精力，具体如何还没什么成形的想法）

专题讨论

随着技术交流的不断深入，团队内可能会出现集中讨论某些问题的需要，这时可以在小组内举行专题讨论会，交流的内容不再局限于代码，而是大家感兴趣的某个技术点或者某种方法论等等，只要是技术类的讨论就行。

前面提到的扩大测试覆盖面的方法都还是只有一个粗略的想法，相关的内容可以考虑作为交流的议题。

测试驱动开发

单元测试、测试驱动开发强调的是用单元测试来保证代码质量，先编写单元测试，再编写代码让测试通过，再重构代码，”红绿构“一个循环，不断往复。”红”是指编写完单元测试还没写相关的实现代码之前单元测试运行会失败，其进度条是红色的，“绿”是指编写相关的实现代码之后，单元测试能通过，进度条为绿色的，构则是指重构，有了单元测试做保障，可以放心地修改代码的内部实现而不修改代码的功能。

具体实施起来还是有许多细节要考虑的，如何用单元测试来测试原有的大量代码？编写单元测试时可以做哪些取舍？哪些应该测哪些不需要测？使用存根或者模拟对象时有没有比较好用的测试框架，具体用法是怎样的？针对我们的业务情况，有没有哪些地方要特殊注意的？诸多问题目前我都无法解答，希望在以后的技术交流中大家能提出好的方案，不断实践不断优化。

自动UI测试

之前跟罗雨沟通过，测试人员想做UI的自动测试是很复杂的，他们基本只能通过鼠标所在的像素位置来定位UI，当分辨率发生变化或者窗口大小变化时原有脚本的有效性都打折扣。MSDN里的资料（https://msdn.microsoft.com/zh-cn/library/dd286726(v=vs.110).aspx）能否更好地解决这个问题，有没有别的更好的解决方法，甚至这样的测试有无必要，都需要进一步的讨论、尝试。

性能测试

按照2/8法则，80%的情况下开发人员的代码基本只要能完成业务逻辑就能交差，对性能并不会有太多要求。然而，剩下的20%的情况正是开发人员核心能力的体现。对我们的程序，应该关注哪些指标（GC次数，，使用怎样的流程和工具去进行性能测试，又有哪些调整的方法和思路，同样的MSDN里也有一部分资料（https://msdn.microsoft.com/zh-cn/library/z9z62c29(v=vs.110).aspx）也是值得一探的。