（四）——實踐.快速迭代.并行開發 · Web開發新人培訓系列

> 本文鏈接：[Web開發新人培訓系列（四）——實踐.快速迭代.并行開發](http://rapheal.sinaapp.com/2015/04/23/webdev-iterate/ "本文固定鏈接 http://rapheal.sinaapp.com/2015/04/23/webdev-iterate/") > 來源：[拉風的博客](http://rapheal.sinaapp.com/) ## 背景我們先看看我們之前的開發場景： [![](https://box.kancloud.cn/2016-09-07_57cfde1dba557.png)](http://rapheal-wordpress.stor.sinaapp.com/uploads/2015/04/SVN%E5%BC%80%E5%8F%91.png) 程序員a開發功能A，程序員b開發功能B，當開發完畢后提測上線。但是公眾平臺的功能越來越多，涉及的開發人員也越來越多。于是乎就出現了程序員c、d、e、f分別開發功能C、D、E、F。大家一起開發完功能提測上線。貌似看起來沒任何問題。突然有一天，功能D和F因為種種原因臨時決定不上線，這下程序員d、f就急急忙忙把對應的代碼給注釋去掉。這種情況越來越多，我們依靠人工的注釋代碼/回退代碼帶來了許許多多的問題。我們必須要找一個合理的辦法來解決這個混亂的現象！我梳理一下上邊幾個關鍵點： 1. 開發人員多、上線需求多 2. 迭代速度非常快 3. 臨上線前，部分功能需要變更重新修改或者不上線 4. 現網容易出故障/投訴 ## 目標梳理完剛剛幾個關鍵點，我們發現1-3是我們很難沒法掌控的流程。也就是現狀是1-3是我們的輸入，而4是我們的輸出。我們需要有個合理的方案，讓1-3即便發生的情況下，4能夠盡量少發生，這就是我們的目標。 ## 方案問題就出現在大家混在一起快速開發導致。一個很自然的做法，我們拆開多個分支并行開發。 [![](https://box.kancloud.cn/2016-09-07_57cfde1ddc9c2.png)](http://rapheal-wordpress.stor.sinaapp.com/uploads/2015/04/%E5%A4%9A%E5%88%86%E6%94%AF%E5%BC%80%E5%8F%91.png) 當功能上完線后，我們需要把上線后的代碼合并到主干去。 [![](https://box.kancloud.cn/2016-09-07_57cfde1e1d0bb.png)](http://rapheal-wordpress.stor.sinaapp.com/uploads/2015/04/%E5%90%88%E5%9B%9E%E4%B8%BB%E5%B9%B2.png) 還有一種情況就是，功能A、B、C、D同時拉分支出來進行開發，但是由于功能C的復雜性，導致功能C拖延了一周才上線，但是功能C在上線前，功能A、B、D已經上線，我們需要把這些功能的代碼也要合進當前的功能C分支。于是乎我們把主干相關的新改動合并到分支C去。于是乎出現了我之前在組內分享的一張圖： [![](https://box.kancloud.cn/2016-09-07_57cfde1e40554.jpg)](http://rapheal-wordpress.stor.sinaapp.com/uploads/2015/04/%E5%A4%8D%E6%9D%82%E7%9A%84%E5%88%86%E6%94%AF%E7%AE%A1%E7%90%86.jpg) 再看一下整個方案的流程： 1. 按照功能拆分對應的分支，并行開發，互不影響。 2. 分支上線前，代碼對齊主干 3. 分支上線后，代碼合回主干我們看到，SVN主干一直跟現網某一時間點的版本一致，一旦發生問題，我們可以很快立馬回退到任何時間點的狀態。 ## 高效準確有合理的執行方案，我們還要求要更高效準確地執行。我們梳理一下從開發 —— 提測 —— 上線整個流程，當中我們項目提測流程可以參考我上一篇文章[《Web開發新人培訓系列（三）——上線》](http://rapheal.sinaapp.com/2015/01/22/webdev-release/)。 [![](https://box.kancloud.cn/2016-09-07_57cfde1e65598.png)](http://rapheal-wordpress.stor.sinaapp.com/uploads/2015/04/%E4%BB%A5%E5%89%8D%E6%B5%81%E7%A8%8B.png) 為了達到高效而準確的目的，我們做了輔助工具用于在整個提測上線流程自動化（上圖中紅色部分是我們主要優化的流程節點）。我們在兩方面做了一些貢獻。 1. 效率 * 提測時僅需要填寫分支名字，再也不需要一個文件一個文件輸入到變更系統，省去不少體力活（從3-4分鐘的提單時間降低到10秒完成提單）。 * merge分支主干時，不再需要自己手工本地co代碼，選擇revision，工具智能選擇需要合并的代碼，生成備注日志（10秒完成全部操作）。 2. 準確 * 智能提測，不遺漏文件。 * 提測時根據變更的文件，智能提示相關提測功能點，測試人員很容易知道當前變更會影響多少頁面/功能點。 * 上線前檢測是否已經對齊主干，避免覆蓋現網新改動的代碼。 * 上線后檢測當前分支是否已經合并回分支，避免沒有把代碼更新回主干。 ## 后話分析問題 —— 得出方案 —— 高效準確執行方案 —— 繼續高效準確執行很自然的一個流程，但是要克服惰性去執行它不容易。最后感謝rexschuang、zhikaimai陪我一起討論了好多次，并把整個工具完善落地。我們還在探討整個web開發生產活動的每個環節（提需求 -> 交互 -> 視覺 -> 開發 -> 連調 -> 提測 ->測試 ->上線）是否能夠再效率準確的點，也歡迎大家一起探討。