为什么研发规范，代码评审，单元测试这么难以推动

来源：知乎

　　前言

　　如何区别一个研发团队是草台班子还是正规军，相信很多人的评判标准是有没有实施研发规范，有没有代码评审，单元测试等。但我相信任何一个尝试推动研发规范，代码评审和单元测试的团队迟早都会发现这是一件非常难的事情，很有可能搞得天怒人怨。为什么会这样？

　　规范执行僵化

　　推动研发规范容易犯的错误在于执行僵化，与现实脱节。为了保障规范被严格执行，往往会要求步步留痕，定期抽查；而为了保障其权威性，一般会把抽查结果和绩效挂钩。虽然有规范和没规范相比，完成相同的需求肯定会花更多的时间，但是在绝大多数公司里，业务方才不管你研发部门有啥规范，排期就得按deadline规范。这种情况下，不但研发人员的工作量增大了，而且即使项目顺利上线，如果某些步骤忘记留痕，规范检查的时候一样会跳进黄河也洗不清。你们的团队是不是每次规范抽查也都搞得鸡飞狗跳的，都会花时间搞合规性自检呢？这些额外增加的时间成本严重的甚至会影响到功能开发和测试的时间，当然线上质量也很难提升。如果不仔细分析，管理层面很容易得出当前规范还不够严格的结论，出现每出一个线上事故，就增加一条规范的搞笑行为。解决之道也很简单，就是确保研发测试有充分的时间去开发测试系统，并把评判研发效能的重点放在实际线上事故率是否降低上面。但实操层面，由于研发处于弱势地位，基本不可能说服业务和管理支持这么做。所以突破点应该放在提高研发效率上。

　　评审过于表面

　　代码评审的问题是团队很容易在风格等低价值的问题上反复纠结，而忽略更重要的结构性优化。代码评审的前提是对质量标准有共识，并且评审者对这些标准有足够的判断力。在对代码不熟悉和研发进度紧迫等因素的影响下，评审很容易局限在命名规则，编码格式等简单规范上。而对高内聚，低耦合等设计原则，方法过长，调用层次过深等结构不良问题难以深入。这会导致评审仅限于皮毛，不但浪费时间，而且对代码品质提升帮助不大。同时现实中代码评审往往都由团队的tech leader组织，leader的水平基本决定了代码评审的上限。如果不巧leader本身水平一般但又很强势，就会搞成一言堂，不但拉低水平还会打击士气，时间长了人才就流失了。如何解决这个问题？提高团队的设计和编程能力，特别是一线leader的能力当然是一个手段，但能力这个东西没法快速突破，因此这显然不是一个速效办法。

　　单侧缺乏基础

　　单元测试则是一个典型的头痛医头，脚痛医脚的例子。一般单元测试的评判标准主要看覆盖率高低。但有没有发现要提高覆盖率非常之难，不但一年下来增加不了几个点，团队的抵触情绪还很大。或者覆盖率看起来很高，但实际测试代码顶多就是system.out.print，几乎没有断言，不但起不到单元测试的目的，还白白增加了很多无用的代码。为什么会这样？除了上面说的时间不够外，很多研发并不真正了解单元测试，把写单元测试简单的等同于会熟练使用mock工具。那通过增加时间和培训能解决这个问题吗？其实没用，因为要想写好单元测试的前提条件是代码的可测试性足够好。但前面也说过代码评审的效果很差，显然解决不了代码可测试性差的问题。那到底该怎么办？

　　效率异常停滞

　　说到底，今天的开发方式和二三十年前相比并没有本质的变化，开发效率也一样没什么提高。在效率没有增加的前提下，增加研发规范，代码评审和单元测试一定会导致开发周期延长，整体效率下降。很多公司面对这种情况的本能反应就是加班，搞得大家疲于奔命。

　　我不知道有多少人意识到研发效率增长长期停滞是一件非常不正常的事情！

