Five Habits of Highly Profitable Software Developers
by Robert J. Miller
08/24/2006
翻译:Coody Sk8er  http://www.blogjava.net/chords



原文地址:
http://today.java.net/pub/a/today/2006/08/24/five-habits-of-highly-profitable-developers.html



当今技术引领经济社会大量的需要能够在团队环境中开发出稳定质量的软件开发人员。在团队开发的环境中,开发者面对的挑战就是读懂别的开发者写的软件。本文将文章尽力帮助软件开发团队来克服这样的困难。

本文为了阐明了五个让开发团队变得比以往更加高效的好习惯,首先将介绍公司业务对开发团队以及他们开发出软件的需求,接下来会解释状态改变逻辑和行为逻辑之间重要的区别,最后会通过顾客账号这么一个案例来阐述这五个习惯。

业务带给开发人员的需求

公司业务团队的工作就是在决定将哪些对公司业务最有利的新价值可以被加到软件中。这里的“新价值”指的是新产品或者是对现有产品的强化。换句话说就是,业务团队决定什么将给公司带来最多的钱。决定了下个新价值是什么的关键因素是实现它的成本。如果实现的成本超过了潜在收益,那么这个新价值就不会被加到软件中来。

业务团队要求开发团队能够尽可能低成本的,并且是在规定时间内以及在不失去原有价值的情况下创造新价值。当软件增加了一定价值后,业务团队会要求一份描述现有软件所能提供的价值的文档。这个文档将帮助他们决定下一个新价值是什么。

软件开发团队通过创造出容易理解的软件来满足商业团队的需求。难以理解的软件带来的后果就是整个开发过程的低效率。低效率会造成软件开发成本的增加,引起一些预料不到的现有价值的损失,开发周期滚雪球般越拖越长以及交付错误的软件文档。通过改变业务团队的需求,甚至将复杂的软件转变成简单、容易理解的软件,就可以提高开发过程的效率。


介绍关键概念:状态和行为

开发容易理解的软件可以从创建有状态和行为的对象开始。“状态”是对象在调用方法前后所保存的数据。一个JAVA对象的实例变量可以暂时的保持自己的状态,并且可以随时存放到数据存储器里。这里,永久数据存储器可以是数据库或者是Web服务。“状态变更方法”主要管理一个对象的数据存取。“行为”则是一个对象基于状态回答问题的能力。“行文方法”回答问题永远不会修改状态,并且这些方法往往跟一个应用的商业逻辑有关。


案例研究:CustomerAccount对象

下面这个ICustomerAccount接口定义了管理一个客户账号对象必须实现的功能。这个接口定义了可以创建一个新的账号,加载一个已经存在的账号的信息,验证某个账号的用户名和密码,验证购买时这个账号是否是激活的。
习惯一:构造器尽量少做事

第一个应该养成的喜欢就是让类的构造器尽量的少做些事情。理想的情况就是构造器仅仅用来接受参数给实例变量加载数据。下面一个例子,让构造器做尽可能少的事情会让这个类使用起来比较简单,因为构造器只是简单的给类中的实例变量赋值。造器是用来创建一个类的实例。构造器的名字永远是跟这个类的名字是一样的。既然构造器的名字无法改变,那么它就不能表达出它做的事情的含义。所以,最好是尽可能的让构造器少做点事。另一个方面,状态变更方法和行为方法会通过自己的名字来表达出自己复杂的工作,在“习惯二:方法名要清晰的表现意图”中会详细讲到。下一个例子表明,很大程度上是因为构造器十分的简单,更多的让状态变更和行为方法来完成其他的部分,使得一个软件具有很高的可读性。

习惯二:方法名要清晰的表现意图

第二个习惯就是要让所有的方法名字清晰的表现本方法要做什么的意图。例如isRequestedUsernameValid()让开发人员知道这个方法时用来验证用户名是否正确的。相反的,isGoodUser() 可能有很多用途:用来验证账号是否是激活的,用来验证用户名或者密码是否正确,或者是用来搞清楚用户是不是个好人。方法名表意不清,这就很难让开发者明白这个方法到底是用来干什么的。简单的说,长一点并且表意清晰的方法名要比又短又表意不明的方法名好。

表意清晰的长名字会帮助开发团队快速的理解他们软件的功能意图。更大的优点在于,给测试方法也起个好名字会让软件现有的要求更加的清晰。例如,本软件要求验证请求的用户名和用户密码是不同的。使用名为testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername()的方法清晰的表达出了方法的意图,也就是软件要达到的要求。
惯三:一个对象只进行一类服务。

第三个喜欢就是对象只关心处理一小类独立的服务。一个对象只处理一小部分事情将使得代码更好读好用,因为每个对象代码量很少。更糟糕的是,重复的逻辑将花费很多时间和成本去维护。设想一下,业务部门将来要求升级一下isRequestedPasswordValid()里的逻辑,然而有两个不同的对象却有着功能完全一样但是名字不一样的方法。这种情况下,开发团队要花费更多的时间去更新两个对象,而不是一个。

这个案例表明了CustomerAccount类的目的就是管理一个客户的帐号。它首先创建了一个帐号,然后严整这个帐号能否用来购买产品。假设软件要给所有购买过10件物品以上的客户打折。再创建一个接口叫ICustomerTransactions和一个叫CustomerTransactions的类,这样会让代码更加易懂,并且实现目标

习惯四:状态变更方法少含有行为逻辑

第四个习惯是让状态变更方法少含有行为逻辑。混合了状态变更逻辑和行为逻辑的代码让人很难理解,因为在一个地方处理了太多的事情。状态变更方法涉及到远程调用来存储数据的话很容易产生系统问题。如果远程方法是相对独立的,并且方法本身没有行为逻辑,这样诊断起状态改变方法就会十分容易。另外一个问题是,混合了行为逻辑的状态代码很难进行单元测试。

习惯五:可以任意次序调用行为方法

第五个习惯是要保证每个行为方法之间保持着独立。换句话说,一个对象的行为方法可以被重复或任何次序来调用。这个习惯能让对象实现稳定的行为。比如,CustomerAccount's isActiveForPurchasing()和getPostLogonMessage() 行为方法都要用到accountStatus的值。这两个方法必须在功能上相互独立。

总结

上述的五种习惯会帮助开发团队创造出方便阅读、理解和修改的软件。如果开发团队仅仅是想快速的创造价值而不考虑将来的规划,他们软件的实现将会耗费越来越多的成本。当这些开发团队要审查软件来理解和修改时,不可避免的会遭到自己写的坏代码的报复。如果软件十分难以理解,在增加新价值的时候会花费巨大的代价。然而,一旦开发团队将良好的习惯运用到开发实践中,他们会以最低的成本为业务提供新价值。