【项目管理一点通】（35） 编码管理

说到编码管理，主要是技术经理或者是技术组长的事情，但是项目经理有时也会充当这个角色，所以需要了解一些这方面的知识。
通常我们的项目经过方案论证、需求分析、概要设计以及详细设计之后，就会进入编码环节，这里我针对编码给出几点建议，仅供大家参考。
1、采用何种语言进行代码实现，原则上是没有强制规定，但是需要结合每个公司的具体的人力分布以及甲方的具体需求，比如说，公司本身Java开发资源比较多，这样选择Java语言开发就是比较妥当的。甲方强烈要求用C#开发（可能的原因是对方考虑维护人员以C#开发人员居多），项目组临时招聘C#开发人员不一定现实，所以比较可能的做法就是外包或者合作开发。尽管这样，一般来说，接这种项目需要慎重，应考虑相应的人力成本是否可以覆盖，如果不能的话，不建议接这种项目。
2、采用何种技术构架。甲方对技术构架方面的要求也比较多，但是相对来说还是以匹配业务为主，也就是说，相比较业务实现，技术构架要次要一些，但不是不重要，恰恰相反，甲方更希望采用先进的技术构架，因为甲方认为先进的构架的有效期会更长一些。
3、编码规范。项目组内部在编码的风格上要统一，不要形成杂牌军，这点一定要在项目内部达成共识，具体做法是应由技术骨干牵头给出编码规范。有些编程老手认为这是多余的，比如说注释，很多高手不愿写注释，甚至导致情绪化的结果。这是非常不好的。编码规范是为了方便项目组内部进行交流，降低沟通成本，提高工作效率的。如果没有注释，我们可能就得每一个函数都得向对方解释，这是不合适的。尤其是当编码人员离职后，这些代码基本上就是天书了，我们无法保证每个人的代码都能被其他人看懂，这样的话，别人就无法接手他的代码，结果是要么重写这部分代码（大多数结果是这样），要么就是凑合，慢慢消化，最后这部分代码很可能就成了大家都不愿去看的垃圾代码了。由此可见代码规范的重要性。
4、编码工具。和编码规范一样，建议项目组内部统一编码工具，虽然并不是强制性约定，但是统一起来更有利于提高效率。
5、代码管理。现在的项目都不是一个人能完成开发的，需要很多人协作才能完成任务，比如说，技术骨干编写核心的算法代码，业务理解能力较强的去实现业务接口，其他的人去实现基本模块。这样就涉及到协作的问题，因为大家都需要调用核心算法，基本模块是为业务模块服务的，所以业务接口很可能需要调用基础功能接口，比如说权限接口、用户接口、日志接口等等。为了解决这个问题，我们就需要使用协作工具来完成工作协同。这种协作的工具很多，现在使用比较普遍的有Git、SVN等，大家可以根据自己团队的使用习惯去选择。个人建议可能Git更方便一些。
6、代码评审。代码评审可能是个尴尬的话题，因为很多项目组虽然堂而皇之的说要经常进行代码评审，而且很多项目经理在任职时也承诺保证项目的代码质量，会严格进行代码评审，但是最终都是浮于形式、走走过场，最终结果很可能留下一堆垃圾代码。为什么会这样呢？根本原因并非是他们不想评审，而是代码量太大，评审的工作量太大，时间成本太高，所以不得不最终放弃。那么如何进行代码评审？首先明确一点，代码评审不是过会，很多人理解成将所有组员召集起来开会一起检查代码，这是极其错误的，为了代码审查而这样兴师动众，实际上是劳民伤财，损失的是项目的时间，不可取。建议采取以下措施：
a. 抽样检查代码。代码量巨大，全部检查不现实，建议抽样检查，可以针对每个人的编码风格进行检查，比如检查是否符合规范等。
b. 结合模块测试进行检查。主要检查代码的功能实现和运行的效率，代码的效率一般隐藏比较深，如果不去经过测试，可能不太容易发现。
c. 重点检查核心代码和关键代码。核心的业务代码和关键的算法代码和基础代码最好要重点检查，而且要过一遍。检查的手段不一定都是看，而是结合单元测试来进行。
d. 尽可能编写单元测试代码。代码质量好不好，从单元测试的结果可以看出一些。如果大家都编写单元测试代码，代码检查的负担就会减轻很多。
e. 关键模块的详细设计很重要，设计不好的话，代码的质量肯定高不了，设计良好的话，一定程度上可以弥补代码质量的不足。
做到以上几点，我们就可以基本上能够解决代码评审的问题。
代码管理非常重要，对于复杂的项目，可能需要进行反复的代码迭代，一旦管理失误，会带来很多不必要的麻烦。