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

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

一、項目開始階段

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

消化需求主要為以下幾個方面：

1、  先整體了解項目的背景，項目生存的環(huán)境是什么？

2、  仔細(xì)了解整體的交互過程，挖掘出你的代碼框架要如何設(shè)計？

3、  對上面2點消化后，開始選擇你的主框架或主庫；在沒有合適框架情況開始規(guī)劃你的庫結(jié)構(gòu)。

4、  思考項目部署問題。如何規(guī)劃你的文件分布以及目錄結(jié)構(gòu)，方面日后的維護(hù)。

5、  評估時間時預(yù)留風(fēng)險（可能會發(fā)生）時間，可以參考一下三點估算法來評估。

三點估算公式：Te=(To+4Tm+Tp)/6

To：基于活動的最好情況，所得到的活動持續(xù)時間

Tm：基于活動最有可能活動持續(xù)時間

Tp：基于活動的最差情況，所得到的活動持續(xù)時間

Te：預(yù)期活動持續(xù)時間

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

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

這里分享以下幾點經(jīng)驗：

1、  底層公用接口設(shè)計要功能單一，不局限調(diào)用方式，方面業(yè)務(wù)層二次封裝。

2、  在業(yè)務(wù)層規(guī)劃好公共接口。

3、  做好底層接口的二次開發(fā)，方便在業(yè)務(wù)層的靈活運用。

4、  解耦代碼，各模塊獨立，盡可能降低交叉引用

5、  做到UI與邏輯分離，減少對UI的依賴

6、  經(jīng)?；仡櫮阍O(shè)計的代碼?？纯从猩恫贿m之癥，即時做好調(diào)整。

7、  確定關(guān)鍵路徑（花費最多時間的路徑，也就是項目的最后完成期限時間），優(yōu)先保障關(guān)鍵路徑的開發(fā)；原則就是先修主線，后修剪枝葉

#p#

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

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

建議如下：

1、  同項目啟動階段一樣，先拿到需求，仔細(xì)閱讀需求，不要急于下手。

2、  了解交互的差異性，看看新的交互與之前的具體變化是什么，這里需要確認(rèn)出來的信息是：a)是否需要完全重構(gòu)；b)是否只是參數(shù)調(diào)整；c)是否只需要屏蔽現(xiàn)在接口的調(diào)用。

3、  如果涉及交互大調(diào)整，需要重構(gòu)的。這里就需要重新思考重構(gòu)方案，不要急于直接重寫你的代碼。

四、兩個示例

1、  接口的設(shè)計

[[65303]]  設(shè)計整體結(jié)構(gòu)

[[65303]]  對單個接口調(diào)用和實現(xiàn)進(jìn)行思考

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

[[65306]]  事件注冊句柄代碼示例

[[65306]]  接口方法實現(xiàn)代碼示例

以PageLoader接口為例：

底層接口為loadPage()

1、  HASH加載請求處理：loadHash() -> loadPage()

2、  用綁定節(jié)點的方式處理：bind() -> call() -> loadPage()

3、  用事件委托綁定節(jié)點的方式處理：all() -> call() -> loadPage()

4、  一個快速響應(yīng)交互流程調(diào)整的優(yōu)化需求

需求：流程優(yōu)化，產(chǎn)品的兩個流程原來都只有一個頁面實現(xiàn)；優(yōu)化為將流程折分成2個頁面來完。

現(xiàn)狀：原來2個頁面都是用的同一個模塊代碼來實現(xiàn)。

#p#

分析過程：

1、  初步印象，需要對代碼模塊拆分，需要把原來的業(yè)務(wù)邏輯重新調(diào)整。這將耗費大量的時間來處理。

2、  重新審視新的交互流程和原有流程的差異性。進(jìn)行新舊頁面文件的對比，努力尋找與原來頁面的共同點以及差異性。

3、  通過兩者之間的對比，發(fā)現(xiàn)A拆分成的（A1、A2）只是對表單元素的分步處理，其它都一樣的，雖然表單被拆分，但是邏輯實現(xiàn)調(diào)整不大。

實現(xiàn)：

頁面A –> A1 + A2

1、  將A1和A2的表單名稱，事件觸發(fā)的節(jié)點selector設(shè)置成一樣。

2、  在A1的表單新增自定義屬性data-step=”1”，在A2類似（data-step=”2”）

3、  OK，頁面結(jié)構(gòu)調(diào)整完了后開始調(diào)整JS的業(yè)務(wù)邏輯；

a)       根據(jù)data-step來給節(jié)點綁定不同的回調(diào)

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

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

五、總結(jié)：

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

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

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

原文鏈接：http://tid.tenpay.com/?p=4459