關於開發流的一點思考

突然想聊聊開發流的東西，可能在乙個新的環境下對之前的整個開發流程有了些思考，思考什麼？

我所理解的乙個高效的開發流程應該是什麼樣的？

實際工作也有四年了，做網際網路開發也三年了，所以自然而然對整個軟體開發流程有了些自己的想法和理解。對於我所理解的開發流程要有如下的特點：

上圖中，我們在開發過程中隨著時間線的前移，我們犯錯的概率盡可能的集中在前面。另外，圖中淡紫色的圖示是在我目前的開發流程中沒有或者體現的並不明顯的地方。

一、技術評審

為什麼需要技術評審？當然這裡需要技術評審的應該是一些體積大或者影響面比較大的專案，具體的評判標準就依環境而定了。

技術評審的目的，一方面，開發人員向負責人和相關人員同步具體的技術實施方式，是乙個資訊同步的過程；另一方面，負責人或相關負責人對技術方案進行評估，畢竟負責人和相關人員是對系統整體了解最透徹的人，從而避免未來專案開發完了或者上線了才發現一些比較大的問題。

最後，技術評審通過後，相應的開發人員寫**也可以一蹴而就，安安心心的碼**，是吧？

二、**建模

建模也不是我第一次談到了，具體的例項在我之前的文章裡也能找得到，我為什麼這麼強調建模？因為建模(就是抽象)之後寫出來的**往往思路清晰，高可擴充套件。

三、習慣性個人diff**

①commit**前diff** ②merge**前diff** ③上線前多人diff**

以上是我一定會去diff**的場景，目的很簡單，一：是不是誤提交了** 二：簡單的code review

四、code review

code review 的最佳時間我一般建議是開發完成時或聯調階段，因為這段時間業務**基本是乙個穩定的版本了。至於這個時間之前，**不穩定；至於這個時間之後，review出問題再修改**的成本(浪費測試的時間)會比較高。

五、上線前多人diff**

目的很簡單：和每一位涉及的開發人員核對每一行**的變動，防止誤提交被發布到線上。

六、上線流程

這個一般出現在多專案上線的情況，涉及多專案的發布依賴關係，為了保證最終按正確順序的序列上線。把上線的推進權利集中到乙個人的手上，梳理並核對發布順序，最終完成上線。

七、異常監測

例如後端系統的話，觀察系統的3xx、4xx、5xx異常日誌曲線在上線後是不是有突然的上公升趨勢來判斷我們的上線是否正常。