質(zhì)量?jī)?nèi)建七步法（轉(zhuǎn)載）

發(fā)布時(shí)間：2020-08-04 12:16:16 來源：ITPUB博客閱讀：388 作者：樸所羅門欄目：關(guān)系型數(shù)據(jù)庫(kù)

一、什么是質(zhì)量?jī)?nèi)建

1.1 關(guān)于質(zhì)量

在軟件開發(fā)里面，質(zhì)量是個(gè)永恒的話題，如下圖所示，這是傳統(tǒng)項(xiàng)目管理中的項(xiàng)目管理三角形：我們可以發(fā)現(xiàn)三角形的三條邊成本，時(shí)間和范圍所圍繞著的是質(zhì)量，也就是說質(zhì)量被認(rèn)為是必選的中心，不可以妥協(xié)的一個(gè)屬性。

而在敏捷的項(xiàng)目管理中，這個(gè)三角形經(jīng)過演進(jìn)，結(jié)果如下圖所示：

我們可以看到演進(jìn)后的敏捷三角形里面，除了將范圍變成了更聚焦于客戶價(jià)值，還加強(qiáng)了質(zhì)量的權(quán)重以提升終端用戶的體驗(yàn)。

所以對(duì)于質(zhì)量，多重視都不為過。那么怎么更好地獲得我們所關(guān)注的質(zhì)量呢？尤其是在當(dāng)前為了適應(yīng)需求的變化，更靈活地應(yīng)對(duì)不確定的市場(chǎng)的同時(shí)，如何保證質(zhì)量變成了一個(gè)更突出的問題。

要知道，對(duì)于敏捷開發(fā)而言，“快速”不是意味著“糙”，MVP是“簡(jiǎn)單”的但是并不意味著它是“簡(jiǎn)陋”的。對(duì)于質(zhì)量的承諾，從未妥協(xié)和打折扣。我們認(rèn)為質(zhì)量不是后來添加的，質(zhì)量不是測(cè)試出來的，質(zhì)量是內(nèi)建的！

1.2 什么是質(zhì)量?jī)?nèi)建

質(zhì)量?jī)?nèi)建作用在開發(fā)過程中，要求軟件生命周期之間參與的各個(gè)角色都需要實(shí)時(shí)的對(duì)軟件的質(zhì)量負(fù)責(zé)。確保軟件在交付到下一環(huán)節(jié)前已經(jīng)有了基礎(chǔ)的質(zhì)量保證。其核心目的就是減少因?yàn)橘|(zhì)量問題導(dǎo)致的返工，避免浪費(fèi)大量人力成本。

1.3 精益敏捷中的質(zhì)量?jī)?nèi)建

質(zhì)量?jī)?nèi)建是精益核心原則之一，它有助于我們減少浪費(fèi)，有助于避免與需求召回、返工及缺陷修復(fù)相關(guān)的延遲成本。如下圖所示，我們可以知道：有大約85%的bug發(fā)生在coding階段，但是解決他們的代價(jià)是最低的。也就是說，如果我們能夠在coding階段就避免掉這些bug，那么我們的產(chǎn)品里面就會(huì)減少85%的bug，從而避免了后面解決缺陷帶來的指數(shù)增長(zhǎng)的成本。也就是 “問題發(fā)現(xiàn)的越早，修復(fù)的成本越低”。

質(zhì)量?jī)?nèi)建也是敏捷的原則之一，敏捷宣言的十二條原則中其中一條就明確的提出要專注在質(zhì)量上：“堅(jiān)持不懈的追求技術(shù)卓越和良好設(shè)計(jì)，敏捷能力由此增強(qiáng)”。在Scrum 指南里面“Scrum事件”中關(guān)于“Sprint”的說明中明確指出：“在Sprint期間，不能降低質(zhì)量的目標(biāo)”。

1.4 SAFe里的內(nèi)建質(zhì)量

內(nèi)建質(zhì)量是SAFe的四個(gè)核心價(jià)值觀之一。

內(nèi)建質(zhì)量能確保解決方案中的每一個(gè)要素和增量都符合質(zhì)量標(biāo)準(zhǔn)，質(zhì)量并不是“后來增加的”。內(nèi)建質(zhì)量是精益開發(fā)流的前提條件，如果沒有質(zhì)量，組織的運(yùn)行可能伴隨著大量的沒有經(jīng)過測(cè)試和驗(yàn)證的工作。這可能會(huì)導(dǎo)致過度的返工和更慢的交付速度。毫無(wú)疑問，內(nèi)建質(zhì)量對(duì)于大型系統(tǒng)而言是至關(guān)重要的（事實(shí)上內(nèi)建質(zhì)量對(duì)于任何一個(gè)系統(tǒng)都是至關(guān)重要的），質(zhì)量是強(qiáng)制性的。

