第14章 軟件架構不是接力運動

更敏捷的軟件團隊很可能由除了一項核心專長，還具備更多綜合知識和經驗的通才組成。理想狀況下，這些跨領域的團隊成員會一起工作，運作和交付一個軟件項目，承擔從收集需求和架構到編碼和部署的所有事情。盡管很多軟件團隊都朝自組織的方向努力，然而現實中他們往往更大、更混亂，而且由專才構成。因此，這些團隊往往需要，也確實有一個人擔任技術領導。

解決方案架構師

有很多人，特別是在大型組織里，自稱“解決方案架構師”或“技術架構師”。他們設計好了軟件，為自己的方案編寫文檔，然后扔給一個單獨的開發團隊。這個方案一旦“完成”，架構師就會去別的地方重復這個過程，甚至往往對開發團隊的進展看都不看一眼。如果再加上“不是我發明的”綜合癥，結果往往就是接手的團隊不會對這個方案負責，最初創建的“架構”變得脫離現實。

我曾見過不少這樣的架構師，我主持過的一次面試就是這種軟件開發方法的縮影。在照例拋出“談談你的角色和最近的項目”這個問題之后，我就清楚地知道，面前這個（為一個大型“藍籌”咨詢公司工作的）架構師的所作所為，就是給一個項目創建軟件架構，寫好文檔然后到其他地方重復這個過程。他告訴我，給出“方案”后就很少或不再參與項目，然后我問他怎么知道他的軟件架構是管用的。他被這個問題困住了，最后他聲明這是“實現細節”。他自信地認為自己的軟件架構是正確的，如果開發團隊沒有讓它工作，那是他們的問題。在我看來，這種說法簡直荒謬，這讓他看起來像頭蠢驢。他的方法也就是AaaS……“架構即服務”！

要有人負責大局

不同于典型的軟件開發者，軟件架構角色需要通才。這肯定是在軟件項目起航階段掌舵的角色，包括管理非功能性需求，整理出對上下文和環境因素敏感的軟件設計。但也要不斷地轉向，因為你選擇的航線可能需要在途中調整。畢竟，敏捷方法已經向我們展示了，不一定預先就有（或需要）所有的信息。

創建一個最初的愿景，交流，并在整個軟件開發的生命周期中潛在地演化它，這些對一個成功的軟件項目是必需的。單是這個原因，讓某人來創建這個愿景，然后讓另一個團隊去（試著）交付，就毫無意義。當這種事情發生時，初始的設計方案本質上就成了在架構師和開發團隊中傳遞的指揮棒。這很低效，甚至無效，文檔交換也意味著很多與創建愿景相關的決策上下文也丟失了。祈禱開發團隊永遠不需要問任何關于設計或其意圖的問題吧！

真正的自組織團隊不會有這樣的問題，但大多數團隊還沒有成熟到那個程度。在整個交付中，要有人負責大局，同時為保證軟件順利交付承擔責任。軟件開發不是接力運動，順利交付也不是“實現細節”。