天天看點

從實戰角度看如何建構高品質的軟體:一線工程師的一份品質手記

聚合了我六年開發生涯中所學到的、親身經曆的關于提升工程品質的絕大部分知識、技能與經驗。建構高品質高可用軟體,可以分為四層:代碼品質,設計品質,測試品質,工程品質。

概述###

這篇文章聚合了我六年開發生涯中所學到的、親身經曆的關于提升工程品質的絕大部分知識、技能與經驗。

要建構高品質高可用軟體,個人覺得,可以分四層來進行:

  • 代碼品質: 高品質軟體的基石。 任何設計、測試和工程方法都無法挽救爛代碼寫出來的系統。
  • 設計品質: 設計品質往往關乎軟體的全局性品質,比如穩定性、可擴充性、健壯性等。
  • 測試品質: 通過良好設計和實作的系統,需要測試品質來把關,保證代碼沒有重要BUG和變更不影響原有系統。
  • 工程品質: 在代碼、設計、測試品質的保證下,還需要工程手段(比如CodeReview, 持續內建、線上錯誤巡檢等)來聚合所有的環節,保證更好的輸出。

代碼品質###

代碼品質的提升,主要可以通過遵循良好的程式設計風格和習慣、追求和學習編寫優秀代碼、熟悉和避免常見程式設計錯誤與陷阱、注重細膩的代碼細節、持續小幅重構來實作。 代碼能力就像球員的腳法和控球技術,腳法不細膩的人很容易自潰防線。

由于程式設計實質上是一種嚴謹的邏輯表達活動,是以,訓練自然清晰的口頭和書面表達技能,嚴謹缜密的邏輯思考,也是間接提升代碼品質的方法。

  • 寫代碼的指導思想:如何寫出易測、清晰、健壯的牢固代碼
  • 代碼品質基本準則
  • 精練代碼:一次Java函數式程式設計的重構之旅
  • 編寫更少bug的程式的六條準則
  • 反思: 為什麼我連普通的程式都寫不好?

設計品質###

設計品質的提升,需要豐富的開發設計經驗、對健壯性、穩定性、擴充性、可維護性、高壓力承載能力等系統品質名額的全面了解,更深入透明地了解系統的運作,以及仔細考量避開陷阱。設計品質就像球員對全場的了解和掌控能力,懂得很好的傳球和助攻。

設計品質需要了解不同系統的特性。中小型系統通常沒有太大的壓力負荷,主要做好性能、健壯性、可擴充性和可維護性的設計;對于大并發系統,需要考慮承受持續而平穩的高壓力負荷和峰值壓力。需要挖掘系統的薄弱點并加以改進完善。

設計品質有時也與産品政策有關。較寬松的産品政策,會給設計留出更多的選擇空間;而較苛刻的産品政策,則會限制設計的選擇,日後改造起來成本也較大。 比如隻允許導出距目前N分鐘之前的訂單。 N 越大,導出設計的選擇空間越大,比如通路備叢集資料、離線計算等,可以提升整體叢集通路的穩定性,了解和維護成本也會大幅降低; 而 N 越小,會暗示商家更“即時”地導出,需要的實時性也越強,實際上并無必要。我以前還有覺得 N 設定小一些讓商家覺得系統的牛逼,現在覺得挺幼稚的想法。

軟體設計是一個需要持續拓展的領域。軟體的複雜度主要展現在對複雜業務及業務組合的綜合了解與領域模組化,落地在性能、維護成本、可擴充性、可定制性、穩定性、安全性和透明監控的設計方案中。非一朝一夕之功,亦非固定模式可循。目前還在持續積累中。

  • Web服務端軟體的服務品質概要
  • 設計方案考量的準則與細則
  • 因修改報表名稱引發的“慘案”
  • 批量發貨阻塞啟示:深挖系統薄弱點
  • 訂單導出應對大流量訂單導出時的設計問題
  • HBase指定大量列集合的場景下并發拉取資料時卡住的問題排查
  • 通用訂單搜尋的API設計得失錄
  • 有贊訂單導出的配置化實踐

測試品質###

測試品質的提升,主要可以通過單測、接口測試、對比測試、壓力測試等來保證。 對于開發人員來說,測試品質的提升主要靠兩點: 1. 編寫覆寫性強的單測和接口測試的習慣和素養; 2. 開發盡可能自動化的測試用例和對比工具。 多多益善,有勝于無。

測試主要追求高效。高效意味着有效與效率。高效的測試用例和高效地建立高效測試用例。 高效的測試用例: 以有限的測試用例覆寫核心流程和方法、主流程和方法、常用流程和方法、會造成資損的流程和方法、影響使用者使用的流程和方法。測試用例忌追求全面,但是要覆寫足夠全面。高效地建立測試用例: 設計良好的測試架構,通過配置化的方式來快速增加測試用例,而不是需要編寫測試代碼。測試資料與測試代碼分離。

  • 訂單搜尋分頁失效的教訓:怠惰必受懲罰
  • 使用Groovy+Spock輕松寫出更簡潔的單測
  • 深入探究單元測試編寫
  • 使用Java函數接口及lambda表達式隔離和模拟外部依賴更容易滴單測
  • 使用Groovy+Spock建構可配置的接口測試用例集
  • 基于Groovy+HttpRestful的超輕量級的接口測試用例配置的設計方案及DEMO實作
  • 預發和線上的自動化對比工具微架構
  • 輸入輸出無依賴型函數的GroovySpock單測模闆的自動生成工具(上)
  • 克服“測試怠惰”的習慣

工程品質###

工程品質的提升,主要可以通過團隊開發規範、CodeReview、持續內建、錯誤日志巡檢等手段來保證。

  • 工程品質保障的基本規範和建議
  • CodeReview實踐與總結
  • 發貨服務化的工程品質實踐
  • Extjs4前端開發代碼規範參考
  • 保持應用系統可維護性的八個實際措施

品質評分建議###

  • 功能實作,可接受的性能 50分
  • 适當單測,覆寫主流程和核心方法 60分
  • 适當的日志,覆寫主要路徑和狀态 63分
  • 添加錯誤和異常處理,增強系統健壯性 68分
  • 代碼遵循良好的程式設計風格和慣用法,很少重複代碼 72分
  • 對象職責劃分合理,互動比較清晰 75分
  • 性能達到比較優異,消除系統明顯薄弱點 80分
  • 有設計良好的公共接口、子產品和API及實作 83分
  • 為擴充變化預留了設計空間 85分
  • 有通過配置化和定制化實作需求的能力 88分
  • 代碼與設計流暢自然清晰 90分
  • 正常服務運作穩定,高壓力負荷下堅挺 92分
  • 可靠性超過99.99% 95分
  • 透明嚴密的系統監控與報警 97分
  • 故障自動恢複能力 99分
  • 無堅可摧,神一樣的系統 100分

繼續閱讀