在開發過程中我意識到一個問題
具體問題就是我沒有一個可靠的機制來防止自己犯錯
現在的流程是 開發 + 調試 -> 測試同學 -> 上線
這裏測試的時間會有點長，因爲bug會有點多，然後需要修改bug，然後測試驗證
改bug時間 = 理解測試bug描述的內容 + 復現bug + 閱讀代碼 + 找出漏洞修改 + 測試驗證關閉bug
改進後的流程是 開發 + 調試 + 最後整體檢查 + 寫測試 -> 測試同學 -> 上線
這種開發模式會環節有點多，寫測試 + 最後整體檢查是多出來的
其實第一個開發模式是不負責任的，把風險轉嫁給了測試。我們交給測試的代碼應該是在自己看來檢查不出問題了（而不是自己不做檢查），測試作爲上線最後把關驗證代碼
整體檢查一遍其實也不會話費多少時間，就算是code review了吧
整體檢查一遍計劃時間是3個小時左右，其實就是跑一遍整個prd的描述
編寫測試真的會佔用很多時間嗎？
其實並不見得
首先，我們並不需要爲所有代碼添加測試
比如 1 + 1 === 2 這種就不需要
其次，我們需要熟悉測試框架和工具，做到信手拈來則會提高效率
哪些代碼需要測試，這是個問題。相比測試覆蓋率100%這種偉大的目標，我提倡的是指哪打哪的方針，只針對自己沒有信心的代碼編寫測試
隨着測試代碼的增加收益會隨之降低，所以指導思想就是，自己覺得會出錯的，後面想要修改實現的，實現複雜的代碼需要測試。這樣會用極小的代價獲取極高的收益
最後測試是一個工具，保證我們代碼在自己手中的時候，再一個範圍內不出問題的最後一道保障，現在我想將這道屏障豎起來，被丟掉的底褲穿起來
設計模式則是在開發中減少bug，清晰思路，方便擴展，方便修改的手段，這是在編碼階段就有一個良好的結構自然會減少很多bug
這些機制都是尊重墨菲定律而制定的方案，肯定不能百分百解決問題，但是會極大的減小出問題的概率，甚至提升整個項目的效率，提升項目質量
所以後面的開發流程就被我改成了
開發（依賴設計模式原則） + 調試（開發的反饋） + 寫測試 + 最後檢查 -> 測試同學 -> 修改bug -> 迴歸 -> 上線
後面的開發流程務必遵守
bug是不可避免的，並且是測不完的，這就需要我們有一個策略能保證項目正常進行，這就是在一個合理的範圍內保證項目正常運行。而這個合理的範圍具體化就是測試編寫的測試用例
其他問題
在開發中我們總想着快點完成任務，有的時候急於求成就會埋下很多不好的設計，想着寫完了有時間再過來修改，就像迭代一樣，一步一步完善。
還有一種編碼方式是一步到位，該做的都做好，後面不需要返工。
這兩種方法，暫時我傾向的一步到位爲，不需要返工。但是實際工作中確是採用了迭代的方式，一步一步完善的。因爲我做不到一步到位，總想着快點完成，控制不住自己
爲什麼我傾向於一步到位呢？因爲返工是有成本的，需要重新理解自己寫的代碼，需要花費更多的時間。但是因爲想要達到完美就止步不前也是不好的，所以其中權衡也沒有一個標準答案