大家在項(xiàng)目中，印象最深的估計(jì)就是“需求變更”了，這個(gè)詞無時(shí)無刻讓coder們緊繃著。祈禱著沒有變更，但是總是事與愿為，不管是進(jìn)行中的，還是結(jié)束后?？倳?huì)有這種那種的變更、優(yōu)化等著你去支持。

那么如何應(yīng)對(duì)這種變更的需求呢？筆者有以下幾點(diǎn)個(gè)人觀點(diǎn)跟大家分享和探討。

一、項(xiàng)目開始階段

在項(xiàng)目開始階段，不要急于去寫你的代碼，不要為一開始拿到需求就想到時(shí)間進(jìn)度問題。當(dāng)你拿到需求的時(shí)候更重要的是先消化好需求，從中間挖掘出今后可能會(huì)存在的發(fā)展方向。

消化需求主要為以下幾個(gè)方面：
1、? 先整體了解項(xiàng)目的背景，項(xiàng)目生存的環(huán)境是什么？
2、? 仔細(xì)了解整體的交互過程，挖掘出你的代碼框架要如何設(shè)計(jì)？
3、? 對(duì)上面2點(diǎn)消化后，開始選擇你的主框架或主庫(kù)；在沒有合適框架情況開始規(guī)劃你的庫(kù)結(jié)構(gòu)。
4、? 思考項(xiàng)目部署問題。如何規(guī)劃你的文件分布以及目錄結(jié)構(gòu)，方面日后的維護(hù)。
5、? 評(píng)估時(shí)間時(shí)預(yù)留風(fēng)險(xiǎn)（可能會(huì)發(fā)生）時(shí)間，可以參考一下三點(diǎn)估算法來評(píng)估。

三點(diǎn)估算公式：Te=(To+4Tm+Tp)/6
To：基于活動(dòng)的最好情況，所得到的活動(dòng)持續(xù)時(shí)間
Tm：基于活動(dòng)最有可能活動(dòng)持續(xù)時(shí)間
Tp：基于活動(dòng)的最差情況，所得到的活動(dòng)持續(xù)時(shí)間
Te：預(yù)期活動(dòng)持續(xù)時(shí)間

二、項(xiàng)目進(jìn)行階段

這個(gè)階段估計(jì)是最頭痛的階段，有時(shí)候基于各種因素。經(jīng)常聽到的是“XX，這里需要調(diào)整一下”、“XX，這個(gè)流程這里因?yàn)閄X原需求調(diào)整一下”等等類似的情況。然而，沒有圣人，這種情況不管前期考慮的多完善，在執(zhí)行過程是不可避免的。我們唯一能做的是——用最小的代價(jià)支持變化的需求。

這里分享以下幾點(diǎn)經(jīng)驗(yàn)：
1、? 底層公用接口設(shè)計(jì)要功能單一，不局限調(diào)用方式，方面業(yè)務(wù)層二次封裝。
2、? 在業(yè)務(wù)層規(guī)劃好公共接口。
3、? 做好底層接口的二次開發(fā)，方便在業(yè)務(wù)層的靈活運(yùn)用。
4、? 解耦代碼，各模塊獨(dú)立，盡可能降低交叉引用
5、? 做到UI與邏輯分離，減少對(duì)UI的依賴
6、? 經(jīng)?；仡櫮阍O(shè)計(jì)的代碼。看看有啥不適之癥，即時(shí)做好調(diào)整。
7、? 確定關(guān)鍵路徑（花費(fèi)最多時(shí)間的路徑，也就是項(xiàng)目的最后完成期限時(shí)間），優(yōu)先保障關(guān)鍵路徑的開發(fā)；原則就是先修主線，后修剪枝葉。

三、項(xiàng)目上線后的優(yōu)化階段

這是一個(gè)長(zhǎng)期的作戰(zhàn)過程，除非你的項(xiàng)目“Game Over”了。而且一些變化會(huì)讓你始料未及，那么如何去快速支持呢？這里大部分依賴于上兩個(gè)環(huán)節(jié)是否設(shè)計(jì)的合理了。

