代码改变世界

朝得银弹,夕死可矣(续)

2004-08-01 15:33 FantasySoft 阅读(...) 评论(...) 编辑 收藏

        [前言]:今天是7月30日,离开公司也正好一个星期。而今天也是我呆在深圳的最后一天,再过不到24小时就要踏上北上的征途了。离职之后,在深圳的窝里呆了几天,对于软件开发,尤其是项目的管理,有了一些新的想法,遂延续前篇[1],将项目中的不足之处记于此,以作日后警醒之用。

        1、需求不明确;项目进行到现在,也有一年有余了,而进行需求分析和概要设计的时间也有近一年了。虽然我们有很多的文档,文档也是洋洋洒洒数千字,上万字,然而我们对于用户需求把握的程度还是很糟糕的。最明显的一点,由于我们所要做的系统第四版了,在此之前的第三版是十年前开发的。那么我们是对原有的系统进行升级呢?还是重新设计一个系统呢?我们的SA一开始都号称着要做一个全新的系统,然后都去跟客户做interview,去收集需求,可惜的是能力有限,时间又急迫,使得需求分析的结果还不足以指导进行概要设计。结果在开始做概要设计的时候,业务逻辑不清楚也没有采取进一步的措施。也不知道是谁提出了由旧系统的源代码去提炼业务逻辑,接下来公司就组织了很多SA,乃至AP去读源代码,然后根据这些源代码去写概要设计文档。说实在的,我觉得很不可思议,大家也许会说,读旧系统的代码没有问题啊。没错,以旧系统的代码作为参考是没有问题,可是如果是将旧系统的源代码直接转换成概要设计文档,我们前期做的业务需求分析不就一点用处都没有了吗?况且这样做,是不是也正好违背了做一个全新系统的想法呢?在我看来,根据源代码去提炼需求,并且做概要设计,无异于盲人摸象。缺少了整体考虑的需求分析,恐怕就是头痛医头,脚痛医脚,而人还是照样over了;

        2、缺少一个完善的training和学习的体系;我觉得这是一个很糟糕的问题。虽然大家会觉得一个小型公司要建立一个完善的training体系几乎是不可思议的,可是我想说,我们必须需要这样的一个体系,即使这个体系仅仅是针对现有的项目的。因为会随着项目的进行,有人会离开,也有新人会进来,如果没有一个完善的体系的话,人员流动对于项目的影响将是非常的大。而且在促进大家去学习的过程也可以提高大家的学习能力,也能够筛选出人才来;
    
        3、缺少激励机制;在项目当中,公司会有很多的惩罚措施,譬如会有一个所谓的红黑榜,然后只有人受罚,却没有人得到奖励。我曾多次表示反对这样的方式,因为我觉得人性总是本善的,应该通过激励的方式去促动大家努力工作。因此,我会想,如果有一个Expert排行榜,会不会更好呢?上榜人员是通过全体程序员投票选举出来的,公司将会对他们给予奖励。给予Expert称号的最大好处就是树立了在开发过程中的权威与榜样。如果有问题,可以找相应的expert解决,正所谓,闻道有先后,术业有专攻,他们既然是专家,就会对在解决相应问题的效率上和结果上都会有过人之处;同时也可以激励其他员工向他们学习,起到了模范作用;

        4、SA与代码脱离,与技术脱离;这是我最百思不得其解的问题。SA是什么的缩写呢?是System Analyist。那什么是系统?我没有办法给出准确的定义,但是我想一个系统必须是为实现某个既定任务而存在的,业务需求就是“任务”,确实是最重要的。那么,如何“实现”是不是也很重要呢?没有了可行的实现手段,所有的“美丽任务”都变成了Mission Impossible了。我觉得两者都是具有相同的分量的,SA要关注需求,更要关注实现。然而我们的SA更多时候是充当着行业专家的角色,可是他们并不是行业专家。结果这个角色耗费着项目的大部分资源,却鲜有贡献。既做不了设计,又做不了coding,到了我将要离开的时候,他们充其量只是一个工头了,问程序员,“什么时候能够做完啊?”,“我只要结果”。这多么的可笑啊!SA是可以不直接参加做coding ,但是他们不能够对技术几乎一无所知,否则,他们如何做分析呢?System的组成不仅仅是业务逻辑,而且业务需求最后也转化为一行行的代码,一个个能够运行的模块啊。为什么就只有SA给大家培训业务逻辑,却没有人为SA培训技术呢?可笑!

        5、缺乏诚信,缺乏敢于承担责任的勇气;在项目当中,从程序员到SA,都有一部分人员缺乏诚信。尤其是SA。我曾经听到三位subteam的老大关于保证业务逻辑的对话:
        A问B:“你怎么保证业务逻辑都已经OK了呢?”
        B马上说:“review代码咯。”回答得一点迟疑都没有。
        C听了,接着说:“你真的一个一个class去看,一行行代码去看?”B也表示了怀疑:“你知道一个模块里面有多少的class,多少的代码吗?你怎么可能看得完呢?”
        A显出一副无可奈何的神情点了点头:“没有办法啊,为了保证逻辑只好这么办啦。”
        哇,我听了都快吐出来了。先不说保证业务逻辑根本就不是通过review代码可以实现的,光说A的诚信就TMD的有问题。他作为SA,首先不可能有那么多的时间将我们所有的代码进行review,而且,我也能保证他从来都没有看过,因为他根本就没有办法对我们系统的整个架构说出个所以然来。还记得《程序员修炼之道》上的第一条:Take responsibility。与之相应的那一节的前面还有这样的一句名言:
        The greatest of all weaknesses is the fear of appearing weak.
        作为程序员,作为SA,乃至每一个做IT的人,都应该懂得承担责任,为自己的每一行代码,每一句话。我想这是做程序员的最基本要求吧。

        [后记]:今天是8月1日,随笔终于都写完了。一部分是30日写的,而大部分则是在北上的大巴上写的。离开了,放弃了,然后徘徊了,痛心了,最后惊醒了。到了一个新的地方,期待着新的开始。写得不当之处,还请各位多多批评。
       
        [1] 朝得银弹,夕死可矣