標籤:
提供同樣功能、產品和服務的服務者中, 競爭力來自功能的多樣化和服務品質的差異化, 無論是個體、企業還是國家。
這裡的服務指功能、產品的實現程度和處理能力,以及研發/客服提供的支援人員程度(7*24, 隨時響應, 溝通便捷,快速解決,溫馨提示,有效指南等)。
從某種意義來說, 一切皆服務。 功能和產品只是形式, 服務才是本質。服務響應某種需求從而具備存在價值。個體、企業為社會提供某種類型、某種程度的服務,並獲得相應回報。
程式員提供的服務是,在特定的工作環境和企業文化中,運用可用的資源以及自己的知識、技能、經驗、時間、精力、資源,在適當可接受的開發成本下,通過將現實問題構造和組織成正確的邏輯流而獲得問題的解決並持續維護的能力程度。
這種能力程度既包括服務能力本身,也包括通過這種能力所創造的服務的能力。 服務能力本身主要包括: 精通特定語言、技術、平台、架構等的技術深度; 組合技術、產品、運營、服務、商業的綜合認知廣度;具備多樣化技能(開發、寫作、外語、溝通、組織、幽默等);做事的能力素養,耐心、專註、縝密、魄力等; 具備非技術方面的特長,比如體育、音樂、文學、藝術、設計等。 通過這種能力所創造的服務, 通常是指軟體、產品或服務。
如何保證服務端開發的功能和服務達到應有的品質呢?
1. 明確需要達成的品質; 知道做什麼以及如何做;
2. 將服務品質儘可能量化並進行測量,做到服務品質透明化;
3. 更傾向於情感因素的服務品質,採用情感化方法處理。不在本文討論範圍內。
基本品質:
1. 正確性: 軟體是否正確實現了指定的功能, 滿足客戶的多樣化需要。
在內部實現上,是資料是否正確完整地構造、存取或銷毀,且沒有產生髒資料和無效資料【內部品質】。
需要建立功能實現的整個流程環路,對其中的所有細節知根究底,對互動的外部系統提供的相關服務也了如指掌。
量化: 業務資料是否合理的存取和一致。
2. 運行效率: 軟體實現指定功能和服務所需時間和資源。 需要有誤差範圍的測量或估算。
可參考 SLA (服務等級協議)。 程式的執行效率應當在可接受的開發成本下達到最佳。
這就是說,在 "開發功能所需要的時間和資源成本" 與 "最終實現的服務能夠提供的品質" 存在一個權衡。
一般來說,品質越高的服務所需要的時間和資源成本越高;無止境追求更高效率而不計成本和服務目標是不可取的。
比較理想的情況是: 通過適量改進、技術革新、管理改善等,可以使得花費較少的時間和資源成本能夠獲得更高的服務品質。
量化: 已耗用時間、 所需的儲存資源、 回應時間、輸送量、並發能力。
3. 錯誤處理: 軟體能夠捕獲所有的錯誤條件(前提不符合、非法輸入、髒資料等)和異常情況並給出合適的返回資訊。
對於前端互動而言,需要友好容易理解的提示資訊; 對於後台服務而言, 需要規範的錯誤碼和錯誤訊息。
建議先建立正確流程的業務主流程,然後對於主流程的每個環節進行推敲,找出各種錯誤情境並進行處理。
量化: 錯誤情境覆蓋完全程度。
4. 易追蹤性: 程式運行過程中輸出適量的日誌資訊,便於追蹤程式執行狀態,快速排查錯誤【內部品質】。
需要適量且關鍵的 INFO 日誌和 Error 日誌。個人認為 DEBUG 日誌可以通過提升代碼品質來消除其必要性。
量化: 排查、定位每個問題的所需時間長度。
5. 易測試性: 主要是單元測試、自動化功能測試和效能測試。 單元測試和功能測試保證正確性,效能測試保證效率【內部品質】。
單元測試要求在開發過程中盡量編寫具有單一職責的短小方法、類;代碼對象越小,單元測試所發揮的作用越大。
功能測試要求針對具體使用情境設計有效測試案例、測試計劃和測試執行。
效能測試要求對業務處理所需的時間和資源進行測量,給出最佳值、最差值和平均值。至少要對已耗用時間進行測量。
量化: 業務方法的測試覆蓋度、程式碼、分支覆蓋程度、測試案例集合、效能測試報告。
6. 安全性: 避免泄漏重要、敏感、隱私資訊; 保護業務和資料不受非法訪問、非授權訪問的破壞; 追蹤系統訪問日誌。
常見的方法有敏感資訊識別和屏蔽、訪問授權機制、 訪問日誌審計、代碼漏洞防備。
可擴充性品質:
7. 可複用性: 要求軟體中的函數、方法、類、庫、模組、組件、架構等能夠在同一工程或不同項目或不同產品中多次使用,便於替換更新【內部品質】。
最起碼要求是在同一工程中能夠儘可能複用, 避免重複程式碼片段。每個業務方法最好不超過 60 行。
對於每個知識點、業務點和事實都有合理的抽象。
量化: 重複程式碼片段數量; 函數、方法、類、庫、模組、組件、架構的複用次數。
8. 可維護性: 要求軟體容易理解、容易做出修改以滿足新的需求,通常系統應具備模組化、高內聚、松耦合的特性【內部品質】。
容易理解需要可複用性的支援,同時要求代碼儘可能具有自解釋能力、適量注釋、有效更新的設計文檔。
容易修改需要快速定位一個功能服務所應對的代碼集合,要求代碼具有良好的組織和實現結構,
避免對多個地方做出相同或類似的修改; 避免對原有整體設計做出大幅度修改。
請參考《敏捷式軟體開發 (Agile Software Development):原則、模式和實踐》一書,儘可能滿足五大設計原則(SRP, OCP, LSP, DIP, ISP),
實現“對修改關閉,對擴充開放”的境界。即:對於新需求的開發,儘可能僅僅是增加代碼,而不需要修改原有代碼。
量化: 理解一個功能需要的時間長度; 修改或擴充一個功能需要修改的程式碼。
全域性品質:
9. 可用性: 程式運行中能夠始終如一、持續長時間地提供正確、一致性的服務。
要求程式能夠合理地使用和釋放資源,監控程式的運行狀態並及時發現異常情況解決。
對於高並發情境, 需要採用合適的技術進行分流,及時處理或拒絕請求,避免因為資源消耗過快過大而導致服務崩潰。
量化: 程式的持續可用性時間長度; 高並發能力。
10. 可靠性: 服務在嚴重錯誤情況下的可恢複能力和可替換能力,避免單點故障,保證可用性,保證使用者資料的正確性和完整性。
主要包括服務的冗餘、容錯、備份、監控、自檢測和恢複機制。
量化: 服務發生錯誤時是否可用; 是否可以從錯誤中恢複。
11. 可移植性: 軟體能夠在多種運行環境、平台上一致性地正確運行而只需要做出少量修改或無需修改。
使用可移植語言和平台、在實現功能和服務時儘可能遵循標準介面和行為,減少非標準行為的使用;
在底層提供介面統一不同平台的差異性;在高層使用統一介面進行處理,避免處理平台細節。
可移植性最好在系統構建之初進行考慮,比如初始採用 PHP, 後續移植到 Ruby, Python 或 Java 平台。
量化: 從一種語言移植到另一種語言或從一個平台移植到另一個平台所需要的程式碼。
12. 可營運性: 服務發布後,管理大規模服務的運行、排查/診斷/解決問題的難度和速度、處理使用者反饋的工作量。
服務發布後,可能產生的問題有哪些? 怎麼排查? 服務的運行規模有多大? 並發程度如何?
在服務開發上,需要避免的是低級問題的產生,減少低級錯誤導致的工作量;
對於疑難問題,則需要提供關鍵的日誌資訊/營運文檔便於排查;
對於大規模服務的運行,通常的方法是監控、警示以及可視化。
量化: 參考營運的量化標準。
13. 互通性: 軟體與其他系統互動的難易程度。主要包括通訊方式、版本相容性。
參考文章:
《用SLA保證Web服務》: https://www.ibm.com/developerworks/cn/webservices/ws-sla/
《軟體品質模型》: http://www.cnblogs.com/gaochundong/p/software_quality_models.html
《細說軟體品質指標》: http://developer.51cto.com/art/201104/255676.htm
《實現軟體架構品質屬性的戰術》: http://www.uml.org.cn/zjjs/201309043.asp
《可複用性:專題》: http://focus.it168.com/200810/softwarereuse/
服務端軟體的服務品質保證