曾经某个项目中的FUD

    “FUD”？从很多人讨论的言辞中后来才知道他们代表的意思是（F: Fear, U: Uncerntainty, D: Doubt）。很多时候，自己在无意识的时候，也会有这种类似的潜意识反应。

    记得若干年前在某个小公司做电子商务系统的建设。当时开发用的系统是.net平台，主要的工具是visual studio, sql server。在开发的过程中，开始感觉很快很顺利，可是越到后面的时候就感觉自己好像是陷入到一个泥潭中开始挣扎了。每次一到后面开发人员把自己负责的那部分代码写完成，然后checkin，再和其他开发人员开发的结果一集成的时候就发现有无数的问题来了。问题似乎总是找也找不完，大家拼命的加了好几个星期的班，后来系统勉强上线了。结果人也累倒了一大批，感觉每个人的身体都非常的虚弱。

    经过这个事情之后，我总结了一下项目中遇到的问题。主要有下面几个：

    一、项目中对需求的管理没有达成一个一致的理解

    因为主要是做一些外包的活，经常是从海外的同事发来的所谓需求规范文档里头来理解需求的规范。可是想想，一份好几百页的英文文档，写的又长又臭又无趣。而且，很多地方的描述是非常模糊的。有的时候你需要去一些文档的边边角角来找需求的内容。那么，这是一种合理的需求记录的方式么？经常是这么一种歧义还没理清楚，任务就已经下达给开发人员了，外包的活时间紧，一直差不多到后面实现做的差不多了才发现很多地方差异挺大的。结果回过头来又得改。

    二、对需求变更的管理不够

    项目中定义了哪些是必须要做的，哪些需要添加，哪些需要修改。这些都需要有一个比较精确清晰的描述方法，如果因为项目紧张一味的这么忙下去，最后给大家的理解和开发带来混乱更加得不偿失。在项目中因为这种改动，使得最后定义需求的文档也过时了，这种文档最终成了一个摆设，没有任何实际的意义。

    三、对软件质量的管理

    公司对项目质量的唯一衡量标准似乎就是只要能跑通就差不多可以了。经常是看到每个人把自己的代码一写完，感觉编译没有问题就checkin了。最后测试的时候发现了一堆的bug，这么来来回回的改了不知道多少个回合才能保证能够基本跑通。如果发现问题了呢？更多的时候就看到开发人员开着调试器这么一行一行的跟踪来发现问题。效率有多低就可想而知了。

    四、对代码的评审

    缺少一套完善的代码审核机制。项目组的管理人员似乎根本就不关心代码如何。于是当我参与到一个项目的维护工作的时候，我愣是看到一个只是为了显示一组商品列表的asp.net页面居然写出了2000多行代码。而其中一个方法的代码就有1000多行。如此之“神码”啊！现在想来依然有一种内牛满面的感觉。

    于是结合这些情况，我提出了一些后面改进的建议给部门的老大，希望后面能够做的更顺利了一点。主要也列了下面几点：1. 项目可以采用一种更敏捷的方式来推进，不需要一次揽太多的需求过来，这样定义不清晰容易遗漏和混淆。 2. 尝试做一些代码的审查，保证代码更简练可读。 3. 在项目中推行单元测试，保证自己开发部分的质量。等等。

    等我把这些建议的内容发出去之后，各位，各种有意思的回复就来了。

    老板：我们需要把项目按时按质量的做出来，如果项目的质量有问题，我就找谁的麻烦。我是要求很严格的人。你要知道，我们目前采用的过程是传统的瀑布模型，这是有很多年实践检验的一种方式，很成熟，我们这么做是一种很成熟的实践方式。如果有什么问题的话，你可以在项目组中负责这些过程和配置管理，大家加加班，克服一下。

    同事A：采用代码评审和单元测试？这样太麻烦了。你看，项目的时间这么紧，谁还有时间去做这些啊？要是因为这些项目完成不了，谁来担这个责任呢？

    同事B：我们用原来的这种方式都做项目好多年了，哪里有做项目不要加班的？干我们这行的都这样。

 

    各位，这种情况你们又碰到过多少次呢？你们又看到多少这种FUD的感觉在里头呢？我们有的时候是不是也有意无意的这么去想呢？