作者 |?張瓅玶(谷樸)? 阿里巴巴研究員

**導讀：**對于大型的軟件系統如互聯網分布式應用或企業級軟件，為何我們常常會陷入復雜度陷阱？如何識別復雜度增長的因素？在代碼開發以及演進的過程中需要遵循哪些原則？本文將分享阿里研究員谷樸關于軟件復雜度的思考：什么是復雜度、復雜度是如何產生的以及解決的思路。較長，同學們可收藏后再看。

軟件設計和實現的本質是工程師相互通過“寫作”來交流一些包含豐富細節的抽象概念并且不斷迭代過程。> 另外，如果你的代碼生存期一般不超過 6 個月，本文用處不大。

軟件架構的核心挑戰是快速增長的復雜性

越是大型系統，越需要簡單性。

大型系統的本質問題是復雜性問題。互聯網軟件，是典型的大型系統，如下圖所示，數百個甚至更多的微服務相互調用/依賴，組成一個組件數量大、行為復雜、時刻在變動（發布、配置變更）當中的動態的、復雜的系統。而且，軟件工程師們常常自嘲，“when things work, nobody knows why”。

圖源：https://divante.com/blog/10-companies-that-implemented-the-microservice-architecture-and-paved-the-way-for-others/

如果我們只是寫一段獨立代碼，不和其他系統交互，往往設計上要求不會很高，代碼是否易于使用、易于理解、易于測試和維護，根本不是問題。而一旦遇到大型的軟件系統如互聯網分布式應用或者企業級軟件，我們常常陷入復雜度陷阱，下圖 the life of a software engineer 是我很喜歡的一個軟件 cartoon，非常形象地展示了復雜度陷阱。

圖源：http://themetapicture.com/the-life-of-a-software-engineer/

作為一個有追求的軟件工程師，大家肯定都思考過，我手上的項目，如何避免這種似乎難以避免的復雜度困境？

然而對于這個問題給出答案，卻出乎意料的困難：很多的文章都給出了軟件架構的設計建議，然后正如軟件領域的經典論著《No silver bullet》所說，這個問題沒有神奇的解決方案。并不是說那么多的架構文章都沒用（其實這么方法多半都有用），只不過，人們很難真正去 follow 這些建議并貫徹下去。為什么？我們還是需要徹底理解這些架構背后的思考和邏輯。所以我覺得有必要從頭開始整理這個邏輯：什么是復雜度，復雜度是如何產生的，以及解決的思路。

軟件的復雜度為什么會快速增長？

要理解軟件復雜度會快速增長的本質原因，需要理解軟件是怎么來的。我們首先要回答一個問題，一個大型的軟件是建造出來的，還是生長出來的？BUILT vs GROWN，that is the problem.

1. 軟件是長出來的，不是建造出來的

軟件不是建造出來的，甚至不是設計出來的。軟件是長出來的。

這個說法初看上去和我們平時的認識似乎不同，我們常常談軟件架構，架構這個詞似乎蘊含了一種建造和設計的意味。然而，對于軟件系統來說，我們必須認識到，架構師設計的不是軟件的架構，而是軟件的基因，而這些基因如何影響軟件未來的形態則是難以預測，無法完全控制。

為什么這么說？所謂建造和“生長”差異在哪里？

其實，我們看今天一個復雜的軟件系統，確實很像一個復雜的建筑物。但是把軟件比作一棟摩天大樓卻不是一個好的比喻。原因在于，一個摩天大樓無論多么復雜，都是事先可以根據設計出完整詳盡的圖紙，按圖準確施工，保證質量就能建造出來的。然而現實中的大型軟件系統，卻不是這么建造出來的。

例如淘寶由一個單體 PHP 應用，經過 4、5 代架構不斷演進，才到今天服務十億人規模的電商交易平臺。支付寶、Google 搜索、Netflix 微服務，都是類似的歷程。

