为什么我们程序员总是这么累、做出来的东西这么差？

Posted on 2005-08-02 16:46 Aaron 阅读(523) 评论(2)   编辑   收藏 所属分类: 1.项目管理 、 3.开发过程

目前国内的很多项目是这样开始的：上头说，这个（或是产品或是项 目）开始做吧，你你，张三，技术好一点，带着大家做吧。就这样 ，开始了！
张三说，哥几个，咱开始吧！小A这块你比较熟，你负责吧 ！小B和小C，你们觉得哪几块怎么样？*&^*&^*(一番讨论 )，好吧，就这样，小B你这块，小C那块；还剩这个，我来吧 。我们要注意协调啊，大家有问题一起讨论！我们要统一编程风格 ，我们就采用那个《××编码规范》吧。等会儿我们一起讨论需求！

这个算是Kick-Off了！

接下来的需求讨论，大家热血沸腾的讨论了大致的功能点 ，和几个过细的细节问题。还强调一下：大家把各自的那块写成文档 啊，免得以后别人看不懂！
就这样，每个人就开始了各自的一块！满怀信心并且热情高涨！

很显然，这样写出的文档可能参差不齐、风格不一。

接下来又说：数据库很重要，我们先把数据库定下来吧！好 ，大家一致同意，坐在一起讨论，你把你这块的设计好 ，我把我这块的设计好，然后，大家再讨论一下，数据相互交换的 "互通有无、取长补短"，半天时间或一天把数据库设计搞个差不多 了。

这样，手脚快的甚至可以开始Coding了。

慢慢的，问题就开始出现了。

由于讨论方法问题、文档编写问题、各人个性问题等等啦 ，很多需求细节没有顾及到（如：用户信息具体包括哪些字段 ；谁可以删除用户记录，是不是所有用户记录都可以随意删除；等等 ），麻烦就开始了，程序员不得不自己冥思苦想，把需求"想"出来 ，或者跟其他人（如张三）。但是在这种情况下，讨论的效果会很小 ，原因有：
（1）大家各负责一块，你应该是对你这块最了解的 ，讨论了别人也插不上话
（2）在这样的项目组架构下，当事人可能自己就根本不会想到跟别 人讨论，理由同上条
（3）别人各自有"事"，根本没时间顾得上
（4）根据经验，从程序员的角度想需求，往往华而不实 ，离客户需求很远
反正凡此种种，自己一个人就边想边做，边做变想；还偶尔改改数据 库，当然还不会忘了通知其他人。

当然项目组其他人也不会好到哪里去，基本一样！

这样，恶梦就开始了！

小B说，我这里要这个数据，小C你给我加上！
小C说，考，又得改，为什么不早说？
而此时，作为负责人的张三早就无能为力了，而蜕为跟其他人一样的 全能的程序员。

在这个过程中，还有一点是，各程序员正充分发挥自己的"创造力" ，不但去想需求，还会把自己新学的一些东西发挥一下 。使用新东西很要命的，看书和做着玩儿的时候一点问题没有 ，一用到实际项目中就他妈这里也不行那里也有问题 。只得往里耗时间，并且抱着一副"不信我搞不定"的凌云壮志 ，原本以为一天搞定的东西，结果一周过去了还没搞定。 （顺便说一下，我很讨厌这种恶俗的自以为是的程序员心态 ！关于这个问题我会在其他地方具体谈谈）

这个时候，项目必定已经明显延期了！张三只能说：大家抓紧啊 ，比计划延迟很多了！（计划？听说过有计划嘛？）说完就埋头赶自 己的模块了。

再往后，灾难就开始了。
——项目延期
——功能越来越多
——模块间关系越来越复杂
——有些功能更加模糊，即使负责人也不能完整、流畅的说出来
——甚至有可能被模块负责人"不小心"忘掉了（真的是忘掉了嘛？ ）
——数据库已经不堪入目
——测试就随便找些数据过过场
——最惨的，项目组开始失去信心了
——不停的加班，效率已经下降了很多
——整个项目组的感觉就像：被蜘蛛网缚住的蝉，连动弹一下都很吃 力了
——绝望了

这个时候，领导要求去给客户安装……


哈哈，醒醒吧，现实没有那么恐怖，就当刚才是个噩梦。
现在再来这个项目过程中究竟有多少问题？
（ 下篇再说吧）

  http://aaronzhu.cnblogs.com/archive/2005/08/02/205774.html