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接口定义了管理一个客户账号对象必须实现的功能。这个接口定义了可以创建一个新的账号，加载一个已经存在的账号的信息，验证某个账号的用户名和密码，验证购买时这个账号是否是激活的。
public
interface
ICustomerAccount
{
//State-changing methods public void createNewActiveAccount() throws CustomerAccountsSystemOutageException; public void loadAccountStatus() throws CustomerAccountsSystemOutageException; //Behavior methods public boolean isRequestedUsernameValid(); public boolean isRequestedPasswordValid(); public boolean isActiveForPurchasing(); public String getPostLogonMessage();
}
习惯一：构造器尽量少做事
第一个应该养成的喜欢就是让类的构造器尽量的少做些事情。理想的情况就是构造器仅仅用来接受参数给实例变量加载数据。下面一个例子，让构造器做尽可能少的事情会让这个类使用起来比较简单，因为构造器只是简单的给类中的实例变量赋值。
public
class
CustomerAccount
implements
ICustomerAccount
{ //Instance variables. private String username; private String password; protected String accountStatus; //Constructor that performs minimal work.
public CustomerAccount(String username, String password) {
this.password = password; this.username = username;
}}
构造器是用来创建一个类的实例。构造器的名字永远是跟这个类的名字是一样的。既然构造器的名字无法改变，那么它就不能表达出它做的事情的含义。所以，最好是尽可能的让构造器少做点事。另一个方面，状态变更方法和行为方法会通过自己的名字来表达出自己复杂的工作，在“习惯二：方法名要清晰的表现意图”中会详细讲到。下一个例子表明，很大程度上是因为构造器十分的简单，更多的让状态变更和行为方法来完成其他的部分，使得一个软件具有很高的可读性。
注：例子中“...”部分仅仅是真实情景中必须的部分，跟本文要阐述的问题没有关系。
String username
=
"
robertmiller
"
;String password
=
"
java.net
"
;ICustomerAccount ca
=
new
CustomerAccount(username, password);
if
(ca.isRequestedUsernameValid()
&&
ca.isRequestedPasswordValid())
{ 
ca.createNewActiveAccount(); }
相反的，如果构造器除了给实例变量赋值以外的事情，将会使代码很难让人理解，并且有可能被误用，因为构造器的名字没有说明要做的意图。例如，下面的代码将调用数据库或者Web服务来预加载账号的状态：
//
Constructor that performs too much work!
public
CustomerAccount(String username, String password)
throws
CustomerAccountsSystemOutageException
{ this.password = password; this.username = username; this.loadAccountStatus();//unnecessary work.}
//
Remote call to the database or web service.
public
void
loadAccountStatus()
throws
CustomerAccountsSystemOutageException
{ }
别人可能在不知道会使用远程调的情况下使用这个构造器，从而导致了以下个远程调用：
String username
=
"
robertmiller
"
;String password
=
"
java.net
"
;
try
{ //makes a remote call ICustomerAccount ca = new CustomerAccount(username, password); //makes a second remote call ca.loadAccountStatus();}
catch
(CustomerAccountsSystemOutageException e)
{ }
或者使开发人员重用这个构造器来验证用户名和密码，并且被强制的进行了远程调用，然而这些行为方法（isRequestedUsernameValid(), isRequestedPasswordValid()）根本不需要账户的状态：
String username
=
"
robertmiller
"
;String password
=
"
java.net
"
;
try
{ //makes unnecessary remote call ICustomerAccount ca = new CustomerAccount(username, password); if(ca.isRequestedUsernameValid() && ca.isRequestedPasswordValid()) { ca.createNewActiveAccount(); }}
catch
(CustomerAccountsSystemOutageException e)
{ }
习惯二：方法名要清晰的表现意图
第二个习惯就是要让所有的方法名字清晰的表现本方法要做什么的意图。例如isRequestedUsernameValid()让开发人员知道这个方法时用来验证用户名是否正确的。相反的，isGoodUser() 可能有很多用途：用来验证账号是否是激活的，用来验证用户名或者密码是否正确，或者是用来搞清楚用户是不是个好人。方法名表意不清，这就很难让开发者明白这个方法到底是用来干什么的。简单的说，长一点并且表意清晰的方法名要比又短又表意不明的方法名好。
表意清晰的长名字会帮助开发团队快速的理解他们软件的功能意图。更大的优点在于，给测试方法也起个好名字会让软件现有的要求更加的清晰。例如，本软件要求验证请求的用户名和用户密码是不同的。使用名为 testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername() 的方法清晰的表达出了方法的意图，也就是软件要达到的要求。
import
junit.framework.TestCase;
public
class
CustomerAccountTest
extends
TestCase
{ public void testRequestedPasswordIsNotValid BecauseItMustBeDifferentThanTheUsername(){ String username = "robertmiller"; String password = "robertmiller"; ICustomerAccount ca = new CustomerAccount(username, password); assertFalse(ca.isRequestedPasswordValid()); }}
这个方法简单的被命名为testRequestedPasswordIsNotValid()，或者更糟的是testBadPassword()。这两个名字都让人很难搞清楚这个方法是用来测试什么的。不清楚或者是模棱两可的测试方法名会带来生产力的损失。从而导致花费来越多的时间来理解测试，不必要的重复测试，或者是破坏了被测试的类。
最后，明了的方法名还能减少文档和注释的工作量。
习惯三：一个对象只进行一类服务。
第三个喜欢就是对象只关心处理一小类独立的服务。一个对象只处理一小部分事情将使得代码更好读好用，因为每个对象代码量很少。更糟糕的是，重复的逻辑将花费很多时间和成本去维护。设想一下，业务部门将来要求升级一下isRequestedPasswordValid()里的逻辑，然而有两个不同的对象却有着功能完全一样但是名字不一样的方法。这种情况下，开发团队要花费更多的时间去更新两个对象，而不是一个。
这个案例表明了 CustomerAccount类的目的就是管理一个客户的帐号。它首先创建了一个帐号，然后严整这个帐号能否用来购买产品。假设软件要给所有购买过１０件物品以上的客户打折。再创建一个接口叫ICustomerTransactions和一个叫CustomerTransactions的类，这样会让代码更加易懂，并且实现目标。
public
interface
ICustomerTransactions
{ //State-changing methods public void createPurchaseRecordForProduct(Long productId) throws CustomerTransactionsSystemException; public void loadAllPurchaseRecords() throws CustomerTransactionsSystemException; //Behavior method public void isCustomerEligibleForDiscount();}
这个新的类里面有状态变更和行为方法，可以储存客户的交易并且判断是否能够打折。这个类创建起来十分简单，方便测试以及稳定，因为它专注心这一个目标。一个低效率的方法是如同下面的例子一样在ICustomerAccount接口和CustomerAccount类加上新的方法：
public
interface
ICustomerAccount
{ //State-changing methods public void createNewActiveAccount() throws CustomerAccountsSystemOutageException; public void loadAccountStatus() throws CustomerAccountsSystemOutageException; public void createPurchaseRecordForProduct(Long productId) throws CustomerAccountsSystemOutageException; public void loadAllPurchaseRecords() throws CustomerAccountsSystemOutageException; //Behavior methods public boolean isRequestedUsernameValid(); public boolean isRequestedPasswordValid(); public boolean isActiveForPurchasing(); public String getPostLogonMessage(); public void isCustomerEligibleForDiscount();}
就像是上面所看到的一样，这样使得类具有太多职责，难以读懂，甚至更容被易误解。代码被误解的后果就是降低生产力，费时费力。总的来说，最好让一个对象和它的方法集中处理一个小的工作单元。
习惯四：状态变更方法少含有行为逻辑
第四个习惯是让状态变更方法少含有行为逻辑。混合了状态变更逻辑和行为逻辑的代码让人很难理解，因为在一个地方处理了太多的事情。状态变更方法涉及到远程调用来存储数据的话很容易产生系统问题。如果远程方法是相对独立的，并且方法本身没有行为逻辑，这样诊断起状态改变方法就会十分容易。另外一个问题是，混合了行为逻辑的状态代码很难进行单元测试。例如，getPostLogonMessage() 是一个依靠accountStatus的值的行为：
public
String getPostLogonMessage()
{ if("A".equals(this.accountStatus)){ return "Your purchasing account is active."; } else if("E".equals(this.accountStatus)) { return "Your purchasing account has " + "expired due to a lack of activity.";