用指令碼構建的程式是怎麼保持後期重構的健壯性的？

我一般使用的是強型別語言，比如java或者c++。但是我知道很多系統是用弱類型的指令碼語言，比如豆瓣。
我嘗試過弱類型開發，但是後期很難維護，具體表現是幾乎無法重構。
是不是會有別的什麼辦法可以避免這個問題，或者可以支援到健壯的重構？
我一直對動態語言構建系統的維護方式比較好奇，求大神賜教！
——————————
看到很多大神都提到單元測試，確實是可以保證系統重構之後的穩定性
但是我寫程式喜歡一邊寫一邊微調程式結構(微重構)，幾乎很少單元測試，所以需要型別安全來做隨時錯誤偵測。 不知道這個是不是什麼好習慣？

回複內容：

動態類型一時爽，項目大了人多了，維護起來都要命，別說重構了。
一個API看起來會返回一個A，沒人敢保證不會有1%的機會返回個null，再有0.01%的機會返回個B。一個小改動要往下看n層代碼才放心，結果commit上去還是掛了。
Facebook就知道錯了，搞了個Hack 搶救一下……不管是什麼語言，重構要保持健壯性靠的都是大量的單元測試。這不是指令碼專屬的問題。無他，大量可迴歸的單元測試，整合測試。多回複一點,其實 @vczh前面說的沒錯,但是卻是個悖論.因為很多時候,人們用指令碼語言就是圖的開發速度,現在為了讓它健壯還得儘可能的單元測試覆蓋,老實說,指令碼多用在商務邏輯多且變化頻率大的領域,單元測試寫起來實在蛋疼.

這就好比,本身你用A是為了好處B,但是為了彌補A的缺陷又不得不做一些事情要犧牲好處B.

所以說,個人認為單元測試覆蓋對指令碼語言開發的項目是個悖論.

我的想法是自己權衡吧,想快趕緊上的時候就指令碼,後面不行了再慢慢改回編譯型.

魚和熊掌,不可兼得也.指令碼就是這樣啊, 火葬場了之後爬出來, 趕快來個熱更新就是了.

上帝給你堵住了一扇門, 還會給你開一道窗子系統的健壯性更多的時候取決於其架構，如何隔離錯誤。比如 Chrome 用多進程架構避免渲染引擎和外掛程式的崩潰，Python Web Server 利用異常捕捉隔離獨立 HTTP 要求的業務錯誤。

系統的可維護性取決於如何設計系統的模組劃分，如何規範模組的外部介面和模組間的通訊，如何降低模組間的耦合度，以使重構影響更少的模組。

設計實踐是編譯器檢查不出來的。首先，看起來你想說的是靜態／動態語言而不是強弱類型的問題，類型強弱跟是否編譯語言沒有絕對關係，也跟是動態還是靜態語言是兩回事兒。其次，我其實是 @vczh 這個蘿莉控的敵對陣營，但是為啥老是想給他點贊呢？前期設計再棒也是無法抵消後期代碼熵增的。

java 這樣的強型別語言，只能說在IDE的協助下進行變數/方法重新命名，方法提取……等基礎重構策略時，比較容易操作。

我們可以把類型檢查視為它的內建約束。這些內建約束只能緩解一部分問題。許多需要大規模重構的情境，強型別語言和弱類型語言面臨的問題沒有差異。

反而是許多弱類型語言，以 ruby 為例，在 ducktype 機制的作用下，邏輯編寫十分靈活，許多情境下代碼反而是更易維護。

綜合來說，解決之道唯有進行嚴格的測試驅動開發。
測試是很好的手段，能按照自己的想法在各個層面去為代碼添加約束。而不是僅僅依賴所謂的類型檢查。

測試驅動開發，而不是開發完了再去用所謂單元測試檢查掃尾。
這是完全不一樣的兩種開發思路。
前者會導致代碼設計的持續改進。是後者不能比擬的。

用測試去儘可能覆蓋需求。進行bugfix時也使用測試驅動。
在持續的代碼提交中，逐步提高測試覆蓋率。
架設CI服務，如果是github上的項目可以用 https://travis-ci.org/

掌握撰寫測試的方法，形成寫測試的思想，在此基礎上花時間積極重構。
別無他法。測試指令碼：單元測試、接受性測試、壓力測試，如果想東西靠譜，一個都不能少。TDD、BDD之說有效。至於覆蓋率的問題，可以後續完善，但必須要由，測試指令碼和財富一樣是需要積累的。

CI：前面 @宋亮 提到持續整合，這個是也必須的。重複的事情必須要交給機器，人負責創造性的東西。

前提：業務不能重構，否則測試案例和指令碼就得重來。

盲區：前端自動自動化測試，主要是瀏覽器渲染走樣的問題。貌似stackoverflow上有人提過原型圖片像素比對的方式做斷言，但沒實踐過。最初設計的時候應該也是分了模組的，介面也應該設計好了的
重構的使用範圍應該限定在模組內部的實現，而即使模組內部的改動即使對模組來說也應該不是太大的吧。

