譯者 | 李睿

審校 | 孫淑娟

如今，很多開(kāi)發(fā)人員將太多的注意力集中在敏捷慣例上，而敏捷宣言中提到的關(guān)鍵方面沒(méi)有根據(jù)它的重要性來(lái)考慮。  

敏捷實(shí)踐已經(jīng)在全球范圍內(nèi)采用。而許多企業(yè)都以敏捷為榮，并且以不同的方式實(shí)現(xiàn)它。這很好，但并沒(méi)有一個(gè)單一的方法來(lái)實(shí)現(xiàn)它，需要根據(jù)每個(gè)場(chǎng)景進(jìn)行調(diào)整。

高級(jí)軟件工程師Jorge Fernández Rodríguez表示，過(guò)于關(guān)注敏捷的某些方面容易遺忘了另外一個(gè)關(guān)鍵方面。這不是什么新鮮事，但如果不考慮這一方面，發(fā)布軟件的新版本可能是一個(gè)永無(wú)止境的故事。這就是要在本文中解決的問(wèn)題。  

但在深入研究之前，先回顧一下軟件開(kāi)發(fā)的演變，先從瀑布和敏捷方法的誕生開(kāi)始。

1.很久以前就采用瀑布方法  

許多在過(guò)去10年開(kāi)始職業(yè)生涯的開(kāi)發(fā)人員可能在敏捷環(huán)境中工作過(guò)。然而，敏捷并不總是存在。而在本世紀(jì)初，瀑布就是一種常見(jiàn)的做法。  

在瀑布方法中，應(yīng)用程序通常是作為一個(gè)整體進(jìn)行規(guī)劃的，客戶可能需要幾個(gè)月才能看到一些可用的軟件。

開(kāi)發(fā)計(jì)劃是作為一個(gè)項(xiàng)目進(jìn)行的，而有了開(kāi)頭，在理論上也有一個(gè)結(jié)束（有時(shí)可能是公司倒閉）。該項(xiàng)目分為以下幾個(gè)階段：

• 需求收集
• 系統(tǒng)設(shè)計(jì)
• 任務(wù)計(jì)劃
• 開(kāi)發(fā)
• 測(cè)試和交付

每個(gè)階段通常由不同的人員進(jìn)行?？蛻粼陂_(kāi)始和結(jié)束時(shí)都參與了合同的簽署。如果項(xiàng)目成功完成，應(yīng)用程序就會(huì)部署到生產(chǎn)環(huán)境中，并且通常會(huì)移交給另一個(gè)團(tuán)隊(duì)，該團(tuán)隊(duì)將負(fù)責(zé)保持正常運(yùn)行。  

眾所周知，這些做法造成了很多問(wèn)題。其中一些是：  

收集所有需求、預(yù)先設(shè)計(jì)系統(tǒng)和規(guī)劃任務(wù)幾乎是不可能的，并且需要數(shù)周時(shí)間。  

每個(gè)階段的交接都會(huì)導(dǎo)致溝通不暢。  

交付產(chǎn)品需要很長(zhǎng)時(shí)間，并且實(shí)施很多次，遠(yuǎn)遠(yuǎn)超出預(yù)期。

在預(yù)算和范圍內(nèi)結(jié)束也很困難。  

階段之間沒(méi)有反饋循環(huán)。很多時(shí)候，只有最后才有反饋。如果反饋是否定的，那么整個(gè)投資都失敗了。

2.敏捷解決關(guān)鍵問(wèn)題  

Rodríguez表示，在他當(dāng)初開(kāi)始其職業(yè)生涯時(shí)就聽(tīng)說(shuō)一個(gè)新概念：敏捷。當(dāng)時(shí)并不知道這是怎么回事。那時(shí)他專注于提高開(kāi)發(fā)技能，并不太關(guān)心軟件開(kāi)發(fā)方法。  

