张玮的专栏

做重构时总有想一步登天的想法，每每想起一个重构到一个大的重构的中间状态时觉得很不习惯。这跟长期以来形成的习惯是格格不入的，程序员总是追求完美。看见软件的这种状态很难习惯。其实仔细想来，也许一个中间状态才是当前的最完美状态，可能你想的最终状态永远不会达到。这部分是因为想象中的状态往往并不完美。往往听见有人说用了一下午完成了一个重构，如果说是指用很多小的重构来最终完成一个大的重构倒比较好，如果是指中间

再过两天Callisto就要发布了。Eclipse 的开发节奏确实保持得很好，这也是敏捷方法的影响。个人认为能保证准时发布的关键还是敏捷计划。通过它的计划的变动情况就可以看出来。它的计划是会经常发生变化的。记得它的计划里面自己也提到了，会经常改变计划。另外Callisto的方式我也比较喜欢，象原来安装一个比较上层的插件，象Web Tools这些，要找到相关插件的合适版本都是一件非常吃力的事情，有时

对不起，暂时还找不出十个理由（开个玩笑，何必当真呢，不是流行吗）。勉强凑出五个理由，但我是坚决支持测试时使用HSQL的。1.环境无关换到另外的机器上时，不用做任何配置即可直接进行测试。2.运行速度快进程内调用，没有其它调用开销（这个并不明显，也许省了运行数据库服务器的开销更明显）3.可以每次重新建立表结构(incremental changes, embracing changes, travel

以修改BUG为例。如果先直接修改了，再加测试的时候，就觉得节奏明显有点乱。因为没有变红的步骤，总觉得少一点“成就感”。

下载的文件太多，也很想用目录把它们组织好。但是因为老是懒得整理，因此下载的文件老是很乱。究其原因，下载后的东西只使用了一次，以后就不会怎么使用了，因此不会去好好整理。我想出一个办法，就是把所有下载的文件就放到桌面，这样如果老不收拾它，它就会总是来提醒你。由此我想到重构，某种程度上看，其实跟整理下载文件也很类似。只是如果用这个比喻去套重构的话，我不知道把下载的文件放到桌面，对应重构应该是什么？是把新

 解耦是好的，但这是在模块间这个前提下的。过分强调解耦，是过分设计的典型例子。因为我记得关于耦合的书上除了“模块间耦合度很低”，还有“模块内耦合很高”这样一句话的。 设想一下解耦到极限的状态，那就跟宇宙间所有物质在时间和空间上均匀分布一样，那就没有银河系，没有地球，我身上的这些物质也不会聚在一起让我在这儿说这些废话了:)。 因为我还存在，还在继续说废话，所以宇宙间所有物质不是在时间和空间上均匀分布

今天重构了一长段界面代码有感如下：1.测试，还是测试    因为没有测试，重构的过程中简直是无以为继，既不知道走到哪里了，也不知道下一步该做什么。2.MVC，旧话重提，还是测试    其实跟上一个话题有关，没有测试的根本原因是因为界面不好测试，再另上是Eclipse框架下的一个View，测起来更加麻烦。毅然决定使用MVC（倒不是我想，这段代码是一个负责控制多块语音卡的界面，因此比较适合用MVC），

Keep the change small.这是一个很有用的实践，可以应用在很多地方：编程，配置，甚至做饭(我看到过的最好的应用这个实践的例子是我妈妈炒菜的时候  ）。1.能够把一件事分成很多小步骤来做。2.每一小步做完都要能够检验。3.发现出错能够轻易倒退。其中第2步比较繁琐，象TDD就是用自动测试来保证的。

XP中很多地方讲求一个“步步为营”。这个“营”字在XP的开发进程中就体现在测试上。通过测试来把已经走过的路径（完成的功能）稳定下来。当然这也包括针对Bug的测试。但是，遗憾的是，测试是违背程序员的天性的;再加上习惯使然，因此常会因为懒或者疏忽或者难以找到比较好的测试的办法而放弃测试。但是，从学习的角度来看的话，遇到不太好测而想出测试方法的时候，往往是测试水平进步最大的时候。因此，经常测试一方面

今天重读了TDD，个人认为前言是精华中的精华。想来也是，如果你有一肚子话要说，但是只给你半分钟，相信这半分钟应该是你要说的话中的精华了吧。相对于XP，TDD应该是可以被更广泛的人所接受的一种技术。而且个人认为TDD包含了XP中很多的原则，是XP的核心价值所在，因此，相对而言，TDD应该更容易被推广，而且算是XP中投入/产出比最高的，只要付出一小点，就可以收获到最多。这也算是XP价值观的一种延伸吧。

测试应该足够简单，足够直白，具体，只针对一种情况，尽量避免一个测试做太多的情况。

在Eclipse PDE开发环境中运行得很好的插件，单独发布后却不能正常运行，也没有出任何错误，真是费我一阵好找。最后才发现是build.properties文件里没有把引用的资源和jar打包到plugin里面，真是。这个问题本来不大，只是没有及时发布发现累积了很多这种问题，至少都改了八九个地方。足可见及时的发布的重要性。如果尽早地进行发布，这个问题本可以早一点发现。如果把打包的过程一直到最后运行

在测试－编码－重构的过程中，测试前置的想法一开始接触的时候会觉得有点匪夷所思：如果单做了一个没有实现或者会出错的测试，难道也是向前进了一步？ 其实看你怎么看这个问题。针对一个失败的测试，一种看法是系统有错了;但另一种更为积极的看法是把测试和代码都看成系统，一个失败的测试至少说明了一个积极的地方：我们的系统可以在没有这项功能/出现这种错误的时候告诉我们，这难道不算是一个重大的进步，不是有古训“知耻而

前一段时间看了Martin Fowler的一篇Blog(http://martinfowler.com/bliki/PrinciplesOfXP.html),介绍关于Principles的事。深以为然，其实XP不XP关键是一种态度，一些原则，也即所谓的“是非观”。而这些是非观体现在比较高层次就是Value，体现在中间层次就是Principles。 结对实践应该是对团队建设极其有益的实践，只是实施起

测试中总会遇到测试关于某个方法是否被调用，其中也包括象事件是否发生以及方法调用的先后，事件发生的顺序以及参数等等，在Kent写的Test Driven Development中看到一个办法，就是简单地记下来，再在最后用assertEquals进行测试。一直想不到一个合适的词来形容，今天使用这个方法的时候突然想到用“秋后算帐”应该算是比较贴切的一个词。因为它代表发生的时候的简单（记下来就是了，真要发

这段时间用CC.Net，有个任务栏监控的工具，一旦集成失败会在任务栏中变红。可以让你变得对集成很敏感，一旦失败，会千方百计地把它弄对。这个工具有助于建立于我们对集成的重视。 程序员是懒惰的，这倒不是坏事。只是需要在选择工具及开发方法上要考虑到这点，再加上单元测试需要100%跑过这点，因此单元测试一定要放到集成环境中去。否则单元测试会一点点慢慢地死掉(王心凌第一次爱的人的歌词，顺便说一下，这首歌不错