摘要: 在没有学会“把事情作对”之前，怎么能妄谈“做对的事情”？魔鬼存在于细节之中，如果不能hands on去做一线的事情，又怎么能空谈战略呢？最近的事情让我深刻体会了这一点，但是却没太多改进，惭愧！ 阅读全文
摘要: 巴尼是一个项目经理，组织的高层只知道瀑布式生命周期。他们觉得迭代式的做法就是浪费时间。他们希望在项目的第一周就看到甘特图，这样项目经理就可以按照甘特图管理，一切都能按部就班进行。如此一来，无可避免的是：要是巴尼报告说项目没有按计划进行，有些高层就会这么说：“哎，按照日程安排，你的进度应该到这儿。没能按照计划进行，你是怎么回事啊？”
决策层对于项目的了解并不深入，他们不知道，人们在项目中是根据经验来思考和行动的。他们相信，关键路径会永远保持不变，任务安排顺序也一直大体相同。
发生如此状况，原因在于：一直以来，决策层看到的报表是由已经完成的工作、销售数字或其他数据构成的，这些数字反应的是在过去发生的事情。然而，项目日程是对于工作未来进展的猜测。该日程游戏也被叫做“梦幻时间日程” 阅读全文
摘要: 经过过去几年的努力，您的公司已经开发了一个庞大的代码库和一个同样庞大的 JUnit 测试套件。一切都很正常，直到大约一年前，测试套件包含了 2000 个测试，同时人们开始注意到运行构建过程用时超过三个小时。在此之前的几个月，由于 CI 服务器资源紧张，您在代码签入时通过 Continuous Integration（CI）停止运行单元测试，并将测试切换到夜间运行，这使得之后的早晨时间非常紧张，于是开发人员努力去弄清楚是什么出错以及为什么出错。
这些天，似乎测试套件整晚极少超过一次运行，为什么会这样呢？因为它们费时太多！没人会仅仅为了弄明白系统是否运行良好而几个小时守在那里。此外，整个测试套件都是在晚上运行，不是吗？
由于测试运行得太不频繁，它们常常充满了错误。因而，您和您的团队开始质疑单元测试的价值：如果它们对代码质量那么重要，那又为什么会让人这么头痛呢？你们的结论是：单元测试有其重要的作用，但必须要能用一种更为敏捷的方式运行它们。 阅读全文
摘要: 太上，不知有之；其次，亲而誉之；其次，畏之；其次，侮之。功成事遂，百姓皆谓：我自然——老子 《道德经》
上面的引言节选自老子的《道德经》。是说：最好的领导是让下属感觉不到他的存在；二等的领导是大家都爱戴的领导，三等的领导是大家都畏惧的领导，四等的领导是大家擦拳磨掌要把他打倒的领导。大功告成，诸事办妥后，老百姓都认为没有受到干扰，实现了自然发展。也就是说，完成的过程没有受他人强制的感觉，是人们的本性使然。
项目经理领导、项目经理指导、项目经理策划、项目经理管理，这些都是需要承担让软件项目实现业务价值这一责任的项目经理所背负的重担。虽然项目经理在整个交付机制中处于一个关键的位置，但是如果他成为一个团队的中心，则会给团队带来不必要的风险。实际上，项目经理应该用一种更温和的方式来开展项目，从内部帮助团队走向成功，建立一个可以让每个人（包括他自己）受益的系统。 阅读全文
Beck全家似乎都弥漫着技术的味道。生长在硅谷, 有着一个对无线电痴迷的祖父，以及一个电器工程师父亲。从小就引导Kent Beck成为了业余无线电爱好者。在俄勒冈州大学读本科期间，Kent Beck就开始研究起模式。然而在他最终拿到计算机学位之前，他却是在计算机和音乐中交替学习。似乎Java大师都能够有这样的能耐，另一Java大牛Rod Johnson同样也拥有音乐学的博士学位。Kent Beck一直倡导软件开发的模式定义。早在1993年，他就和Grady Booch（UML之父）发起了一个团队进行这个方面的研究。虽然著有了《Smalltalk Best Practice Patterns》一书，但这可能并不是Kent Beck最大的贡献。他于1996年在DaimlerChrysler启动的关于软件开发的项目，才真正地影响后来的软件开发。这次的杰作就是XP（极限编程）的方法学。和软件开发大师Martin Fowler合著的《Planning Extreme Programming》可谓是关于XP的奠基之作。从此，一系列的作品如《Test Driven Development: By Example》，《Extreme Programming Explained: Embrace Change》让更多的人领略到了极限编程的精髓，也逐步导致了极限编程的流行。Kent Beck的贡献远不仅如此。对于众多的Java程序员来说，他和Erich Gamma共同打造的JUnit，意义更加重大。也许正是这个简单而又强大的工具，让众多的程序员更加认可和信赖极限编程，从而引起了Java敏捷开发的狂潮吧。
摘要: Kent Beck和Martin Fowler撰写了《规划极限编程》（Planning Extreme Programming）一书专门详细阐述了在极限编程（XP）中如何来规划和计划Project，有兴趣的朋友可以在此下载并阅读。在阅读过程中，我也把一些重要的Notes记录了下来，供大家参考。 阅读全文
l 在TDD中，按照Failed -> Passed –> Refactoring的步骤进行，写完Test Case并在写Code或改Code前，应该先运行一下Test Case，这时应得到一个Failed或Error的结果，以确保Test Case不是在任何情况下都会Pass，以确保它确实能验证程序的结果。
l 最好用小步伐的节奏进行TDD。
如果要写的程序有10个function要完成，应该按照以下的方式进行：
写function1的Test Case -> 写function1的Code并使Test Case通过 -> Check-in -> Code Review/FingBug/Refatoring -> Check-in -> 写function2的Test Case…
这样的好处是：
n 每步的范围越小，测试、查错和Roll Back越容易，也有利于最简设计和最简实现。
n 完成的部分完全可交付。
l 以Iteration为单位进行计划（Planning）、开发和跟踪（Tracking）。定义Iteration的原则是：
n Simple：一个Iteration不应能被拆分为Task，如果可以拆分，应考虑继续拆分为若干个Iterations。
n Clear：Iteration的需求/User Story应该是清楚的、确定的。如果一个Requirement Point部分确定，部分未确定，而已确定的部分已可独立开发，应该把确定的部分定义为一个Iteration，减少未确定部分对整个进度的影响。
n Independent：一个Iteration应相对独立，不应与其他部分有太多的依赖。
n Short：一个Iteration不应超过3周。
我们应该结合这4个原则进行Iteration定义。
l 不管是auto test还是manual test，都是testing的手段而已，Testing的有效性取决于Test Case的质量和覆盖率。可以通过以下方法提高Testing的有效性：
n 邀请Customer提供或者和他们一起制定Functional Test Case。
n Pair Programming
n 如果不能进行Pair Programming，也必须在前期和中期与其他同事Walk Through或讨论Test Case，减少遗漏。
l 如果Customer不能配合我们进行短Iteration开发，不妨把Release分为Internal Release和External Release。对外发布按照Customer的要求和步伐，而内部我们按照自己的步伐进行持续集成和测试。
l XP Planning的一个重要原则：
One of the most important principles in planning for Extreme Programming is that the dates are hard dates, but scope will vary.
当Deadline临近，我们已确定无法完成本Iteration计划的全部时，应该及时和Customer沟通，把剩下的部分进行Prioritize，把最重要的、可在Deadline前完成的部分先完成，按时交付，把未完成的部分定义为新的Iteration，并把它和其他所有未开始的Iteration一起进行Prioritize。这样可避免一味延时带来的恶性循环，也可确保整个Project最重要的部分被优先完成，因为很有可能，未完成的部分并不那么重要。
软件设计的学问很深，学一点可以开拓思路，学透了可以成为专家，而学得半透不透的时候，感觉就会像一种病，一种“设计病”。
得了“设计病”的程序员干活很慢。你看那些刚毕业的年轻同志，拿到任务后立刻打开开发工具，又是点又是敲的，一会儿就能看到界面，程序功能一个一个地不断被实现，速度快的很。得了“设计病”的程序员就不能这样。拿到任务后左思右想，总觉得这样也行，那样也不错，一个小程序他能想出几百种方法来，光权衡就得半天。写程序通常也不从界面开始做，闷着头在键盘上狂按了好久，程序还是不能运行，搞得项目经理直冒汗。
“设计病”的程序员写的程序，写着费劲，看起来劳神。通常别人写一个函数的，“设计病”人非要写成好几个。使用面向对象开发语言的更是如此。“设计病”人写的程序里，类特别多。人家用两三个类就可以实现的功能，“设计病”人要用五六个类，甚至更多。还弄一些个类，一堆虚函数，一个成员变量也没有。稍大一点的程序就有几十上百的类挤在一起，关系也很复杂，一般人还真看不懂。
和“设计病”人讨论问题也不容易。通常大家都在谈这是个什么功能，某个功能怎么样才能实现，而“设计病”人常常不讨论这个，嘴上总挂着什么“复用”、“耦合”、“模式”等一类莫名其妙的词汇。就算“设计病”人在讨论功能的时候，听起来也和程序的实际功能相差很远。比如当大家在讨论使用多线程实现的时候，他就讨论线程管理类的接口；当大家讨论发送数据要缓冲的时候，“设计病”人却在研究如何实现一个快速的数据队列。
事实上“设计病”人自己也很痛苦。他们对现有的方案总是不满意，甚至昨天他自己写的方案，今天再看时也觉得不满。自己费尽心机设计出来的可复用的类，却从来都没有被复用过。自己好不容易设计出的松耦合的模块结构，在增加新功能时，却不得不在很多层次的类上做修改。
“设计病”也很难治好。“设计病”人总是不由自主地做设计，不愿意用直接的方式实现程序，总想把程序一点点剥开、分解。怎么劝都不会有用。他们相信迟早有一天自己的设计会发挥作用。
“设计病”人写出过很多烂程序。要么设计失败，考虑不周，程序结构有问题，要么过度设计，简单的功能，大堆的类，还不如不做设计。
不由自主地去设计，努力去写出烂程序，不是一种病又是什么？
如果您觉得也得了“设计病”了，也别太着急，办法有一个，就是继续“病”下去，努力做设计。直到有一天，能平衡完美和实用了，这病也就好了。
作者：苏林
自动测试成为你Java项目中的一部分了吗？你最爱的测试框架是什么哪？使用的又是哪一种标准？
本文的4名开发者将和你一起分享他们在自动测试领域中的观点和经验。当你的项目面临测试阶段的时候，希望这些观点能对你有所帮助。如果你也想要分享自己的观点，请回帖参与讨论。我们真挚的希望我们能够为这个领域中新手提供一些有用建议和标准。
文章最后列出了文章的作者和提到的测试框架。
论自动测试——Tom Wheeler当我给那些有经验的开发者上课时，我发现只有40%左右的人写测试。大约还有40%的人甚至从来没听说过JUnit，这其中更有一般人完全没有单元测试的概念。开发者通常处于在项目经理制定的紧促计划的压力中——而那些项目经理同样处于客户的压力之下，客户希望他们的软件能够被快速的开发出。不幸的是，测试是项目中的一个重要部分而很多人却轻易的将它砍掉。真是目光短浅，那种做法只会让你的应用成为bug的乐园而且会大大超出你的计划时间。
为什么会这样？因为写自动测试实际上省下了大量的运行时间。每个开发者都会出错而通过测试可以帮助找到这些错误。可能手工测试在某些方面要比自动测试更快一些，但是手工测试需要用户界面。手工测试的结果并不一致，因为测试者和开发者一样都会犯错。而一个自动测试总会保持结果的一致性。
也许更重要的是，当一个旧bug被修复或者新特性被添加时会引入更多的bug.你需要在改变系统后重新运行所有的测试。这也是自动测试的价值体现，因为对比手工测试的开销，自动测试的开销是微不足道的。如果开发者经常测试，他们可以更容易地发现并修改问题，这可以保证代码质量并保证团队开发的进度。
比较JUnit和TestNG——Meera Subbraro Martin Fowler曾说过，软件开发领域中此前从没有过这样的事情：很少几行代码对大量的代码起了如此重要的作用。JUnit过去直到如今依然是单元测试的一个标准。它是最流行的开源工具。当然现在我们有许多有别于JUnit的其他的开源工具。我自己，除了使用JUnit外，我还是用TestNG.下面我们来谈谈下这两个框架。
JUnit和TestNG都使用Annotation，都使得测试简单有趣。如果你写两个测试类，一个使用JUnit一个使用TestNG，除非你看到它们import语句，否则你几乎看不到他们之间的差别。
如果你是一个TDD的信徒，通过运行测试来完成你的持续集成过程。TestNG可能更加适合。重新运行失败的测试这样的机制对于每天都进行编译来说非常有帮助。而这个特性只有TestNG才有。
TestNG的另一个亮点是支持参数化。在JUnit中如果你要测试不同的参数，你需要写不同的测试用例来覆盖不同参数。而在TestNG，通过使用xml配置文件做到。开发者可能会抱怨XML文件“这下好了，除了要维护那些测试用例，我还要维护那么一堆xml文件”。（译者按：JUnit4也已经支持参数化测试了）
JUnit生成的HTML格式的报告非常好。我使用TestNG和Java 6，生成的报告远没有JUnit那么漂亮。
最后，两个框架都有自己的长处和弱处，必要时我们可以同时使用。让我们使用这两个伟大的框架，享受编写测试的快乐吧。
我为什么从JUnit换到了TestNG上——Andres Almiray当我开始编写测试程序时候，我选择了JUnit3.x.因为那个时候它是唯一的开源选择，而且有着相当详尽的文档和成堆的书供我参考。在此基础上还有许多扩展如dbUnit，xmlUnit帮助测试一些大型组件。但是如果我们需要面对更多复杂的测试，通常是集成/功能测试，很明显JUnit会力不从心。那就是为什么我换到TestNG上。Cedric和Alexandru TestNG的作者从一开始就很明确，TestNG是为更广的测试场合而设计，而不仅是单元测试。TestNG可以运行没有修改过的JUnit测试，这使得两者的转换非常平滑。
稍后发布的JUnit4.x在细节上非常类似TestNG，这也弥补了这两个框架的裂痕。TestNG仍然是我最喜欢的，而且它仍然保持更新。现在在开源的Java测试框架中仍然有新进者，easyb，一个基于Groovy行为驱动开发的测试工具，为Java和Groovy测试。通过编写合理的测试或是假定一个任务，它可以视为一种规范尽管它是可执行代码。如果你在Ruby世界中使用Rspec一样。
为什么JUnit仍然是首选——Aslam Khan像许多人开始测试驱动开发和单元测试一样，我也是从JUnit3.x起步的。我发现JUnit是最广泛的工具，出现在各种不同的地方（ANT，Maven，Eclipse，IntelliJ IDEA， 等）。它也很容易介绍给那些新团队。我也使用TestNG对它的多样性同样印象深刻。然而，JUnit的大量插件（dbUnit，xmlUnit等）使得Junit仍然是首选的。如果你花大量的时间在Spring上，那么基于Junit的Srping ApplicationContext aware测试用例会带来优势。为了测试前台，我几乎只使用Selenium.我曾经涉足过Canoo和其他的框架，但是发现这些途径都是反TDD模式的。使用Selenium，我可以处理Selenium测试脚本和记录，给任何需要的人并日后处理。
如果我们谈论的是纯粹的TDD，即书写良好的代码（不仅仅是良好的测试）需要增加一个mock测试。对于mocking，我使用Jmock，它和Junit配合良好，通过基于mock的方式和程序内部边界，我得到了设计良好的，互相通信的对象。这在可读性和可维护性上迈出了重要的一步。EasyMock也不错，但是Jmock是我个人的首选。
从Java世界上溯到Ruby世界中，RSpec很优秀而且也有DSL来描述场景。既然Rbehave已经融合进了Rspec，这样的整合将成为Ruby世界的首选。有趣的是，Rbehave是从Jbehave衍生来来，它是一个行为驱动开发测试框架。如果你喜欢BDD模式来收集和确定需求，你会喜欢Jbehave和RSpec.
如果你发现一个对自己很有用的网站或Blog，你想知道这个网站或Blog是否有更新，传统的方法就是把这个网站或Blog的链接加入自己的收藏，然后不定时地去Refresh一下这个网站或Blog，但你可能一无所获，特别是Blog，博主更新的频率其实是不确定的。有没有一种方法，当感兴趣的网站或Blog有更新的时候，我们会被通知到呢？
RSS订阅，就可以实现这样的功能。很多网站或Blog都提供了RSS Feed，只要把Feed添加到RSS Reader中，我们打开RSS Reader即可知道订阅的网站或Blog是否有新的文章，有多少新的文章，并且直接读取。
下面的文章将向你全面介绍RSS订阅以及推荐的RSS Reader - Google Reader的使用：
http://www.blogjava.net/Files/pdclh/RSS_v2.doc
用了RSS订阅后，上网不再漫无目的，通过一个reader，即可集中阅读到所有订阅网站的最新资讯，方便、省时、高效。