代码质量控制

代码质量控制

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

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

单元测试

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

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

让改代码验证，不须要要把依赖的各类东西都启动好才能肯定这行代码是否能没问题能够提测。

代码review

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

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

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

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

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

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

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