二、如果沒有質(zhì)量?jī)?nèi)建

如果沒有質(zhì)量?jī)?nèi)建，那么我們遇到的將會(huì)是

不斷增長(zhǎng)的技術(shù)債，直到無(wú)力償還。
開發(fā)新feature與修改舊bug的摩擦。
無(wú)法預(yù)期的交付，對(duì)于客戶響應(yīng)變慢。
團(tuán)隊(duì)對(duì)于質(zhì)量喪失了信心。

2.1 技術(shù)債

技術(shù)債，也就是我們?cè)诖a里留下的壞味道。比如一個(gè)類的代碼行數(shù)太多、編碼格式不符合編碼規(guī)范、重復(fù)代碼、hardcode、workaroud、架構(gòu)設(shè)計(jì)不合理等等。需要說明的是技術(shù)債并不總是壞事，或者說技術(shù)債并不是零容忍的。比如說在我們一個(gè)產(chǎn)品的設(shè)計(jì)初期，可能還處于跑通商業(yè)的階段，那么需要我們非常迅速的上線我們的設(shè)想，并得到客戶的驗(yàn)證，這時(shí)候?yàn)榱丝焖僭囧e(cuò)，我們會(huì)不可避免地引入技術(shù)債。但是需要注意的是一旦得到反饋并決定繼續(xù)的時(shí)候，在接下來的迭代需要及時(shí)償還技術(shù)債務(wù)，以避免技術(shù)債的累積和蔓延。

技術(shù)債是有利息的。程序員在寫代碼的時(shí)候，如果發(fā)現(xiàn)原有的代碼很糟糕，心底里會(huì)一邊罵一邊不由自主地拷貝粘貼，如法炮制出同樣風(fēng)格的爛代碼。于是，在代碼走查和故障復(fù)盤的時(shí)候，我們聽到最多的辯解是：原來的代碼就是這么寫的……

質(zhì)量差的代碼不停地增加技術(shù)債務(wù)，應(yīng)該變被動(dòng)為主動(dòng)，只有內(nèi)建質(zhì)量才能進(jìn)入良性循環(huán)。技術(shù)債是躲不掉的，現(xiàn)在不還技術(shù)債只會(huì)讓我們?cè)趯砀冻龈蟮拇鷥r(jià)去償還。為什么需要第一時(shí)間解決軟件里的缺陷？就是因?yàn)槟悴荒軘U(kuò)展糟糕的代碼，從而避免技術(shù)債的利息。

2.2 新特性和舊缺陷的摩擦

在敏捷開發(fā)里面我們承諾在每個(gè)Sprint里面完成某一些Story，或者在Kanban的模式中如下圖所示，我們希望價(jià)值流動(dòng)起來。想象一下，如果我們正在做story C或者D的時(shí)候，A和B正在測(cè)試，然后出現(xiàn)很多很多的bug。我們將會(huì)陷入到繼續(xù)開發(fā)新特性和修改舊缺陷的摩擦里面，bug越多，這個(gè)摩擦越大。如果我們不能及時(shí)解決前面Story A或者B里面的bug，價(jià)值就流動(dòng)不起來，很可能會(huì)阻礙后面的一系列行為，比如測(cè)試，發(fā)布等。

但是如果及時(shí)地解決發(fā)現(xiàn)的bug，那么意味著我們正在開發(fā)新特性的過程會(huì)被不停地打斷，這樣會(huì)讓我們的開發(fā)節(jié)奏混亂，并且效率低下。我們做C和D的時(shí)候，不會(huì)有“酷”的感受，只會(huì)感受到死亡行軍的痛苦。甚至存在更糟糕的情況，等我們已經(jīng)在開發(fā)G和H了，依然有來自A和B（發(fā)布階段）和C，D（驗(yàn)收階段）的bug，同時(shí)可能還需要處理G和H中的問題，這個(gè)摩擦帶來的痛苦可想而知。只有質(zhì)量?jī)?nèi)建，減少每一部分的缺陷，才能讓價(jià)值的流動(dòng)更平滑和順利。價(jià)值的流動(dòng)像水一樣，我們不能讓水逆流（頻繁的回頭修正以前的問題），也盡可能的不讓水的流動(dòng)停止下來。

