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

软件研发之殇

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

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

        第一，概念阶段。

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

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

        这个阶段出现的问题主要有下面几个：

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

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

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

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

        第二，计划阶段。

        在此阶段，主要是依据需求说明书来进行软件的具体设计，确定程序的运行流程及相关功能模块。这也是软件开发project师要干的事情。

        在这个阶段，可能出现的问题例如以下：

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

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

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

        第三，开发阶段。

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

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

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

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

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

        以上三点差点儿是开发者的通病，也是提高软件质量的最大障碍。

        第四，验证阶段。

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

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

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

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

        第五，公布阶段。

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

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

        第六，运营维护阶段。

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

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

        都说IT从业人员非常累，无论是做技术的，还是搞销售的。确实是这样，仅仅要产品有一个小小的问题，那么上面所说的六个阶段又要又一次走一遍，能不累吗？

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

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