首先我必须有力的反击在软件开发中充满迷惑性的两点误区,据我所知者两点误区已经深深毒害了软件开发人员多年,大大的降低了代码质量。他们是:

1.       我们的代码应该有很多文档。
2.       我们的代码似乎很烂。

首先来看看误区1:

在软件开发中,新加入一个项目的程序员常常会有这样的抱怨: “我们的代码没有文档”。这种抱怨甚至会得到项目中已经颇有经验的程序员的附和。但其实这种抱怨是带有不合理要求的,不应该支持的,是可以驳回的。
首先,这世界上90+的软件是没有(或缺乏)文档的,千万不要以为在大公司会有很“理想”的写一大堆文档然后才开始写代码的“正规流程”。如果不相信,可以问问你在大公司,比如Microsoft, IBM等工作的朋友,看看我们耳熟能详的那些软件到底有多少文档。似乎只有外包公司比较重视文档,然而敏捷开发的风行也使开发者对书写笨重的文档难以保持耐心。文档与代码的不同步也使许多文档变得失去意义。
其次,让我们来看看文档对于开发者的意义。也许新加入的项目组成员会想,在理想的情况下,只要让我先看看文档,一点代码都不用看。等我通读完文档后,我打开代码就懂得全部的代码啦!然而这真的很幼稚。
好吧,也许你理由还是很充分,你认为磨刀不误砍柴工,你认为…. , 总之你认为就是应该有文档嘛!但是我们得面对现实的对不对,现实是,你所拥有的只是一堆代码,放在一个Visual Studio的Solution文件里面,你无法使用心爱的Adobe Reader, Microsoft PowerPoint and Visio,你只能使用对着Visual Studio,阅读一行行代码,所以,你所能考虑的只应该是如何多快好省的搞懂这些代码。


当然,我不是说你应该不写文档。


误区二:
好吧,无论有没有文档,有一件事情是肯定的,你现在对代码有了一些了解。是时候发表点自己的评价了,于是你说:


         “我们的代码烂到家了!”
你的评价是有道理的,因为你的评价基于你对软件开发的真知灼见。你举出了无可动摇的事实,你说:


         “这个地方应该用State模式,而我们则使用了大量的 if, else, switch。这个函数纯粹就是一个万能函数,并且与另一个函数严重耦合,更糟的是函数名也挂羊头卖狗肉。这个地方应该用二分查找,这里则应该用动态规划提高效率…”总之:


“这代码真应该从一开始就让我写!”


         好主意!如果一开始就让你写,或许你会理解所有代码的来龙去脉,你会认为代码本来就应该是这个样子。你会认识到我们为得到这些混乱的代码,所付出的巨大努力:一个个优秀的程序员,一个个目光犀利的QA,以及大量花数年时间使用我们软件的客户,如辛勤哺育孩子一般,让我们的软件逐渐成长起来,而有人却认为他很烂?!


         现在让我们看看我们的代码,看看这个5000行以上的函数,里面署有50位程序员的大名。而他的功能仅仅是显示一个窗口,随着岁月的积累,他开始变得庞大。但是不像中年发福的人,这个函数的增长,是在积累有用的东西,那就是:Bug fix。有人发现在没有安装Internet Explorer时窗口不能正确的现实,有人为内存不足时正确的现实窗口做了点特殊处理,为了使某个将数据存储与局域网服务器的客户能看到给窗口,我们还得加点代码;至于丑陋的LoadLibrary的调用,则是为了支持Windows 98以及Linux用户。
         所有这些bug的发现都是在我们的软件被大量使用 - 测试之后发现的,定位这些bug花了我们大量的精力,时间。在一个个Bugfix 中,我们的软件从一个婴儿 – 单纯,简洁,变得越来越成熟,稳定,越来越善于处理来自客户的需求。然而,随着一个个Bug被修掉,我们的代码会逐渐零乱,代码中或许会混杂着各种各样的风格,或许会有重复的API调用,或许有些地方必须要提高性能了,甚至或许会有自相矛盾的地方。但是你应该感觉得到与这微不足道的缺陷相比,他所能提供的强大的功能,他所具有的巨大的容错性,才是我们代码真正的本色!


         至于那些毛病,我们有你,优秀的开发人员。对于软件进化已成为软件开发主流的当代,代码重构是一个程序员最需要提高的能力。
         况且,从态度来说,一个喜欢自己工作与之上的code base的程序员,会有更积极的态度,因而也更能改进现有的代码。
 


Comments




Leave a Reply