作者 | Vanessa Formicola

譯者 | 張衛(wèi)濱

項目延期；架構偏離了最初的設計；代碼神秘地演變成了沒有人計劃的東西。這些在軟件開發(fā)中持續(xù)存在的問題往往不是由技術失敗引起的，而是因為我們忽視了錯以為不存在的力量，即獎勵系統(tǒng)激勵了錯誤的行為，組織結構忽視了領域邊界，以及我們認為“太瑣碎”而沒有考慮技術決策中的人際關系。

整體工程（holistic engineering）是有意將這些非技術力量納入我們的技術決策、設計和策略的做法。就像地質(zhì)力量在峽谷壁上留下可見的層一樣，組織和人類的力量在我們的代碼庫中留下了它們的印記。不同的是，我們可以清楚地看到峽谷的層，而塑造我們軟件的力量在我們學會尋找它們之前是看不見的。

圖片來源：感謝Tomá? Malík 在 Pexels 上的貢獻。

在我的職業(yè)生涯中，無論是作為軟件工程師、架構師、技術領導、工程經(jīng)理、首席工程師還是顧問，我都觀察到相同的模式在不同的公司、領域和技術棧中反復出現(xiàn)。這些模式揭示了非技術力量如何始終塑造我們的技術系統(tǒng)，無論我們是否承認這一點。

現(xiàn)實環(huán)境中的現(xiàn)象

項目延期是我們的業(yè)務中一個持續(xù)存在的問題。要與截止日期完美對齊是非常具有挑戰(zhàn)性的。另一個持續(xù)存在的問題是，當項目結束時，在經(jīng)過如此多的策略和設計之后，最終結果與原始設計完全不同，這不是出于好的原因。不是因為我們在演變架構，而是因為資金被削減了，出現(xiàn)了其他問題，或者存在非常大的誤解，以至于在某個時候，團隊必須在現(xiàn)有約束下工作。

這些模式的出現(xiàn)是因為技術專家在孤立的視角中運作。像許多其他學科一樣，技術專家會從自己的角度看待我們的問題空間，考慮我們的責任，很少有機會像我們本可以做到的那樣徹底地檢查全局視角。

“現(xiàn)象”代表了每個人都能認識到存在的事件或情況，但人們對為什么會發(fā)生這種情況可能會有不同的意見。這些模式被稱為“現(xiàn)實環(huán)境中的現(xiàn)象（phenomena in the wild）”，是反復出現(xiàn)的模式。同樣適用于自然力量，這些力量通常以某種方式影響路徑，團隊必須找到接受、緩解或解決它們的方法。

共享廚房水槽現(xiàn)象

有一個俗語叫做“除了廚房水槽什么都有（everything but the kitchen sink）”，意思是你把各種各樣的東西都塞進了你的包或行李箱里，里面除了廚房水槽什么都有。這種現(xiàn)象幾乎在每個組織中都以工具庫的形式出現(xiàn)。組織通常將這些庫命名為“common”或使用公司名稱。這是一個由公司所有服務使用的庫，它的所有開發(fā)人員來自不同的團隊，他們添加小功能以幫助彼此。

這種方法造成了多個嚴重的問題。第一個問題是，假設我們有一個每個人都貢獻的庫，如果這個庫有問題，所有使用它的服務都是想象中最大爆炸半徑的一部分。另一個問題是，如果來自不同團隊的多個人不斷添加小功能，你最終會得到一個非常大的庫，而在某個時候，開發(fā)人員會失去對庫內(nèi)容的可見性。

它越大，參與協(xié)作的人越多，人們就越難重構它，以使其更有效、更靈活。這不可避免地增加了復雜性，增加了錯誤率，而且，通常情況下，每當有復雜性出現(xiàn)時，它就難以很好地測試。

兩個主要的力量促成了這種現(xiàn)象：人員管理過程和相應的獎勵系統(tǒng)。此外，糟糕的計劃或交付壓力也是促成因素。

職業(yè)框架通常包括看起來很合理的標準，這些標準卻創(chuàng)造了錯誤的技術激勵。人力資源部門和高級領導經(jīng)常設計評估系統(tǒng)，通過“影響范圍”來衡量工程成熟度，其中公司范圍的影響表明比團隊級貢獻更高的成熟度。雖然概念上聽起來合理，但這種影響驅使工程師通過向共享庫和服務添加功能來操縱系統(tǒng)，允許他們在績效評估中聲稱創(chuàng)建廣泛的組織影響，而不是專注于適當?shù)募夹g解決方案。

