代码质量控制

常规三板斧：静态检查 代码review 单元测试

静态检查，之前写过工具sonar，以及操作流程。这次纪录下reivew与单元测试。

单元测试

得到更易于测试的代码并且帮助设计，改的动代码，能快速验证。单纯追求覆盖率不是关键。

见过实施tdd atdd流于形式，为了保证覆盖率，欺骗性的各种手段通过，简直没法看。

让改代码验证，不需要要把依赖的各种东西都启动好才能确定这行代码是否能没问题可以提测。

代码review

本身是一种知识传递过程，代码质量把控。既然是知识传递，就跟人有很大关系。

如果是水平接近，最后基本就是瞅下就过，大家都知道对方的水平线，有没有这个流程都无所谓。

有差距的代码reivew，这个过程很耗费精力，而且也在于你想怎么要求别人，是满足90%还是60%就行。

举个例子：曾遇到过花费大量时间讲代码应该怎么写，怎么设计，怎么做，解惑对方各种问题，举出各种场景，然后对方听完后表示的缺应该如此，然后继续不改，当然这里面缺少有效跟踪，更没有权限控制，在代码里继续玩自己的，悲伤那么大。

至于review工具方式，细力度分角色控制当然好，如果是赶时间，控制核心流程关键点吧。跟踪机制在细力度情况下，通过gitlab提供的角色活着pull request，粗力度就wiki 邮件跟踪吧。

梳理核心流程，对系统影响很大关键路径。

ps：最近在赶一个工期非常紧的平台产品，涉及旧代码复用，关于质量控制，代码reivew做粗力度的控制，由于人员水准，保障质量平均线以上。