《SAFe 4.0參考指南：精益軟體與系統工程的規模化靈活架構》一3.15 内建品質

本節書摘來自華章出版社《safe 4.0參考指南：精益軟體與系統工程的規模化靈活架構》一書中的第3章，第3.15節 作者［美］迪恩·萊芬（deanleffingwell），更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

3.15　内建品質

通過快速內建學習環，進行增量式建構。

—— safe原則#4

摘要

内建品質是safe的四個核心價值觀之一。企業以最快的可持續前置時間傳遞新功能，并應對瞬息萬變的商業環境，這些都有賴于解決方案的品質。内建品質不是safe特有的概念，它是精益–靈活的核心原則之一，有助于避免與需求召回、返工及缺陷修複相關的延遲成本。靈活宣言同樣專注于品質，其中有一條靈活原則是這樣描述的：“堅持不懈地追求技術卓越和良好設計，靈活能力由此增強”（參考資料[1]）。内建品質對于大規模系統的價值是确切無疑的，并且屬于強制性的。為此，本節将介紹軟體、固件和硬體的品質實踐。

軟體方面的品質實踐——很多是受到極限程式設計的啟發，而且在極限程式設計中也有描述——可以幫助靈活軟體開發團隊，確定他們所建構的解決方案是高品質的，易于響應變化的。這些實踐間的互相協同的本質，重點在于頻繁地确認，以及建立一種把工程和匠藝作為關鍵業務推動者的自發的文化氛圍。

對于固件和硬體，其品質目标和軟體是相同的，但是在實體和經濟上有些不同，是以實踐上也有些差異。這些差異包括，固件和硬體的開發會更加專注于模組化、模拟和更多的早期探索過程，以及更多的設計驗證和更頻繁的系統級內建。

詳述

當企業需要應對變化時，建立在良好的技術基礎上的軟體和系統更容易去改變和适應。這對大型系統來說則更為重要，因為即使是小缺陷的累積效應以及錯誤的假設，都可能造成令人無法接受的後果。

實作高品質的系統是一項嚴謹的工作，需要持續的教育訓練和承諾，但對業務收益的投資也是非常必要的：

更高的客戶滿意度——低缺陷率的産品和服務能提供更好的客戶滿意度、更高的安全性、更好的投資回報，并給業務部門增添更多的信心。

開發組織的預見性與信任——如未在解決方案的品質上進行可靠的控制，那麼對新功能的開發不可能做出可預測性的計劃，也無法确定開發的速度。是以在公司内會造成一種信任感缺乏，降低個體對軟體工藝的榮譽感，造成士氣的低落。

可延展性——當元件能清楚地表達設計意圖，展現出簡潔的風格，并在系統架構上支援內建和測試，這時投入更多的人力和資源會為企業帶來更多的商業價值。否則，增加更多的開發和測試人員反而會給企業帶來拖累，最終将導緻高度不确定的、企業無法接受的品質和延遲。

速度、靈活性和系統性能——更高的品質有助于提高可維護性和增強快速開發新業務功能的能力。同時也會提高團隊維護和提升關鍵的非功能性需求的能力，包括：性能、可擴充性、安全性和可靠性。

創新的能力——創新出現在聰明的、富有激情的人身上，以及由他們所掌控的環境中。在高品質創造出的良好技術環境下，創新的想法能夠很容易地産生原型、測試和示範。

下文将對在軟體、固件和硬體上達成内建品質的實踐進行總結。

軟體

safe是建立在長達幾十年的不斷演化、不斷追求更好的工程實踐的基礎之上的，在很大程度上受到了創新性的精益和靈活方法的推動。當談到軟體工程時，極限程式設計實踐起着引領的地位（參考資料[2]）。除了靈活架構在保證系統級的品質中所起的關鍵作用之外，safe還引入了關鍵的精益–靈活軟體工程實踐，以幫助團隊實作最進階别的品質。下文總結了這些實踐，其中的兩個——持續內建和測試先行，在本書中會有更深入的闡述。

持續內建

持續內建（continuous integration，ci）是一種軟體工程實踐，它每天不間斷地把開發人員自己工作空間中的代碼合并到單一主幹代碼分支上。通過這種方式，所有共同開發程式的人員能一直保持在最新的程式版本上工作，開發人員之間的程式缺陷能立即被發現，假設也能立刻得到驗證。持續內建有助于避免系統內建的延遲風險，及其對系統品質和項目可預測性的不利影響。

