軟體開發過程中代碼經常出現低級問題，怎麼處理呢？用大家都能聽懂的白話文來給你講明白。
代碼畢竟是人寫的，不能保證一點錯也不出，但是絕對可以通過方法來減少甚至杜絕這種情況的發生。
出現問題，一個正常的思維是什麼呢？
先看看為什麼會出現問題，然後針對這些問題，做一些針對性的改進，這次改進了不算完事，要保證以後也不會出現這樣的問題，是以你就想了，能不能搞個規範的流程，大家都按着做，就不會出問題了。
小夥子，這個想法是很好的！是以，大家聚在一起就把規範搞出來了，然後大家照做。
那怎麼保證是按着規範做的呢？
做完以後，就得有個檢查的過程，總結執行計劃的結果，厘清哪些對了，哪些錯了，明确效果，找出問題。最後對檢查的結果進行處理，成功的表揚，失敗的總結教訓。這就是一個解決問題的流程。
那麼，從管理的角度而言，這就是PDCA戴明環管理方法。
P(PLAN)：從問題的定義到行動計劃
分析現狀，讨論出現問題的原因，确定最終的目标（就是以後不會出現低級問題）
比如，經常變量定義錯誤？邏輯錯誤？版本不對？未進行充分的單元測試、繼承測試，等等。。。
為什麼要讨論這個呢？
就是為了針對這些問題，對開發人員而言制訂出開發規範，對項目管理人員而言制定出管理規範。
D(DO)：實施行動計劃
就是執行落實上面制定的規範。開發人員執行既定的開發規範，管理人員依據管理規範監督開發人員執行情況。就是具體的行動方法。
C(CHECK)：評估結果
上一階段規範已經不折不扣的執行了，但是執行完不是萬事大吉，我們的最終目标是不會再出現之前的問題。是以，這一步就是确認實施方案是否達到了目标。效果檢查，檢查驗證、評估效果；"下屬隻做你檢查的工作，不做你希望的工作”， IBM的前CEO郭士納的這句話将檢查驗證、評估效果的重要性一語道破。
A(ACT)：标準化和進一步推廣
肯定成績，把成功的經驗盡可能納入标準，進行标準化，遺留問題則轉入下一個PDCA循環去解決。這個階段就是解決存在問題，總結經驗和吸取教訓的階段。該階段的重點又在于修訂标準，包括技術标準和管理制度。沒有标準化和制度化，就不可能使PDCA循環轉動向前。