在演示passalert函數的抽取的時候，有人提出了這樣的意見：
“我更加喜歡所有和這個功能有關的代碼放到一起。這樣看起來一目瞭然，而且調試的時候不需要跳來跳去的”。
抽取函數後，一個函數等效於一個代碼塊。就是說一個代碼塊變成了一行語句，顯然看一行比看一塊代碼更加一目瞭然吧。
至於調試的時候跳來跳去的，這是事實，如果可以不跳當然對調試來說更加方便。可是在TDD開發中，更加強調測試，少用調試。就是說，丟進去參數，看結果對不對，如果對了，就不說了；如果不對，那麼因爲經過重構的代碼邏輯清晰，應該是隻要靜態看代碼就可以解決問題；如果不能的話，那麼需要繼續重構。通過重構達到減少調試的目的。調試比較多的話，常常就是一個指標，說明代碼的質量還是不夠高。
顯而易見的，往往並不合理。比如RAD技術，可以幾下就通過可視化技術，繪製出界面來。可是這樣的技術，還是少用爲妙，因此RAD的畫界面存在的代碼難以重用，修改風格困難，界面風格不統一，無法批量調整的問題(比如把查詢的按鈕區統一從上方調整到下方，調整全部界面的背景色)。carpa平臺的gaml，silverlight的xaml都是採用了靜態設計的技術。有些產品也是在數據庫內定義界面，而不是繪製出來。所以我的看法是：“RAD是給新手入門的，並不適合真正的商業項目開發”。
同樣的，調試雖然是查找問題的利器，但是調試器常常存在運行緩慢的問題，並且常常需要一點點的觀察變量的變化，數據庫的修改，因此調試效率必定是非常低的。TDD的普及，提供了一個新的方法，就是通過輸入參數，查看輸出結果，並把這個過程批量化，自動化，從而獲得效率的提升。實際上，主流的carpaxiwa的開發模式就是重視測試，輕視調試的。
即便如此，這個tx還是不太認可。我說，你用老的方法做了7-8年了吧，爲什麼不換換思路？不妨試試看吧。