一、什么是質量內建

目前創新互聯公司已為上千的企業提供了網站建設、域名、虛擬空間、網站托管維護、企業網站設計、黟縣網站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協力一起成長，共同發展。

1.1 關于質量

在軟件開發里面，質量是個永恒的話題，如下圖所示，這是傳統項目管理中的項目管理三角形：我們可以發現三角形的三條邊成本，時間和范圍所圍繞著的是質量，也就是說 質量被認為是必選的中心，不可以妥協的一個屬性。 而在敏捷的項目管理中，這個三角形經過演進，結果如下圖所示： 我們可以看到 演進后的敏捷三角形里面，除了將范圍變成了更聚焦于客戶價值，還加強了質量的權重以提升終端用戶的體驗。 所以對于質量，多重視都不為過。那么怎么更好地獲得我們所關注的質量呢？尤其是在當前為了適應需求的變化，更靈活地應對不確定的市場的同時，如何保證質量變成了一個更突出的問題。 要知道，對于敏捷開發而言，“快速”不是意味著“糙”，MVP是“簡單”的但是并不意味著它是“簡陋”的。對于質量的承諾，從未妥協和打折扣。我們認為質量不是后來添加的， 質量不是測試出來的，質量是內建的！ 1.2 什么是質量內建 質量內建作用在開發過程中， 要求軟件生命周期之間參與的各個角色都需要實時的對軟件的質量負責。 確保軟件在交付到下一環節前已經有了基礎的質量保證。 其核心目的就是減少因為質量問題導致的返工，避免浪費大量人力成本。

1.3 精益敏捷中的質量內建

質量內建是精益核心原則之一，它有助于我們減少浪費，有助于避免與需求召回、返工及缺陷修復相關的延遲成本。 如下圖所示，我們可以知道：有大約85%的bug發生在coding階段，但是解決他們的代價是最低的。也就是說，如果我們能夠在coding階段就避免掉這些bug，那么我們的產品里面就會減少85%的bug，從而避免了后面解決缺陷帶來的指數增長的成本。也就是 “問題發現的越早，修復的成本越低”。 質量內建也是敏捷的原則之一，敏捷宣言的十二條原則中其中一條就明確的提出要專注在質量上：“堅持不懈的追求技術卓越和良好設計，敏捷能力由此增強”。在Scrum 指南里面“Scrum事件”中關于“Sprint”的說明中明確指出：“在Sprint期間，不能降低質量的目標”。

1.4 SAFe里的內建質量

內建質量是SAFe的四個核心價值觀之一。 內建質量能確保解決方案中的每一個要素和增量都符合質量標準，質量并不是“后來增加的”。內建質量是精益開發流的前提條件，如果沒有質量，組織的運行可能伴隨著大量的沒有經過測試和驗證的工作。這可能會導致過度的返工和更慢的交付速度。毫無疑問， 內建質量對于大型系統而言是至關重要的（事實上內建質量對于任何一個系統都是至關重要的），質量是強制性的。

二、如果沒有質量內建

如果沒有質量內建，那么我們遇到的將會是

• 不斷增長的技術債，直到無力償還。
• 開發新feature與修改舊bug的摩擦。 
• 無法預期的交付，對于客戶響應變慢。 
• 團隊對于質量喪失了信心。

2.1 技術債

技術債，也就是我們在代碼里留下的壞味道。比如一個類的代碼行數太多、編碼格式不符合編碼規范、重復代碼、hardcode、workaroud、架構設計不合理等等。需要說明的是技術債并不總是壞事，或者說技術債并不是零容忍的。比如說在我們一個產品的設計初期，可能還處于跑通商業的階段，那么需要我們非常迅速的上線我們的設想，并得到客戶的驗證，這時候為了快速試錯，我們會不可避免地引入技術債。但是 需要注意的是一旦得到反饋并決定繼續的時候，在接下來的迭代需要及時償還技術債務，以避免技術債的累積和蔓延。 技術債是有利息的。 程序員在寫代碼的時候，如果發現原有的代碼很糟糕，心底里會一邊罵一邊不由自主地拷貝粘貼，如法炮制出同樣風格的爛代碼。于是，在代碼走查和故障復盤的時候，我們聽到最多的辯解是：原來的代碼就是這么寫的…… 質量差的代碼不停地增加技術債務，應該變被動為主動，只有內建質量才能進入良性循環。技術債是躲不掉的，現在不還技術債只會讓我們在將來付出更大的代價去償還。為什么需要第一時間解決軟件里的缺陷？就是因為你不能擴展糟糕的代碼，從而避免技術債的利息。

2.2 新特性和舊缺陷的摩擦

