前两天o6z兄说《无聊的讨论》，然而对于像我这样的TDD入门者来说，却是一个很好的提醒。
TDD不是UNIT DRIVEN DEVELOPMENT，而是TEST CASE DRIVEN DELELOPMEN。
正好这两天看《重构》，可以好好体会一下。比如我在令狐的《EPB？》中留言说到像我这种做原生开发的，对效率性能之类的总是比较敏感。那天，当看到《重构》中强调要设法把临时变量重构掉时，我觉得不可思议。但看到后面就体会到了：因为在重构过程中，总是会有一些代码可能会被Extract Method到别的地方去，临时变量的存在带来了不必要的麻烦。至于性能，应该在重构后再设法优化，毕竟去掉了Bad smells以后，优化起来要容易不少。
学无止境啊。
关于这一点，我可以不谦虚的说一句，我领悟得比你早 :P原因其实还在我以前思考过的那个“界面的测试用例”问题上。后来我突然发现，其实界面测试用例并不一定要编码，写在测试单上，每次做完一个功能就手工测试，开发的目的就是为了通过所有测试，每次测试必须回归以前的测试。再后来我就觉得，其实测试驱动未必一定是指单元测试，其实从设计分析编码整个来说都可以测试驱动。比如，需求，我把需求转换为测试用例，那么我的分析，我的设计，我的编码就是为了通过这个测试。设计，我对设计其实也可以做一些测试用例，那就是更加面向开发人员的测试用例了，这样，也变成测试驱动了。
关于重构，我虽然一直在提，但是一直没有很好的实践。因为我最感兴趣的两个语言，C++和Python，都没有好用的重构浏览器（其实Python是有一个的：Bicycle Repair Man，可惜只能用于emacs、vi，这两个东东在Windows下都不那么好用）。手工重构实在是繁琐。所以，现在对Bad Smell代码的敏感度还不太够。:P但是对于效率问题，我一直是相信3/7法则的，我会优先去保证程序正确性、结构，最后才是效率。（人家说C++的玩家都是最注重效率的，嗯，要么我是Python玩得太多了，要么我就是个异类。）而且，我认为优化架构比优化代码在很多情况下能带来更好的效率提升。
所以说,很多事没有亲自动手做一下,体会不到啊.其实据说BCBX是有一定的重构功能的，看来有必要试试。
Eclipse里的CDT 2.0 有个Rename功能，了不起啊，大肆宣传啊……看来C++的重构工具真是不好做 :S
BCBX早就有rename功能了，我刚才还试了一下，8过其它的就没有了，比如Extract Method