　　低代码提效原理

　　有没有什么办法能带来质的改变，能同时提升研发效率，代码质量和可测试性呢？答案就是低代码技术。虽然现在市场上绝大多数低代码技提升的主要是前端页面的开发效率，帮不上后端研发的忙。但x-series是专门面向后端的低代码工具。X-Series包含3个独立工具，xUnit 用于构建清晰的后台系统；xDecision 用于表达复杂的判断逻辑；xState 用于管理复杂的状态变迁。

　　xunit利用流程图来表达后端处理逻辑：

xunit编辑器

　　xunit通过以下几个方面提升后端研发效率：

　　1. 加快设计速度。研发人员可以使用xunit将系统功能用流程图进行表达，将设计时间由天缩短为分钟。维护时也无需深入了解代码，可以从流程图上直接定位到对应代码。

　　2. 保障代码质量。流程图通过步骤对整体代码进行了切分，步骤间的调用顺序由流程图来保障。每个步骤对应的代码只关心当前步骤所处理的逻辑。通过这种方式不仅能从根本上满足高内聚低耦合，结构简单等质量要求，同时还能保持代码精简。当代码增长时，可以通过增加流程节点的方式灵活的对代码进行重新分布，确保每个步骤的代码长度在合理范围之内；反之也可以通过合并步骤，避免代码过于零散。

　　3. 提高可测试性。可测试性是代码质量的自然延伸，有了符合设计原则并且精简的代码，就可以满足写单元测试的前提条件。

　　更进一步，如果问题是由代码质量造成的，那么没有代码的话，自然也就没有和代码相关的问题。xdecision和xstate正是从这个思路出发，直接使用决策树和状态机模型来可视化表达业务逻辑，连代码都不需要。

　　xdecision模型示例：

xdecision编辑器

　　xstate模型示例：

xstate编辑器

　　可视化模型完美的解决了沟通不畅的问题，设计评审和功能验收时可以直接拉上业务和测试一起参与，更容易达成一致。

本书第1章与第2章介绍软件单元测试的概念和基础知识。

第1章简单介绍软件单元测试所包含的概念，包括桩对象和测试驱动函数、测试驱动开发、软件测试贯彻始终、软件测试金字塔、单元测试在传统/敏捷开发模式中的地位、精准测试、单元测试和白盒测试，以及单元测试的FIRST原则和AIR原则。
第2章介绍软件单元测试基础知识，包括动态自动化/手工单元测试、静态自动化/手工单元测试。在动态自动化单元测试中介绍了语句覆盖、分支覆盖、条件覆盖、条件/分支覆盖、MC/DC、路径覆盖和控制流覆盖。

第3章到第5章介绍C语言、Java语言和Python语言的单元测试框架。

第3章介绍C语言动态自动化单元测试框架，包括在Windows下安装C语言运行环境、在Windows和Linux下安装编译CUnit、查看测试报告、CUnit介绍和案例。
第4章介绍Java语言动态自动化单元测试框架，包括在Eclipse中创建Maven项目和配置JUnit与TestNG运行环境、JUnit 4测试框架、JUnit 5测试框架、TestNG测试框架、测试替身、变异测试、利用EvoSuite自动生成测试用例，以及在Jenkins中配置JUnit 4、JUnit 5、TestNG和Allure。
第5章介绍Python语言动态自动化单元测试框架，包括unittest、Pytest及Python的模拟对象和变异测试工具mutpy。

第6章与第7章介绍代码覆盖率工具和代码语法规范检查工具。

第6章介绍代码覆盖率工具，包括C语言覆盖率工具gcov和lcov、Java语言覆盖率工具JaCoCo，以及Python语言覆盖率工具Coverage和pytest-cov。
第7章介绍代码语法规范检查工具，包括Java语言静态分析工具PMD、Python语言静态分析工具flake8和pylint，以及多代码语法规范检查平台SonarQube。