譯者 | 李睿

審校 | 孫淑娟

如今，很多開發人員將太多的注意力集中在敏捷慣例上，而敏捷宣言中提到的關鍵方面沒有根據它的重要性來考慮。  

敏捷實踐已經在全球范圍內采用。而許多企業都以敏捷為榮，并且以不同的方式實現它。這很好，但并沒有一個單一的方法來實現它，需要根據每個場景進行調整。

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

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

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

許多在過去10年開始職業生涯的開發人員可能在敏捷環境中工作過。然而，敏捷并不總是存在。而在本世紀初，瀑布就是一種常見的做法。  

在瀑布方法中，應用程序通常是作為一個整體進行規劃的，客戶可能需要幾個月才能看到一些可用的軟件。

開發計劃是作為一個項目進行的，而有了開頭，在理論上也有一個結束（有時可能是公司倒閉）。該項目分為以下幾個階段：

• 需求收集
• 系統設計
• 任務計劃
• 開發
• 測試和交付

每個階段通常由不同的人員進行。客戶在開始和結束時都參與了合同的簽署。如果項目成功完成，應用程序就會部署到生產環境中，并且通常會移交給另一個團隊，該團隊將負責保持正常運行。  

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

收集所有需求、預先設計系統和規劃任務幾乎是不可能的，并且需要數周時間。  

每個階段的交接都會導致溝通不暢。  

交付產品需要很長時間，并且實施很多次，遠遠超出預期。

在預算和范圍內結束也很困難。  

階段之間沒有反饋循環。很多時候，只有最后才有反饋。如果反饋是否定的，那么整個投資都失敗了。

2.敏捷解決關鍵問題  

Rodríguez表示，在他當初開始其職業生涯時就聽說一個新概念：敏捷。當時并不知道這是怎么回事。那時他專注于提高開發技能，并不太關心軟件開發方法。  

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

大多數這些流行術語本身并沒有告訴很多。在工作一段時間后，他開始對了解為什么很多企業都采用這些做法感興趣，所以開始深入研究這個話題。  

他在工作中理解了其中一些術語的含義，并且看到了很多討論：開發團隊應該做Scrum、看板、極限編程（XP）還是其他？團隊每個Scrum應該在每個慣例上花費多長時間？應該談論什么？等等。  

他了解一些膚淺的信息，并且遺漏了一些信息。也許這是他的研究技能。回顧過去，發現不僅如此。  

當閱讀敏捷宣言時，他了解其中一件事是：“個人和交互優于流程和工具”。  

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

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

專注于敏捷的要點，與瀑布的主要區別之一是以增量的方式組織開發：應用程序將被劃分為具有優先級的小塊。每個塊都是在一個Sprint內開發的（通常是1周或2周）。在每個Sprint之后，應該為客戶提供應用程序的功能版本。客戶（或者在某些情況下是業務代表）積極參與了該過程，因此可以盡早獲得反饋。可以看到這些想法是如何解決瀑布方法出現的一些問題，它通過快速交付和通過早期獲得反饋來快速失敗。  

而在敏捷宣言中，其中一個價值觀是“歡迎不斷變化的需求，即使是在開發的后期”。一開始，Rodríguez無法理解這句話的含義，他不確定這是否是一個好主意。然而，在思考它并在敏捷環境中獲得不同的經驗之后，他認為它是最重要的部分之一。重要的是要考慮到變化可能涉及領域的新特征和新概念，但也可能涉及現有行為和市場的變化等。  

因此，不僅在敏捷中快速行動很重要（盡早交付客戶需要的價值，通過早期反饋快速失敗），而且對環境變化快速做出反應也很重要。它們不是唯一重要的方面，但以下將重點關注這兩個方面。  

因此繼續這種軟件開發實踐的演變，提到一些主要有助于快速發展的改進。  

3.快速行動：軟件編碼和交付實踐的演變  

當時的工具并不容易采用敏捷實踐，例如頻繁部署。在過去的25年中出現了一些實踐和技術，以幫助開發團隊更快地發布軟件。其中一些是敏捷的結果，而另一些則是獨立出現的。  

Rodríguez簡要提及其中的一些技術及其好處，而沒有詳細說明。他認為大多數都是廣為人知的技術，但如果對人們來說是新技術，那么網上有很多資源可以找到更多信息：  

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

除了這些實踐之外，新工具、IDE改進、框架、庫和語言演變使開發人員能夠加快軟件開發。  

如果企業采用上述大多數做法，這可能意味著軟件可以比以前更快地交付。而且這些更改不僅更快而且更安全，因為許多任務都被自動化或委派了。  

有些人可能會認為軟件交付就像閃電一樣快，對嗎？

根據Rodríguez的經驗，即使遵循了這些做法，也可能需要很長時間才能實現價值。以下是一些案例：  

示例1：  

Rodríguez表示，他花費三天時間來理解必須修改的代碼。這是他第一次接觸到那個代碼。值得慶幸的是，他正在與非常了解該應用程序的人一起工作。通過相應的測試來實施主要更改花費了開發團隊兩周時間。最后，他們花費大約16周的時間在整個代碼中尋找錯誤并實施修復。  

正如人們所看到的，在第三點上花了很多時間。在這16周中，大約70%的人在尋找錯誤，大約20%的人理解開發人員發現的邏輯并考慮如何使其適應新行為，3%的人用于編寫自動化測試，1%的人自己實施更改。  

以下是為什么花費這么長時間的一些原因：  

• 服務做的事情太多了。
• 代碼耦合非常緊密，因為代碼的不同部分發生了很多問題。
• 與此同時，代碼的內聚性不是很強。處理同樣問題的邏輯被廣泛傳播。

示例2：  