敏捷似乎解決了瀑布方法難以解決的許多問(wèn)題，并迅速被采用。但許多人將其視為一種教條，認(rèn)為采取一些慣例可以解決他們所有的問(wèn)題。行業(yè)專家聽(tīng)到的最多的是一些流行術(shù)語(yǔ)，如：“Scrum”、“極限編程（XP）”、“Sprint”、“Retro”、“ Grooming”，以及其他一些術(shù)語(yǔ)（后來(lái)發(fā)現(xiàn)它們與精益更相關(guān)），例如“看板”、“ 進(jìn)行中的工作（WIP）”。

大多數(shù)這些流行術(shù)語(yǔ)本身并沒(méi)有告訴很多。在工作一段時(shí)間后，他開(kāi)始對(duì)了解為什么很多企業(yè)都采用這些做法感興趣，所以開(kāi)始深入研究這個(gè)話題。  

他在工作中理解了其中一些術(shù)語(yǔ)的含義，并且看到了很多討論：開(kāi)發(fā)團(tuán)隊(duì)?wèi)?yīng)該做Scrum、看板、極限編程（XP）還是其他？團(tuán)隊(duì)每個(gè)Scrum應(yīng)該在每個(gè)慣例上花費(fèi)多長(zhǎng)時(shí)間？應(yīng)該談?wù)撌裁?？等等? 

他了解一些膚淺的信息，并且遺漏了一些信息。也許這是他的研究技能?；仡欉^(guò)去，發(fā)現(xiàn)不僅如此。  

當(dāng)閱讀敏捷宣言時(shí)，他了解其中一件事是：“個(gè)人和交互優(yōu)于流程和工具”。  

在他工作的過(guò)程中，其印象是過(guò)于關(guān)注過(guò)程和慣例。這是第一個(gè)跡象表明，無(wú)論是谷歌的算法還是軟件行業(yè)的某些部分都在關(guān)注不太重要的主題。  

同樣值得澄清的是，有些人將這些原則解讀為“第二部分并不重要”。然而，正如他多次聽(tīng)到的那樣，這些原則應(yīng)該被理解為：“盡管第二部分很重要，但第一部分更重要。”  

專注于敏捷的要點(diǎn)，與瀑布的主要區(qū)別之一是以增量的方式組織開(kāi)發(fā)：應(yīng)用程序?qū)⒈粍澐譃榫哂袃?yōu)先級(jí)的小塊。每個(gè)塊都是在一個(gè)Sprint內(nèi)開(kāi)發(fā)的（通常是1周或2周）。在每個(gè)Sprint之后，應(yīng)該為客戶提供應(yīng)用程序的功能版本。客戶（或者在某些情況下是業(yè)務(wù)代表）積極參與了該過(guò)程，因此可以盡早獲得反饋?？梢钥吹竭@些想法是如何解決瀑布方法出現(xiàn)的一些問(wèn)題，它通過(guò)快速交付和通過(guò)早期獲得反饋來(lái)快速失敗。  

而在敏捷宣言中，其中一個(gè)價(jià)值觀是“歡迎不斷變化的需求，即使是在開(kāi)發(fā)的后期”。一開(kāi)始，Rodríguez無(wú)法理解這句話的含義，他不確定這是否是一個(gè)好主意。然而，在思考它并在敏捷環(huán)境中獲得不同的經(jīng)驗(yàn)之后，他認(rèn)為它是最重要的部分之一。重要的是要考慮到變化可能涉及領(lǐng)域的新特征和新概念，但也可能涉及現(xiàn)有行為和市場(chǎng)的變化等。  

因此，不僅在敏捷中快速行動(dòng)很重要（盡早交付客戶需要的價(jià)值，通過(guò)早期反饋快速失?。?，而且對(duì)環(huán)境變化快速做出反應(yīng)也很重要。它們不是唯一重要的方面，但以下將重點(diǎn)關(guān)注這兩個(gè)方面。  

因此繼續(xù)這種軟件開(kāi)發(fā)實(shí)踐的演變，提到一些主要有助于快速發(fā)展的改進(jìn)。  

3.快速行動(dòng)：軟件編碼和交付實(shí)踐的演變  

