首页 > 代码库 > 让你提前认识软件开发(39):软件研发之殇

让你提前认识软件开发(39):软件研发之殇

第3部分 软件研发工作总结

软件研发之殇

 

        在经典著作《人月神话》中,作者提出了一个观点:绝大部分的软件研发项目都不能按期完成。我工作也有一段时间了,发现这确实是一个不争的事实。我所从事的项目中,能按期按质完成的还真的很少。这是什么原因呢?我工作不够努力吗?非也。为了完成任务,我也是经常加班加点地工作,生怕惹恼了上司而饭碗不保。

        软件研发是一个系统的工程,是由很多环节组成的。你一个人把自己那部分工作做好了,还不足以保证整个系统能正常运转。在本文中,我按照软件的生命周期(如下图所示)来分析软件研发的各个阶段会出现的问题,供大家参考。

 

        第一,概念阶段。

        在这个阶段,主要是售前人员(也可能有其他称呼)与局方(也就是客户)谈合同,弄清楚他们到底需要一个什么样的东西,并反馈给系统工程师(System Engineer,简称SE)SE再写成需求说明书给软件开发人员。

        软件研发项目出现的问题,很大部分要归咎于这个阶段。问题越是发现得早,解决起来就越是容易。而这个阶段中一个小的问题,在后期也会被放得很大。

        这个阶段出现的问题主要有以下几个:

        (1) 售前人员为了“讨好”局方,签了一些令人“匪夷所思”的合同。社会竞争越发的激烈,在信息技术领域尤其如此。在众多公司的竞标中,能够签到合同实属不易。为了签到合同(同时满足公司考核指标),售前人员总是在客户面前拍胸脯,不惜以各种承诺、豪言壮语换回那利润已经薄得很可怜的合同。在这些合同中,有很多是有待考究的,需要反复思量的。可大部分售前人员都不懂技术,签完合同之后就“领赏”去了,这就害苦了开发人员,也影响了产品研发的进度和质量。

        (2) 局方人员高高在上,经常将自己的想法变来变去。就像现在雇主招聘应届生一样,局方(也就是所谓的甲方)在众多的公司(俗称乙方)中进行选择,不仅将合同的金额压得很低,还隔三岔五地将售前人员叫过去,让他们修改需求说明书。说得不好听,这是不诚信的表现。每当这个时候,总会有人冒出一句:“谁让人家是甲方呢?”

        (3) 系统工程师(SE)没有将需求写清楚,没有表达出局方人员的意思。每个人对事物的看法不同,写出来的东西就会有所不同,更何况从局方人员到售前人员,再到SE,中间已经转了好几次,出现表达的差错也是在所难免的。而SE有时又比较的“懒”,不想与局方人员进行深入的交流,认为自己已经明白意思了,这也导致后期软件功能不合局方之意,又要推倒重来。

        我们经常说,要将坏的事物扼杀在萌芽状态。在概念阶段,也就是软件雏形的形成阶段,一定要将软件的功能搞清楚,这样也省去了后期的很多不便与折腾。

 

        第二,计划阶段。

        在此阶段,主要是根据需求说明书来进行软件的详细设计,确定程序的执行流程及相关功能模块。这也是软件开发工程师要干的事情。

        在这个阶段,可能出现的问题如下:

        (1) 软件详细设计完成之后,不经评审就马上开始编码。公司有规定,详细设计要经过评审之后才能启动开发。而很多时候,为了赶进度(我个人比较讨厌“赶进度”这三个字),这个环节也省去了,直接导致开发人员按照个人想法来设计软件,出现了理解上的偏差,最终导致客户验收不通过。为了保证软件的正确性,一定不要吝啬那么一点点时间,要请有经验的同事来评审自己的详细设计。所谓的“磨刀不误砍柴工”,也就是这个道理。

        (2) 软件开发人员为了应付评审,写出了详细的程序流程,可启动开发之后,偏离了之前的想法。这在研发过程中也是经常出现的。当我们照着软件详细设计阅读代码的时候,发现程序流程与文档中的流程图不相符,而且有时偏差还比较大。这就是开发人员个人素质的问题了。在编码的过程中,一定要尽量忠于自己的详细设计,而在确实需要修改的时候,要同步更新详细设计文档。

        在很多项目中,设计阶段往往与开发阶段合二为一,一边开发,一边设计。我个人认为这是不恰当的,一定要对程序流程有全面的了解之后再开始编码。

 

        第三,开发阶段。

        开发阶段,就是将想法用程序来实现的阶段,也称为编码阶段。这个阶段的重要性不言而喻,问题出得最多的也是这个阶段。

        只要是参加过软件开发的人,都会知道这个的阶段的问题会出在哪里。我总结了一下,应该有以下方面:

        (1) 不按公司的编程规范来办事,编写出只有自己才能读懂的代码。这是最令人头疼的事情。当我们打开前面一个开发人员编写的程序文件,一眼就能够看出其专业素质和态度。在我阅读过的程序中,真正符合编程规范的极少,大部分都存在这些问题:无注释、变量和函数命名不规范、程序逻辑混乱、程序版式不工整等。在前面的文章中,我对这方面的内容也做了详细的说明。总之,不管怎样,规范是必不可少的,尽量不要破坏“游戏规则”。

        (2) 不用最简洁的方式来编程,故意卖弄自己的水平。很多开发人员水平比较高,他们喜欢用一般人不知道的方法来写代码,以表现自己的能力。但他们忘了,我们是要用代码来实现产品的功能,而不是来展现自己的水平有多高(展现的地方是网上的各种编程大赛)。当你的后任来读到令人费解的代码时,他们绝对不会赞美你的水平有多高,而会在心里骂你。在很多著作中,都对这方面的内容进行了阐述,一个中心思想就是:我们要用最简单、最通俗易懂的方法来编写程序

        (3) 不注重对程序进行自测,以为测试就只是测试工程师的事情。在很多开发人员的观念里,自己只管把代码写好就行了,剩下的测试任务有专门的人来完成。现在,大公司都在强调产品质量,强调对产品进行充分的测试。对于开发人员,要求则是要自测充分,尽量保证提交到测试部的程序是零差错的。也许有很多人看不起搞测试的,也不想自己找自己的问题(测试就是要找出问题),但这并不是喜不喜欢的问题,是职业素质对我们的要求。

        以上三点几乎是开发人员的通病,也是提高软件质量的最大障碍。

 

        第四,验证阶段。

        验证阶段,也可以叫做测试阶段,主要是由软件测试工程师来对开发工程师编写的程序进行测试,以保证软件质量。测试方式分为白盒测试和黑盒测试两种,大部分到软件公司实习过的人应该都知道。

        本来,测试人员和开发人员应当是“亲如兄弟”,大家合力来共同保证产品质量,而现在的情况却相反,开发部和测试部有时是“苦大仇深”,互不往来。开发的看不起测试的,认为那个没有什么技术含量;而测试的也以找到开发漏洞为荣,很多项目甚至设定了指标,每个月要提多少故障单(提单就是发现了开发问题),搞得开发人员是心神不宁,很是反感。

        如何解决这个问题呢?首先,公司的考核机制要变,不能以什么提单数量来考核员工;其次,开发人员和测试人员要多沟通交流,不要“老死不相往来”;再次,要以交付出高质量的产品为共同目标,而不是整天以“抓小辫子”为乐。

        当然,我上面的表达可能有不当的地方,但多多少少说明了一个事实:开发和测试应合作多于对立

 

        第五,发布阶段。

        测试完成之后,就应当将产品交付给客户,请他们来验收。在这个时候,最怕的就是他们当场变脸,说产品功能不满足他们的要求。这种情况还经常出现,导致很多项目出现严重的亏顺。

        为了避免此类事情的发生,在软件的开发阶段,相关负责人(特别是SE)一定要起到协调沟通的作用,将已实现的功能让客户知道,请他们确认这是否是他们想要的。可以看出,交流沟通在哪里都很重要。

 

        第六,运营维护阶段。

        产品商用之后,公司还要对之进行维护,出现了问题要及时修补更正。一般说来,只要产品测试验证得比较充分,出现问题的几率还是比较小的。怕的就是客户脑袋发热,一会儿想出这个,一会儿又想出那个,这样开发和测试人员又要忙碌起来了。

 

        如上所述,软件研发是一个复杂的系统,只有系统的每一部分都正常运转,整个系统才能够一切正常。一旦某个环节出了问题,那么系统就犹如漏水的轮船,如不及时修补,终将沉入大海。

        都说IT从业人员很累,不管是做技术的,还是搞销售的。确实是这样,只要产品有一个小小的问题,那么上面所说的六个阶段又要重新走一遍,能不累吗?

 

        本文以作者的工作经验为基础,结合个人的感悟,表达了对软件研发项目的一点看法。不当之处,还请各位批评指正。总之,纵使夜晚多么的黑暗,明天太阳还是会照常升起。工作主要是看心态如何,你觉得呢?

 

 

(本人微博:http://weibo.com/zhouzxi?topnav=1&wvr=5,微信号:245924426,欢迎关注!)