发信人: laofo (偶是fofo), 信区: SoftEng
标 题: 《{zy1}软件开发流程》培训有感

昨天去参加了《{zy1}软件开发流程》的培训，时间很短，但是还是有些收获。{zd0}的收获莫过于对持续集成的一个更深的认识和对量化管理的理解。

首先还是说说持续集成。谈到持续集成不得不说 Daily Build. 其实很早我就做Daily Build了，那时候还是用 Suversion + CruiseControl.Net，应该还是在06年末，还是07年初?具体时间不记得了。虽然实行了日构建，但是结果却没有想象中的好，我一直在思考为什么会是这样。其实就是大家对 Daily Build的不重视，Jim （这次培训的讲师）说，必须要提高大家对 Daily Build的认识，每天都进行构建，这是项目的心跳线，每个人都要重视，构建报告，每个人都要读，都要看。Daily Build 构建失败，是一个很严重的研发事故，谁提交代码导致的失败，谁就要对这个研发事故负责。可以在项目结束后进行总结。我觉得这样很好，否则没有一个人xx Daily Build的结果。一旦不xx，就会造成，SCM 做的 Daily Build 只是给自己看的，除了 SCM 几乎没人xx这个事情。这是不行的。

在这种情况下做不做 daily Build 意义不是很大。只有大家对自己的代码质量，对 Daily Build 的重视度提高到一个很高的水平了，那么项目才会在这根“心跳线”的作用下一步一步的在往前走，{yt}{yt}的有所进步。

其次说说量化管理吧。量化管理的确很重要，在一定的程度上，可以提高生产力，促进生产关系。对于配置管理也一样，我们在考虑配置管理的工作，对配置管理工程师的时候也可以量化管理，这样才能让每个人都看到进步，同时给予奖励。在量化指标的支持下，上下级之间，同事之间的沟通就会好很多。


其他一些小的提示：

1）代码复杂度。代码复杂度要尽可能的低."一眼看不懂的代码是有问题的“。当然对于一些比较复杂的情况下是允许的，比如某个核心算法，但是大部分代码复杂度都不高。
2）迭xx发中要保持定期发布。如果这个功能影响这次发布，那么就不要在这次发布中包含这些功能，或者直接砍掉这些功能。
3）集成时间，测试时间几乎占了研发周期一般的时间。（Jim的经验数据）
4）每次check-in之前都要请其他同事代码审查，并且check-in 时，要写上审查代码的同事的名字。
5）小构建 vs 大构建。可以设置每次 check-in触发的小构建，然后每天定时进行大构建（比如夜里）。其实这一点我们已经做的不错了。只不过没有进行 check-in触发的小构建，因为项目构建时间很长，一次 check-in就触发一次构建不现实。
6）对研发的考核要重在质量，而不是代码量。客户直接看到的是源代码（就是看到源代码编译出来的产品），那么我们就要提高对代码质量的认识。
7） coding -> code review(buddy review) -> check-in -> build -> some test(BVT) -> Code review(Team Review) -> Daily Build

听了Jim说的，对比下自己现在配置管理这块的工作，发现虽然细节不太一样，但是我们已经做的很完善了。