在敏捷開發里面我們承諾在每個Sprint里面完成某一些Story，或者在Kanban的模式中如下圖所示，我們希望價值流動起來。想象一下，如果我們正在做story C或者D的時候，A和B正在測試，然后出現很多很多的bug。我們將會陷入到繼續開發新特性和修改舊缺陷的摩擦里面，bug越多，這個摩擦越大。如果我們不能及時解決前面Story A或者B里面的bug，價值就流動不起來，很可能會阻礙后面的一系列行為，比如測試，發布等。 但是如果及時地解決發現的bug，那么意味著我們正在開發新特性的過程會被不停地打斷，這樣會讓我們的開發節奏混亂，并且效率低下。我們做C和D的時候，不會有“酷”的感受，只會感受到死亡行軍的痛苦。甚至存在更糟糕的情況，等我們已經在開發G和H了，依然有來自A和B（發布階段）和C，D（驗收階段）的bug，同時可能還需要處理G和H中的問題，這個摩擦帶來的痛苦可想而知。只有質量內建，減少每一部分的缺陷，才能讓價值的流動更平滑和順利。價值的流動像水一樣，我們不能讓水逆流（頻繁的回頭修正以前的問題），也盡可能的不讓水的流動停止下來。

2.3 無法預期的交付

迭代的開發讓我們更早的發現問題，解決問題，從而在迭代結束的時候盡可能地按時交付客戶價值增量。在進入迭代之前，我們會采用各種方式對將要開發的新特性進入工作量的預估，從而選擇部分合適的user story作為迭代的承諾（Scrum），這樣我們會對交付有一個預期，即使迭代結束不能完成所有的承諾，那么剩余的用戶故事會delay多久，我們也能有一個相對清晰的預測。 但是糟糕的質量將會摧毀我們的期待和預估。因為你無法預估在你接下來兩周要走的路上有多少大坑，什么時候能夠填滿它們。坐在電腦前面，就像走在迷霧里面，無法看到盡頭在哪兒，也不知道身處何方，只能埋頭填坑，等著天光大亮才能看到路盡頭的旗子。 質量差的代碼導致團隊間的成員不容易互為備份，尤其是新人很難上手，甚至不得不重構。沒有人愿意去動祖傳的代碼就是這個原因，因為代碼的質量太差難以理解，難以擴展，架構不清晰，邏輯混亂，嚴重影響代碼公有制的原則，一旦其他人涉及自己不夠熟悉的部分，就會遇到上圖所示的各種大坑，自然預期的交付時間就無從保證。 軟件開發過程往往是復雜和變化的，所以 批量的修復勢必帶來新的缺陷。

2.4 團隊對質量失去信心

Bug也是累積的。你的bug越多，消除每一個bug也就越不容易。一定程度上是因為bug互相影響，表現出來的失敗可能是很多錯誤共同的結果—這就導致很難找到每一個錯誤。這也是心理上的，當有很多bug的時候，人們自然就缺少激情去找到并解決這些bug—這是一種在《Pragmatic Programmer》一書中被稱為 “破窗效應” 的現象。 破窗效應（英語：Broken windows theory）是犯罪學的一個理論，該理論由詹姆士·威爾遜（James Q. Wilson）及喬治·凱林（George L. Kelling）提出。此理論認為環境中的不良現象如果被放任存在，會誘使人們仿效，甚至變本加厲。一幢有少許破窗的建筑為例，如果那些窗不被修理好，可能將會有破壞者破壞更多的窗戶。 破窗理論能夠很好地解釋人們違反代碼整潔之道，對質量問題視若罔聞的背后原因：是因為原來就是垃圾，別人做了錯誤的行為沒有受到懲罰或者約束，那么我做同樣的事情和行為也是正常的，大家都一樣。但是所謂的沒有關系的錯誤或者瑕疵被放過去，累積起來，等雪崩的時候，沒有一片雪花是無辜的。最后整個團隊為質量買單。 怎么避免破窗效應？ 讓我們的質量能夠保持在一個健康的狀態呢？ 應對方式就是童子軍軍規：“當你離開一個露宿營地的時候，一定要讓它比你來的時候更整潔干凈一點?！蔽覀兊拿看翁峤欢紤撟尨a比前一個版本更干凈一點，哪怕是減少一部分重復代碼，修正一個格式問題。這樣也能讓我們遠離代碼的壞味道，保持我們代碼和架構的整潔。 

三、如何質量內建

3.1 需求分析

這是一個PO和團隊持續對話的過程。 US和AC的澄清，是保障外部質量的一個最重要的手段或者說工具。 AC不是合同，US也不是用來交接的文檔，他們的最重要的作用就是用來溝通。 需求的分析是我們質量內建的開始，輸入的是垃圾，輸出的一定是垃圾。 沒有足夠的需求分析和溝通，質量將無從談起。 在需求澄清時需要注意：以終為始，確保需求輸入質量。 如我們一開始給出的敏捷三角形所示：

