求代码质量保障最佳实践

[JustForLp]

背景:最近看了不少关于单元测试的资料，都是在教如果使用工具来写单元测试，但是缺少关于最佳实践方面的案例，我看了TestableMock觉得的确很好用，相信TestableMock团队也一定深入研究过相关实践方案 问题： 1.想了解下在阿里是如何保障代码质量的呢，有最佳实践案例可以分享吗？ 2.如何去衡量投产比的呢，代码覆盖的保障都是由开发去保障还是由开发、测试一起保障？ 3.业务开发团队与中间件开发团队对于单元测试要求是否有差异？ 4.业务代码编写时间与单元测试编写时间比例如何分配？

若能得到各位指点，将不胜感激

[linfan]

感谢对这个项目的关注。

TestableMock最初的设计主要是希望降低Mock的入门门槛，把需要用到的注解、操作步骤都减少到最少，顺便将我们过去在单元测试中遇到的私有成员访问、参数对象构造等等常见问题一起解决。但从后来推广的情况来看，TestableMock对于比较规范的项目来说（项目结构、测试文件命名、测试粒度等方面），确实能够极大的提高Mock的引入成本，但遇到工程实践原本就做得不够好的项目，反而会用起来很绕，甚至不如传统的Mock工具易用。为了适配一些不规范的场景，TestableMock加入了如@MockWith、包路径映射等等复杂的用法，一定程度上逐渐违背初衷，目前此项目已经暂时转入低频维护状态。

关于你提的几个问题。

1. 保障质量的措施有非常多，单元测试主要的目的是确保局部业务逻辑（尤其在边界条件下）的正确性，这只是代码质量里（比较细节）的一个方面。如果是为了提升整体代码质量，推荐从 “代码评审” 和 “代码安全扫描” 这两件事做起。影响代码质量最根本的因素依然在于开发者个人能力、编码习惯和业务经验，有效的 代码评审可以促进开发者之间快速的相互学习进步。除了人工评审，代码扫描能发现不少质量上的漏网之鱼，尤其是 安全相关 的扫描（相比于编码风格、规约一类的扫描而言）对于防范风险的作用更大，建议了解一下阿里云Codeup产品的相关能力。除此之外，团队内的技术氛围、开发者与测试人员之间的有效沟通、好用的开发&调试&发布工具都会对产出高质量代码很有帮助。
2. 单元测试覆盖应该由开发同学来保障，但是否要把覆盖率作为质量的衡量指标，值得商榷。单元测试写得好，覆盖率会提高，但覆盖率高并不一定单元测试做得就好，在工程能力不足的团队里推行测覆盖率往往反而会导致开发同学编写大量低质量的单测用例。API和UI级别的测试通常可以由专职的测试同学来完成，也可以是开发同学自己做。
3. 差异不大，主要看代码本身是否有复杂的计算逻辑、业务规则或者边界条件，如果有，那就要建议做单元测试。
4. 根据项目的重要程度、复杂程度、开发者技能的熟练程度（以及项目是否强制要求覆盖率数量）而异。譬如一些底层通信编解码类的核心逻辑，业务和单测编写时间可以是1:1，甚至花比业务代码更多的时间在单元测试上。对于一般性的业务，开发者花在单元测试的时间占总编码时间的20%-50%都是正常范围。