持續內建需要專業的基礎設施和工具，包括自動化建構伺服器和自動化測試架構。但更重要的是需要建立一種文化和使命感，要求個人和團隊以傳遞完全內建和全面測試的軟體為榮。

在safe中，團隊至少每天執行一次本地內建，但同樣重要的是要将完整的系統進行內建，并在必要的時候運作回歸測試，以確定系統向期望的方向發展。在初期實作每日內建不太可行，是以合理的初始目标可能是，在每疊代中至少實作一到兩次全系統的內建。這樣也為成功地進行每兩周一次的系統示範提供了基線。

8.1節中提供了關于該主題的更多内容，特别是系統級和解決方案級的持續內建。

測試先行

測試先行是一種鼓勵團隊在代碼實作前深入思考系統行為的哲學。它提升了編碼的效率并使得産品更易于使用，它同時建立了一種更為全面的測試政策，由此系統的需求被轉化為一系列的測試案例，通常這些測試案例在編寫代碼前會事先寫好。

測試先行政策可細分為測試驅動開發（tdd）和接收測試驅動開發（atdd）。兩者都由自動化測試所支援，自動化測試是支援持續內建、團隊速度和開發有效性所必需的。

在測試驅動開發中，開發人員首先編寫自動化單元測試案例，執行測試案例并觀察其運作失敗，然後編寫一個最小的代碼用以通過測試。測試驅動開發主要适用于編碼方法或者單元（技術）層面，這保證了測試的真實存在，防止鍍金和編寫不必要的更複雜的代碼。同時，測試驅動開發還有助于保證需求能持續得到自動化測試，并保持最新的狀态。

接收測試驅動開發是一種先進的技術，表征系統行為的接收标準由産品負責人确定，然後将接收标準轉換為可反複執行的接收測試，在系統演進的過程中保證持續的一緻性。接收測試驅動開發有助于團隊專注于系統級别的、使用者可觀測的需求，這給團隊提供了清晰的成功标準。

8.2節中提供了關于該主題的更多内容。

重構

重構是“重組代碼的現有結構，改變其内部結構而不改變其外部行為的技術”（參考資料[3]）。靈活避免“大量的前期設計”（bufd），并遵從“即使在開發後期，也擁抱需求變

更”（參考資料[1]），這意味着目前的代碼庫在業務需要新增功能時是經得起考驗的。為了保持這種應變能力，團隊不間斷地通過一系列小的改進持續進行重構，為未來的發展打下堅實的基礎。如果因為“總是希望增加新功能”，而忽視重構，就會快速建構起一個僵化和不可維護的系統，最終導緻經濟效益越來越差。

重構是實作浮現式設計的關鍵，而且是靈活開發中必要和不可或缺的組成部分。有關重構的更多指導資訊，請參見“重構”的有關闡述。

結對工作

結對工作與結對程式設計相對應，結對程式設計是極限程式設計中的一種強制實踐，需要兩個程式員在同一台電腦上工作。一個人編碼，另一個人是觀察員，負責評審、檢查和為編碼過程增值，在結對過程中角色可以互換。在每寫一行代碼前，結對人員都要讨論需要做的事情，并達成對需求、設計、測試的一緻了解。觀察員檢查代碼，提出關于如何提高代碼的意見，并指出潛在的錯誤。結對程式設計中會進行實時的、全面的同行評審。

結對程式設計是極限程式設計的組成部分，但它也是有争議的，有些人認為結對增加了成本，因為兩個人在同樣的代碼上工作。同時，結對程式設計也可能面臨人際交往和文化上的挑戰。

對很多人而言，結對程式設計過于極端了。然而在實踐中，靈活團隊中有很多種不同的結對工作方式，每一種都有其價值，并且可以結合起來應用。有的團隊在所有編碼工作上都遵循結對程式設計标準，就像極限程式設計中所描述的那樣；有的團隊中開發人員與測試人員針對故事進行結對，在故事完成時評審彼此的工作；還有的團隊更傾向于自發的結對，開發人員在關鍵代碼片段、重構遺留代碼、開發接口定義以及系統級别內建等有挑戰性的工作上進行結對。結對工作是重構、持續內建、測試自動化，以及代碼集體所有權的重要基礎。

