愉快的项目

 

我从倾斜角超过45度的高级雪道上俯冲而下，寒风夹着带有结晶体的颗粒打在雪镜上劈啪作响，身边的景物飞速倒退……此时我的心提到嗓子眼，每根汗毛都竖了起来，心想：我是不是选错雪道了？

这是我第一次滑雪的情景，坐在缆车上看着众多高手从高级雪道上滑过，他们的速度看起来并不快。

……

我摆着舒服的姿势坐在办公室，一边喝咖啡一边讥笑身边那些已经失败的、即将失败的、看起来遥遥无期的项目：简直是一群精神分裂的人在做精神分裂的项目！

……

我修改着一年前的程序员留下的代码，时不时地对显示器竖起中指。它们看起来简直是一堆垃圾，运行缓慢、疾病缠身，或许还一脸的雀斑，我从来都不写这样的代码！我的代码考虑了各种异常，从不出错，无毒无害、绿色环保、低脂肪、低胆库醇、而且没有尾气。是这样吗？是的。也许并不尽然……

档案影像系统接近尾声，一切看起来还不错，两版测试一共20个bug也让我稍感满意，B/S版17个菜单4个bug让我得意了一阵子，我甚至加了点“彩蛋”。RDMS上的各种指标都好的出奇，所有工作都比预计提前完成，可以提前半个月交付客户使用，这些都让QA很满意，当然，我也很满意。

再次回忆一下这个项目的前世今生。

去年的11月份我们接到了东方有线单据影像项目，在毫无准备的情况下匆匆开发了这个系统。B/S部分短短11700行代码就有79个bug，组内程序员糟糕的工作态度终于惹怒了我，我在会议室大发雷霆。C/S部分稍好一点，这得益于两个熟练的老手。在紧张的修改后终于可以释放版本，提前两天交付客户。

此后的公积金影像系统也与此类似。

没想到居然接到了第三个影像系统，而且我们得知马上会有第四个。一切都让我们始料不及，一年前匆匆编写的方案和代码居然能够为公司开辟一个新的行业线，公司也有意将其继续做大。

既然知道了战略方向就用心去做。

项目周期通常分为几个阶段：

阶段1      可行性分析；

阶段2      需求分析；

阶段3      架构及设计；

阶段4      编码实现；

极端5      测试；

阶段6      系统完善，交付使用。

当然，这些阶段可以穿插和迭代。在阶段1前似乎应该增加阶段0，以便提供部分基础框架代码、完成简单的功能、技术难点研究，这部分工作可以与阶段1同步进行。我做了阶段0的工作，在复用已有代码的时候发现原来的代码与业务耦合度相当高，修改极其困难，于是我下令在一周时间内重构代码。清理垃圾是件索然无味的事情，但是为了清澄的世界我们必须这么做。

事实证明我的决定是对的，阶段0的工作让阶段4变得容易起来。我们每天进行代码复查。我的要求近乎苛刻，不允许任何重复的东西，所有人的代码必须清晰并且风格一致，，要么提交干净的代码，要么什么也不提交，总之你不能拿狗屎糊弄。

开发人员似乎都有急于编码的冲动，尤其当这个开发人员是个愣头青的时候。某个中午我发现了一个bug，告诉编写这段代码的开发人员一个简单的方法修改此问题。这个开发人员从午饭后就坐在显示器旁修改，两小时候他依然双眉紧锁。我忍不住上前询问，发现他正在写一个复杂的迭代，“我只需要得到办公文件的权限就能解决这个问题”他依然紧盯着显示器。“那么你没有找一下其他人的代码吗？我保证有你要的方法。”“我找了，但是没找到。”当我10秒中便找到那个方法后我又一次被激怒了。

软件复用似乎天生就存在两难的选择，创建或借用。每个项目迟早都会到达这个岔路口。世界上到处都是别人写好的代码，为什么还有那么多程序员扫了一眼其他人的代码就毫不客气的宣称，这不是我所要的方法，我可以轻易写出同样的方法，而且更快，更好。或者，根本就没打算寻找其他人的代码。这也是一大堆Another插件存在的原因。

在开发阶段也遇到了刺头，他打算重写所有代码。开发人员似乎渴望学习，希望写更多的代码，同时希望公司给予更高的报酬，这没错，但是在要求公司的同时我们是否想过，我们的工作究竟值多少钱？我们给公司带来了什么？最终我说服他放弃这个想法，尽管我们没有共同的立场，但是有共同的利益，要么大家一起活，要么一起死。

两条小型项目的经验值得今后继续发扬：

1.         任务、进度多做调整，每次只安排一周的任务，根据本周的完成情况调整下周的任务，同时也要规划一个蓝图，明确项目的里程碑和截止时间点。其实我见过很多信心满满的项目，从一开始就排好了今后几个月的任务进度，但是每个任务都是延迟完成，以至最后的缓冲时间段全部耗费在追赶进度而不是系统完善上。不妨观察一下身边的开发人员，他们在完成一个任务后是继续开始下一个任务还是坐在原地耗时间。如果他们继续工作或认真测试，那么恭喜了，否则作为项目经历的你就要考虑重新安排任务。初级滑雪者直到快撞到大树才被迫拐弯，高级滑雪者则不断拐弯，持续调整，将变化当作通常规则；

2.         每日评审，多做测试。这适合于所有项目，也是保证质量的最佳方法，记住，代码就是你的家，你生活在这里。

没有加班的日子固然愉快，但愉快的同时也暴露出团队存在的不足：

1.         技术水平薄弱。当需要我讲解正则表达式时我很火大，当需要我讲解int和Integer的区别时我简直想骂人；

2.         遇到问题时手忙脚乱。没什么说的了，提高自己的技术功底，静下心来仔细分析，其实一切都会迎刃而解；

3.         测试人员对需求理解不够深入。用例仅仅停留在字符串长度和规则的校验上实在没什么意思。当所有重要问题全部由我亲自提出时更让我火大。

看起来我是在抱怨，没错，我正是在抱怨。原本我们可以做的更轻松，提前的步伐更大，bug更少，只要我们再强一点。

希望我们今后能够更加顺利。感谢组内的兄弟能够忍受我的火爆脾气，当我用极高的音量讲话时他们能够默默地接受。

……

写在最后：

每天都想着烦人的业务逻辑，接着没完没了的电话，这简直糟透了，真想回到从前的日子。

大约两年前，我看到一本叫《Perl语言入门》的小册子（后来才知道这就是著名的骆驼书），第一次目睹了这种与众不同的语言，它嚣张顽劣、乖张散漫、放荡不羁，让我难以接受又倍感刺激……我疯狂地爱上它，每天晚上都乐在其中，同时也为它的缺点付出了代价——很容易忘记三天前写过的代码的含义——但是我才不在乎……我们每天都在谈论软件大势，掰着指头计算每种技术的钱途，这无可厚非，甚至非常重要，但是如果你热爱编程，或者至少以此为职业，那你总该为自己留一块纯净的技术空间，在那里抛开一切功名，享受纯粹的乐趣。