软件开发过程中,我们经常遭遇各种各样的问题,而本文就是要讲解这些问题中最棘手的12个。读完本文后,相信读者会对它们影响开发效率的原委有个初步的认识。
 
  我们发现,有很多的文章、书籍都在阐述软件的开发方法,为什么呢?个人以为那是因为提高团队的开发效率是一场永无止境的战争。软件的开发技术日新月异,开发 团队只能不停地适应这种革新(如果这个团队不是此项技术的领头羊),否则只能消亡。而适应很大的程度表现在效率和时间上,因为客户对软件质量的要求是越来 越高,同时却不希望延长开发周期。
  我们知道,随着软件外包的到来,同一个团队的开发人员可能来自不同的国家,他们处在不同的时区,有着不同的文化背景。和其它行业的人一样,开发人员往往喜欢把精力用在他们感兴趣的任务上面,却经常忽略了更重要的事情——开发效率。
  在软件开发这个繁杂的世界里,作为一个项目经理,也作为一个开发人员,我碰到过各种各样的有趣的问题。这篇文章就罗列出了这些问题中最棘手的12个,并提供一些处理问题的参考意见。(原文请参见我的Blog:[url]http://lauploix.blogspot.com[/url]
  1.维护的开销是效率最大的敌人
  软件的维护需要很大的开销,它很自然地把开发团队带向低效。维护的开销往往和代码行数成比例,尤其当代码没有经过很好的测试的时候,这个情况尤为明显。开发团队会发现:随着代码行数的增加,bug的数目也会随之增长,当然,bug产生的原因包括内部因素和外部因素。内部因素的的确确是我们的代码的问题,而外部因素实际上并不是程序的bug,但是无论如何必须修正。
  说得更详细点,外部因素可能是你调用的代码改变了,或者是运行环境改变了。例如,一段Java代码在JRE1.4下面工作得很好,客户要求它升级到JRE 1.5下也能运行。这个时候,如果不能运行,你可能会声明原因不在程序上。但是客户可不管那么多,站在他的角度上,这就是你的程序的bug。
  实际上,完美的程序是不存在的,在做项目计划的时候必须考虑周全。因此,在开始编码之前,你就应该把维护的开销算到软件开发周期里去。甚至在思考怎样编码之 前就应该思考怎样去测试。而且,你还得考虑怎样让服务器自动测试你的代码——如果一个测试不能做到完全自动化,那么它只能算作半个测试。只有让测试做到完 全自动化,团队才能在新的环境里毫不费劲的测试自己的代码,也可以迅速高效地对测试进行扩展。
  刚刚提到的,你必须找到一种可行的方法能够保证你的代码能够被自动地测试,的确如此,但这也是在单元测试中存在的一个问题,因为单元测试不可能面面俱到。事实上,如果对测试进行分层,测试的效率可能会大大提高(关于分层测试,将在后面作具体的阐述)。
  2.开发人员讨厌测试,他们不按照测试的规范去做
  代码在某个环境中能正常工作,就假想它在其它环境中也能正常工作,这是软件开发人员的通病。在现实生活中,这根本就是不可能的,可开发人员却生活在虚拟的完美世界中,他们认为这个世界里万事万物都是完美的,不可能遭遇任何的问题。例如,一个J2EE程序在JBoss下工作正常,开发人员往往理所当然地认为在WebSphere下也能正常工作,事实却未必。所以,开发人员有必要在所有的目标平台上测试代码。否则,程序就有可能无法通过。
  我相信,你一定需要一个框架,使你的程序能够在任何平台下工作,而且能够把测试结果保存到数据库中。概括地讲一下过程:你写好各种语言的测试代码,它就可以 在各种平台下自动测试,保存测试结果。之后,你就可以查阅测试结果了。这个结果包括各个平台下、各个版本的代码的测试的历史。
  据我所知,某些工具支持这些功能。例如,BuildBot 开源项目正在为之而努力,至少在不久的将来可以实现这个目标。
  3.出现bug时,分析原因比修正错误更耗时间
  当开发人员修改好代码,并把它提交到代码库里的时候,你必须反应迅速,及时地测试他(她)提交的代码,这样,如果测试不通过,开发人员就还记得他(她)刚刚修正过的地方,也很容易找到bug的原因所在。
  时间一长,他可能就忘了,Bug出现时不得不查看代码历史,比较不同版本的代码,直到代码原因分析出来。很有可能光找原因就白白的耗费了几个小时,太不值得了!
  4.开发人员在转换项目过程中花费了太多的时间
  通常来说,搭建一个项目的开发环境是不容易的。如果对项目没有很好的了解,不具备一定的专业知识,要搭建好环境几乎是不可能的。如果仅仅是搭建环境就花费很 长的时间,开发人员往往更希望长期呆在同一个项目环境中。比较理想的状况是:开发人员有能力毫不费力的从一个项目转到另一个项目,不存在技术难题,“项目 文化”已经不是个难题了。
  对此,我有个建议:使用项目管理工具,比如Apache Maven。用Maven描述的项目一般很容易在Eclipse中搭建起来。对于Java项目来说,只需要要从SVN下载代码,键入“maven eclipse”,刷新,它就可以工作了。所有与代码对应的测试代码也可以运行!哇,简直是太神奇了!整个项目不到30秒就建好了。
  很可惜,这项技术目前还只支持Java。至于其它的语言,如Python、C,等等,仅仅Maven还是不够的。
  5.随着开发人员的增加,Bug也增加
  如果方法不得当,一般来说,开发人员增加的同时,程序的bug数目也会增多;随着程序的复杂性的增大,软件的质量也会下降。而我们必须与之作斗争。那采取什么方法呢?很简单的理论:透明、代码审查和自动测试。
  透明能够确保每个人都能得到代码,决定谁去修改它,何时修改,或者是为什么要修改它。透明能够确保团队的每个人都会因为自己的代码质量而感到压力,并由此而产生动力。
  而代码审查呢?开发人员对别人的代码进行审查,不仅能够从别人的代码中学到东西,而且它还确保开发人员有效地发现代码的问题,对提高代码质量功不可没。
  至于自动测试,我们在下面进行详解。
  6.分层测试
  不可否认,写出好的测试代码的确是个很大的挑战。例如,代码写好后,对它们进行单元测试就很困难,单元测试不可能测试到程序运行的方方面面。功能性(质量保证)测试对程序测试相当有效,不过它通常运行慢,对问题发生的原因给出的信息往往很不够。
  因此,你不得不对测试进行拆分以克服这种情况。如果简单的基础测试都无法通过,那么运行更大的测试显然是无意义的。分层测试的目的就是让测试从易到难。
  ——第0层:开发人员在自己本地环境中进行的单元测试。
  ——第1层:构建服务器上的单元测试,(几乎每个)代码提交之后开始。
  ——第2.1层:集成测试,在几个模块整合到一起之后进行的测试。(用真正的模块代替掉原先的模拟模块。例如,使用真正的XML解析器换掉原先的那个替代品)
  ——第2.2层:集成测试,通过入口访问系统(接口、磁盘等等,到这儿,你可以测试访问真正的系统)
  ——第3层:功能性测试,测试程序可见的部分。(用户能够看到的实实在在的功能,当然,这一层还不够)
  ——第4层:性能测试。
  ——第5层:客户体验。(OK,这并不是一个测试层,但是这个环节的确会发现不少意料之外的bug)
  这个方法的理念是同一个bug决不会再次重现。因而,对于每个你发现的bug,你都应该创建测试用例以保证它不会重现。这个测试可能是单元测试(这样最好),也有可能是集成测试。
总之,问题发现得越早越好,这意味着我们可以更早修复它。所以如果某个问题能够尽量的在第0层发现,我们就不要让它等到第3层才发现。随着测试代码的增加,代码质量也会越来越健壮。
  7.严格限制使用编程语言的数目
  如果你无论完成什么任务都为它选择最好的工具,那么当你的任务越来越多,你采用的工具也越来越多,这可不是什么好事。如果你总是为短期的目标选择最便捷的方 法,系统的复杂性会随之增加。所以,有时候,你不一定要选择最好的工具。在同一个团队里,最好只使用一门语言,尽量不要超过两种语言,否则单单培训开发人 员的成本就不少。例如,Ruby on Rails就是个很好的工具,但是它涉及到不止一门语言和技术。在用它的某种技术开发网站之前,必须要考虑所有的花费。如果你们的主要活动就是开发网站,那么这条规则对你并不适用,因为在这种情况下,Ruby很可能变成你们项目组的主要语言了。
  我的观点是,选择有限数目的编程语言。当然,你也必须确保这种技术对你们公司有用。例如,有必要用四种网络服务框架吗?没必要,一种足矣。
  8.紧跟技术的发展和革新,不过这个比较困难
  我们很容易碰到这种情况,为了实现某个功能你必须付出很大的努力,但是实际上已经有工具可以做到这点,但是我们却不知道。如果我们关注着技术的发展,包括开 发框架的革新,方法的提出等等,就可以避免这种情况的出现。幸亏有这种关注的习惯,我发现了现在我用得几乎所有的工具:Eclipse, Maven, Tomcat, Apache, LDAP, CruiseControl, TestNG, Python,等等。它们中大多数工具都可以为我节省很多工作。有的项目本来需要几个月的开发时间,结果缩短到几周。
  比较困难的就是如何去选择工具(要花费很多时间去选择工具),而且还得避免你的工作团队同时使用太多的技术。有个建议,当使用某项技术还在实验之中的时候,我们最好不要用,最好等到它已经实现了,有成熟的产品了。
  另外一个挑战就是评估、选择新的技术。如果要对旗鼓相当、都是很有竞争力的框架进行评估,并从中选择一两个的话,这个难度一般也很大。
  9.为了保持效率,最好不要被频繁地打断
  在解决复杂的问题的,开发人员一般需要7到15分钟进入高效的状态。如果从一个活动转到另外一个活动(电话,电子邮件等等)就会打断开发人员的进程。例如,如果一个团队的开发人员每20分钟就有个技术服务的电话骚扰他,哦,这完全是灾难性的。因此,我们不应该允许用户直接打开发人员的电话。
  取而代之,我们应该建立一个工具收集问题、bug、需求等等来完成这些工作,这样开发人员就可以专心致志地忙他的本职工作。这样的工具很多,包括Mantis 和Jira。
  另外一点,记住,开发人员并不是机器,他是人。为什么项目经理要求开发人员记住——存储——他们的要求?难道他就不能把他的要求写下来吗?
  10.定义好构架与编码同等重要
  在没有构架的基础上进行编码如同在没有灯光的夜晚驾车。你有可能达到你的目的地,但是行程很慢,也很危险。如果有构架师,他就会经常审核原始的产品,预测可能出现的问题。缺少了构架师,系统能难有很好的框架,如果每次加进一个新功能,系统复杂度就会大大增加。
即使编码没问题,据我所见到的走捷径的项目,基本上都多多少少存在些问题。这就是产品构架师应该对产品的框架有一个全局的概念的重要原因。
  11.开发人员和产品使用者考虑的重点不同
  开发人员总是对“有趣”的任务感兴趣,而产品的使用者总是希望产品的功能对他的客户有用。开发过程中,应该尽量地做到,至少应该使这两个目标比较接近:让开发人员解决比较无趣的问题时也让他很高兴。
  据我所看到,Scrum就 是个不错的软件管理方法。它主张在一个开发过程里,开发人员准时地提交结果,这时,开发人员的自尊心就会成为一个强大的动力。当然,当项目经理提出某一个 用处并不大的需求时,如果开发人员很难准时提交结果,也就是说,这个功能需求在实现上困难很大,但是又没有很大的用处,这个时候项目经理应该在提需求之前 三思,是否有必要提这个需求。当然,有时间可以研究一下,Scrum方法的确相当不错。
  12.代码规约很高效,必须强制执行
  代码规约把开发人员从理解代码的格式上解放出来,让他们有更多的时间去理解代码的核心含义。在我工作的团队里,我们建立了自己的规约,包括代码存放的目录,文件名,还有代码本身(类的名字、方法、变量等等)。
  某些SVN插件甚至可以禁止不符合代码规约的代码提交。呵呵,不错!
  ● 将影响效率的问题消灭在萌芽状态
  大多数开发过程和方法的目的就是为了解决效率问题。本文指出了开发过程中的几个我观察到的并牢记在心的问题。希望你能够从我的经验中学到些东西,同时,世上并没有那种解决方案是银弹,我建议看看Scrum,因为它的确提高了开发中各个环节的效率。