是不是一定要經過幾代演進才能構建出來大型軟件，就不能一次到位嗎？如果一個團隊離開淘寶，要拉開架勢根據淘寶交易的架構重新復制一套，在現實中是不可能實現的：沒有哪個創業團隊能有那么多資源同時投入這么多組件的開發，也不可能有一開始就朝著超級復雜架構開發而能夠成功的實現。

也就是說，軟件的動態“生長”，更像是上圖所畫的那樣，是從一個簡單的“結構”生長到復雜的“結構”的過程。伴隨著項目本身的發展、研發團隊的壯大，系統是個逐漸生長的過程。

2. 大型軟件的核心挑戰是軟件“生長”過程中的理解和維護成本

復雜軟件系統最核心的特征是有成百上千的工程師開發和維護的系統（軟件的本質是工程師之間用編程語言來溝通抽象和復雜的概念，注意軟件的本質不是人和機器溝通）。

如果認同這個定義，設想一下復雜軟件是如何產生的：無論最終多么復雜的軟件，都要從第一行開始開發。都要從幾個核心開始開發，這時架構只能是一個簡單的、少量程序員可以維護的系統組成架構。隨著項目的成功，再去逐漸細化功能，增加可擴展性，分布式微服務化，增加功能，業務需求也在這個過程中不斷產生，系統滿足這些業務需求，帶來業務的增長。業務增長對于軟件系統迭代帶來了更多的需求，架構隨著適應而演進，投入開發的人員隨著業務的成功增加，這樣不斷迭代，才會演進出幾十，幾百，甚至幾千人同時維護的復雜系統來。

大型軟件設計核心要素是控制復雜度。這一點非常有挑戰，根本原因在于軟件不是機械活動的組合，不能在事先通過精心的“架構設計”規避復雜度失控的風險：相同的架構圖/藍圖，可以長出完完全全不同的軟件來。大型軟件設計和實現的本質是大量的工程師相互通過“寫作”來交流一些包含豐富細節的抽象概念并且相互不斷迭代的過程。稍有差錯，系統復雜度就會失控。

所以說了這么多是要停留在形而上嗎？并不是。我們的結論是，軟件架構師最重要的工作不是設計軟件的結構，而是通過 API，團隊設計準則和對細節的關注，控制軟件復雜度的增長。

• 架構師的職責不是試圖畫出復雜軟件的大圖。大圖好畫，靠譜的系統難做。復雜的系統是從一個個簡單應用 一點點長出來的；

• 當我們發現自己的系統問題多多，別怪“當初”設計的人，坑不是一天挖出來的。每一個設計決定都在貢獻復雜度。

理解軟件復雜度的維度

1. 軟件復雜度的兩個表現維度：認知負荷與協同成本

我們分析理解了軟件復雜度快速增長的原因，下面我們自然希望能解決復雜度快速增長這一看似永恒的難題。但是在此之前，我們還是需要先分析清楚一件事情，復雜度本身是什么？又如何衡量？

代碼復雜度是用行數來衡量么？是用類的個數/文件的個數么？深入思考就會意識到，這些表面上的指標并非軟件復雜度的核心度量。正如前面所分析的，軟件復雜度從根本上說可以說是一個主觀指標（先別跳，耐心讀下去），說其主觀是因為軟件復雜度只有在程序員需要更新、維護、排查問題的時候才有意義。一個不需要演進和維護的系統其架構、代碼如何關系也就不大了（雖然現實中這種情況很少）。

既然 “軟件設計和實現的本質是工程師相互通過寫作來交流一些包含豐富細節的抽象概念并且不斷迭代過程” （第三次強調了），那么，復雜度指的是軟件中那些讓人理解和修改維護的困難程度。相應的，簡單性，就是讓理解和維護代碼更容易的要素。

“The goal of software architecture is to minimize the manpower required to build and maintain the required system.” Robert Martin, Clean Architecture.

