在演示passalert函数的抽取的时候，有人提出了这样的意见：
?
“我更加喜欢所有和这个功能有关的代码放到一起。这样看起来一目了然，而且调试的时候不需要跳来跳去的”。
?
抽取函数后，一个函数等效于一个代码块。就是说一个代码块变成了一行语句，显然看一行比看一块代码更加一目了然吧。
?
至于调试的时候跳来跳去的，这是事实，如果可以不跳当然对调试来说更加方便。可是在TDD开发中，更加强调测试，少用调试。就是说，丢进去参数，看结果对不对，如果对了，就不说了；如果不对，那么因为经过重构的代码逻辑清晰，应该是只要静态看代码就可以解决问题；如果不能的话，那么需要继续重构。通过重构达到减少调试的目的。调试比较多的话，常常就是一个指标，说明代码的质量还是不够高。
?
显而易见的，往往并不合理。比如RAD技术，可以几下就通过可视化技术，绘制出界面来。可是这样的技术，还是少用为妙，因此RAD的画界面存在的代码难以重用，修改风格困难，界面风格不统一，无法批量调整的问题(比如把查询的按钮区统一从上方调整到下方，调整全部界面的背景色)。carpa平台的gaml，silverlight的xaml都是采用了静态设计的技术。有些产品也是在数据库内定义界面，而不是绘制出来。所以我的看法是：“RAD是给新手入门的，并不适合真正的商业项目开发”。
?
同样的，调试虽然是查找问题的利器，但是调试器常常存在运行缓慢的问题，并且常常需要一点点的观察变量的变化，数据库的修改，因此调试效率必定是非常低的。TDD的普及，提供了一个新的方法，就是通过输入参数，查看输出结果，并把这个过程批量化，自动化，从而获得效率的提升。实际上，主流的carpaxiwa的开发模式就是重视测试，轻视调试的。
?
即便如此，这个tx还是不太认可。我说，你用老的方法做了7-8年了吧，为什么不换换思路？不妨试试看吧。
相关文章
