經驗談:如何快速應對項目需求中的變化
大家在項目中，印象最深的估計就是“需求變更”了，這個詞無時無刻讓coder們緊繃著。祈禱著沒有變更，但是總是事與愿為，不管是進行中的，還是結束后。總會有這種那種的變更、優化等著你去支持。
那么如何應對這種變更的需求呢？筆者有以下幾點個人觀點跟大家分享和探討。
一、項目開始階段
在項目開始階段，不要急于去寫你的代碼，不要為一開始拿到需求就想到時間進度問題。當你拿到需求的時候更重要的是先消化好需求，從中間挖掘出今后可能會存在的發展方向。
消化需求主要為以下幾個方面：
1、 先整體了解項目的背景，項目生存的環境是什么？
2、 仔細了解整體的交互過程，挖掘出你的代碼框架要如何設計？
3、 對上面2點消化后，開始選擇你的主框架或主庫；在沒有合適框架情況開始規劃你的庫結構。
4、 思考項目部署問題。如何規劃你的文件分布以及目錄結構，方面日后的維護。
5、 評估時間時預留風險（可能會發生）時間，可以參考一下三點估算法來評估。
三點估算公式：Te=(To+4Tm+Tp)/6
To：基于活動的最好情況，所得到的活動持續時間
Tm：基于活動最有可能活動持續時間
Tp：基于活動的最差情況，所得到的活動持續時間
Te：預期活動持續時間
二、項目進行階段
這個階段估計是最頭痛的階段，有時候基于各種因素。經常聽到的是“XX，這里需要調整一下”、“XX，這個流程這里因為XX原需求調整一下”等等類似的情況。然而，沒有圣人，這種情況不管前期考慮的多完善，在執行過程是不可避免的。我們唯一能做的是——用最小的代價支持變化的需求。
這里分享以下幾點經驗：
1、 底層公用接口設計要功能單一，不局限調用方式，方面業務層二次封裝。
2、 在業務層規劃好公共接口。
3、 做好底層接口的二次開發，方便在業務層的靈活運用。
4、 解耦代碼，各模塊獨立，盡可能降低交叉引用
5、 做到UI與邏輯分離，減少對UI的依賴
6、 經常回顧你設計的代碼。看看有啥不適之癥，即時做好調整。
7、 確定關鍵路徑（花費最多時間的路徑，也就是項目的最后完成期限時間），優先保障關鍵路徑的開發；原則就是先修主線，后修剪枝葉
#p#
三、項目上線后的優化階段
這是一個長期的作戰過程，除非你的項目“Game Over”了。而且一些變化會讓你始料未及，那么如何去快速支持呢？這里大部分依賴于上兩個環節是否設計的合理了。
建議如下：
1、 同項目啟動階段一樣，先拿到需求，仔細閱讀需求，不要急于下手。
2、 了解交互的差異性，看看新的交互與之前的具體變化是什么，這里需要確認出來的信息是：a)是否需要完全重構；b)是否只是參數調整；c)是否只需要屏蔽現在接口的調用。
3、 如果涉及交互大調整，需要重構的。這里就需要重新思考重構方案，不要急于直接重寫你的代碼。
四、兩個示例
1、 接口的設計
設計整體結構
對單個接口調用和實現進行思考
接口剖析：多樣化的調用實現以及二次封裝接口預留
事件注冊句柄代碼示例
接口方法實現代碼示例
以PageLoader接口為例：
底層接口為loadPage()
1、 HASH加載請求處理：loadHash() -> loadPage()
2、 用綁定節點的方式處理：bind() -> call() -> loadPage()
3、 用事件委托綁定節點的方式處理：all() -> call() -> loadPage()
4、 一個快速響應交互流程調整的優化需求
需求：流程優化，產品的兩個流程原來都只有一個頁面實現；優化為將流程折分成2個頁面來完。
現狀：原來2個頁面都是用的同一個模塊代碼來實現。
#p#
分析過程：
1、 初步印象，需要對代碼模塊拆分，需要把原來的業務邏輯重新調整。這將耗費大量的時間來處理。
2、 重新審視新的交互流程和原有流程的差異性。進行新舊頁面文件的對比，努力尋找與原來頁面的共同點以及差異性。
3、 通過兩者之間的對比，發現A拆分成的（A1、A2）只是對表單元素的分步處理，其它都一樣的，雖然表單被拆分，但是邏輯實現調整不大。
實現：
頁面A –> A1 + A2
1、 將A1和A2的表單名稱，事件觸發的節點selector設置成一樣。
2、 在A1的表單新增自定義屬性data-step=”1”，在A2類似（data-step=”2”）
3、 OK，頁面結構調整完了后開始調整JS的業務邏輯；
a) 根據data-step來給節點綁定不同的回調
b) 緩存data-step為1的表單，在data-step=”2”的頁面進行合并后整體提交。
很簡單是不是，這里的時間花費分配大概時：思考（6h左右）+執行（1h左右）
五、總結：
云淡風清的去對待你所面對的需求，移位思考；
必要時可以做一些假設性的場景調用；
多參考他人的實現方式，吸收他人的實現思想。
