在開發過程中我意識到一個問題

具體問題就是我沒有一個可靠的機制來防止自己犯錯

現在的流程是 開發 + 調試 -> 測試同學 -> 上線

這里測試的時間會有點長，因為bug會有點多，然后需要修改bug，然后測試驗證
改bug時間 = 理解測試bug描述的內容 + 復現bug + 閱讀代碼 + 找出漏洞修改 + 測試驗證關閉bug

改進后的流程是 開發 + 調試 + 最后整體檢查 + 寫測試 -> 測試同學 -> 上線

這種開發模式會環節有點多，寫測試 + 最后整體檢查是多出來的

其實第一個開發模式是不負責任的，把風險轉嫁給了測試。我們交給測試的代碼應該是在自己看來檢查不出問題了（而不是自己不做檢查），測試作為上線最后把關驗證代碼

整體檢查一遍其實也不會話費多少時間，就算是code review了吧
整體檢查一遍計劃時間是3個小時左右，其實就是跑一遍整個prd的描述

編寫測試真的會占用很多時間嗎？

其實并不見得

首先，我們并不需要為所有代碼添加測試

比如 1 + 1 === 2 這種就不需要

其次，我們需要熟悉測試框架和工具，做到信手拈來則會提高效率

哪些代碼需要測試，這是個問題。相比測試覆蓋率100%這種偉大的目標，我提倡的是指哪打哪的方針，只針對自己沒有信心的代碼編寫測試

隨著測試代碼的增加收益會隨之降低，所以指導思想就是，自己覺得會出錯的，后面想要修改實現的，實現復雜的代碼需要測試。這樣會用極小的代價獲取極高的收益

最后測試是一個工具，保證我們代碼在自己手中的時候，再一個范圍內不出問題的最后一道保障，現在我想將這道屏障豎起來，被丟掉的底褲穿起來

設計模式則是在開發中減少bug，清晰思路，方便擴展，方便修改的手段，這是在編碼階段就有一個良好的結構自然會減少很多bug

這些機制都是尊重墨菲定律而制定的方案，肯定不能百分百解決問題，但是會極大的減小出問題的概率，甚至提升整個項目的效率，提升項目質量
所以后面的開發流程就被我改成了

開發（依賴設計模式原則） + 調試（開發的反饋） + 寫測試 + 最后檢查 -> 測試同學 -> 修改bug -> 回歸 -> 上線

后面的開發流程務必遵守

bug是不可避免的，并且是測不完的，這就需要我們有一個策略能保證項目正常進行，這就是在一個合理的范圍內保證項目正常運行。而這個合理的范圍具體化就是測試編寫的測試用例

其他問題

在開發中我們總想著快點完成任務，有的時候急于求成就會埋下很多不好的設計，想著寫完了有時間再過來修改，就像迭代一樣，一步一步完善。

還有一種編碼方式是一步到位，該做的都做好，后面不需要返工。

這兩種方法，暫時我傾向的一步到位為，不需要返工。但是實際工作中確是采用了迭代的方式，一步一步完善的。因為我做不到一步到位，總想著快點完成，控制不住自己

為什么我傾向于一步到位呢？因為返工是有成本的，需要重新理解自己寫的代碼，需要花費更多的時間。但是因為想要達到完美就止步不前也是不好的，所以其中權衡也沒有一個標準答案

總結

以上是生活随笔為你收集整理的开发流程补全的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。