2.3 無(wú)法預(yù)期的交付

迭代的開發(fā)讓我們更早的發(fā)現(xiàn)問題，解決問題，從而在迭代結(jié)束的時(shí)候盡可能地按時(shí)交付客戶價(jià)值增量。在進(jìn)入迭代之前，我們會(huì)采用各種方式對(duì)將要開發(fā)的新特性進(jìn)入工作量的預(yù)估，從而選擇部分合適的user story作為迭代的承諾（Scrum），這樣我們會(huì)對(duì)交付有一個(gè)預(yù)期，即使迭代結(jié)束不能完成所有的承諾，那么剩余的用戶故事會(huì)delay多久，我們也能有一個(gè)相對(duì)清晰的預(yù)測(cè)。

但是糟糕的質(zhì)量將會(huì)摧毀我們的期待和預(yù)估。因?yàn)槟銦o(wú)法預(yù)估在你接下來兩周要走的路上有多少大坑，什么時(shí)候能夠填滿它們。坐在電腦前面，就像走在迷霧里面，無(wú)法看到盡頭在哪兒，也不知道身處何方，只能埋頭填坑，等著天光大亮才能看到路盡頭的旗子。

質(zhì)量差的代碼導(dǎo)致團(tuán)隊(duì)間的成員不容易互為備份，尤其是新人很難上手，甚至不得不重構(gòu)。沒有人愿意去動(dòng)祖?zhèn)鞯拇a就是這個(gè)原因，因?yàn)榇a的質(zhì)量太差難以理解，難以擴(kuò)展，架構(gòu)不清晰，邏輯混亂，嚴(yán)重影響代碼公有制的原則，一旦其他人涉及自己不夠熟悉的部分，就會(huì)遇到上圖所示的各種大坑，自然預(yù)期的交付時(shí)間就無(wú)從保證。

軟件開發(fā)過程往往是復(fù)雜和變化的，所以批量的修復(fù)勢(shì)必帶來新的缺陷。

2.4 團(tuán)隊(duì)對(duì)質(zhì)量失去信心

Bug也是累積的。你的bug越多，消除每一個(gè)bug也就越不容易。一定程度上是因?yàn)閎ug互相影響，表現(xiàn)出來的失敗可能是很多錯(cuò)誤共同的結(jié)果—這就導(dǎo)致很難找到每一個(gè)錯(cuò)誤。這也是心理上的，當(dāng)有很多bug的時(shí)候，人們自然就缺少激情去找到并解決這些bug—這是一種在《Pragmatic Programmer》一書中被稱為 “破窗效應(yīng)” 的現(xiàn)象。

破窗效應(yīng)（英語(yǔ)：Broken windows theory）是犯罪學(xué)的一個(gè)理論，該理論由詹姆士·威爾遜（James Q. Wilson）及喬治·凱林（George L. Kelling）提出。此理論認(rèn)為環(huán)境中的不良現(xiàn)象如果被放任存在，會(huì)誘使人們仿效，甚至變本加厲。一幢有少許破窗的建筑為例，如果那些窗不被修理好，可能將會(huì)有破壞者破壞更多的窗戶。

破窗理論能夠很好地解釋人們違反代碼整潔之道，對(duì)質(zhì)量問題視若罔聞的背后原因：是因?yàn)樵瓉砭褪抢瑒e人做了錯(cuò)誤的行為沒有受到懲罰或者約束，那么我做同樣的事情和行為也是正常的，大家都一樣。但是所謂的沒有關(guān)系的錯(cuò)誤或者瑕疵被放過去，累積起來，等雪崩的時(shí)候，沒有一片雪花是無(wú)辜的。最后整個(gè)團(tuán)隊(duì)為質(zhì)量買單。

怎么避免破窗效應(yīng)？讓我們的質(zhì)量能夠保持在一個(gè)健康的狀態(tài)呢？應(yīng)對(duì)方式就是童子軍軍規(guī)：“當(dāng)你離開一個(gè)露宿營(yíng)地的時(shí)候，一定要讓它比你來的時(shí)候更整潔干凈一點(diǎn)?！蔽覀兊拿看翁峤欢紤?yīng)該讓代碼比前一個(gè)版本更干凈一點(diǎn)，哪怕是減少一部分重復(fù)代碼，修正一個(gè)格式問題。這樣也能讓我們遠(yuǎn)離代碼的壞味道，保持我們代碼和架構(gòu)的整潔。

三、如何質(zhì)量?jī)?nèi)建

3.1 需求分析