當(dāng)時(shí)的工具并不容易采用敏捷實(shí)踐，例如頻繁部署。在過(guò)去的25年中出現(xiàn)了一些實(shí)踐和技術(shù)，以幫助開(kāi)發(fā)團(tuán)隊(duì)更快地發(fā)布軟件。其中一些是敏捷的結(jié)果，而另一些則是獨(dú)立出現(xiàn)的。  

Rodríguez簡(jiǎn)要提及其中的一些技術(shù)及其好處，而沒(méi)有詳細(xì)說(shuō)明。他認(rèn)為大多數(shù)都是廣為人知的技術(shù)，但如果對(duì)人們來(lái)說(shuō)是新技術(shù)，那么網(wǎng)上有很多資源可以找到更多信息：  

• 測(cè)試自動(dòng)化通過(guò)防止大量錯(cuò)誤和減少調(diào)試需求為開(kāi)發(fā)人員提供信心。
• 版本控制幫助開(kāi)發(fā)人員將更改追溯到添加時(shí)，輕松恢復(fù)更改，以更輕松的方式解決沖突，并且它是許多其他改進(jìn)的基礎(chǔ)。
• 功能分支或與分支并行工作。具有并行性總是好的，這在很多情況下也帶來(lái)了一個(gè)新問(wèn)題：當(dāng)進(jìn)行大量更改或長(zhǎng)時(shí)間保持分支打開(kāi)時(shí)，開(kāi)發(fā)人員需要花費(fèi)大量時(shí)間來(lái)集成這些更改。
• 功能標(biāo)志。如果團(tuán)隊(duì)需要長(zhǎng)時(shí)間并行處理多個(gè)計(jì)劃，但希望避免長(zhǎng)期存在的分支經(jīng)常出現(xiàn)的沖突，這是一個(gè)選項(xiàng)。
• 持續(xù)集成（CI）/持續(xù)交付（CD）。通過(guò)集成更改、運(yùn)行測(cè)試和經(jīng)常部署，交付到生產(chǎn)的巨大障礙正在消失。
• 代碼審查/配對(duì)編程。多年前，每個(gè)開(kāi)發(fā)人員都在自己開(kāi)發(fā)，甚至是關(guān)鍵代碼。審查代碼不僅可以幫助開(kāi)發(fā)人員更好地編碼，還可以分享知識(shí)、學(xué)習(xí)并減少遺漏重要內(nèi)容的可能性。Rodríguez認(rèn)為這并不總是必要的，但與對(duì)長(zhǎng)期存在的分支進(jìn)行大型拉取請(qǐng)求相比，它可以提供優(yōu)勢(shì)，因?yàn)榉答伿窃诰幋a時(shí)提供的，避免了重新編寫代碼。
• 開(kāi)發(fā)人員構(gòu)建并運(yùn)行它。開(kāi)發(fā)團(tuán)隊(duì)也開(kāi)始負(fù)責(zé)維護(hù)應(yīng)用程序。這很有意義，因?yàn)殚_(kāi)發(fā)應(yīng)用程序的團(tuán)隊(duì)比其他任何人都更能理解它，并且它帶來(lái)了幾個(gè)好處：
• 發(fā)現(xiàn)問(wèn)題的時(shí)間更少。
• 解決問(wèn)題時(shí)犯的錯(cuò)誤更少。
• 在生產(chǎn)環(huán)境中處理問(wèn)題會(huì)帶來(lái)寶貴的經(jīng)驗(yàn)。這些有利于進(jìn)一步的發(fā)展。
• 由于不再需要交接會(huì)議，因此節(jié)省了大量時(shí)間。
• 如果團(tuán)隊(duì)進(jìn)行隨叫隨到的工作，軟件的質(zhì)量可以進(jìn)一步受益，因?yàn)槊總€(gè)人都會(huì)盡最大努力避免在不適當(dāng)?shù)臅r(shí)間聯(lián)系。
• 團(tuán)隊(duì)結(jié)構(gòu)的變化：組建小型、獨(dú)立、跨職能的產(chǎn)品團(tuán)隊(duì)來(lái)打破IT孤島。
• 消除開(kāi)發(fā)階段之間的交接可加快交付速度，并避免溝通不暢。
• 讓團(tuán)隊(duì)更接近領(lǐng)域?qū)＜覍?duì)解決方案的質(zhì)量產(chǎn)生積極影響，并通過(guò)減少場(chǎng)景切換等方式提高關(guān)注度。
• 它還促進(jìn)了系統(tǒng)的模塊化（康威定律）。
• 需要注意的是，跨職能人員并不是指全棧人員，Rodríguez認(rèn)為這非常困難，甚至?xí)m得其反。“T型開(kāi)發(fā)者”的想法可能更有趣。
• DevOps、容器、服務(wù)網(wǎng)格、分布式架構(gòu)和云平臺(tái)?；A(chǔ)設(shè)施變?yōu)樽灾?wù)（團(tuán)隊(duì)無(wú)需等待服務(wù)器分配即可部署）。它還變得不可變、易于替換、提高安全性等等。
• 自動(dòng)依賴項(xiàng)更新。
• 更好的監(jiān)控和事件管理，例如SLI/SLO、DORA指標(biāo)和其他，以關(guān)閉反饋循環(huán)并做出更明智的決策。

