作者 | Vanessa Formicola

譯者 | 張衛(wèi)濱

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

使無意識變得有意識

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

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

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

整體工程

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

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

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

外部力量

• 世界事件

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

• 技術(shù)趨勢

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

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

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

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

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

內(nèi)部力量

• 組織

• 技術(shù)

• 產(chǎn)品

• 人員

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

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

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

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

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

產(chǎn)品

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

人員

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

工程

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

將整體工程付諸實踐

識別組織力量

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

使隱性知識顯性化

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

有組織地社會化信息

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

設(shè)計兩種架構(gòu)

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

定義演變路徑

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

結(jié) 論

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

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

另一種選擇是可預(yù)測的：項目延誤、架構(gòu)漂移和技術(shù)解決方案的持續(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)許可禁止轉(zhuǎn)載。