编码
最后更新于：2022-04-01 20:47:03
2013.6.11
如果说一个男人最有面子的事是身边常伴漂亮的女伴，引别人侧目。那么程序员最有面子的事，一定是写下的漂亮的代码，引无数草莽感叹。有趣的是，我们总是有机会看到这样的现象：一些老模块虽然设计不好，但是代码质量不错，所以依旧稳定，但是一些设计理念很好的模块，却被写得乱七八糟，漏洞百出。
代码是设计的最终产物，是一个程序员基本功，偷不得一分巧。如果一个人总是喜欢高谈阔论，那么去看他的代码，通常一眼看下去，就能知道他是“真正的高手”还是“空想家”。
项目管理的代码管理，通常期望达成以下几个目的：
1、避免出现杀手：“高手不是培训出来的，也不是管教出来的“，高手之所以视为高手，是因为其很少见，而成就高手的素质通常不是众生常具备的。但是项目组内的隐藏的杀手，却可以通过管理降低其出现的风险及危害。A/B角审核，签入代码控制等这些都是关卡。
2、保证代码质量：代码不一定能像高手写的那么极端漂亮，多一分便肥，少一分便瘦的地步，但是却可以通过管理保证大家代码的逻辑清晰度，可读性，减少边界错误，减少低级错误等。例如：工具扫描，单元测试，每日构建等。
3、培养人员：“近朱者赤，近墨者黑”，影响的力量是巨大的，通过编码阶段的互动交流，可以让一部分组员能够快速脱离”山寨“，进入”职业“状态，尤其对新员工有效。
按项目管理的五要素分解如下：
**1、干系人期望-目标**
编码阶段干系人的影响已经很小，可以先不讨论这节。
**2、沙盘-思路**
1）开始前挂牌讲解好的代码
同设计一样，很多时候往往不是大家不愿意写出好的代码，而是大家不知道好的代码是什么样的，因此在项目组开始编码前，讲解优秀的代码，会让组员开工之前，有一个学习的目标，会让编码工作变得更有意思。这里更好的做法找出那些和本项目组有关的优秀代码示例，更是事半功倍，例如：部门类似业务的好的代码。
2）公开走读计划
记得在管理上有个研究工作效率的故事，发现把工人召集到一个实验环境中，在设施完全一样的情况他们的工作效率和质量比平时都有大幅提高，逐个排除了很多影响因素，最后发现原来是”关注度提高“的原因。人都是有表现欲，当自己手头的上事被关注时，往往我们希望把自己最好的一面表现出来，人性如此。代码走读就是这个作用，大多数时候提前公布的走读计划比实际走读出那几个问题更重要。
安排走读计划时，需要注意到这几点;
a、走读成员要有威慑力和权威性，避免大家扯皮。例如：找专家，架构师，主管等
b、走读的结果无论好坏，都要公布，以便项目组形成一股良性氛围
c、当项目组模块很多时，可以抽查一定比例的模块走读，这样在走读计划公布时，不要明确模块，避免没有在走读计划内的模块作者，暗自庆幸。
3）A/B角审核
只有走读计划是不够的，因为走读通常要不少人参加，不可能将时间拉得过长，因此很多细的逻辑审核不到。另外走读模块往往是在这个模块代码已经或接近完成时，时间点偏晚，有些”木已成舟“的味道。和走读计划相配合的是进行A/B角审核，我们可以在设计或更早的阶段，明确项目组的A/B角关系。A/B角的好处在于，代码得到及时审核，测试阶段A/B角可以互担压力。
A/B角的常见组成方式如下：
a、项目组分成小组，组长担当B角
b、项目组有某些模块的专家，这些专家担当对应领域的B角
c、一个模块有几个人共同完成，他们互为A/B角
d、项目组不大时，由项目经理或质量经理担任B角
4）代码checklist及工具扫描
代码checklist是将大家常犯的共性错误集合成的检查表，例如：一些潜在的死锁风险，C++用法等。而工具扫描是为了排除一些低级错误，例如：内存泄露。 很多时候低级错误的排查bug的难度是不低的。
5）单元测试
做好的单元测试的核心在于两点：
a、要有好用，省时的单元测试案例编写工具，例如：C++ Test等
b、管理好单元测试案例，不能只做一次，而是每次代码发生变化，每次代码重新编译时，都能自动执行单元测试。如果单元测试只能用第一次，投入产出比，就会小很多。
c、能够在目标机上执行单元测试案例，这样能够避免大量打桩，导致工作效率下降。
6）代码签入控制
代码签入控制往往是强制A/B角的实施方法，即：收回A角的代码签入权限，只允许B角签入，如此能够保证B角的审核频率能够达到每个包一次.
7）每日构建
每日构建是指编码开始后，每天环境会自动从SVN/VSS上获取代码进行编译，并执行对应的单元测试案例，每天早上通报错误。每日构建的好处在于：系统在持续良性集成，避免联调开始后，大家一窝蜂的把代码签入，有大量的编译错误等，消除这些错误需要消耗很多时间，并容易犯错误。
**3、计划制定**
1） 代码走读计划
代码走读计划如上述第二点，需要提前预约专家，架构师等，并在项目组进行公布。
2） 配置管理计划
涉及到代码签入权限，编译环境维护权限等。例如：一个大项目组，如果编译环境没有控制权限，没有指定操作规范，很容易被大家搞乱套。
3） 单元测试计划
不是所有情况下，用单元都是合适的。例如：对于一个老模块的改动，此模块依赖很多外部资源，并且之前没有任何单元测试案例，这会导致编写对应改动的单元测试案例，成本很高，此时需要进行权衡投入产出，可能这时找此模块的专家进行审核是个更好的选择。
**4、风险管理**
1）编码进度不透明
大多数人都习惯先松后紧的工作方式。“犹记得大学时，老师布置了作业，两周期限，下课是交作业的最后期限，上课时，班上大多数同学们都是拿着借来的作业奋笔疾书”。编码阶段的时间在转集成前各阶段中，算上比较长的。而这个阶段的工作进度非常不好衡量。经常看到一个模块编码进度迅速从0%到90%，而后花了两倍的时间才从90%到100%，无法有效得知项目的进度，就是项目的风险。
这里有个好的做法可以参考，编码计划表从估算表中导出，因为估算表中每个估算项粒度通常不会超过2天。这样在编码进度表更新时，去除百分比，只能更新两种状态，未完成，完成，如此计算出的项目进度是比较准确的，同时也能够帮助组员理清当前自己的工作进度。
2）新员工代码质量
新员工的成长是需要团队付出精力的，针对他们我们往往要有更频繁的代码审核、指导 或安排责任心更强的B角。虽然新员工的操心在所难免，但是他们潜力也是无限的，耐心地培养后，总能从中收获到惊喜。
3）识别出风险模块
项目组的进度不同于齐步走，总是有前有后，质量同比也是有好有坏，那么在整个过程中通过上述的种种办法找出这些有风险的模块，进而采取调整措施是项目管理中不可缺少的部分。
4）需求实现有遗漏
任务分解时往往并不能完全根据需求进行，在代码实现时，因为大家的思维已经在很细节的层次，所以此时核对系统需求或需求跟踪矩阵，就很容易发现需求的遗漏项。
**5、团队管理**
1）每日构建有奖惩
有奖惩是为了提高大家对这件事的重视程度，当然每日构建通常犯的错误不是很严重，而且易于发现，针对这种场景，不适合采用过于严厉的惩处措施就不合适了。例如可以采用如下措施：
a、累计错误数，如果项目组整体达到5次，造成错误的同事请项目全体成员吃水果或喝饮料。
b、每天系统自动通告构建的结果
2）走读计划有奖惩
走读计划因为动用了外部资源，比较权威，惩处和奖励要重一些。例如：对于代码走读结果不好的组员，本季度取消得A资格，走读结果好的组员，给予奖品及季度优秀的考核。
3）进度在项目组定期通告
每周至少一次项目组在一起回顾上周的进度和下周的计划是很有必要的，这样容易让大家对整个团队产生归属感，并且能够得知其他人的工作进度，有个横比，从而能够自我进行进度调整。
4）严格执行计划
此阶段的项目计划的时间点是确定的，除非项目经理有把握控制后续的进度，否则尽量不要调整里程碑点。
';