另一個驅動力是由于交付壓力導致的糟糕計劃。常見的短語如“ 我們需要明天之前完成 ”或“ 我們需要下周完成 ”創(chuàng)造了交付壓力。然后，團隊中的開發(fā)人員將別無選擇，只能使用他們已經(jīng)擁有的交付機制，即已經(jīng)存在的這個庫。

這兩者代表了在實際上促使工具庫形成的力量。背后的決策根本不是技術性的。不同的部門出于不同的原因做出決策，但它們對你的代碼有非常直接的影響。

領域身份危機現(xiàn)象

組織經(jīng)常創(chuàng)建一些共享領域庫，這些庫中包含了像 Customer 或 Order 這樣的類，試圖代表公司所有團隊的核心業(yè)務實體。例如，一個 Customer 類可能需要滿足市場團隊（需要人口統(tǒng)計數(shù)據(jù)和活動偏好）、計費團隊（需要支付歷史和信用評分）、支持團隊（需要工單歷史和溝通偏好）以及物流團隊（需要地址和交付偏好）。團隊沒有認識到它們是需要單獨表示的不同限界上下文，而是將所有這些關注點塞進一個龐大的 Customer 類中。

這種方法違反了領域驅動設計的原則，因為它假設整個公司共享一個單一的領域模型。由此產(chǎn)生的膨脹類變得無法維護和修改。團隊開始使用不同的術語來引用相同的概念，這提示他們對應該分開的領域表達了完全不同的觀點。當人類的理解以這種方式分裂時，軟件不可避免地無法正確地模擬它應該代表的業(yè)務現(xiàn)實。

當產(chǎn)品組織缺乏完全理解和溝通領域邊界的成熟度時，這種現(xiàn)象就會出現(xiàn)。沒有與產(chǎn)品團隊適應的領域映射和溝通技巧，工程部門無法在代碼中準確地表示業(yè)務現(xiàn)實。

缺乏專職業(yè)務分析師的團隊會面臨額外的挑戰(zhàn)。業(yè)務分析師連接需求和開發(fā)團隊，確保需求不重疊，并且捕獲所有細節(jié)。當團隊缺乏這個角色時，開發(fā)人員會將這些責任作為次要職責承擔，由于時間限制和注意力分散，不可避免地產(chǎn)生較差的領域建模。

這現(xiàn)象的最強有力引發(fā)因素是組織設計在組建團隊時忽視了領域邊界。組織可能會根據(jù)技術而不是領域來分組服務，將兩個 Java 服務分配給同一個團隊，而其他團隊使用不同的語言。雖然這種方法優(yōu)化了資源流動，但它迫使團隊將不同的領域視為統(tǒng)一的，導致他們將獨立的業(yè)務領域建模成了代碼中單一的領域。

太陽馬戲團編碼現(xiàn)象

太陽馬戲團（Cirque du Soleil）以精湛的雜技表演而聞名。類似地，一些代碼庫展示了所謂的“太陽馬戲團編碼”，在這些實現(xiàn)中，簡單的特性包含了所有可用的設計模式、庫特性和外部依賴。這些解決方案優(yōu)先展示技術范圍，而不是確定最簡單有效的方法。

這種過度工程模式造成了巨大的維護開銷。復雜的解決方案在調(diào)試、修改和測試方面花費更多。結果代碼變得更脆弱，團隊難以理解，導致 bug 率增加，開發(fā)速度降低。在這種背景下，有種“酷文化”出現(xiàn)了，在該文化中，開發(fā)人員將技術成熟度與專業(yè)能力等同起來，促使工程師使用每一種可用的工具，而不是選擇合適的解決方案。

職業(yè)框架通過包括像“從業(yè)者在公司的技術棧中非常熟練”的標準加劇了這個問題。當組織缺乏適當評估工程工作的技術深度時，開發(fā)人員通過在他們的拉取請求中創(chuàng)建復雜的技術演示來做出回應。這些演示允許開發(fā)人員在集中的例子中展示他們的知識廣度，而不是分散在多個更簡單的實現(xiàn)中。

有影響力的技術領導者無意中加強了這種模式。當高級工程師或架構師推廣特定的庫或方法時，團隊將這些建議解釋為命令。無意間的認可變成了普遍應用的組織標準，而不是符合上下文的標準。

有毒的組織文化加劇了這些動態(tài)。在開發(fā)人員感到需要不斷證明自己能力的壓力環(huán)境中，過度工程變成了一種防御機制。工程師創(chuàng)建不必要的復雜解決方案來展示他們的技術能力并確保他們在團隊中的地位。

使無意識變得有意識