Rodríguez表示，他們的研究團隊花費三天時間了解需要改變什么，并花費一天的時間來實施這些更改，并花費七天的時間讓測試再次通過。  

在這種情況下，開發人員正在修復代碼以前的錯誤。其中一些甚至沒有完全修復。很明顯，一些開發人員對這些技術還不夠熟悉。幸運的是，問題并不嚴重，客戶也沒有注意到。糟糕的是，它們在應用新更改時突然出現，使得測試幾乎不可能，因此必須在完成任務之前修復它們。

另一個問題是堆棧不是最新的，開發團隊想要實施的許多解決方案都行不通。在這些情況下，可能看到大量時間被浪費在調試和理解需要調整的代碼上。  

除此之外，還有一些可以永遠運行的構建通道（同一應用程序中的大量代碼、緩慢或不穩定的測試等）。  

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

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

代碼質量并不是敏捷的獨有問題，但它在這里尤其重要，甚至比傳統項目更重要。還有一種誤解是，在敏捷方法中，不需要在軟件架構和設計上進行任何計劃或投入精力，但實際上恰恰相反。代碼經常被擴展和調整，因此使系統易于更改至關重要，否則它們將使未來的開發變得非常緩慢。因此，對于敏捷開發，這句話的下一個迭代可能是：系統靈活性是敏捷中被忽略或遺忘的最重要部分之一。  

這并不是什么新鮮事。正如在以上內容看到的，敏捷宣言中提到了這一點，但持續關注卓越的技術和良好的設計可以提高敏捷性。  

敏捷流程促進可持續發展。贊助商、開發人員和用戶應該能夠無限期地保持恒定的速度。如果代碼混亂、難以理解和變化，團隊如何保持恒定的步伐？  

需要記住的是，質量并不意味著復雜性。簡單也很重要：而簡單就是最大化未完成工作量的藝術。  

架構通常與剛性和提前規劃有關，因為經常想到難以改變的架構。從這個角度來看，在敏捷環境中投入時間在架構或設計上是沒有意義的，因為事情經常發生變化。  

但是在軟件世界中，可以選擇讓選項保持開放并使更改更容易的架構。事實上，敏捷促進了短期思維。眾所周知，預測并不容易，開發人員最終付出了代價，甚至不知道兩天后客戶會需要什么。  

對于沒有采用敏捷方法的開發人員來說，需要知道的是，高績效員工不必以速度換取穩定性，反之亦然，因為通過提高質量，可以實現兩全其美。

5.開發緩慢的后果  

隨著開發人員添加更多代碼，開發速度變得更慢，這不僅是開發人員的問題。每個利益相關者都用自己的方式說話，并且含義略有不同：  

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

所以很明顯開發速度會變慢，但幸運的是，如果投資于靈活的代碼，可以節省一些時間。  

然而，要讓一些人相信這一點并不容易。還有一個問題：僵化代碼的效果不是立竿見影的。從長遠來看，它們是可見的。在短期內投資開發靈活的代碼可能看起來更慢。那么，誰愿意投資于沒有立竿見影的效果呢？很多人的想法大多是短期的，需要更多地了解代碼質量將如何影響未來的發展。  

6.將剛性系統的影響與業務聯系起來  

嚴格的代碼對開發某個產品需要多長時間的影響并不容易被發現。因此，對業務的影響也不明顯。如果兩者之間沒有聯系，就很難讓人們相信擁有靈活系統的重要性。這是一個非常復雜的話題，但需要填補空白。  

DORA指標至少部分解決了這個問題。其代碼不是同質的，代碼路由很慢，問題可能被發現得太晚。  

軟件架構師Glenn Engstrand在他的演講中介紹的技術能力計劃（TCP）在微服務架構中管理技術債務可能是一個起點。  

Rodríguez表示，他并沒有一個理想的解決方案，夢想有一個在每次提交后更新的分數，它可以用作估計未來任務需要多長時間才能完成的乘數。  

然而，想以一些關于如何提高代碼靈活性的簡單想法作為結束。

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

網上有很多關于代碼質量的書籍和資源，因此就不再贅述：  

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

對于測試，需要記住它們提供安全性，但它們抵制更改，并且可能會比生產代碼本身占用更多的時間，因此：

• 他們需要帶來足夠的價值。進行測試驅動開發（TDD）是一種可以幫助企業實現它的實踐。
• 如果他們測試實施細節，他們將很難改變。

很多單元測試來驗證提供內部結果的代碼片段。這些代碼是開發人員組織代碼的結果。如果邏輯需要以不同的方式組織和移動，許多測試就會中斷。發生這種情況時，測試不再保護并且幾乎毫無用處。它還給團隊額外的工作。因此，重要的是要考慮什么是實際的單位。在不得不多次重組代碼之后，Rodríguez表示一直在思考這個問題，開始認為單元的概念可能不僅僅是方法或類，而是可能需要從特性的角度來考慮。這可能聽起來很奇怪，并且類似于集成測試，但事實并非如此。

• 支持更簡單、更快速的測試：單元優于集成。考慮應用層面的集成；集成測試應該處理單元測試中無法驗證的事情，例如與框架的集成。
• 在默認情況下，并非每個功能都需要端到端測試。它們對于可能危及生命、個人可識別信息(PII)至關重要、可能使企業損失大量資金或類似情況的功能非常重要。

8.結論  

如果開發人員需要經常引入更改，保持系統的靈活性至關重要，就像在敏捷環境中一樣。否則在一段時間后，合并更改將變得越來越困難。其他做法將幫助暫時彌補這一點，但最終它們的影響將不那么顯著。很多時候，幫助開發人員保持代碼靈活性的實踐非常容易應用。

每天都有更多的證據支持這樣一個事實，即質量有助于保持持續的發展速度。此外出現了一些新的想法，可以將僵化代碼在業務中的作用聯系起來。

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