[ZT]代码地震（作者：王咏刚 2004 年1 月）(3) 复杂程度。客户仅仅想增加一项业务代码，修改一项业务代码的构成规则，程序员们居然要在系统中的几十个地方修改程序！更重要的是，在列出了上面那张庞大的修改工作清单之后，项目组还必须仔细评估每一项修改需要什么样的程序员，需要多长时间，修改后的代码应当进行什么样的单元测试，代码改动可能引起什么样的系统风险。对于并发控制组件等关系到服务程序稳定性的模块，项目组还必须在修改前明确风险评估和防范的原则和方法。为了保证软件的质量不受影响，在所有代码修改完成后，项目组还要对整个系统的功能和性能进行严格的测试。 按照这样的思路，项目组在项目经理的带领下，又花了整整三周时间完成了所有代码修改和系统测试工作。当升级后的系统在客户现场成功上线的时候，客户方的项目负责人只对可怜的项目经理说了一句话： “你们真是挺辛苦的，升级的结果也还不错——可你们当初为什么要骗我说五天之内就能做完呢？你这不是明摆着让我欺上瞒下吗？” 项目经理哭笑不得，感慨万千。为什么一处小小的需求变更就能带来如此大的修改工作量呢？混沌学家曾经预言，一只蝴蝶扇动翅膀就足以引发几千公里外的一场热带风暴。这一次，一个微不足道的需求变更，竟实实在在地引发了软件系统的一场“代码地震”：数据库表结构的修改导致数据访问控制组件的变更，然后又引出交易处理和并发控制代码的改动，接下来还有服务接口、客户端连接代码、客户端界面组件需要修改..更要命的是，所有代码改动都可能引发风险，都需要重新测试，关键的代码变更甚至会触及软件的基础架构..这种“地震效应”一旦在软件中出现，就必然像滚雪球一样一发而不可收拾。如果不是项目经理沉着冷静，“银证通”项目的升级历程恐怕只会更加糟糕。 现在，我和这位项目经理都迫切想知道的是，类似的需求变更一定会引发一次“代码地震”吗？系统的设计和编码过程与这种“代码地震”有什么必然的联系吗？是否存在有效的“防震”、“减震”或“抗震”的措施？ 2 一些题外话 前面的案例提到了技术人员年终奖金的问题。对于软件企业来说，这始终是一个敏感的话题。应当说，项目经理、程序员等技术人员的基本薪金（月薪或年薪）反映的是技术人员的经验水平和工作能力；各种形式的奖励（包括年终奖、项目奖、股权分配等）反映的则是技术人员在考核期限内的工作业绩。前者通常和技术人员的职位或技术级别挂钩，有相对明确的标准；后者，也即奖励数额的多少，就不那么好确定了。 一些公司直接根据技术人员的职位或级别来确定奖励额度，这实际上抹煞了基本薪金和奖励之间的根本区别， 体现不出奖金的鼓励和惩戒作用；另一些公司由老板或部门经理凭经验决定下属的奖励额度，在这种分配体系下， 即便负责奖金分配的领导没有半点私心杂念，最终也很可能出现按“苦劳”而不是按“功劳”分配的不合理局面。 有没有一种合理的、客观的工作业绩评价方法呢？其
实，只要项目管理和财务制度健全，我们完全有可能像评定销售人员的销售业绩那样，利用技术人员贡献给公司的“钱”数来评定其工作业绩，而且，我们还可以进一步把这种评定方式简化为计算技术人员在单位时间内的“贡献率”。 计算“贡献率”的方法有很多种，我个人比较喜欢以项目组为单位来考核“贡献率”的做法。即，先计算项目组的“贡献率”，然后给出项目组总的奖金额度。项目组内部各成员的奖金分配由项目经理自行决定。与单独考察每个技术人员“贡献率”的做法相比，这种做法既能保证评价规则的简明和参考数据的准确，也能赋予项目经理在项目组内部实施奖惩的基本权力。 我们可以用公式计算项目组在单位时间内的贡献率： 项目组的贡献率（R）=单位时间内项目组为公司创造的实际效益（V）÷单位时间内项目组的成本和费用总和（C）。 公式的分母部分很容易确定（查财务数据，一般包括
