软件开发之殇

 很早就想写一篇有关软件研发中遇到的问题的文章，但一直苦于没有时间。最近刚完成了一个新的项目，我对各种问题又有了新的认识。在此以“软件研发之殇”为题，记下软件研发的各个阶段会遇到的各种问题。

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

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

 

 

        第一，概念阶段。

        在这个阶段，主要是售前人员(也可能有其他称呼)与局方(也就是客户)谈合同，弄清楚他们到底需要一个什么样的东西，并反馈给系统工程师(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)还会不断更新，欢迎大家关注！最后，感谢大家一直以来对本博客的支持！