除了這些實(shí)踐之外，新工具、IDE改進(jìn)、框架、庫(kù)和語(yǔ)言演變使開(kāi)發(fā)人員能夠加快軟件開(kāi)發(fā)。  

如果企業(yè)采用上述大多數(shù)做法，這可能意味著軟件可以比以前更快地交付。而且這些更改不僅更快而且更安全，因?yàn)樵S多任務(wù)都被自動(dòng)化或委派了。  

有些人可能會(huì)認(rèn)為軟件交付就像閃電一樣快，對(duì)嗎？

根據(jù)Rodríguez的經(jīng)驗(yàn)，即使遵循了這些做法，也可能需要很長(zhǎng)時(shí)間才能實(shí)現(xiàn)價(jià)值。以下是一些案例：  

示例1：  

Rodríguez表示，他花費(fèi)三天時(shí)間來(lái)理解必須修改的代碼。這是他第一次接觸到那個(gè)代碼。值得慶幸的是，他正在與非常了解該應(yīng)用程序的人一起工作。通過(guò)相應(yīng)的測(cè)試來(lái)實(shí)施主要更改花費(fèi)了開(kāi)發(fā)團(tuán)隊(duì)兩周時(shí)間。最后，他們花費(fèi)大約16周的時(shí)間在整個(gè)代碼中尋找錯(cuò)誤并實(shí)施修復(fù)。  

正如人們所看到的，在第三點(diǎn)上花了很多時(shí)間。在這16周中，大約70%的人在尋找錯(cuò)誤，大約20%的人理解開(kāi)發(fā)人員發(fā)現(xiàn)的邏輯并考慮如何使其適應(yīng)新行為，3%的人用于編寫自動(dòng)化測(cè)試，1%的人自己實(shí)施更改。  

以下是為什么花費(fèi)這么長(zhǎng)時(shí)間的一些原因：  

• 服務(wù)做的事情太多了。
• 代碼耦合非常緊密，因?yàn)榇a的不同部分發(fā)生了很多問(wèn)題。
• 與此同時(shí)，代碼的內(nèi)聚性不是很強(qiáng)。處理同樣問(wèn)題的邏輯被廣泛傳播。

示例2：  

Rodríguez表示，他們的研究團(tuán)隊(duì)花費(fèi)三天時(shí)間了解需要改變什么，并花費(fèi)一天的時(shí)間來(lái)實(shí)施這些更改，并花費(fèi)七天的時(shí)間讓測(cè)試再次通過(guò)。  

在這種情況下，開(kāi)發(fā)人員正在修復(fù)代碼以前的錯(cuò)誤。其中一些甚至沒(méi)有完全修復(fù)。很明顯，一些開(kāi)發(fā)人員對(duì)這些技術(shù)還不夠熟悉。幸運(yùn)的是，問(wèn)題并不嚴(yán)重，客戶也沒(méi)有注意到。糟糕的是，它們?cè)趹?yīng)用新更改時(shí)突然出現(xiàn)，使得測(cè)試幾乎不可能，因此必須在完成任務(wù)之前修復(fù)它們。

