重读code complete 说说代码质量
2014年的第一篇文章本来计划写些过去一年的总结和新年展望，但是因为还有一些事情要过一阵才能完成，所以姑且不谈这个，说说最近重读code complete 的收获吧。
记得第一次读code complete 还是刚毕业的时候，身边好多朋友极力向我推荐此书，于是我就买了一本读起来，可能是当时功力不够，读起来总是觉得没啥味道，而且极为枯燥，总觉得不如<深入浅出MFC>，<CLR Var C#>，<Windows Internals>等来的痛快，惶惶不得其精髓，只是当小说一样草草看了一遍。
慢慢的随着工作深入，自己也参与到更多的开发周期中，比如Plan, 配置团队，做计划，代码审查，控制代码质量，尤其是近两年，每当我看到某些team member一下子提交几十个源文件让我来审查我就有些为难。首先，这么多的代码是一个工程师近一个月的工作量，而审查的时间通常只有1天，这无疑给保证代码质量造成了极大的隐患。说实话我遇到这种情况是的情绪是极为复杂的，我对这样的事情也是极为反感的，这个做根本就是不负责任。当然我也可以不负责任，随便看看就pass， 但是反过来想想，一下子把一个系统中加入那么多的代码，而让其他干别的工作的人用那么短的时间去review你几个月的工作本身就是耍流氓。我通常的办法是既然你耍流氓，那我就不客气了，我在你的每个文件上都给你加上几十个有建设性comments 让你去改，然后在别人改代码的时候我再继续审查在审查代码。
闲下来的时候每每回忆这样的事情，实在是太浪费时间了，我就问问自己能不能有办法处理这些类似问题呢，软件工程发展到今天，一定有无数的人遇到过这样的问题，我所需要做的应该只有学习就够了。
看看下面的条目：
- 比如一个项目计划做多久比较合理，计划文档应该写到什么程度
- 代码审查一次提交多少比较适合
- 如何保证代码质量
- 如何配置工程师
- 如何高效玩转整个开发周期和流程
…
有多少是经常困扰你的呢? 当然如果这些问题你都没想过，或者全靠拍脑袋，那我也不好说你什么啦。对于同样的问题，有些团队就可以处理的非常好，而有些团队就极为混乱，我不能说某些团队不行，要怪也只能说团队的领导不行，根本没办法驾驭这些问题。
带着这些问题在最近的两年我在桌上放了两本code complete, 一本中文，一本英文原版，每当遇到类似的问题我就问问它，当然有些问题，它里面也没有描述，其实也不怎么全，呵呵。但是大部分的问题还是让我受益匪浅。
按照我对每个问题的理解我对每种情况作了相应的总结，形成规范，首先自己follow，然后慢慢的潜移默化给整个团队，我发现慢慢的大家的开发效率，代码质量和代码审查效率都有了显著的提高。
这一轮带着经验，带着问题读code complete 让我受益匪浅，如果非要总结原因的话，我想说的是，其实代码大全最少要读两遍，因为没写过一定的代码，没遇到过一定的问题去读它是不可能明白全部的精髓。