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