因此我們將軟件的復雜度分解為兩個維度，都和人理解與維護軟件的成本相關：

• 第一，認知負荷 cognitive load ：理解軟件的接口、設計或者實現所需要的心智負擔；

• 第二，協同成本 Collaboration cost：團隊維護軟件時需要在協同上額外付出的成本。

我們看到，這兩個維度有所區別，但是又相互關聯。協同成本高，讓軟件系統演進速度變慢，效率變差，工作其中的工程師壓力增大，而長期難以取得進展，工程師傾向于離開項目，最終造成質量進一步下滑的惡性循環。而認知負荷高的軟件模塊讓程序員難以理解，從而產生兩個后果：

• 維護過程中易于出錯，bug 率故障率高；
• 更大機率 團隊人員變化時被拋棄，新成員選擇另起爐灶，原有投入被浪費，甚至更高糟糕的是，代碼被拋棄但是又無法下線，成為定時炸彈。

2. 影響到認知負荷的因素

認知負荷又可以分解為：

• 定義新的概念帶來認知負荷，而這種認知負荷與概念和物理世界的關聯程度相關；

• 邏輯符合思維習慣程度：正反邏輯差異，邏輯嵌套和獨立原子化組合。繼承和組裝差異。

1）不恰當的邏輯帶來的認知成本

看以下案例：

A. Code with too much nesting

response = server.Call(request)if response.GetStatus() == RPC.OK:if response.GetAuthorizedUser():if response.GetEnc() == 'utf-8':if response.GetRows():vals = [ParseRow(r) for r inresponse.GetRows()]avg = sum(vals) / len(vals)return avg, valselse:raise EmptyError()else:raise AuthError('unauthorized')else:raise ValueError('wrong encoding') else:raise RpcError(response.GetStatus())

B.? Code with less nesting

response = server.Call(request)if response.GetStatus() != RPC.OK:raise RpcError(response.GetStatus())if not response.GetAuthorizedUser():raise ValueError('wrong encoding')if response.GetEnc() != 'utf-8':raise AuthError('unauthorized')if not response.GetRows():raise EmptyError()vals = [ParseRow(r) for r inresponse.GetRows()] avg = sum(vals) / len(vals) return avg, vals

比較 A 和 B，邏輯是完全等價的，但是B的邏輯明顯更容易理解，自然也更容易在 B 的代碼基礎上增加功能，且新增的功能很可能也會維持這樣一個比較好的狀態。

而我們看到 A 的代碼，很難理解其邏輯，在維護的過程中，會有更大的概率引入 bug，代碼的質量也會持續惡化。

2）模型失配：和現實世界不完全符合的模型帶來高認知負荷

軟件的模型設計需要符合現實物理世界的認知，否則會帶來非常高的認知成本。我遇到過這樣一個資源管理系統的設計，設計者從數學角度有一個非常優雅的模型，將資源賬號用合約來表達（下圖左側），賬戶的 balance 可以由過往合約的累計獲得，確保數據一致性。但是這樣的設計，完全不符合用戶的認知，對于用戶來說，感受到的應該是賬號和交易的概念，而不是帶著復雜參數的合約。可以想象這樣的設計，其維護成本非常之高。

3）接口設計不當

以下是一個典型的接口設計不當帶來的理解成本。