集體所有權

集體所有權“鼓勵每個人為項目的所有部分貢獻新的想法。任何開發人員都可以更改任意一行代碼去增加新的功能、修複缺陷、改進設計或重構。沒有人會成為變化的瓶頸”（參考資料[4]）。集體所有權在safe體系中尤為重要，因為大型系統擁有大型代碼庫，最初的開發人員很可能已經不在項目團隊中了。即使那些人還在團隊中，如果總是依賴某一個人去修改代碼，就會造成工作上的交接，也一定會帶來延遲等待。

擴充集體所有權的實施，需要在整個項目群中遵循經過驗證的、一緻商定的編碼标準，擁抱簡單的設計，揭示代碼結構中的意圖，并建立接口機制用于進行靈活的系統修改。

固件和硬體

除了編碼以外，沒人能夠擴充低品質的元件或系統。硬體元素都很少涉及“軟”的部分，比如電子、電氣、流體、光學、機械、包裝、熱能等，是以它們更加難以變更，而且如果發生變更會更為昂貴。如圖3.15-1所示（參考資料[5]），固件和硬體中的錯誤和未經證明的假設可能導緻更高的變更和返工成本。

如下文所述，這種更高的後期變更成本，促使網絡實體系統的精益開發人員使用一些相關實踐，確定在解決方案開發過程中的内建品質。

探索早期疊代

正如參考文獻[6]中所強調的，即使在建造“哈雷–戴維森摩托”時，也需要一個非常完整的團隊在道路上測試新的機車，更頻繁的設計周期是系統建構者的有效工具，它能夠用以加快對産品知識的掌握，降低風險和後期發現錯誤的成本。在這方面，safe使用與軟體相同的方式來處理固件和硬體，比如所涉及的疊代和項目群增量節奏，以及目标期望等都大緻相同。然而，早期的疊代是特别關鍵的，因為變更成本還沒有達到很高的水準。精益系統建構者應用“更軟”的工具系統展開更快的疊代，包括以下内容：

靈活架構

基于模型的系統工程

基于集合的設計

頻繁的系統級內建和測試

持續內建是許多軟體解決方案的一個有價值的、可實作的目标。然而，在網絡實體系統中卻難以應用甚至難以想象，因為有許多實體部件——模具、機械、小部件等，産品演變緩慢，而且無法每天進行內建和評估。但是，這不能成為延遲和難于進行內建的借口。

畢竟，最終所有不同的元件和子系統——軟體、固件、硬體等——必須內建到一起，才能提供有效的解決方案級的行為，而且越早越好。為此，精益系統建構者嘗試在早期頻繁地內建和測試子系統和完整系統。這通常需要增加在開發、部署、測試等基礎設施方面的投資。

設計驗證

然而，僅僅內建和測試是不夠的。首先，由于系統的各種元件在可用性方面的依賴，內建和測試可能在整個流程中發生得太晚；第二，內建和測試不可能覆寫所有可能的使用情況和失敗場景。為了解決這個問題，系統建構者執行設計驗證以確定設計滿足解決方案的意圖。設計驗證可以包括：諸如子系統之間需求的規範和分析的步驟，最差情況下的容忍度和性能分析，失敗模型和影響分析，可跟蹤性，熱分析，環境，以及其他系統級部署方面等。

在軟體領域，雖然設計驗證的諸多方法也很重要，但由于軟體的變更成本較低，是以在設計的選擇上不需要太多的事先承諾。然而，對于固件和硬體，需要前期設計方面的更多考慮，以及工作規範上的保證。

參考資料

[1]　manifesto for agile software development.

www.agilemanifesto.org.

[2]　beck, kent, and cynthia andres. extreme

programming explained: embrace change. addison-wesley, 2004.

[3]　fowler, martin. refactoring.com.

[4]　http://www.extremeprogramming.org/rules/collective.html.

[5]　rubin, ken. http://www.innolution.com/blog/agile-in-a-hardware-firmware-environment-draw-the-cost-ofchange-curve.

[6]　oosterwal, dantar p. the lean machine: how

harley-davidson drove top-line growth and profitability with revolutionary lean

product development. amacom, 2010.