前言
突然想聊聊開發流的東西，可能在一個新的環境下對之前的整個開發流程有了些思考，思考什麼？
我所理解的一個高效的開發流程應該是什麼樣的？
我所理解的開發流
實際工作也有四年了，做網際網路開發也三年了，所以自然而然對整個軟體開發流程有了些自己的想法和理解。對於我所理解的開發流程要有如下的特點：
- 儘可能的把問題暴露在開發時間週期的前期(凡事無完美，儘可能的想一些措施做好輔助即可)
- 養成好的開發習慣去避免犯錯
如下圖，是我整理的我所理解的一套開發流程：
上圖中，我們在開發過程中隨著時間線的前移，我們犯錯的概率儘可能的集中在前面。另外，圖中淡紫色的圖示是在我目前的開發流程中沒有或者體現的並不明顯的地方。
需要單獨說說的地方
一、技術評審
為什麼需要技術評審？當然這裡需要技術評審的應該是一些體積大或者影響面比較大的專案，具體的評判標準就依環境而定了。
技術評審的目的，一方面，開發人員向負責人和相關人員同步具體的技術實施方式，是一個資訊同步的過程；另一方面，負責人或相關負責人對技術方案進行評估，畢竟負責人和相關人員是對系統整體瞭解最透徹的人，從而避免未來專案開發完了或者上線了才發現一些比較大的問題。
最後，技術評審通過後，相應的開發人員寫程式碼也可以一蹴而就，安安心心的碼程式碼，是吧？
二、程式碼建模
建模也不是我第一次談到了，具體的例項在我之前的文章裡也能找得到，我為什麼這麼強調建模？因為建模(就是抽象)之後寫出來的程式碼往往思路清晰，高可擴充套件。
三、習慣性個人diff程式碼
①commit程式碼前diff程式碼 ②merge程式碼前diff程式碼 ③上線前多人diff程式碼
以上是我一定會去diff程式碼的場景，目的很簡單，一：是不是誤提交了程式碼 二：簡單的code review
四、code review
code review 的最佳時間我一般建議是開發完成時或聯調階段，因為這段時間業務程式碼基本是一個穩定的版本了。至於這個時間之前，程式碼不穩定；至於這個時間之後，review出問題再修改程式碼的成本(浪費測試的時間)會比較高。
五、上線前多人diff程式碼
目的很簡單：和每一位涉及的開發人員核對每一行程式碼的變動，防止誤提交被髮布到線上。
六、上線流程
這個一般出現在多專案上線的情況，涉及多專案的釋出依賴關係，為了保證最終按正確順序的序列上線。把上線的推進權利集中到一個人的手上，梳理並核對釋出順序，最終完成上線。
七、異常監測
例如後端系統的話，觀察系統的3xx、4xx、5xx異常日誌曲線在上線後是不是有突然的上升趨勢來判斷我們的上線是否正常。
掃面下方二維碼關注我的技術公眾號，及時為大家推送我的原創技術分享