另一個(gè)問(wèn)題是堆棧不是最新的，開(kāi)發(fā)團(tuán)隊(duì)想要實(shí)施的許多解決方案都行不通。在這些情況下，可能看到大量時(shí)間被浪費(fèi)在調(diào)試和理解需要調(diào)整的代碼上。  

除此之外，還有一些可以永遠(yuǎn)運(yùn)行的構(gòu)建通道（同一應(yīng)用程序中的大量代碼、緩慢或不穩(wěn)定的測(cè)試等）。  

4.而被遺忘的部分是...  

采用了許多圍繞軟件開(kāi)發(fā)的實(shí)踐可以使其更快：敏捷、CI/CD、DevOps、團(tuán)隊(duì)結(jié)構(gòu)等。但是，在更改現(xiàn)有代碼的同時(shí)保持現(xiàn)有代碼的工作可能是一場(chǎng)噩夢(mèng)。大量時(shí)間仍然浪費(fèi)在理解代碼和四處尋找錯(cuò)誤上，盡管已經(jīng)存在了很多有用的實(shí)踐。與此同時(shí)，圍繞Scrum、看板、獨(dú)立團(tuán)隊(duì)等有很多爭(zhēng)論，而且，正如以上提到的，敏捷宣言并沒(méi)有過(guò)多地關(guān)注特定的流程或儀式；它只是給出了一些一般性的想法。所以代碼（測(cè)試）質(zhì)量（尤其是靈活性）是敏捷中被忽略或遺忘的最重要部分之一。  

代碼質(zhì)量并不是敏捷的獨(dú)有問(wèn)題，但它在這里尤其重要，甚至比傳統(tǒng)項(xiàng)目更重要。還有一種誤解是，在敏捷方法中，不需要在軟件架構(gòu)和設(shè)計(jì)上進(jìn)行任何計(jì)劃或投入精力，但實(shí)際上恰恰相反。代碼經(jīng)常被擴(kuò)展和調(diào)整，因此使系統(tǒng)易于更改至關(guān)重要，否則它們將使未來(lái)的開(kāi)發(fā)變得非常緩慢。因此，對(duì)于敏捷開(kāi)發(fā)，這句話的下一個(gè)迭代可能是：系統(tǒng)靈活性是敏捷中被忽略或遺忘的最重要部分之一。  

這并不是什么新鮮事。正如在以上內(nèi)容看到的，敏捷宣言中提到了這一點(diǎn)，但持續(xù)關(guān)注卓越的技術(shù)和良好的設(shè)計(jì)可以提高敏捷性。  

敏捷流程促進(jìn)可持續(xù)發(fā)展。贊助商、開(kāi)發(fā)人員和用戶應(yīng)該能夠無(wú)限期地保持恒定的速度。如果代碼混亂、難以理解和變化，團(tuán)隊(duì)如何保持恒定的步伐？  

需要記住的是，質(zhì)量并不意味著復(fù)雜性。簡(jiǎn)單也很重要：而簡(jiǎn)單就是最大化未完成工作量的藝術(shù)。  

架構(gòu)通常與剛性和提前規(guī)劃有關(guān)，因?yàn)榻?jīng)常想到難以改變的架構(gòu)。從這個(gè)角度來(lái)看，在敏捷環(huán)境中投入時(shí)間在架構(gòu)或設(shè)計(jì)上是沒(méi)有意義的，因?yàn)槭虑榻?jīng)常發(fā)生變化。  

但是在軟件世界中，可以選擇讓選項(xiàng)保持開(kāi)放并使更改更容易的架構(gòu)。事實(shí)上，敏捷促進(jìn)了短期思維。眾所周知，預(yù)測(cè)并不容易，開(kāi)發(fā)人員最終付出了代價(jià)，甚至不知道兩天后客戶會(huì)需要什么。  

