如何以最小的改動盡量不改變已有代碼的情況下適應不斷變更的需求?

01-13

求大神們說一說你的經驗

如果有時間，別怕改代碼，要鼓勵重構，別怕改代碼。

我有時候覺得寫代碼就像搭積木，原來我有9個方塊，我搭個1x3x3豎成一排像個牆一樣看起來很美，現在又來5個方塊，我啥也不管就往牆上摞，又來4個球，我也直接「做最少的改動」，早晚變成一個顫顫巍巍隨時要倒的危樓。

正確的做法應該是，發現來個5個方塊，立刻應該改成3x3x1的底座先。然後每次放上去東西都要保證之後是個穩穩的結構。如果不穩，就把地基改改，改到可以穩為止。

當然這並沒有回答你的問題。因為我覺得很多時候追求「最少的改動」就是萬惡之源。

熟練使用設計模式

這個問題可以分成兩個問題：

1、怎麼改動最小實現功能變更。

簡單來說，如果你用最少的代碼實現了一個功能，那麼當這個功能變化的時候，你要改動的代碼也會隨之變少。這裡面涉及到很多個哲學，例如KISS（Keep it simple stupid）

2、怎麼才能不該動現有代碼實現功能變更。

簡單說你重新做一個新的模塊替換掉現有的模塊就能達到不該動現有代碼的效果。為了降低這樣做的成本，就需要你把模塊都做的足夠小。

任何一份系統設計，都會對需求的變更方向做一定的假設；

這種假設是有「方向」的，有預期的，不存在沒有方向沒有預期的假設, 沒有方向沒有預期那就不叫「假設」了；

當需求的變更符合事先的方向和預期時，系統是好擴展的，所做的變更是意料之中的；

但當需求的變更超出了事先的預期，違背了預想中的方向時，改動就是傷筋動骨的，痛苦的；

所以，想要適應需求的變化，最重要的是你要預料到需求會「怎樣變化」，從而為系統留出意料之中的擴展點；

當然，這個的實現還需要需求來源方面的配合，如果你的需求來源，本就是天馬行空，無法判斷其發展方向的，那麼最好的辦法就是「保持簡單」、「不做任何假設和預留」、「保持發布的敏捷、迭代迅速」，以快速的響應來應對無法預料的需求變化，以彌補「不做任何假設」的不足

把常變化的需求提取成外部數據，即所謂data-driven，適合在一些簡單的場景用。

要注意的是如果場景變的複雜而使用者沒有堅持讓data保持簡單，最後你的data又會跨越「數據」和「代碼」之間那模糊的邊界而演變成一種DSL。

不要僅僅從技術方面考慮。要主動對需求方進行引導，這需要一定的溝通技巧

首先認真理解需求，然後多提供給需求方几個方案來選擇，明確說明哪些他可以很快看到、哪些他要等很久。

很多時候需求並不是非要那麼複雜的方案不可，經常真的只需要改幾行代碼就行，就可以讓他立刻看到效果。

《head first 設計模式》

這也是函數式風格的擅長。

坑掉進去的多了你就知道如何避免再次掉進大坑了。。。

不想需求老變動，幹掉產品經理即可。

其實不改代碼的方法還是有的，直接刪掉重寫。

所謂的「開閉原則」，大體上是說通過繼承的方式覆寫原有的實現來避免代碼修改，很顯然良好地實施這個原則需要一開始就規劃好各個模塊的層次、關係、介面，本質上依賴於某種抽象層面上確定的需求。

現實中的需求變更往往不是換種實現細節這麼簡單，比如一個類繼承了十幾次後發現最頂層的介面需要修改，整個繼承樹瞬間崩盤……

所以我認為不要懼怕修改代碼，而是要使代碼對修改友好，如 @溫悅所說保持簡單和機動，設計模式應該用來隔離模塊降低耦合，在滿足當前需求基礎上做到結構清晰，而不是預設以後的演變方向。

下面說點題外話，我認為應對需求的變更重要的一點是程序員和需求人員做好溝通，在問題的解決模型上達成一致。

舉個不恰當的例子，微信朋友圈。假如產品經理設想的模型是用戶發一條狀態後，狀態被推送到每個好友的timeline；而程序員實際的做法是打開朋友圈後從自己的每個好友拉取狀態。這樣就形成了模型認知上的不一致。有一天產品經理基於自己的模型提出了一個很簡單的需求：明天往每個用戶的timeline中插入一條廣告。而程序員發現必須更新所有客戶端，明天根本來不及……

那麼如果一開始就有良好的溝通呢？要麼產品經理會提出你的實現方式不適合今後需求的變化，然後使用推送的模型，最後滿足這個需求輕而易舉；要麼程序員會表示我的方案技術上更容易實現，然後使用拉取的模型，最後產品經理在設計需求時就會對需求的難度有正確的評估了。

熟練使用SOA的架構，預測可能變化的值放到配置文件或資料庫里。

這就要求「已有代碼」盡量模塊化，儘可能降低耦合性。改變需求的時候只改變某些模塊，其他一概不動。

輪子哥說的用好設計模式可以很好的完成這一目標。

設計結構的時候，多分一層。妥妥的

我聽說要看SICP

不改是最好的辦法

平時模塊化好復用性高，現在也不用糾結這些了