刚开始知道有这件事情的时候，脑子里并没有一个系统的想法，关于这件事情，到底需要做什么？相关的就只有一些零星的点，比如:静态代码检查中的圈复杂度，重复代码率，阻断违规，严重违规等……但一些零星的点就能构成一个代码质量评估体系么？这里需要画一个大大的问号？如果不能，那差的是什么？
既然是一个体系，自然应该是一个系统的体系，而不是一些零星的点，那我们究竟应该从哪里出发来考虑这个事情？
如果稍作思考就会发现，我们其实应该回到最初的那个问题，我们的代码评估体系究竟要解决什么样的问题？我们为什么需要它？从这个问题出发，我似乎找到了答案。
今年项目的改进目标是“质量”，质量的提升可以从很多个维度来做，“代码”其实只是其中的一个维度。那我们实际项目的“质量”问题里真的有“代码质量”相关的问题么？
为了找到这个答案，我们曾经对16年整年的外场和外部故障进行了复盘，并且今年作为项目质量的重要反馈环，我们也在坚持持续做这件事情，从故障复盘里，问题引入的原因，有一个维度，就是代码的质量相关的问题。再进一步细分，我们可以继续深挖，到底是基础编码类的问题多？还是异常处理类的多？还是资源占用类的多？亦或是并发类的问题多？如果发现基础编码类问题较多，我们就需要考虑制定一些基础编码规范，异常处理类、资源占用类等问题也是类似，可能需要制定一些这方面的编码规范和实际的编写案例。有了规范，我们再去考虑规范如何落地效果会更好。比如，培训、考试、代码走查、典型案例分享、CI挂接检查等多种形式。从问题出发，再针对具体的问题去制定相应的改进方案，最后还需要一个反馈环，我们的规范制定了，也去落地了，但究竟做的效果怎么样，就可以用度量的方式来得到一些反馈，根据反馈再继续调整，包括规范的进一步完善和落地实施的调整和适应。
仔细分析一下，不难发现这其实都是套路。任何改进都是从问题域出发，找出根因，制定改进目标，根据目标再制定改进计划，并通过度量得到反馈，持续改进，这和SCRUM里的三大基石:透明、检视、调整有相通之处。几乎所有的改进从根本来说就是这个套路，只是具体操作手法上有些不同。
每次和外部的连接，都能获取不少好的思路，感恩有这样的外部连接的机会，可以把今年代码评估体系的工作更有信心的开展下去，感恩分享。
