做了很多專案，每個專案都有不同的bug產生，如何減少bug產生的個數，如何避免重複的犯錯，最終的目的是去提高專案質量，就成為我們開發人員所需要關注的地方了。面對越來越多的變更需求，在敏捷開發中需要我們更多的提煉合適的方法去處理變化的需求。
減少bug的產生，可以從幾個方面的維度去考慮：
1.專案設計文件：乙個迭代中可能出現比較複雜的業務邏輯，乙個好的設計文件就決定了開發人員在開發中的思路，參照文件可以更快的把握需求和coding。
① 編寫設計文件需要考慮全面，在上新業務的時候需要全面權衡在哪些方面會影響原有的邏輯，規避設計時少考慮或者考慮欠缺全面的情況。
② 設計完成後需要通知qa，pd等相關人員進行評審，綜合各方的意見，最後在大家都認可的情況下完成乙個最終的設計文件。
2.開發質量：開發人員有水平的高低和不同的角度看問題，不同的開發人員寫出的**也是不同的。那麼結對程式設計將很好的去處理這個問題，通過兩個人對需求模組的分工去各自完成**後，互相review對方的**，並通過tala這個code review 工具進行彙總記錄**中的缺陷和邏輯問題，在結對人員修改完**後再次check**。可以保證開發階段的**邏輯問題的減少。
3.自測階段：在專案開發結束後，專案進入聯調自測階段。這個時候開發人員可以先對完成的功能進行自測。如何進行自測又可以從以下幾個點來進行：
① 開發**結束後，結對人員對對方的**進行編寫單元測試，通過單元測試的編寫，能夠進一步的提高結對人員對對方**邏輯的熟悉以及驗證開發結果是否滿足需求。
② 在提交測試前一天，進行黑盒測試，參考qa的測試用例，對主流程邏輯進行驗證，盡可能的走多的分支流程，降低提交測試後的專案bug的產生的風險，提前測試判斷功能實現是否需求，確保冒煙測試的一次通過率。
③ 不確定的業務實現和需求盡早提出，在群裡或者郵件告知pd，pm和qa等人員，三方一起溝通確定業務實現，降低提交測試後的不明確需求導致的bug，降低溝通成本。
4.專案總結：專案發布後，我們都需要做總結和回顧，可以從以下幾點開始入手：
①
bug分析：通過對專案中產生的bug的原因入手，分析導致bug的情況是屬於設計階段還是開發階段，總結原因，提醒我們在下次開發中需要加強哪方面的投入。
② 做的好的，做的不好的和可以嘗試的三點總結：專案組中開發人員各自寫上這三條中的內容，然後將進行分類彙總，做的好的需要保持，做的不好的需要我們重點投入精力去完善，可以改進嘗試的項在下次迭代中進行實踐。
③ 專案心得：開發人員通過每次專案進行總結體會，在不斷的專案開發中實現個人成長，而不是做完就忘了做了什麼，進一步的促進開發人員的個人成長。
希望通過這個說明能夠給大家在提高專案質量上有所幫助，以上4點歸類後就是以下這張圖所示：
提高程式設計質量的一些規則（1）
規則一 為了防止標頭檔案被重複引用，應當用ifndef define endif結構產生預處理塊。規則二 用 include 格式來引用標準庫的標頭檔案 編譯器將從標準庫目錄開始搜尋 規則三 用 include filename.h 格式來引用非標準庫的標頭檔案 編譯器將從使用者的工作目錄開始搜尋 ...
軟體質量的一些問題
如果要分析原因的話可能有一下幾點吧 第一點，之前我們開發進行開發不論前端後端都是上來就擼 完了也不會寫單元測試 公司整個專案沒有任何一段單元測試的 以後要是重構就頭痛了 頂多就是自己對介面跑一兩次，跟別說什麼測試覆蓋率這些了，壓根就沒有，團隊成員也都沒有概念。完了就直接丟給測試跟測試說這個功能好了測...
軟體內部質量的一些思考
內部質量指的是 的可讀性，可修改性，複雜度 圈複雜度，函式深度 可移植性等軟性質量。像bug率指的是外部質量 軟體的內部質量只對開發者有直接影響，對公司來說間接影響就是開發的維護成本。為什麼程式會有這麼多偶然複雜性呢？基本都會有這個問題，在傳統公司，每半年會有個大版本，質量改進可以放到乙個大版本中來...