對(duì)于沒(méi)有采用敏捷方法的開(kāi)發(fā)人員來(lái)說(shuō)，需要知道的是，高績(jī)效員工不必以速度換取穩(wěn)定性，反之亦然，因?yàn)橥ㄟ^(guò)提高質(zhì)量，可以實(shí)現(xiàn)兩全其美。

5.開(kāi)發(fā)緩慢的后果  

隨著開(kāi)發(fā)人員添加更多代碼，開(kāi)發(fā)速度變得更慢，這不僅是開(kāi)發(fā)人員的問(wèn)題。每個(gè)利益相關(guān)者都用自己的方式說(shuō)話，并且含義略有不同：  

• 對(duì)于用戶體驗(yàn)（UX）實(shí)驗(yàn)愛(ài)好者：實(shí)驗(yàn)可能需要數(shù)周而不是數(shù)天。
• 對(duì)于產(chǎn)品愛(ài)好者：及時(shí)響應(yīng)市場(chǎng)/滿足客戶需求……會(huì)發(fā)生嗎？
• 對(duì)于管理者：目標(biāo)缺失，工作積壓。
• 對(duì)于DevOps研究與評(píng)估( DORA )指標(biāo)愛(ài)好者：部署頻率(DF)降低，變更的平均提前期(MLT)增加，變更失敗率(CFR)增加。
• 對(duì)于企業(yè)：即使開(kāi)發(fā)人員有很好的想法，如果不能輕易地轉(zhuǎn)化為軟件，企業(yè)就會(huì)陷入困境。代碼將是一種責(zé)任而不是一種資產(chǎn)，與此同時(shí)，競(jìng)爭(zhēng)對(duì)手可能會(huì)利用。
• 對(duì)于開(kāi)發(fā)人員：不得不處理糟糕的代碼可能會(huì)導(dǎo)致開(kāi)發(fā)人員精疲力盡。

所以很明顯開(kāi)發(fā)速度會(huì)變慢，但幸運(yùn)的是，如果投資于靈活的代碼，可以節(jié)省一些時(shí)間。  

然而，要讓一些人相信這一點(diǎn)并不容易。還有一個(gè)問(wèn)題：僵化代碼的效果不是立竿見(jiàn)影的。從長(zhǎng)遠(yuǎn)來(lái)看，它們是可見(jiàn)的。在短期內(nèi)投資開(kāi)發(fā)靈活的代碼可能看起來(lái)更慢。那么，誰(shuí)愿意投資于沒(méi)有立竿見(jiàn)影的效果呢？很多人的想法大多是短期的，需要更多地了解代碼質(zhì)量將如何影響未來(lái)的發(fā)展。  

6.將剛性系統(tǒng)的影響與業(yè)務(wù)聯(lián)系起來(lái)  

嚴(yán)格的代碼對(duì)開(kāi)發(fā)某個(gè)產(chǎn)品需要多長(zhǎng)時(shí)間的影響并不容易被發(fā)現(xiàn)。因此，對(duì)業(yè)務(wù)的影響也不明顯。如果兩者之間沒(méi)有聯(lián)系，就很難讓人們相信擁有靈活系統(tǒng)的重要性。這是一個(gè)非常復(fù)雜的話題，但需要填補(bǔ)空白。  

DORA指標(biāo)至少部分解決了這個(gè)問(wèn)題。其代碼不是同質(zhì)的，代碼路由很慢，問(wèn)題可能被發(fā)現(xiàn)得太晚。  

軟件架構(gòu)師Glenn Engstrand在他的演講中介紹的技術(shù)能力計(jì)劃（TCP）在微服務(wù)架構(gòu)中管理技術(shù)債務(wù)可能是一個(gè)起點(diǎn)。  

Rodríguez表示，他并沒(méi)有一個(gè)理想的解決方案，夢(mèng)想有一個(gè)在每次提交后更新的分?jǐn)?shù)，它可以用作估計(jì)未來(lái)任務(wù)需要多長(zhǎng)時(shí)間才能完成的乘數(shù)。  

然而，想以一些關(guān)于如何提高代碼靈活性的簡(jiǎn)單想法作為結(jié)束。

7.提高代碼靈活性的思路  