這是一個(gè)PO和團(tuán)隊(duì)持續(xù)對(duì)話的過程。 US和AC的澄清，是保障外部質(zhì)量的一個(gè)最重要的手段或者說工具。 AC不是合同，US也不是用來交接的文檔，他們的最重要的作用就是用來溝通。需求的分析是我們質(zhì)量?jī)?nèi)建的開始，輸入的是垃圾，輸出的一定是垃圾。沒有足夠的需求分析和溝通，質(zhì)量將無(wú)從談起。

在需求澄清時(shí)需要注意：以終為始，確保需求輸入質(zhì)量。如我們一開始給出的敏捷三角形所示：

首先要講解業(yè)務(wù)目標(biāo)，也就是價(jià)值，換句話說就是要解決用戶或業(yè)務(wù)什么問題。
其次操作及操作流程，為了實(shí)現(xiàn)上面目標(biāo)，系統(tǒng)需要支持哪些用戶操作？這些操作的流程是什么樣的？
再次是業(yè)務(wù)規(guī)則，各個(gè)操作步驟對(duì)應(yīng)的業(yè)務(wù)規(guī)則是什么樣的？業(yè)務(wù)規(guī)則會(huì)轉(zhuǎn)化成驗(yàn)收標(biāo)準(zhǔn)。

需求不是方案，而是用戶的價(jià)值。只有我們從價(jià)值開始，層層分解，從業(yè)務(wù)到實(shí)現(xiàn)層面充分溝通，才能保證后面交付的質(zhì)量。

3.2 持續(xù)集成

持續(xù)集成并不是一個(gè)新鮮的概念，而是我們軟件開發(fā)工作者生活中的一部分。簡(jiǎn)單來說持續(xù)集成是一種軟件開發(fā)的實(shí)踐，即團(tuán)隊(duì)開發(fā)成員經(jīng)常集成他們的工作，通常每個(gè)成員每天至少集成一次，也就意味著每天可能會(huì)發(fā)生多次集成。每次集成都通過自動(dòng)化的構(gòu)建（包括編譯，發(fā)布，自動(dòng)化測(cè)試)來驗(yàn)證，從而盡快地發(fā)現(xiàn)集成錯(cuò)誤。許多團(tuán)隊(duì)發(fā)現(xiàn)這個(gè)過程可以大大減少集成的問題，讓團(tuán)隊(duì)能夠更快的開發(fā)內(nèi)聚的軟件。

持續(xù)集成是我們質(zhì)量左移的一個(gè)重要實(shí)踐。因?yàn)樗梢詭Ыo我們非常及時(shí)的質(zhì)量反饋，越頻繁的集成，意味著越早期的發(fā)現(xiàn)代碼中的問題。

在持續(xù)集成的工程實(shí)踐里面，我們需要自動(dòng)化一切。因?yàn)轭l繁的集成意味著連續(xù)的和可重復(fù)性的工作。自動(dòng)化對(duì)于此類工作的可靠性遠(yuǎn)大于我們手工的操作。作為工程師，代碼就是我們的工具和武器，任何可以被自動(dòng)化的地方，都應(yīng)該用自動(dòng)化的方式來實(shí)現(xiàn)，以減少人工失誤帶來的缺陷，并且可以釋放我們的精力和時(shí)間，聚焦在更有價(jià)值和創(chuàng)造性的任務(wù)上面。在DevOps時(shí)代，如果想做到提交完代碼后1小時(shí)上線發(fā)布，沒有持續(xù)集成這個(gè)武器，質(zhì)量將無(wú)從談起。

3.3 測(cè)試先行

測(cè)試驅(qū)動(dòng)開發(fā)（TDD）：測(cè)試驅(qū)動(dòng)開發(fā)是是Extreme Programming (XP)--極限編程的一個(gè)重要組成部分。，也是一種設(shè)計(jì)方法論。TDD的原理是在開發(fā)功能代碼之前，先編寫單元測(cè)試用例代碼，測(cè)試代碼確定需要編寫什么產(chǎn)品代碼。TDD雖是XP的核心實(shí)踐，但不只適用于XP（Extreme Programming），同樣可以適用于其他開發(fā)方法和過程。

TDD比較重要的優(yōu)點(diǎn)在于：

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

這些優(yōu)點(diǎn)將會(huì)是質(zhì)量的有力保障。

驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)（ATDD）：在代碼層次，在編碼之前寫測(cè)試腳本就是上面所說的TDD，而在業(yè)務(wù)層次，在需求分析時(shí)就確定需求（如用戶故事）的驗(yàn)收標(biāo)準(zhǔn)，就是這里所說的驗(yàn)收測(cè)試驅(qū)動(dòng)開發(fā)（Acceptance Test Driven Development，ATDD）。

TDD和ATDD的關(guān)系如下圖所示。ATDD解決了TDD在實(shí)踐中遭遇的一部分實(shí)際障礙：比如工期緊張然而單元測(cè)試需要的時(shí)間又比較多等。從需求的角度去準(zhǔn)備驗(yàn)收標(biāo)準(zhǔn)和測(cè)試用例。同樣可以保障從開發(fā)的開始就有較高的質(zhì)量。

行為驅(qū)動(dòng)開發(fā)（BDD）： BDD可以看成ATDD的延伸，只是BDD更強(qiáng)調(diào)用戶的視角、用戶的行為，為ATDD注入了“Given，When，Then”這樣特定的需求描述語(yǔ)言。和敏捷的user story極為吻合。TDD在寫測(cè)試用例時(shí)，常常會(huì)提出“我們應(yīng)該先測(cè)什么”，然后針對(duì)測(cè)試的條件來填充代碼，而BDD則試圖換一種方式去思考問題，即問自己“預(yù)期的行為是什么？”，可能會(huì)寫出結(jié)構(gòu)更好的代碼。說到底，BDD更關(guān)注客戶的需求，通過了解客戶的不同行為，對(duì)客戶的需求有更深刻的理解，從而借助對(duì)需求逐漸深入的理解來驅(qū)動(dòng)軟件開發(fā)。

下圖就是一個(gè)BDD的典型case：

而BDD和TDD的關(guān)系則可以通過下圖清晰的看出來區(qū)別所在：

3.4 重構(gòu)

在Martin Fowler的名著《重構(gòu)》一書中，他把重構(gòu)定義為：“在不改變代碼外在行為的前提下對(duì)代碼做出修改，以改進(jìn)代碼內(nèi)部結(jié)構(gòu)的過程?！笨墒菫槭裁匆薷恼谡＿\(yùn)行的代碼結(jié)構(gòu)呢？我們應(yīng)該都知道亨利福特有句話是“如果東西沒有壞，就不要去修理它！”

重構(gòu)的目的是為了隨時(shí)都在清潔你的代碼。我們不想讓臟亂積累。我們想通過最小的努力就能夠?qū)ξ覀兊南到y(tǒng)進(jìn)行擴(kuò)展和修改。敏捷開發(fā)的原則之一就是每個(gè)迭代交付可用的用戶功能，這樣能夠更快地獲得用戶的反饋，然后根據(jù)真實(shí)的數(shù)據(jù)和反饋不斷改進(jìn)。需求如此，代碼亦如此。代碼除了保持現(xiàn)狀的功能運(yùn)行，還必須可以足夠健壯以應(yīng)對(duì)隨時(shí)帶來的變化，如何讓代碼保持活力？重構(gòu)是我們的不二選擇。重構(gòu)也是消除我們文中提到的技術(shù)債的好辦法。

當(dāng)然，也不是隨隨便便就可以重構(gòu)的，重構(gòu)之前，首先檢查自己是否有一套可靠的測(cè)試機(jī)制。所有更好效果的工程實(shí)踐，一定對(duì)于實(shí)踐人員有著更高的要求！從來沒有捷徑可言。

3.5 Code review

對(duì)于Code review的必要性想來不需要再做重新說明，Code review的好處幾乎不存在爭(zhēng)議。 Code review既是質(zhì)量的一道門禁，也是知識(shí)分享的一個(gè)很好途徑。那么如何保證review的質(zhì)量？

首先我們要在團(tuán)隊(duì)的技術(shù)能力的不同階段采用不同的review策略。比如團(tuán)隊(duì)穩(wěn)定，編碼規(guī)范掌握的比較好，使用的語(yǔ)言也是熟悉的語(yǔ)言，那么可能review的重點(diǎn)就會(huì)放到業(yè)務(wù)邏輯方面；如果團(tuán)隊(duì)新成立，還在磨合，可能編碼規(guī)范就需要多注意；如果是團(tuán)隊(duì)新?lián)Q了一門編程語(yǔ)言，那么語(yǔ)法本身可能也會(huì)是review的重點(diǎn)。

