这篇《损人损己的代码质量检查》文章题目看起来比较残酷，内容还是值得一看。这种讨论实际项目开发过程出现的问题的文章较少，我毕业到现在，工作还不到两年，又只在一个公司，相关经验少，所以很想知道别的开发团队是不是也有这样的问题，是怎么解决，通过他们的经验来反思自己。

　　代码质量检查，我习惯说代码走读，理论上是开发过程很重要的一项，对系统健壮性，可维护性都有很大帮助，毕竟大部分严重的bug就出在攻城师写的程序。但现实项目中，就很难执行，我自己总结了两个原因。

　　一、忠言逆耳，易得罪人。像上面文章说的“结果把所有的人都得罪光了，人都被挖走了”，程序员都比较有个性，代码能运行，需求也实现了，凭啥对我代码指指点点？我们还是要保持谦虚，抱着学习态度。

　　二、需要高手。我理解的代码走读可以分为三层：

　　1、代码规范，如果代码没有这个基础，那不需要再走读了。完成任务式的走读都停留在这层，问题比较明显，例如变量命名不合适，少空格等。

　　2、程序逻辑，业务逻辑。要找出逻辑上的问题，检查者不仅要读懂代码，还要熟悉业务。

　　3、架构，包含类之间的关系，某个函数的实现。如果不考虑后期维护可以忽略这层，或是有强大的架构设计师。其实这类问题比逻辑更容易发现，例如某个类功能太多或函数if\switch太多等。

　　但也让很多人纠结：类要分成几个小类？之间怎么交互？if\switch是太多，那要怎么解决啊，“不要光说我不好，或者错了，最好是有水平，告诉我哪里错了？为什么错了？我怎么做会更好？”，因为原先的代码已经实现了需求，先入为主，大多数程序员对需求实现形成了思维定势，重构又是费时费力的事，就可能认为检查者“可能也是出于好心，但是大部分是瞎评论，瞎扯蛋”。

　　这一层做的好，代码走读不仅仅是发现问题，而是提高编程水平。

　　不过在项目急着上线情况下，还是不要动架构，解决架构的问题很费时间，程序员本来就处于紧张状态，可以先把问题记录下来后期再维护。

　　困惑：不知道是不是理解对了？怎样才是好的代码走读？