class BufferBadDesign {explicit Buffer(int size);// Create a buffer with given sized slotsvoid AddSlots(int num);// Expand the slots by `num`// Add a value to the end of stack, and the caller need to// ensure that there is at least one empty slot in the stack before// calling insertvoid Insert(int value);int getNumberOfEmptySlots(); // return the number of empty slots }

希望我們的團隊不會設計出這樣的模塊。這個問題可以明顯看到一個接口設計的不合理帶來的維護成本提升：一個 Buffer 的設計暴露了內部內存管理的細節（slot 維護），從而導致在調用最常用接口 “insert” 時存在陷阱：如果不在 insert 前檢查空余 slot，這個接口就會有異常行為。

但是從設計角度看，維護底層的 Slot 的邏輯，也外部可見的 buffer 的行為其實并沒有關聯，而只是一個底層的實現細節。因此更好的設計應該可以簡化接口。把 Slot 數量的維護改為內部的實現邏輯細節，不對外暴露。這樣也完全消除了因為使用不當帶來問題的場景。同時也讓接口更易于理解，降低了認知成本。

class Buffer { explicit Buffer(int size); // Create a buffer with given sized slots // Add a value to the end of buffer. New slots are added // if necessary. void Insert(int value); }

事實上，當我們發現一個模塊在使用時具備如下特點時，一般就是難以理解、容易出錯的信號：

• 一個模塊需要調用者使用初始化接口才能正常行為：對于調用者來說，需要調用初始化接口看似不是大的問題，但是這樣的模塊，帶來了多種后患，尤其是當存在多個參數需要設置，相互關聯關系復雜時。配置問題應該單獨解決（比如通過工廠模式，或者通過單獨的配置系統來管理）；

• 一個模塊需要調用者使用后做清理/ finalizer 才能正常退出；

• 一個模塊有多種方式讓調用者實現完全相同的功能：軟件在維護過程中，出現這種狀況可能是因為初始設計不當后來修改設計 帶來的冗余，也可能是設計原版的缺陷，無論如何這種模塊，帶著強烈的“壞味道”。

完全避免這些問題很難，但是我們需要在設計中盡最大努力。有時通過文檔的解釋來彌補這些問題是必要的，但是好的工程師/架構師，應該清醒的意識到，這些都是“壞味道”。

4）一個簡單的修改需要在多處更新

簡單修改涉及多處更改也是常見的軟件維護復雜度因素，而且主要影響的是我們的認知負荷：維護修改代碼時需要花費大量的精力確保各處需要修改的地方都被照顧到了。

最簡單的情形是代碼當中有重復的“常數”，為了修改這個常數，我們需要多處修改代碼。程序員也知道如何解決這一問題，例如通過定義個 constant 并處處引用避免 magic number。再例如網頁的風格/色彩，每個頁面相同配置都重復設置同樣的色彩和風格是一種模式，而采用 css 模版則是更加易于維護的架構。這在架構原則中對應了數據歸一化原則（Data normalization）。

稍微復雜一些的是類似的邏輯/或者功能被 copy-paste 多次，原因往往是不同的地方需要稍微不同的使用方式，而過去的維護者沒有及時 refactor 代碼提取公共邏輯（這樣做往往需要更多的時間精力），而是省時間情況下選擇了 copy-paste。這就是常說的 Don’t repeat yourself 原則：

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

5）命名

軟件中的 API、方法、變量的命名，對于理解代碼的邏輯、范圍非常重要，也是設計者清晰傳達意圖的關鍵。然而，在很多的項目里我們沒有給 Naming /命名足夠的重視。

我們的代碼一般會和一些項目關聯，但是需要注意的是項目是抽象的，而代碼是具體的。項目或者產品可以隨意一些命名，如阿里云喜歡用中國古代神話（飛天、伏羲、女媧）命名系統，K8s 也是來自于希臘神話，這些都沒有問題。而代碼中的 API、變量、方法不能這樣命名。

一個不好的例子是前一段我們的 Cluster API 被命名為 Trident API（三叉戟），設想一下代碼中的對象叫 Trident 時，我們如何理解在這個對象應該具備的行為？再對比一下 K8s 中的資源：Pod, ReplicaSet, Service, ClusterIP，我們會注意到都是清晰、簡單、直接符合其對象特征的命名。名實相符可以很大程度上降低理解該對象的成本。

有人說“Naming is the most difficult part of software engineering[9][10]”，或許也不完全是個玩笑話：Naming 的難度在于對于模型的深入思考和抽象，而這往往確實是很難的。

需要注意的是：

（a）Intention vs what it is

需要避免用“是什么”來命名，要用“for what / intention”。“是什么”來命名是會很容易將實現細節。比如我們用 LeakedBarrel 做 rate limiting，這個類最好叫 RateLimiter，而不是 LeakedBarrel：前者定義了意圖（做什么的），后者描述了具體實現，而具體實現可能會變化。再比如 Cache vs FixedSizeHashMap，前者也是更好的命名。

（b）命名需要符合當前抽象的層級

首先我們軟件需要始終有清晰的抽象和分層。事實上我們 Naming 時遇到困難，很多就是因為軟件已經缺乏明確的抽象和分層帶來的表象而已。

6）不知道一個簡單特性需要在哪些做修改，或者一個簡單的改動會帶來什么影響，即 unknown unknowns

在所有認知復雜度的表現中，這是最壞的一種，不幸的是，所有人都曾經遇到過這樣的情況。

一個典型的 unknown unknowns 是一部分代碼存在這樣的情況：

• 代碼缺乏充分的測試覆蓋，一些重要場景依賴維護者手工測試；

• 代碼有隱藏 / 不易被發現的行為或者邊界條件，與文檔和接口描述并不符合。

對于維護者來說，改動這樣的代碼（或者是改動影響到了這樣代碼 / 被這樣代碼影響到了）時，如果按照接口描述或者文檔進行，沒發現隱藏行為，同時代碼又缺乏足夠測試覆蓋，那么就存在未知的風險 unknown unknowns。這時出現問題是很難避免的。最好的方式還是要盡量避免我們的系統質量劣化到這個程度。

上線時，我們最大的噩夢就是 unknown unknowns：這類風險，我們無法預知在哪里或者是否有問題，只能在軟件上線后遇到問題才有可能發現。其他的問題 尚可通過努力來解決（認知成本），而 unknown unknowns 可以說已經超出了認知成本的范圍。我們最希望避免的也是 unknown unknowns。

7）認知成本低要不易出錯，而不是無腦“簡化”

從認知成本角度來說，我們還要認識到，衡量不同方案/寫法的認知成本，要考慮的是不易出錯，而不是表面上的簡化：表面上簡化可能帶來實質性的復雜度上升。

例如，為了表達時間段，可以有兩種選擇：

// Time period in seconds. void someFunction(int timePeriod); // time period using Duration. void someFunction(Duration timePeriod);

在上面這個例子里面，我們都知道，應該選用第二個方案，即采用 Duration 作 time period，而不是 int：盡管 Duration 本身需要一點點學習成本，但是這個模式可以避免多個時間單位帶來的常見問題。

3. 影響協同成本的因素

協同成本則是增長這塊模塊所需要付出的協同成本。什么樣的成本是協同成本？

• 增加一個新的特性往往需要多個工程師協同配合，甚至多個團隊協同配合；
• 測試以及上線需要協調同步。

1）系統模塊拆分與團隊邊界

在微服務化時代，模塊/服務的切分和團隊對齊，更加有利于迭代效率。而模塊拆分和邊界的不對齊，則讓代碼維護的復雜度增加，因這時新的特性需要在跨多個團隊的情況下進行開發、測試和迭代。

另外一個角度，則是：

Any piece of software reflects the organizational structure that produces it.

或者就是我們常說的“組織架構決定系統架構”，軟件的架構最后會圍繞組織的邊界而變化（當然也有文化因素），當組織分工不合理時，會產生重復的建設或者沖突。

2）服務之間的依賴，Composition vs Inheritance / Plugin

軟件之間的依賴模式，常見的有 Composition 和 Inheritance 模式，對于 local 模塊/類之間的依賴還是遠程調用，都存在類似模式。

上圖左側是 Inheritance（繼承或者是擴展模式），有四個團隊，其中一個是 Framework 團隊負責框架實現，框架具有三個擴展點，這三個擴展點有三個不同的團隊實現插件擴展，這些插件被 Framework 調用，從架構上，這是一種類似于繼承的模式。

右側是組合模式（composition）：底層的系統以 API 服務的方式提供接口，而上層應用或者服務通過調用這些接口來實現業務功能。

這兩種模式適用于不同的系統模型。當 Framework 偏向于底層、不涉及業務邏輯且相對非常穩定時，可以采用 inheritance 模式，也即 Framework 被集成到團隊 1，2，3 的業務實現當中。例如 RPC framework 就是這樣的模型：RPC 底層實現作為公共的 base 代碼 / SDK 提供給業務使用，業務實現自己的 RPC 方法，被 framework 調用，業務無需關注底層 RPC 實現的細節。因為 Framework 代碼被業務所依賴，因此這時業務希望 Framework 的代碼非常穩定，而且盡量避免對 framework 層的感知，這時 inheritance 是一種比較合適的模型。

然而，我們要慎用 Inheritance 模式。Inheritance 模式的常見陷阱：

（a）要避免出現管理倒置

即 Framework 層負責整個系統的運維（framework 團隊負責代碼打包、構建、上線），那么會出現額外的協同復雜度，影響系統演進效率（設想一下如果 Dubbo 的團隊要求負責所有的使用 Dubbo 的應用的打包、發布成為一個大的應用，會是多么的低效）。

（b）要避免破壞業務邏輯流程的封閉性

Inheritance 模式如果使用不當，很容易破壞上層業務的邏輯抽象完整性，也即“擴展實現1”這個模塊的邏輯，依賴于其調用者的內部邏輯流程甚至是內部實現細節，這會帶來危險的耦合，破壞業務的邏輯封閉性。

如果你所在的項目采用了插件 / Inheritance 模式，同時又出現上面所說的管理倒置、破壞封閉性情況，就需要反思當前的架構的合理性。

而右側的 Composition 是更常用的模型：服務與服務之間通過 API 交互，相互解耦，業務邏輯的完整性不被破壞，同時框架 / Infra 的 encapsulation 也能保證。同時也更靈活，在這種模型下，Service 1, 2, 3 如果需要也可以產生相互調用。

另外《Effective Java》一書的 Favor composition over inheritance 有很好的分析，可以作為這個問題的補充。

3）可測試性不足帶來的協同成本

交付給其他團隊（包括測試團隊）的代碼應該包含充分的單元測試，具備良好的封裝和接口描述，易于被集成測試的。然而因為 單測不足/模塊測試不足，帶來的集成階段的復雜度升高、失敗率和返工率的升高，都極大的增加了協同的成本。因此做好代碼的充分單元測試，并提供良好的集成測試支持，是降低協同成本提升迭代效率的關鍵。

可測試性不足，帶來協同成本升高，往往導致的破窗效應：上線越來越靠運氣，unknown unknowns 越來越多。

4）文檔

降低協同成本需要對接口 / API 提供清晰的、不斷保持更新一致的文檔，針對接口的場景、使用方式等給出清晰描述。這些工作需要投入，開發團隊有時不愿意投入，但是對于每一個用戶/使用方，需要依賴釘釘上的詢問、或者是依靠 ATA 文章（多半有 PR 性質或者是已經過時，沒有及時更新，畢竟 ATA 不是產品文檔），協同成本太高，對于系統來說出現 bug / 使用不當的幾率大為增加了。

最好的方式：

• 代碼都公開；
• 文檔和代碼寫在一起（README.md， *.md），隨著代碼一起提交和更新，還計算代碼行數，多好。

4. 軟件復雜度生命周期

復雜度的惡化到一定程度，一定進入有諸多 unknown unknowns 的程度。好的工程師一定要能識別這樣的狀態：可以說，如果不投入力氣去做一定的重構/改造，有過多 unknown unknowns 的系統，很難避免失敗的厄運了。

這張圖是要表明，軟件演進的過程，是一個“不由自主”就會滑向過于復雜而無法維護的深淵的過程。如何要避免失敗的厄運？這篇文章的篇幅不容許我們展開討論如何避免復雜度，但是首要的，對于真正重要的、長生命周期的軟件演進，我們需要做到對于復雜度增量零容忍。

5. Good enough vs Perfect

軟件領域，從效率和質量的折中，我們會提“Good enough”即可。這個理論是沒錯的。只不過現實中，我們極少看到“overly good”，因為過于追求 perfection 而影響效率的情況。大多數情況下，我們的系統是根本沒做到 Good enough。

對復雜度增長的對策

每一份新的代碼的引入，都在增加系統的復雜度：因為每一個類或者方法的創建，都會有其他代碼來引用或者調用這部分代碼，因而產生依賴/耦合，增加系統的復雜度（除非之前的代碼過度復雜 unncessarily complex，而通過重構可以降低復雜度），如果讀者都意識到了這個問題，并且那些識別增加復雜度的關鍵因素對于大家有所幫助，那么本文也就達到了目標。

而如何 Keep it simple，是個非常大的話題，本文不會展開。對于 API 設計，在 API 設計最佳實踐思考中做了一些總結，其他的希望后續有時間能繼續總結。

API 設計最佳實踐思考：https://developer.aliyun.com/article/701810

有人會說，項目交付的壓力才是最重要的，不要站著說話不腰疼。實際呢？我認為絕對不是這樣。多數情況下，我們要對復雜度增長采用接近于“零容忍”的態度，避免“能用就行”，原因在于：

• 復雜度增長帶來的風險（unknown unknowns、不可控的失敗等）往往是后知后覺的，等到問題出現時，往往 legacy 已經形成一段時間，或者坑往往是很久以前埋的；

• 當我們在代碼評審、設計評審時面臨一個個選擇時，每一個 Hack、每一個帶來額外成本和復雜度的設計似乎都顯得沒那么有危害：就是增加了一點點復雜度而已，就是一點點風險而已。但是每一個失敗的系統的問題都是這樣一點點積累起來的；

• 破窗效應 Broken window：一個建筑，當有了一個破窗而不及時修補，這個建筑就會被侵入住認為是無人居住的、風雨更容易進來，更多的窗戶被人有意打破，很快整個建筑會加速破敗。這就是破窗效應，在軟件的質量控制上這個效應非常恰當。所以，Don’t live with broken windows (bad designs, wrong decisions, poor code) ：有破窗盡快修。

零容忍，并不是不讓復雜度增長：我們都知道這是不可能的。我們需要的是盡力控制。因為進度而臨時打破窗戶也能接受，但是要盡快補上。

當然文章一開始就強調了，如果所寫的業務代碼生命周期只有幾個月，那么多半在代碼變得不可維護之前就可以下線了，那可以不用關注太多，能用就行。

最后，作為 Software engineer，軟件是我們的作品，希望大家都相信：

• 真正的工程師一定在意自己的作品：我們的作品就是我們的代碼。工匠精神是對每個工程師的要求；

• 我們都可以帶來改變：代碼是最公平的工作場地，代碼就在那里，只要我們愿意，就能帶來變化。

云原生微服務框架哪家強？

近期阿里云原生團隊聯合 X-lab 開放實驗室發布《2020 年微服務領域開源數字化報告》，通過 2020 年 1 月到 6 月的 GitHub 日志進行統計，分析微服務框架項目以及 Spring Cloud 項目的 GitHub 開發者行為日志，分析了開源微服務框架活躍度。

點擊查看報告全文：https://developer.aliyun.com/article/770673

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的公眾號。”

總結

以上是生活随笔為你收集整理的阿里研究员谷朴：警惕软件复杂度困局的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。