在公司業(yè)務(wù)發(fā)展的不同階段也需要采用不同的review策略。比如To B的業(yè)務(wù)在穩(wěn)定推進(jìn)，那么Code review可能需要更加仔細(xì)嚴(yán)格，保證質(zhì)量和代碼的可讀性可維護(hù)性；但是如果是在互聯(lián)網(wǎng)行業(yè)，業(yè)務(wù)發(fā)展初期，在快速試錯(cuò)階段，那么Code review需要Technical Leader去平衡review力度和業(yè)務(wù)交付的要求。

需要團(tuán)隊(duì)里有開放的文化和心態(tài)。要團(tuán)隊(duì)清楚Code review并不是設(shè)置障礙，或者挑毛病，而是一個(gè)必不可少的質(zhì)量保證過程，同時(shí)也是一個(gè)互相學(xué)習(xí)的過程。在這里需要對(duì)于編程規(guī)范有一個(gè)共識(shí)，避免因?yàn)榫幊塘?xí)慣發(fā)生不必要的異議。

控制每次需要Review的代碼量。如果一次提交大量的代碼進(jìn)行review，幫助做Review的人一個(gè)是時(shí)間上很難一次性拿出這么多的時(shí)間，另外一個(gè)是也很容易抓不到重點(diǎn)，同時(shí)提交代碼的人在commit note中應(yīng)該寫清楚提交代碼的目的：實(shí)現(xiàn)的是什么功能？做的是什么優(yōu)化？修改的是什么bug？這樣review的人才能有的放矢，清楚代碼改動(dòng)的上下文。

最后要讓Code Review變成一種習(xí)慣，工作中的一部分，那么就需要對(duì)Review者的時(shí)間有所保證，因?yàn)槊總€(gè)人在一個(gè)迭代中有自己承諾的任務(wù)，只有在預(yù)留了Review的時(shí)間的情況下，review才能作為一個(gè)日常任務(wù)被執(zhí)行?？梢园裷eview作為DoD的一部分。

3.6 代碼共有

代碼共有是“共享與進(jìn)步”精神的體現(xiàn)。它意味著每個(gè)人寫的代碼都是屬于團(tuán)隊(duì)的，并且每個(gè)人都可以去修改任何代碼。集體所有權(quán)鼓勵(lì)每個(gè)人為項(xiàng)目的所有部分貢獻(xiàn)新的想法。任何開發(fā)人員都可以更改任意一行代碼去增加新的功能、修復(fù)缺陷、改進(jìn)設(shè)計(jì)或重構(gòu)。沒有人會(huì)成為變化的瓶頸。

在沒有集體代碼所有制的情況下，會(huì)造成修改困難，重構(gòu)困難，甚至?xí)斐芍貜?fù)代碼的出現(xiàn)，增加技術(shù)債務(wù)，破壞代碼質(zhì)量。而代碼共有可以增強(qiáng)團(tuán)隊(duì)對(duì)于代碼的ownership，全員都成為代碼的負(fù)責(zé)人，他們互相監(jiān)督，信息共享。代碼共有制的環(huán)境里，沒有領(lǐng)導(dǎo)，沒有權(quán)威，公平公開的環(huán)境讓我們回到最本質(zhì)的工程師文化里面，質(zhì)量由此而生。

3.7 代碼即文檔

這是在諾基亞用過的一個(gè)工程實(shí)踐，把代碼作為主要的文檔來源的理由是：代碼是唯一足夠詳細(xì)并且準(zhǔn)確的執(zhí)行該角色的代碼。尤其是在敏捷開發(fā)中，文檔的地位越發(fā)不重要（雖然敏捷從沒有說過不需要文檔）。殘缺的文檔，過期的文檔，錯(cuò)誤的文檔，反而會(huì)在開發(fā)維護(hù)中誤導(dǎo)我們，造成不必要的缺陷和浪費(fèi)。

包括注釋也是，如果一個(gè)程序員修改了代碼，但是沒有修改注釋，就會(huì)造成比較大的麻煩，一旦出了問題我們就很難搞清楚是代碼邏輯錯(cuò)了，還是注釋過期了，尤其是在祖?zhèn)鞔a里這種情況更常見。所以把代碼當(dāng)做文檔來用，可以讓我們的視野更清晰，我們可以有一個(gè)唯一的質(zhì)量標(biāo)準(zhǔn)：就是可工作的代碼。

為了保證代碼即文檔，程序員需要在保證代碼的整潔和可讀性上下功夫，如同重構(gòu)部分所說，好的工程實(shí)踐一定對(duì)應(yīng)著更高的要求。

參考文獻(xiàn)：

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 指南

向AI問一下細(xì)節(jié)