關於開發流的一點思考

前言

---

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

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

我所理解的開發流

---

實際工做也有四年了，作互聯網開發也三年了，因此天然而然對整個軟件開發流程有了些本身的想法和理解。對於我所理解的開發流程要有以下的特色：

• 儘量的把問題暴露在開發時間週期的前期(凡事無完美，儘量的想一些措施作好輔助便可)
• 養成好的開發習慣去避免犯錯

以下圖，是我整理的我所理解的一套開發流程：

上圖中，咱們在開發過程當中隨着時間線的前移，咱們犯錯的機率儘量的集中在前面。另外，圖中淡紫色的圖標是在我目前的開發流程中沒有或者體現的並不明顯的地方。

須要單獨說說的地方

---

1、技術評審

爲何須要技術評審？固然這裏須要技術評審的應該是一些體積大或者影響面比較大的項目，具體的評判標準就依環境而定了。

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

最後，技術評審經過後，相應的開發人員寫代碼也能夠一蹴而就，安安心心的碼代碼，是吧？

2、代碼建模

建模也不是我第一次談到了，具體的實例在我以前的文章裏也能找獲得，我爲何這麼強調建模？由於建模(就是抽象)以後寫出來的代碼每每思路清晰，高可擴展。

3、習慣性我的diff代碼

①commit代碼前diff代碼 ②merge代碼前diff代碼 ③上線前多人diff代碼

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

4、code review

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

5、上線前多人diff代碼

目的很簡單：和每一位涉及的開發人員覈對每一行代碼的變更，防止誤提交被髮布到線上。

6、上線流程

這個通常出如今多項目上線的狀況，涉及多項目的發佈依賴關係，爲了保證最終按正確順序的串行上線。把上線的推動權利集中到一我的的手上，梳理並覈對發佈順序，最終完成上線。

7、異常監測

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

掃面下方二維碼關注個人技術公衆號，及時爲你們推送個人原創技術分享