建議如下：
1、? 同項(xiàng)目啟動(dòng)階段一樣，先拿到需求，仔細(xì)閱讀需求，不要急于下手。
2、? 了解交互的差異性，看看新的交互與之前的具體變化是什么，這里需要確認(rèn)出來的信息是：a)是否需要完全重構(gòu)；b)是否只是參數(shù)調(diào)整；c)是否只需要屏蔽現(xiàn)在接口的調(diào)用。
3、? 如果涉及交互大調(diào)整，需要重構(gòu)的。這里就需要重新思考重構(gòu)方案，不要急于直接重寫你的代碼。

四、兩個(gè)示例

1、? 接口的設(shè)計(jì)
? 設(shè)計(jì)整體結(jié)構(gòu)

? 對(duì)單個(gè)接口調(diào)用和實(shí)現(xiàn)進(jìn)行思考

? 接口剖析：多樣化的調(diào)用實(shí)現(xiàn)以及二次封裝接口預(yù)留

? 事件注冊(cè)句柄代碼示例

? 接口方法實(shí)現(xiàn)代碼示例

以PageLoader接口為例：
底層接口為loadPage()
1、? HASH加載請(qǐng)求處理：loadHash() -> loadPage()
2、? 用綁定節(jié)點(diǎn)的方式處理：bind() -> call() -> loadPage()
3、? 用事件委托綁定節(jié)點(diǎn)的方式處理：all() -> call() -> loadPage()
4、? 一個(gè)快速響應(yīng)交互流程調(diào)整的優(yōu)化需求

需求：流程優(yōu)化，產(chǎn)品的兩個(gè)流程原來都只有一個(gè)頁(yè)面實(shí)現(xiàn)；優(yōu)化為將流程折分成2個(gè)頁(yè)面來完。
現(xiàn)狀：原來2個(gè)頁(yè)面都是用的同一個(gè)模塊代碼來實(shí)現(xiàn)。

分析過程：
1、? 初步印象，需要對(duì)代碼模塊拆分，需要把原來的業(yè)務(wù)邏輯重新調(diào)整。這將耗費(fèi)大量的時(shí)間來處理。
2、? 重新審視新的交互流程和原有流程的差異性。進(jìn)行新舊頁(yè)面文件的對(duì)比，努力尋找與原來頁(yè)面的共同點(diǎn)以及差異性。
3、? 通過兩者之間的對(duì)比，發(fā)現(xiàn)A拆分成的（A1、A2）只是對(duì)表單元素的分步處理，其它都一樣的，雖然表單被拆分，但是邏輯實(shí)現(xiàn)調(diào)整不大。

實(shí)現(xiàn)：
頁(yè)面A –> A1 + A2
1、? 將A1和A2的表單名稱，事件觸發(fā)的節(jié)點(diǎn)selector設(shè)置成一樣。
2、? 在A1的表單新增自定義屬性data-step=”1”，在A2類似（data-step=”2”）

3、? OK，頁(yè)面結(jié)構(gòu)調(diào)整完了后開始調(diào)整JS的業(yè)務(wù)邏輯；
a)?????? 根據(jù)data-step來給節(jié)點(diǎn)綁定不同的回調(diào)

b)?????? 緩存data-step為1的表單，在data-step=”2”的頁(yè)面進(jìn)行合并后整體提交。

很簡(jiǎn)單是不是，這里的時(shí)間花費(fèi)分配大概時(shí)：思考（6h左右）+執(zhí)行（1h左右）

五、總結(jié)：

云淡風(fēng)清的去對(duì)待你所面對(duì)的需求，移位思考；

必要時(shí)可以做一些假設(shè)性的場(chǎng)景調(diào)用；

多參考他人的實(shí)現(xiàn)方式，吸收他人的實(shí)現(xiàn)思想。

來源：騰訊TID