• 首先要講解業務目標，也就是價值，換句話說就是要解決用戶或業務什么問題。
• 其次操作及操作流程，為了實現上面目標，系統需要支持哪些用戶操作？這些操作的流程是什么樣的？
• 再次是業務規則，各個操作步驟對應的業務規則是什么樣的？業務規則會轉化成驗收標準。

需求不是方案，而是用戶的價值。 只有我們從價值開始，層層分解，從業務到實現層面充分溝通，才能保證后面交付的質量。

3.2 持續集成

持續集成并不是一個新鮮的概念，而是我們軟件開發工作者生活中的一部分。簡單來說持續集成是一種軟件開發的實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試)來驗證，從而盡快地發現集成錯誤。許多團隊發現這個過程可以大大減少集成的問題，讓團隊能夠更快的開發內聚的軟件。 持續集成是我們質量左移的一個重要實踐。 因為它可以帶給我們非常及時的質量反饋，越頻繁的集成，意味著越早期的發現代碼中的問題。 在持續集成的工程實踐里面，我們需要自動化一切。因為頻繁的集成意味著連續的和可重復性的工作。 自動化對于此類工作的可靠性遠大于我們手工的操作。 作為工程師，代碼就是我們的工具和武器，任何可以被自動化的地方，都應該用自動化的方式來實現，以減少人工失誤帶來的缺陷，并且可以釋放我們的精力和時間，聚焦在更有價值和創造性的任務上面。在DevOps時代，如果想做到提交完代碼后1小時上線發布，沒有持續集成這個武器，質量將無從談起。

3.3 測試先行

測試驅動開發（TDD）： 測試驅動開發是是Extreme Programming (XP)--極限編程的一個重要組成部分。，也是一種設計方法論。TDD的原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什么產品代碼。TDD雖是XP的核心實踐，但不只適用于XP（Extreme Programming），同樣可以適用于其他開發方法和過程。 TDD比較重要的優點在于：

• 一是可以澄清需求，因為是測試先行，所以測試用例是根據需求來設計的，而不是根據代碼來設計的，含糊不清的需求是沒有辦法進行測試用例的編寫，必須予以提前澄清；
• 二是可以避免過度設計，只編寫讓測試用例通過的代碼，多余的代碼一行不寫；
• 三是測試用例就是最好的代碼注釋，避免了沒有注釋/文檔或者文檔/注釋過期的問題；
• 四是跟隨代碼提交的還有一個測試用例集，保障了將來重構和代碼沖突時候的安全性。

這些優點將會是質量的有力保障。 驗收測試驅動開發（ATDD）： 在代碼層次，在編碼之前寫測試腳本就是上面所說的TDD，而在業務層次，在需求分析時就確定需求（如用戶故事）的驗收標準，就是這里所說的驗收測試驅動開發（Acceptance Test Driven Development，ATDD）。 TDD和ATDD的關系如下圖所示。ATDD解決了TDD在實踐中遭遇的一部分實際障礙：比如工期緊張然而單元測試需要的時間又比較多等。從需求的角度去準備驗收標準和測試用例。同樣可以保障從開發的開始就有較高的質量。 行為驅動開發（BDD）： BDD可以看成ATDD的延伸，只是BDD更強調用戶的視角、用戶的行為，為ATDD注入了“Given，When，Then”這樣特定的需求描述語言。和敏捷的user story極為吻合。TDD在寫測試用例時，常常會提出“我們應該先測什么”，然后針對測試的條件來填充代碼，而BDD則試圖換一種方式去思考問題，即問自己“預期的行為是什么？”，可能會寫出結構更好的代碼。說到底，BDD更關注客戶的需求，通過了解客戶的不同行為，對客戶的需求有更深刻的理解，從而借助對需求逐漸深入的理解來驅動軟件開發。 下圖就是一個BDD的典型case： 而BDD和TDD的關系則可以通過下圖清晰的看出來區別所在：

3.4 重構

在Martin Fowler的名著《重構》一書中，他把重構定義為：“在不改變代碼外在行為的前提下對代碼做出修改，以改進代碼內部結構的過程?！笨墒菫槭裁匆薷恼谡＿\行的代碼結構呢？我們應該都知道亨利福特有句話是“如果東西沒有壞，就不要去修理它！” 重構的目的是為了隨時都在清潔你的代碼。我們不想讓臟亂積累。我們想通過最小的努力就能夠對我們的系統進行擴展和修改。敏捷開發的原則之一就是每個迭代交付可用的用戶功能，這樣能夠更快地獲得用戶的反饋，然后根據真實的數據和反饋不斷改進。需求如此，代碼亦如此。代碼除了保持現狀的功能運行，還必須可以足夠健壯以應對隨時帶來的變化，如何讓代碼保持活力？重構是我們的不二選擇。 重構也是消除我們文中提到的技術債的好辦法。 當然，也不是隨隨便便就可以重構的，重構之前，首先檢查自己是否有一套可靠的測試機制。所有更好效果的工程實踐，一定對于實踐人員有著更高的要求！從來沒有捷徑可言。