工程師經(jīng)常避免承認組織的問題和變化超出了他們的直接技術責任。就像諺語所說的“三只聰明的猴子”一樣，技術團隊對不正常的模式閉上眼睛和耳朵，拒絕討論不可避免地影響他們工作的力量。

Carl Jung 觀察到：“當內(nèi)部情況沒有被意識到時，它就像宿命一樣在外部發(fā)生”。工程師經(jīng)常能夠認識到他們公司內(nèi)部的人類動態(tài)和組織問題，然而當項目運行延遲或偏離預定方向時，他們將這些結果歸因于不可預見的情況，而不是可預測的組織力量。

Gloria Steinem 曾指出：“真相會讓你自由，但它首先會激怒你?！奔夹g團隊經(jīng)常意識到不正常的動態(tài)，但將其視為過于瑣碎或不專業(yè)，無法納入技術決策。他們認為，利益相關者的沖突、不協(xié)調(diào)的職業(yè)框架或有害的團隊變動，都低于他們的專業(yè)標準。這種故意無視非技術力量的做法并不能消除它們的影響；它只是確保團隊對不可避免的結果缺乏準備，這些結果直接體現(xiàn)在他們的代碼體系結構和項目結果中。

整體工程

解決方案需要全面地審視問題。整體（holistic）這個詞描述了一個構造，其組成部分代表整個有機體，如果不檢查整個系統(tǒng)就無法正確理解。整體醫(yī)學可以作為一個例子。當人們接受整體醫(yī)學治療時，從業(yè)者不僅要檢查疾病和癥狀，還要檢查整體健康狀況。治療考慮到疾病的完整背景，包括環(huán)境和生活方式因素。

在技術設計過程中，整體工程涉及考慮的因素不僅包括傳統(tǒng)的技術因素，還包括所有其他非技術因素，這些因素無論如何都會影響你的系統(tǒng)。通過承認這些力量，團隊可以將問題視為一個有機系統(tǒng)，并在某種程度上影響系統(tǒng)的各個組成部分。

你的項目如何位于多個系統(tǒng)的交匯處

外部力量

• 世界事件

• 商業(yè)變化和趨勢

• 技術趨勢

外部力量是組織控制之外的影響技術決策和項目結果的因素。這些力量在公司之外運作，但直接影響系統(tǒng)設計、架構選擇和項目時間表。

影響技術決策的外部因素（用綠色表示）

構建電子商務系統(tǒng)的團隊通常會考慮假日期間的支持能力。很少有團隊考慮選舉或監(jiān)管變化會如何影響其項目的未來，尤其是在更大的戰(zhàn)略項目的時間框架內(nèi)。

商業(yè)趨勢也提出了類似的挑戰(zhàn)。如果沒有了解產(chǎn)品在更廣泛的商業(yè)背景中的位置，團隊很難確定哪些組件會發(fā)生變化，哪些會保持穩(wěn)定。了解哪些因素可能完全顛覆市場或摧毀產(chǎn)品對于優(yōu)先考慮技術決策至關重要。

技術趨勢是另一類外部力量，不過團隊在做出架構決策時會更普遍地承認這些。

內(nèi)部力量

• 組織

• 技術

• 產(chǎn)品

• 人員

內(nèi)部力量是公司內(nèi)部影響技術決策和項目結果的組織因素。與外部力量不同，團隊可以潛在地影響、緩解或繞過內(nèi)部力量，不過這些力量由于其制度性質(zhì)通常感覺是不可改變的。

影響技術決策的內(nèi)部因素（用綠色表示）

人員、產(chǎn)品和工程的三元組合會在一個預先存在的組織結構中運轉。這種組織基礎是在當前團隊成員加入之前就已經(jīng)建立起來的，并且可能在他們離開后繼續(xù)存在。團隊必須認識到他們的技術解決方案是建立在這個組織基礎之上并受其約束的。

考慮組織中的實際信息結構。了解實際的工作流模式和溝通渠道可以揭示工作是如何真正完成的。這些通信模式通常與正式的層次結構有很大的不同。接下來，確定哪些過程會阻礙你的進度。例如，一些組織需要 20 個人的批準來決定版本發(fā)布，包括 CTO。

獎勵系統(tǒng)、職業(yè)框架和獎金結構代表了在關鍵項目中時刻影響團隊行為的強大內(nèi)部力量。這些機制決定了個人工作的優(yōu)先順序，通常與最佳技術決策相沖突，但與個人發(fā)展目標一致。

產(chǎn)品

