引言

    本来拉开架势准备继续做我的遥感影像库，然而世事难料，就在我实验正做得起劲的时候，一纸命令把我抽调到北京支援一个MIS项目。

    MIS项目我只在本科的时候做过一个，当时用的是ASP.NET，五个血气方刚的小伙子由于共同的兴趣凑到了一起，给学校做了一个本科生学籍/成绩/课程综合管理系统，虽然最后学校由于不具备项目需要的网络条件而没有用上那个系统，但现在回头看看，项目做的也算是有板有眼。头一次做这种规模的项目，就用上了源代码管理；文档也算中规中矩，都是按照国标格式写的。但我们当时的软工理论还很落后，对“统一过程”、“敏捷”等方法论都是到后期才开始注意的，对设计模式更是没有认识，所以整个开发过程基本是按照传统的瀑布过程进行的。最后学校只给了我们可怜的1000块人民币，但大家也没太当回事，因为得到了丰富的经验，获得了成就感，这在当时足够了。

    从那以后，本科毕业，大家各奔东西，我上研之后就开始做GIS，再没碰过MIS项目。到现在转眼将近三年，9月16日突然接到对我工作经验了如指掌的老板通知，抽我到北京救火，19号就动身。18号老婆才刚考完博啊，19号我就要走，实在是对不起她，但又没有办法，因为现在的我只是个小工，对这种事只有服从。

    然而当我赶到北京满怀希望打算重操旧业时，却发现事情远没有我想的那么简单。这两天利用十一放假的机会把前一阶段的项目日志整理了一下，分成几个部分post出来，以备查考。

        第一篇：“切五花肉”式的分工

    我面对的是一个被几乎一天一变的需求折磨得疲惫不堪的团队；一个初步看上去，代码几乎读不懂的烂尾工程。这里的负责人就告诉我一句话：“你是生力军。”

    而先于我两个月到达这里，一直泡在这个项目中的另两个同事则一边表达着对变化的需求的无奈与烦躁，一边向我展示由于不适应北方干燥气候而产生的皮肤反应，又一边不断自言自语对南方家乡的思念之情。看到此情此景，一种不祥的预感便从我心里油然而生。

    这仍然是一个使用ASP.NET开发的项目，仍然是分成数据库和前端代码两大块。我由于来的晚，没有赶上数据库设计和业务逻辑的架构设计。

    按照我过去的经验，MIS项目的分工大概应该分层划分。本科时我们五个人的分工为：一个人专门设计数据库，使用ERwin，一个人专门写存储过程，与设计数据库的结成一组；另外一个人和我结成一组，负责写业务逻辑，由于人手不够，他也同时负责页面美工；最后一个人专门负责测试。项目中应该产生的文档都由我来写。

    设计数据库的专门负责数据库设计，编写存储过程的专门负责数据层和业务逻辑层的接口，编写业务逻辑的可以无须知道数据库的具体结构——有多少表，都叫什么，都有什么约束关系，而只管将前端需求变成一组接口，由存储过程来实现它们。这样角色、权限、安全等等都可以与数据层的相关机制结合起来，而且在业务逻辑层代码中见不到一条SQL语句，取而代之的是对存储过程的调用，其功能从存储过程名便一目了然，不清楚的再稍加注释。我觉得这样划分应该还是比较合理的。一是因为职责分明，开发人员各负其责；二是容易让彼此之间有清晰的接口，降低耦合度，特别是专门设立存储过程开发人员大大降低了数据层与业务逻辑层之间的耦合度，存储过程作为一个重要的独立部分的存在屏蔽掉了底层数据层的变化对上层业务逻辑的影响。这样代码的清晰度、安全性、效率自然而然的就上了一个档次。

    然而这次我看到的情况却完全不同。我刚到的时候，正好赶上有一块新的需求在前一天讨论确定。于是负责人就让我做这部分，并且这样交代我：
    “数据库的ER图就在vss里面，你根据需要，要添什么表就自己添，要改什么表和关系就自己改，只要加上comment就可以了。除了要实现功能以外，页面也要自己画，只要风格和整体一致就可以了。”

    我当时就郁闷了——等于是从数据库设计到画页面一条龙全要我一个人搞？！对这种分工方式我把它比作“切五花肉”。在我看来这简直就是胡闹。然而郁闷之余，与其它单位的同学交流了一下，居然这种分工方式当下还非常流行！一般就是一到两个号称很牛的博士，项目拿来便开始“切五花肉”，一人一块，分完还不忘撂下一句“这个，没啥”。干去吧~~~

天哪……

    这简直就是对OOA/D、分层编程模型、设计模式等等基本原则的肆意践踏和蹂躏。也难怪他们已经被不断变化的需求折磨得焦头烂额了，须知“Requirements always change”啊。这种“切五花肉”式的分工弊端再明显不过了：
（1）、所有开发人员必须对数据库的设计、业务逻辑的设计开发、客户端逻辑的控制和页面的美工都非常熟悉；
（2）、作为项目基石的数据库设计由多人仅仅以vss中comment的沟通方式合作完成，这些人对数据库都是管中窥豹，而且他们各有所长，有的对数据库设计较有经验，而有的可能只略懂皮毛，这样设计出来的库能不是“豆腐渣”吗？
（3）、不断变化的需求就像是一场场地震，破坏力会从底层一直波及到顶层；
（4）、项目就是一盘散沙，没有整体的设计；
（5）、协调成本非常大，对项目经理的要求一下子提到很高，因为要想在这种分工模式下开发出基本能用的系统，就必须严格定义好每个人之间“肉块”与“肉块”的接口，还有每个人自己“肉块”内部各层之间的接口。否则最终的系统只能是一锅“肉酱”。然而更加不幸的是应该做这种协调工作的项目经理根本就不存在。

    明知道这样做下去必将坠入这痛苦的深渊，等待我的也将是与他们一样无尽的折磨，但我也无能为力，因为我现在不是两年前的项目负责人，而只是个普通的小工。

    痛苦的历程才刚刚开始，接下来的日子里，了解项目架构，读原来的代码，我在这倒退的历史中品尝着无能为力的苦涩。

    未完待续