用腳本構建的程序是怎麼保持後期重構的健壯性的？

01-01

我一般使用的是強類型語言，比如java或者c++。但是我知道很多系統是用弱類型的腳本語言，比如豆瓣。
我嘗試過弱類型開發，但是後期很難維護，具體表現是幾乎無法重構。
是不是會有別的什麼辦法可以避免這個問題，或者可以支持到健壯的重構？
我一直對動態語言構建系統的維護方式比較好奇，求大神賜教！
——————————

看到很多大神都提到單元測試，確實是可以保證系統重構之後的穩定性
但是我寫程序喜歡一邊寫一邊微調程序結構(微重構)，幾乎很少單元測試，所以需要類型安全來做隨時錯誤檢測。不知道這個是不是什麼好習慣？

動態類型一時爽，項目大了人多了，維護起來都要命，別說重構了。

一個API看起來會返回一個A，沒人敢保證不會有1%的機會返回個null，再有0.01%的機會返回個B。一個小改動要往下看n層代碼才放心，結果commit上去還是掛了。

Facebook就知道錯了，搞了個Hack搶救一下……

不管是什麼語言，重構要保持健壯性靠的都是大量的單元測試。這不是腳本獨有的問題。

前期設計再棒也是無法抵消後期代碼熵增的。

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

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

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

綜合來說，解決之道唯有進行嚴格的測試驅動開發。

測試是很好的手段，能按照自己的想法在各個層面去為代碼添加約束。而不是僅僅依賴所謂的類型檢查。

測試驅動開發，而不是開發完了再去用所謂單元測試檢查掃尾。

這是完全不一樣的兩種開發思路。

前者會導致代碼設計的持續改進。是後者不能比擬的。

用測試去儘可能覆蓋需求。進行bugfix時也使用測試驅動。

在持續的代碼提交中，逐步提高測試覆蓋率。

架設CI服務，如果是github上的項目可以用 https://travis-ci.org/

掌握撰寫測試的方法，形成寫測試的思想，在此基礎上花時間積極重構。

別無他法。

無法重構？

你去看下discuz2012年的版本後，

再看看現在的版本，

就知道為什麼難重構了！~

無他，大量可回歸的單元測試，集成測試。

多回復一點,其實 @vczh前面說的沒錯,但是卻是個悖論.因為很多時候,人們用腳本語言就是圖的開發速度,現在為了讓它健壯還得儘可能的單元測試覆蓋,老實說,腳本多用在業務邏輯多且變化頻率大的領域,單元測試寫起來實在蛋疼.

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

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

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

魚和熊掌,不可兼得也.

系統的健壯性更多的時候取決於其架構，如何隔離錯誤。比如 Chrome 用多進程架構避免渲染引擎和插件的崩潰，Python Web Server 利用異常捕捉隔離獨立 HTTP 請求的業務錯誤。

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

設計實踐是編譯器檢查不出來的。

腳本就是這樣啊, 火葬場了之後爬出來, 趕快來個熱更新就是了.

上帝給你堵住了一扇門, 還會給你開一道窗子

首先，看起來你想說的是靜態／動態語言而不是強弱類型的問題，類型強弱跟是否編譯語言沒有絕對關係，也跟是動態還是靜態語言是兩回事兒。其次，我其實是 @vczh 這個蘿莉控的敵對陣營，但是為啥老是想給他點贊呢？

測試腳本：單元測試、接受性測試、壓力測試，如果想東西靠譜，一個都不能少。TDD、BDD之說有效的。至於覆蓋率的問題，可以後續完善，但必須要由，測試腳本和財富一樣是需要積累的。

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

前提：業務不能重構，否則測試用例和腳本就得重來。

盲區：前端自動自動化測試，主要是瀏覽器渲染走樣的問題。貌似stackoverflow上有人提過原型圖片像素比對的方式做斷言，但沒實踐過。

最初設計的時候應該也是分了模塊的，介面也應該設計好了的

重構的使用範圍應該限定在模塊內部的實現，而即使模塊內部的改動即使對模塊來說也應該不是太大的吧。