網(wǎng)上有很多關(guān)于代碼質(zhì)量的書(shū)籍和資源，因此就不再贅述：  

• 代碼需要易于理解。通過(guò)閱讀方法名稱，應(yīng)該清楚它的作用。例如，理解一種方法不應(yīng)超過(guò)10秒。
• 代碼需要模塊化。模塊，松散耦合，封裝。這適用于每個(gè)級(jí)別：系統(tǒng)、庫(kù)、包、類和方法。
• 代碼需要有凝聚力。每個(gè)部分只需要做一件事，并且做這件事的所有代碼都需要緊密結(jié)合在一起。
• 將業(yè)務(wù)邏輯與控制器、偵聽(tīng)器、過(guò)濾器等框架結(jié)構(gòu)分開(kāi)尤為重要。
• 代碼需要簡(jiǎn)單（不要過(guò)度設(shè)計(jì)，不要強(qiáng)行引入設(shè)計(jì)模式）。
• 針對(duì)當(dāng)前需求進(jìn)行開(kāi)發(fā)。當(dāng)開(kāi)發(fā)人員想：“如果我們需要X功能怎么辦？”，采用YAGNI。

對(duì)于測(cè)試，需要記住它們提供安全性，但它們抵制更改，并且可能會(huì)比生產(chǎn)代碼本身占用更多的時(shí)間，因此：

• 他們需要帶來(lái)足夠的價(jià)值。進(jìn)行測(cè)試驅(qū)動(dòng)開(kāi)發(fā)（TDD）是一種可以幫助企業(yè)實(shí)現(xiàn)它的實(shí)踐。
• 如果他們測(cè)試實(shí)施細(xì)節(jié)，他們將很難改變。

很多單元測(cè)試來(lái)驗(yàn)證提供內(nèi)部結(jié)果的代碼片段。這些代碼是開(kāi)發(fā)人員組織代碼的結(jié)果。如果邏輯需要以不同的方式組織和移動(dòng)，許多測(cè)試就會(huì)中斷。發(fā)生這種情況時(shí)，測(cè)試不再保護(hù)并且?guī)缀鹾翢o(wú)用處。它還給團(tuán)隊(duì)額外的工作。因此，重要的是要考慮什么是實(shí)際的單位。在不得不多次重組代碼之后，Rodríguez表示一直在思考這個(gè)問(wèn)題，開(kāi)始認(rèn)為單元的概念可能不僅僅是方法或類，而是可能需要從特性的角度來(lái)考慮。這可能聽(tīng)起來(lái)很奇怪，并且類似于集成測(cè)試，但事實(shí)并非如此。

• 支持更簡(jiǎn)單、更快速的測(cè)試：?jiǎn)卧獌?yōu)于集成。考慮應(yīng)用層面的集成；集成測(cè)試應(yīng)該處理單元測(cè)試中無(wú)法驗(yàn)證的事情，例如與框架的集成。
• 在默認(rèn)情況下，并非每個(gè)功能都需要端到端測(cè)試。它們對(duì)于可能危及生命、個(gè)人可識(shí)別信息(PII)至關(guān)重要、可能使企業(yè)損失大量資金或類似情況的功能非常重要。

8.結(jié)論  

如果開(kāi)發(fā)人員需要經(jīng)常引入更改，保持系統(tǒng)的靈活性至關(guān)重要，就像在敏捷環(huán)境中一樣。否則在一段時(shí)間后，合并更改將變得越來(lái)越困難。其他做法將幫助暫時(shí)彌補(bǔ)這一點(diǎn)，但最終它們的影響將不那么顯著。很多時(shí)候，幫助開(kāi)發(fā)人員保持代碼靈活性的實(shí)踐非常容易應(yīng)用。

每天都有更多的證據(jù)支持這樣一個(gè)事實(shí)，即質(zhì)量有助于保持持續(xù)的發(fā)展速度。此外出現(xiàn)了一些新的想法，可以將僵化代碼在業(yè)務(wù)中的作用聯(lián)系起來(lái)。

原文鏈接：https://dzone.com/articles/agile-forgotten-parts