在开发的q程中有错误发生了，此时你该如何应对呢？John Ferguson Smart在他?a >最新博?/a>中提Z一些想法，大家可以参考一?2008.10.27最后更?
C比以后Q何时候，都需要开发者更加高效。极度高效。组l需要提高从它们的开发项目中得到的附加|q且它们也乐于寻扑֮现这一目标的方法?br /> 当然Q你可以采用传统的方?-努力工作。ؓ了消除项目中不可预见的症Ӟ每天工作16个小Ӟq没有周末。但做的更聪明一点儿Q会不会更好些？
在引q新的实跉|法及改进现有Ҏ斚w投入的相对多一些，以ɾl织能努力获得更多回报，q就是开发的q程。一般而言Q事物中有许多方面都可以被改q，但此处有一些小H门能你的开发流E更加合理，只是Z开个头|了?br />
持箋集成(CI)通知{略的再思?br /> 到目前ؓ止，最通用的CI通知机制是陈旧的邮件服务器。然而，你能肯定在你手边能完成这Q务的最合适系l就是电子邮件吗Q尝试不使用电子邮gQ而用即时消息去完成你的CI通知。记住，电子邮g易成ZU干?-如果你仅仅大U每两小时才查阅一ơ邮Ӟ你就会变得十分高效。电子邮件只是，或至是Q用于构建失?-Z需?em>快?/em>地知晓失败Q务?br />
U极C化构E?/strong>
构徏度量(Build Metrics)是一U监控构E健L늚极好Ҏ。ؓ什么过?周中Q代码覆盖率一直在下降Qؓ什么单元测试的数量q未呈有规律的增长？Z么要p很长的时间去修复q样的构建？q行单元试需要多长时?-是否有一些测试需要执行过分长的时_q些信息q华而不实的东西--在不断改q构E的工作中，它们都扮演着关键的角艌Ӏ现代CI工具Q如HudsonQBamboo和TeamCityQ能为构建展CZ富的l计。Bamboo在这斚w做的佳。无Z正用何UCI工具Q都要学习如何最大限度地使用它的报表Ҏ，q用这些特性去定位及修复开发过E中讨厌污点。如果你的CI工具不能l你所需要的全部信息Q那找一个能做到的?br />
合理化发布过E?/strong>
在发布过E中有许多必做的工作Q如准备发行说明Q确定该版本中哪些问题已被解决了Q标记版本，{等。这些都是Y件生命周期的重要部分Q如果你忽略了它们，QA们和最l用户可能会很生气。但要尽量自动地dq些工作。许多CI工具能很好地与问题追t系l?如JIRA和Trac)q行集成Q以便你能基于版本控制日志看到某个问题是在哪ơ特定的构徏中被解决的。如果你在用EclipseQMylyn能帮你将处理q的问题归L逻辑变化l，q用标准的模板列出在某工作中已被解决?或仅是媄响到?问题。或者你可用Subversion的hook脚本ȝ保每ơ向Subversion做的提交都能对应C个有效的问题~号?br /> q只是一些想法Ş?-q有更多。底U就?-你不需要忍耐一个次理想的开发过E?-相反Q要q入其中Qƈ做些能改q它的事情。祝好运!
]]>
本文?a >java.net上的一?a >博客Q作?a >Curtis Cooley对编写好的面向对象代码有些徏议，希望对大安有所帮助?2008.10.08最后更?
获取l验没有捷径。编写好的面向对象代码需要经验，但这儿有三种做法能帮你在一开始就很顺利，即便你是老顽固：
1. 使用试驱动开?TDD)~写你所有的代码
2. 遵@单法?/a>
3. 告之而非问之
使用TDD~写所有代?/strong>
?a href="http://ponderingobjectorienteddesign.blogspot.com/2008/09/tdd-is-design-activity.html">试先行~写的代码与按测试后行编写的代码是极Z同的代码。按试先行~写的代码是松耦合与高聚合的。当某个属性或U有Ҏ需要暴露给试E序Ӟ按测试后行编写的代码怼打破装Q因cdƈ不是Z试而设计的。如果你首先~写试代码Q你的依赖将会更好，你的代码是松耦合与高聚合的。后面会有更多关于测试能帮助你设计更佳代码的内容?br />
遵@单法?/strong>
代码是简单的Q只要当它：
1. 执行了所有的试
2. 不包含重?br />
3. 表达了所有的意图
4. 使用最的cdҎ
注意到我用的是个被排序了的列表是很重要的。顺序是重要的。只有一个main()Ҏ的的GodClass[1]不会是简单的。这个类可能执行了所有的试Q但在Q何比"Hello, world!"更复杂的E序中，它肯定包含了重复Qƈ且也没有表达出全部的意图?br />
我努力用简单法则去xIf问题。我不知道如何用简单法则去L某h~写重量U的If代码。有人可能会提出不同意见Q我也尝试过Q但q样的重量If代码实无法表达意图。但当你阅读如下代码?/span>
if (mobile.getType() == MobileTypes.STANDARD) {
alert();
}
实难以看出其中的意图。这些代码无论处于哪个方法的上下文环境中Q我们都能知道，如果mobile是STANDARDcd的话Q那么就报警。而你所需要的更多意图呢？alert();
}
我还有一点儿灉|昄。如果有那样的代码，那么在其它地方肯定还会有更多那样的代码。这些代码可能就像：
if (mobile.getType() == MobileTypes.GAS) {
registerGasReading();
}
?/span>registerGasReading();
}
if (mobile.getType() == MobileTypes.TEXT) {
sendTextMessage();
}
?/span>sendTextMessage();
}
if (mobile.getType() == MobileTypes.LOCATION) {
notifyLocation();
}
你看出来了吗Q我是看出来了。它q反了规?Q有很多地方都违反了规则2Qƈ且是一U最坏的情Ş。这D代码有多处重复。重复将极难发现。所以，请帮助防止这U情形的发生Q我已包含其中了?br />
notifyLocation();
}
告之而非问之
a之，告之而非问之意指不要先问一个对象的状态，然后才让它去工作。而应该告之对象如何去工作。这意味着之前所有的那些If例子应该变ؓQ?/span>
mobile.alert();
?/span>mobile.registerGasReading();
?/span>mobile.sendTextMessage();
?/span>mobile.notifyLocation();
现假N布该E序中的一些If语句块有重复的实现。在"重量UIf"版本的程序中Q可能很隑֏现它们；但在"告之而非问之"版本的程序中Q所有的实现都在Mobile中。所有的实现都在一处，q就便于察觉q根除问题?br />
們你的试E序也能帮助你保持代码的z?/span>public interface Alarm {
void alert(Mobile mobile);
}
public class Siren implements Alarm {
public void alert(Mobile mobile) {
if (mobile.getType == MobileTypes.STANDARD) {
soundSiren();
}
}
}
public class TestSiren extends TestCase {
public void test_alert() {
LocationMobile mobile = new LocationMobile();
Siren siren = new Siren();
siren.alert(mobile);
assert(sirenSounded());
}
}
如果你密切地們试E序Q它可能会问你，"Z么你需要一个LocationMobileL试Siren呢？"的确Qؓ什么呢Q看hQSiren应该q不知道LocationMobile吧?/span>void alert(Mobile mobile);
}
public class Siren implements Alarm {
public void alert(Mobile mobile) {
if (mobile.getType == MobileTypes.STANDARD) {
soundSiren();
}
}
}
public class TestSiren extends TestCase {
public void test_alert() {
LocationMobile mobile = new LocationMobile();
Siren siren = new Siren();
siren.alert(mobile);
assert(sirenSounded());
}
}
public class LocationMobile {
private Alarm alarm;
public LocationMobile(Alarm alarm) {
this.alarm = alarm;
}
public void alert() {
alarm.alert(); // alert on Alarm no longer needs a mobile
}
}
public class TestLocationMobile() extends TestCase {
public void test_alert() {
Alarm alarm = EasyMock.createMock(Alarm.class);
alarm.alert();
EasyMock.replay(alarm);
Mobile mobile = new LocationMobile(alarm);
mobile.alert();
EasyMock.verify(alarm);
}
好像我只是交换了依赖关系。Alarm不再依赖MobileQ现在是Mobile依赖Alarm。但如果你仔l地观察q个试E序Q你会发现真正的依赖关系是，Siren知晓了LocationMobile。一个具体类依赖另一个具体类Q这q反?a >依赖反{原则(DIP)。第二个例子pLocationMobile依赖Alarm接口。具体类依赖抽象Q这满DIP了?br />
如果你用TDDQƈ遵@单法则和告之而非问之原则ȝ写所有的代码Q你处于成Z个更好的面向对象E序员的道\上了。好的面向对象代码易于阅dl护Q但难以~写Q至，在开始时是这L。你写的多Q你׃变得好Q也会获得更多的l验。同Ӟq些实践l验也会使你在自q道\上受益匪?br />
private Alarm alarm;
public LocationMobile(Alarm alarm) {
this.alarm = alarm;
}
public void alert() {
alarm.alert(); // alert on Alarm no longer needs a mobile
}
}
public class TestLocationMobile() extends TestCase {
public void test_alert() {
Alarm alarm = EasyMock.createMock(Alarm.class);
alarm.alert();
EasyMock.replay(alarm);
Mobile mobile = new LocationMobile(alarm);
mobile.alert();
EasyMock.verify(alarm);
}
译注
[1]GodClass(上帝c?指包含了太多内容的类?br />
]]>
是在~写一个方法之前就~写它的单元试Q还是在写完q个ҎQ甚x整个cM后才~写单元试呢？John Ferguson Smart[1]在他?a >blog中再ơ提Zq个问题QƈҎ自己的经验给Z一些徏议?2008.06.10最后更?
都别书生意气了。在你编写一个方法之前或是之后编写单元测?-Ҏ我的l验Q只要你在编写代码的几乎同时p虑q编写单元测试程序，那么q就无关紧要了。过后再q回?或者根本就不回?写测试程序将D问题。就我个言Q我喜欢在编写少量代码之前或紧接着的之后就~写单元试--q不会打破工作流E，因ؓ它就是流E的一部分?br /> q需要一点儿实践l验--~Zl验的开发者经ؓ要写什么样的测试程序而烦恹{但q可能也反映Z个事实：他们同样也不知道要写什么样的代码。一些h评说TDD能够鼓励q行微设?-一U非常底层的设计Q它不需要考虑较大的场景。这会发生在~Zl验的开发者n上；如果你教条般地应用这U方法，同样也会遇上。像行ؓ驱动开发这LҎ在此处就会很酗当你在写getterҎ之前Q你会写一个针对这个getterҎ的单元测试吗Q如果是的话Q那么你的单元测试专注的层次p高了Q也会更接近于用?或系l?的需求?br /> 回到问题的本质，Z么我喜欢把单元测试放在最开始的位置Q很单！我的实践l验告诉我，那样可以帮助提高代码的质量，q且节约调试旉。在开始时写十个小的单元测试所q旉比在以后修复Bug所q旉要少Q如果代码经q了正确的单元测试，那就不会有Bug了?br /> 事实上，我屡屡见刎ͼ如果某些代码l过了适当的单元测试，那么׃会有~码问题。最q就有一个例子：׃一个小时的旉L寻Web应用中的一个问题，该问题出现在一个编写正的Spring-MVCE序中。结果是׃一个检验器cd略了一个异常。很Ҏ发Cq个问题Q实际上Q在看了代码(代码?Code Review)也很有效)之后立刻发C。但关键是，我们׃一个小时甚x多的旉Lq个需要进行检查的cR如果这些代码经q了适当的测试，那么p很快地发现ƈ解决q个问题?br /> Ҏ我的l验Q当Z在编写完E序之后才开始编写单元测试，如同事后才有这LxQ他们很隑ֆ些测试了 ("我已l完成了所有的代码Q此时我q得d单元试")。或者根本就不去做。在q种情况下，代码是否完成了呢Q如果代码运行地很好Q那q是完成了。这L话，再写单元试大大地丧失了它的h倹{还不仅如此Q事后编写的单元试是肤浅的，不会对代码进行良好地试。或者，开发者已l耗完了时_他们Ҏ׃惛_为单元测试伤了?br /> TDD与Q何其它的~码实践一栗当你正在学习某个新的技术时Q你会們于对学习指导亦步亦趋。类似地Q当你学习一Ҏ术时Q你也会试着一步步地模仿大师的动作Q而不必去理解其中的逻辑。一旦你熟悉了某个技术，能够熟练C用它Qƈ对它有了更深入地理解Q?em>然后Q你p改进它，q与你之前掌握的其它技术进行溶合了?br />
译注
[1]John?a >Java Power Tools一书的M者，也是java.net中一位活跃的Blogger?br />
译后
上周在java.net上看到这BlogQ再联想到自己在qx工作中的单元试实践Q有些感触，故将其翻译了出来Q与大家׃n?br /> 事先q写单元测试，q是事后才编写单元测试？q是一个老问题。按照TDD的思想Q自然是要先~写单元试Q然后再~写能够通过该单元测试的Ҏ?br /> 但，单元试q不是TDD的专属领圎ͼ很多不实践TDD的项目也在应用着单元试?br /> 我认为，在不实践TDD的项目中(我自己所处的环境是如此)Q事后编写单元测试仍有着其合理性：
1. 以消极的态度来看Q既焉目本w不严格要求事先~写单元试Q那么就可以在事后去做了。这臛_比不d要好Q聊胜于无嘛?嘿嘿Q是够消极的Q但也拿你没办法)
2. 事后~写单元试臛_也是一U检验手D，当然Q肯定比不上事先~写的单元测试。因为，事后~写的单元测试很可能?就"已经写好的应用程序，正如John所?事后~写的单元测试将是肤的Q不会对代码q行良好地测?。但...仍然是聊胜于无嘛 :-D (哈哈Q有完没完了)
3. 可以把单元测试，其中包含事后单元测试，作ؓ"后来?了解、学习应用程序的手段。因为单元测试程序就是应用程序的"客户"Q所以无论它是事先写的，q是事后写的Q都能够表现出应用程序的行ؓ?br /> 4. 事后单元试Q也可能转化Z先单元测试。在应用E序的整个生命周期中Q维护阶D|最长的。在"漫长"的维护过E中Q?之前"所写的"事后"单元试会成ؓ"后来?(包括原始作者本??事先"单元试。在改进E序的过E中Q这些单元测试仍然能起到监督的作用?orzQ有点儿诡辩)
虽然Q事后单元测试明显不如事先单元测试，但它的作用仍然不可低估。只要编写了优秀的单元测试程序，无论是在哪个阶段Q它都会Ҏq应用程序有莫大的帮助?q可不是"聊胜于无"能够表达?
]]>
上个月就在TheSeverSide中看到关?a >q篇文章(实际是一简短的Blog)的消息，当时p得很有趣Q因己正在学习设计模式，故将q篇短文保存了下来。昨天在自己电脑中又看到了此文，手把它翻译了出来?br /> q篇Blog的作者认为大部分设计模式在代码层都是code smellQ在文末评论中有Google Guice目的leader -- Bob Lee的评语。Bob对作者的观点表示了赞同，但也指出框架可以减轻Ҏ式的需要?2007.06.04最后更?
在原始的Gof的书中，作者清楚地指出当你在用设计模式时Q?br /> E序设计语言的选择是重要的Q因为它会媄响某人的观点。我们的模式假设是用Smalltalk/C++语言U特性，q种选择军_了什么容?不容易实?Design Patterns, p.4)?br /> 不幸的是Q这条信息基本上被丢弃了Q程序员们时常将模式当作处方。Martin Fowler解释了区别：
处方于更加特别Q经常关联于一个特别的语言和^台。甚臛_一些模式需要依赖一个特定的q_Ӟ他们仍试图于用这些模式去解释更加一般的概念?br /> 如果你已l遇C个Java或C#应用E序看v来像C++的处理方式，你就会知道这两个概念的合将造成损害?br /> 不管你如何从处方中区分出模式Q你所思考的E序设计语言是你要Z所设计的程序语a。这也就是ؓ什么Prags鼓励每个人每q学习一U新的语a。你仍会ؓ你所知道的这l语aq行设计Q但臛_你将不会没有希望?br /> E序语言提前使模式不能成斏V回?998q_Petter Norvig争论道，大部分的原始Gof模式在Dylan或Lisp中都是无形或单的。之后，Greg Sullivan对Scheme持同L观点。Jan Hannemann也用Java+AspectJ证明了相同的观点。设计模式不能如处方那样发挥良好。它们最多是周期性的?br /> 在代码别，大部分的设计模式都是代码异味(code smells)。当E序员在代码查中看到了设计模式，他们׃滑入到催眠般的熟悉场景中。醒醒！那是一个设计模式，或者说是一个来自腐臭程序语a的失效药方？
]]>