團隊經(jīng)常缺乏時間來檢查超出其直接項目范圍的產(chǎn)品需求。如果不了解完整的產(chǎn)品策略和公司的使命，團隊就無法做出明智的決定，決定哪些功能將保持穩(wěn)定，在哪里投入精力，以及什么可能會發(fā)生變化。這種局部項目需求和更廣泛的產(chǎn)品方向之間的脫節(jié)嚴重影響了技術決策。市場營銷策略可以揭示即將發(fā)生的變化，幫助團隊預防架構問題。

人員

分析團隊成員需要超越技術技能和角色數(shù)量。項目參與者的關鍵特征、他們的職業(yè)動機、對項目結果的個人投資，以及個人環(huán)境會直接影響項目的成功與否。人們可能會被分配到他們職業(yè)規(guī)劃之外的項目，這會影響他們的敬業(yè)度和績效。個人生活的變化，如關系變化、搬遷、家庭成員增加或求職，都會產(chǎn)生可用性和關注點的限制，需要特定的緩解策略。

工程

技術決策必須與公司的技術戰(zhàn)略和能力保持一致。如果團隊設計的解決方案在部署頻率、回滾能力或架構復雜性方面超過了其組織的運維成熟度，就會創(chuàng)建公司無法維持的實現(xiàn)。產(chǎn)品質(zhì)量、可觀測系統(tǒng)和運維成熟度的路徑直接限制了團隊可以成功部署的架構。在項目后期處理安全和隱私需求時，通常會成為需要額外資金的障礙，并導致延遲。

將整體工程付諸實踐

識別組織力量

每個組織都包含影響技術決策的功能失調(diào)模式。系統(tǒng)地識別這些力量使團隊能夠預測項目將在哪里遇到阻力、延遲或意外變更。該分析揭示了哪些技術方法將在現(xiàn)有的限制條件下取得成功，哪些技術方法需要組織變更才能有效地實施。

使隱性知識顯性化

將關于組織功能失調(diào)的非正式觀察轉化為具體的文檔。為通信模式建模，繪制實際的決策過程，并可視化工作如何在組織中流動。這些制品將非正式的觀察轉化為團隊可以用于項目計劃的可操作的情報。文檔使以前看不見的力量可以測量和定位。

有組織地社會化信息

將力量分析分享給直接利益相關者之外的人，以創(chuàng)建組織范圍內(nèi)的共識。當功能失調(diào)成為一個公認的事實而不是私人知識時，它使組織內(nèi)的協(xié)調(diào)改進工作成為可能。公開承認“我們的部署流程造成瓶頸”會將個人的挫敗感轉變?yōu)榻M織變革的使命。這種方法建立了解決根源而不是解決癥狀的聯(lián)盟。

設計兩種架構

創(chuàng)建一個理想的“北極星”架構和一個務實的當前狀態(tài)解決方案。北極星代表了沒有組織約束的最佳設計，而務實的設計則在現(xiàn)有限制內(nèi)工作。這種雙重方法提供了潛在和現(xiàn)實之間差距的具體證據(jù)，使人們能夠就是否解決組織約束或接受技術妥協(xié)進行知情討論。

定義演變路徑

記錄當前架構和理想架構之間的具體里程碑。這些過渡計劃表明，務實的初始解決方案可以隨著組織成熟度的提高而演變?yōu)楦玫脑O計。清晰的演變路徑防止團隊永久性地滿足于次優(yōu)架構，同時為改進提供現(xiàn)實的時間表。這種方法將“我們希望我們能構建 X，但我們被困在 Y”轉變?yōu)椤?我們現(xiàn)在正在構建 Y，以下是我們?nèi)绾芜_到 X”。

結 論

采用整體工程的組織能夠以可預測的方式控制通常使技術項目脫軌的力量。團隊不是對“不可預見”的延誤和架構漂移做出反應，而是可以預測和計劃那些不可避免地影響技術結果的組織約束。

整體工程將工程團隊從組織功能失調(diào)的被動受害者轉變?yōu)橄到y(tǒng)改進的積極伙伴。當團隊明確組織力量并同時處理技術和人的因素時，他們創(chuàng)建了可持續(xù)的解決方案，這些解決方案在組織約束中茁壯成長，同時隨著時間的推移逐漸改進這些約束。

另一種選擇是可預測的：項目延誤、架構漂移和技術解決方案的持續(xù)循環(huán)，這些解決方案在紙面上有效，但在組織現(xiàn)實中卻以失敗告終。

Holistic Engineering: Organic Problem Solving for Complex Evolving Systems(https://www.infoq.com/articles/holistic-engineering-organic-problem-solving-complex-systems/)

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉載。