3.5 Code review

對于Code review的必要性想來不需要再做重新說明，Code review的好處幾乎不存在爭議。 Code review既是質量的一道門禁，也是知識分享的一個很好途徑。 那么如何保證review的質量？ 首先我們要 在團隊的技術能力的不同階段采用不同的review策略。 比如團隊穩定，編碼規范掌握的比較好，使用的語言也是熟悉的語言，那么可能review的重點就會放到業務邏輯方面；如果團隊新成立，還在磨合，可能編碼規范就需要多注意；如果是團隊新換了一門編程語言，那么語法本身可能也會是review的重點。 在公司業務發展的不同階段也需要采用不同的review策略。 比如To B的業務在穩定推進，那么Code review可能需要更加仔細嚴格，保證質量和代碼的可讀性可維護性；但是如果是在互聯網行業，業務發展初期，在快速試錯階段，那么Code review需要Technical Leader去平衡review力度和業務交付的要求。 需要團隊里有開放的文化和心態。 要團隊清楚Code review并不是設置障礙，或者挑毛病，而是一個必不可少的質量保證過程，同時也是一個互相學習的過程。在這里需要對于編程規范有一個共識，避免因為編程習慣發生不必要的異議。 控制每次需要Review的代碼量。 如果一次提交大量的代碼進行review，幫助做Review的人一個是時間上很難一次性拿出這么多的時間，另外一個是也很容易抓不到重點，同時提交代碼的人在commit note中應該寫清楚提交代碼的目的：實現的是什么功能？做的是什么優化？修改的是什么bug？這樣review的人才能有的放矢，清楚代碼改動的上下文。 最后要 讓Code Review變成一種習慣，工作中的一部分， 那么就需要對Review者的時間有所保證，因為每個人在一個迭代中有自己承諾的任務，只有在預留了Review的時間的情況下，review才能作為一個日常任務被執行?？梢园裷eview作為DoD的一部分。

3.6 代碼共有

代碼共有是“共享與進步”精神的體現。它意味著每個人寫的代碼都是屬于團隊的，并且每個人都可以去修改任何代碼。 集體所有權鼓勵每個人為項目的所有部分貢獻新的想法。任何開發人員都可以更改任意一行代碼去增加新的功能、修復缺陷、改進設計或重構。沒有人會成為變化的瓶頸。 在沒有集體代碼所有制的情況下，會造成修改困難，重構困難，甚至會造成重復代碼的出現，增加技術債務，破壞代碼質量。而代碼共有可以增強團隊對于代碼的ownership，全員都成為代碼的負責人，他們互相監督，信息共享。 代碼共有制的環境里，沒有領導，沒有權威，公平公開的環境讓我們回到最本質的工程師文化里面，質量由此而生。

3.7 代碼即文檔

這是在諾基亞用過的一個工程實踐，把代碼作為主要的文檔來源的理由是： 代碼是唯一足夠詳細并且準確的執行該角色的代碼。 尤其是在敏捷開發中，文檔的地位越發不重要（雖然敏捷從沒有說過不需要文檔）。殘缺的文檔，過期的文檔，錯誤的文檔，反而會在開發維護中誤導我們，造成不必要的缺陷和浪費。 包括注釋也是，如果一個程序員修改了代碼，但是沒有修改注釋，就會造成比較大的麻煩，一旦出了問題我們就很難搞清楚是代碼邏輯錯了，還是注釋過期了，尤其是在祖傳代碼里這種情況更常見。所以把代碼當做文檔來用，可以讓我們的視野更清晰， 我們可以有一個唯一的質量標準：就是可工作的代碼。 為了保證代碼即文檔，程序員需要在保證代碼的整潔和可讀性上下功夫，如同重構部分所說，好的工程實踐一定對應著更高的要求。 參考文獻：

• https://www.scaledagileframework.com/safe-core-values/
• http://blog.cutter.com/2009/08/10/beyond-scope-schedule-and-cost-measuring-agile-performance/ 敏捷三角形 Jim Highsmith
• http://agilemanifesto.org/principles.html 敏捷12原則
• https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Chinese-Simplified.pdf Scrum 指南

網站題目：質量內建七步法（轉載）-創新互聯
標題鏈接：http://vcdvsql.cn/article32/cscdpc.html

成都網站建設公司_創新互聯，為您提供全網營銷推廣、電子商務、域名注冊、用戶體驗、網站收錄、企業建站

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