在維護軟體時，最怕的事情就是當我們更動某部分的程式碼時，會需要來帶著修改其他程式碼，而這些程式碼的修改，又會再造成另一部分的程式碼需要被修改，就像是石頭濺入水中時，產生了一層層的漣漪。而好的軟體開發，就應該減少變動時造成的漣漪，像是透過思考下列問題：
這部分程式碼的修改會造成哪些程式碼需要連動被改？原因是什麼？是因為這個程式碼所屬的函式、方法身兼太多職責了，導致相關的程式碼自然太多嗎？我們是不是能這個方法只負責一種職責？
這部分的程式碼會不會常常被修改？原因是什麼？能不能以擴充的方式代替修改既有的程式碼？只要減少修改的機會，就可以斷絕後續的漣漪。
需求變動是必然發生的事情，所以我們也一定會常遇到需要改動軟體的情況。若能減少修改專案造成的漣漪，那也就意味這降低修改成本，讓未來的維護能夠較低成本、快速地適應變動。所以我們在開發軟體時，應該要思考著這樣的設計是否會產生漣漪，是否能降低，並在成本、日程以及未來變動的可能性等因素下，去判斷要將漣漪降低到何種程度。
iThome鐵人賽
看影片追技術