除了創(chuàng)建技術(shù)架構(gòu)和做出架構(gòu)決策外，軟件架構(gòu)師還負責在架構(gòu)的實現(xiàn)過程中指導開發(fā)團隊手报。優(yōu)秀的軟件架構(gòu)師能夠創(chuàng)建高效的開發(fā)團隊蚯舱，這些團隊緊密合作來解決問題并產(chǎn)出成功的解決方案。雖然這聽起來很容易理解掩蛤，但我們已經(jīng)見過太多架構(gòu)師忽視開發(fā)團隊枉昏，在孤立的環(huán)境中工作來創(chuàng)建架構(gòu)。然后揍鸟，這個架構(gòu)被移交給開發(fā)團隊兄裂，然后開發(fā)團隊在如何正確地實現(xiàn)架構(gòu)中掙扎句旱。能夠使團隊高效是有效率的和成功的軟件架構(gòu)師區(qū)別于其他軟件架構(gòu)師的方法之一。在本章中晰奖，我們將介紹架構(gòu)師可以利用的一些基本技術(shù)谈撒，以使開發(fā)團隊更高效。
團隊邊界
根據(jù)我們的經(jīng)驗匾南，軟件架構(gòu)師可以極大地影響開發(fā)團隊的成敗啃匿。感覺被排除在圈子之外或與軟件架構(gòu)師（以及架構(gòu)）疏遠的團隊通常沒有得到適當級別的指導和關(guān)于系統(tǒng)上各種約束的恰如其分的知識，因此不能正確地實現(xiàn)架構(gòu)蛆楞。
軟件架構(gòu)師的角色之一是創(chuàng)建和溝通約束溯乒，即開發(fā)人員可以在其中實現(xiàn)架構(gòu)的框框。架構(gòu)師可以創(chuàng)建過度嚴緊豹爹、過度寬松或恰到好處的邊界裆悄。這些邊界如圖22-1所示。過緊或過松的邊界會直接影響到團隊成功實現(xiàn)架構(gòu)的能力臂聋。
創(chuàng)建過多約束的架構(gòu)師在開發(fā)團隊周圍形成一個嚴緊的盒子光稼，從而阻止對許多有效實現(xiàn)系統(tǒng)所必需的工具、庫和實踐的訪問逻住。這會導致團隊內(nèi)部的挫敗感仁连，通常會導致開發(fā)人員離開項目去尋找更快樂空执、更健康的環(huán)境只嚣。
相反的情況也可能發(fā)生叹侄。軟件架構(gòu)師可以創(chuàng)建過于寬松的約束（或者根本沒有約束），將所有重要的架構(gòu)決策留給開發(fā)團隊扒秸。在這種與嚴密約束同樣糟糕的場景中播演，團隊本質(zhì)上扮演著軟件架構(gòu)師的角色，在沒有適當級別的指導的情況下執(zhí)行概念驗證并為設(shè)計決策進行斗爭伴奥，從而導致低效写烤、混亂和挫敗。
一個有效的軟件架構(gòu)師努力提供正確級別的指導和約束拾徙，以便團隊擁有正確的工具和庫來有效地實現(xiàn)架構(gòu)洲炊。
架構(gòu)師個性
有三種基本類型的架構(gòu)師個性：控制狂架構(gòu)師（圖22-2）、扶手椅架構(gòu)師（圖22-3）和高效的架構(gòu)師（圖22-5）尼啡。每一種個性都與上一節(jié)關(guān)于團隊邊界的討論中所討論的特定邊界類型相匹配：控制狂的架構(gòu)師會建立緊密的邊界暂衡，扶手椅架構(gòu)師會建立松散的邊界，而高效的架構(gòu)師會建立恰到好處的邊界崖瞭。
控制狂
控制狂架構(gòu)師試圖控制軟件開發(fā)過程的每一個細節(jié)狂巢。一個控制狂架構(gòu)師所做的每一個決定通常都過于細粒度和低級，導致開發(fā)團隊受到太多的約束书聚。
控制狂架構(gòu)師產(chǎn)生了上一節(jié)討論的嚴密邊界唧领。一個控制狂架構(gòu)師可能會限制開發(fā)團隊下載任何有用的開源或第三方庫藻雌，而是堅持讓開發(fā)團隊使用語言API從頭開始編寫所有東西≌陡觯控制狂架構(gòu)師還可能對命名約定胯杭、類設(shè)計、方法長度等進行嚴格約束萨驶。他們甚至可能會為開發(fā)團隊編寫偽代碼歉摧。從本質(zhì)上說，控制狂架構(gòu)師從開發(fā)人員那里竊取編程的藝術(shù)腔呜，從而導致團隊沮喪情緒產(chǎn)生和對架構(gòu)師缺乏尊重。
成為一個控制狂架構(gòu)師是非常容易的再悼，特別是當從開發(fā)人員過渡到架構(gòu)師時核畴。架構(gòu)師的角色是創(chuàng)建應(yīng)用的構(gòu)建塊（組件）并確定這些組件之間的交互。開發(fā)人員在這項工作中的角色是獲取這些組件冲九，并確定如何使用類圖和設(shè)計模式實現(xiàn)它們谤草。然而，在從開發(fā)人員到架構(gòu)師的轉(zhuǎn)變中莺奸，他們還是會希望去創(chuàng)建類圖和設(shè)計模式丑孩，因為這是新上任的架構(gòu)師先前的角色。
例如灭贷，假設(shè)架構(gòu)師創(chuàng)建一個組件（架構(gòu)的構(gòu)建塊）來管理系統(tǒng)中的引用數(shù)據(jù)温学。引用數(shù)據(jù)包括網(wǎng)站上使用的靜態(tài)名稱-值對數(shù)據(jù)，以及產(chǎn)品代碼和倉庫代碼（整個系統(tǒng)中使用的靜態(tài)數(shù)據(jù)）等內(nèi)容甚疟。架構(gòu)師的角色是識別組件（在本例中是引用管理器）仗岖，確定該組件的核心操作集（例如GetData、SetData览妖、ReloadCache轧拄、NotifyOnUpdate等等），以及哪些組件需要與引用管理器交互讽膏￠莸纾控制狂架構(gòu)師可能會認為實現(xiàn)這個組件的最佳方式是通過一個并行加載程序模式來實現(xiàn)，該模式利用一個內(nèi)部緩存府树，并為該緩存提供一個特定的數(shù)據(jù)結(jié)構(gòu)俐末。雖然這可能是一個有效的設(shè)計，但它不是唯一的設(shè)計鹅搪。更重要的是，提出引用管理器的內(nèi)部設(shè)計不再是架構(gòu)師的角色遭铺，而是開發(fā)人員的角色丽柿。
我們將在“多大的控制恢准？中討論，有時架構(gòu)師需要扮演控制狂的角色甫题，這取決于項目的復雜性和團隊的技能水平馁筐。然而，在大多數(shù)情況下坠非，控制狂架構(gòu)師擾亂了開發(fā)團隊敏沉，沒有提供正確級別的指導，妨礙了開發(fā)炎码，并且在通過架構(gòu)的實現(xiàn)來領(lǐng)導團隊方面沒有效率盟迟。
扶手椅架構(gòu)師
扶手椅架構(gòu)師是那種在很長一段時間內(nèi)（如果有的話）都沒有編寫過代碼的架構(gòu)師，在創(chuàng)建架構(gòu)時也沒有考慮到實現(xiàn)細節(jié)潦闲。他們通常與開發(fā)團隊隔絕開來攒菠，從不四處走動，或者在初始架構(gòu)圖完成后從一個項目轉(zhuǎn)移到另一個項目歉闰。
在某些情況下辖众，扶手椅架構(gòu)師確實是在技術(shù)或業(yè)務(wù)領(lǐng)域方面超出了他們的能力，因此不可能從技術(shù)或業(yè)務(wù)問題的角度來領(lǐng)導或指導團隊和敬。例如凹炸，開發(fā)人員做什么？當然昼弟，他們是編碼的啤它。編寫程序代碼真的很難偽造；要么一個開發(fā)人員編寫了軟件代碼私杜，要么沒有編寫蚕键。然而，架構(gòu)師是做什么的衰粹？沒人知道锣光！大多數(shù)架構(gòu)師都會畫很多線和框，但是架構(gòu)師應(yīng)該在這些圖中描述得有多詳細呢铝耻？這里有一個關(guān)于架構(gòu)的骯臟的小秘密誊爹，很容易偽裝成一個架構(gòu)師！
假設(shè)一個扶手椅架構(gòu)師在某些方面超出了他們的能力瓢捉，或者沒有時間為股票交易系統(tǒng)設(shè)計一個合適的解決方案频丘。在這種情況下，架構(gòu)圖可能類似于圖22-4所示泡态。這種架構(gòu)沒有什么問題搂漠，只是層次太高以至于對任何人都沒有任何用處。
扶手椅架構(gòu)師在開發(fā)團隊周圍創(chuàng)建松散的邊界某弦，如前一節(jié)所討論的桐汤。在這個場景中而克，開發(fā)團隊最終扮演架構(gòu)師的角色，基本上完成架構(gòu)師應(yīng)該做的工作怔毛。團隊的速度和生產(chǎn)力因此受到影響员萍，團隊對系統(tǒng)應(yīng)該如何工作感到困惑。
就像控制狂架構(gòu)師一樣拣度，成為一個扶手椅建筑師太容易了碎绎。一個架構(gòu)師可能會成為一個扶手椅架構(gòu)師的最大跡象是沒有足夠的時間與實現(xiàn)該架構(gòu)的開發(fā)團隊在一起（或者選擇不與開發(fā)團隊在一起）。開發(fā)團隊需要架構(gòu)師的支持和指導抗果，他們需要架構(gòu)師在技術(shù)或業(yè)務(wù)相關(guān)的問題出現(xiàn)時回答這些問題筋帖。扶手椅架構(gòu)師的其他標志如下：
- 不完全了解業(yè)務(wù)領(lǐng)域、業(yè)務(wù)問題或使用的技術(shù)
- 沒有足夠的軟件開發(fā)的實踐經(jīng)驗
- 不考慮與架構(gòu)解決方案的實現(xiàn)相關(guān)的影響
在某些情況下冤馏，架構(gòu)師并沒有打算成為一個扶手椅架構(gòu)師幕随，而是通過在項目或開發(fā)團隊之間延展得過于淺薄、與技術(shù)或業(yè)務(wù)領(lǐng)域缺乏接觸而“發(fā)生”的宿接。架構(gòu)師可以通過更多地參與項目中使用的技術(shù)并理解業(yè)務(wù)問題和業(yè)務(wù)領(lǐng)域來避免這種個性。
高效的架構(gòu)師
一個高效的軟件架構(gòu)師會在團隊中建立適當?shù)募s束和邊界辕录，確保團隊成員能夠很好地協(xié)同工作睦霎，并對團隊有正確的指導。高效的架構(gòu)師還確保團隊擁有正確和適當?shù)墓ぞ吆图夹g(shù)走诞。此外副女，他們還消除了阻礙開發(fā)團隊實現(xiàn)目標的所有障礙。
雖然這聽起來很顯然也很容易蚣旱，但事實并非如此碑幅。在開發(fā)團隊中成為高效的領(lǐng)導者是一門藝術(shù)。成為一名高效的軟件架構(gòu)師需要與團隊緊密合作塞绿，并獲得團隊的尊重沟涨。在本書的后面幾章中，我們將探討成為一名高效的軟件架構(gòu)師的其他方法异吻。但是現(xiàn)在裹赴，我們將介紹一些指導方針來了解一個高效的架構(gòu)師應(yīng)該對開發(fā)團隊施加多大的控制。
多大的控制诀浪？
成為一個高效的軟件架構(gòu)師需要知道對一個給定的開發(fā)團隊施加多大的控制棋返。這一概念被稱為彈性領(lǐng)導，并被作家兼顧問Roy Osherove廣為宣揚雷猪。我們將稍微偏離Osherove在這一領(lǐng)域所做的工作睛竣，并關(guān)注軟件架構(gòu)的特定因素。了解一個高效的軟件架構(gòu)師在多大程度上應(yīng)該是一個控制狂還是一個扶手椅架構(gòu)師求摇，主要涉及五個因素射沟。這些因素還決定了一個軟件架構(gòu)師可以同時管理多少個團隊（或項目）：
團隊熟悉度
團隊成員相互了解程度如何殊者？他們以前合作過一個項目嗎？一般來說躏惋，團隊成員相互了解得越好幽污，就越不需要控制，因為團隊成員開始變得自組織簿姨。相反距误，團隊成員越新，就越需要控制來促進團隊成員之間的協(xié)作扁位，減少團隊內(nèi)部的派系准潭。
團隊規(guī)模
團隊有多大？（我們認為同一個團隊中有12個以上的開發(fā)人員是一個大團隊域仇，4個或更少的開發(fā)人員是一個小團隊刑然。）團隊越大，就越需要控制暇务。團隊越小泼掠，需要的控制就越少。這將在“團隊告警標志”中詳細討論垦细。
總體經(jīng)驗
有多少團隊成員是資深的择镇？有多少是初級的？它是由初級和高級開發(fā)人員組成的混合團隊嗎括改？他們對技術(shù)和商業(yè)領(lǐng)域了解多少腻豌？擁有大量初級開發(fā)人員的團隊需要更多的控制和指導，而擁有更多高級開發(fā)人員的團隊需要更少的控制嘱能。在后一種情況下吝梅，架構(gòu)師從導師的角色轉(zhuǎn)變?yōu)閰f(xié)調(diào)者的角色。
項目復雜度
這個項目是非常復雜還是只是一個簡單的網(wǎng)站惹骂？高度復雜的項目需要架構(gòu)師花更多的時間在團隊上苏携，并協(xié)助解決出現(xiàn)的問題，因此需要對團隊進行更多的控制析苫。相對簡單的項目很直接兜叨，因此不需要太多的控制。
項目工期
項目是短期（兩個月）衩侥、長期（兩年）還是平均工期（六個月）国旷？工期越短，需要的控制就越少茫死；反之跪但，項目越長，需要的控制就越多。
雖然大多數(shù)因素在多或少的控制方面是有意義的屡久，但項目工期因素似乎沒有意義忆首。如前表所示，項目持續(xù)時間越短被环，需要的控制就越少糙及；項目持續(xù)時間越長，就越需要控制筛欢。直覺上浸锨，這似乎是相反的，但事實并非如此版姑≈眩考慮一個兩個月的快速項目。兩個月的時間對于確認需求剥险、實驗聪蘸、開發(fā)代碼、測試每個場景以及發(fā)布到生產(chǎn)環(huán)境中來說并不多表制。在這種情況下健爬，架構(gòu)師應(yīng)該更像一個扶手椅架構(gòu)師，因為開發(fā)團隊已經(jīng)有了強烈的緊迫感么介。一個控制狂架構(gòu)師可能會妨礙項目的進行浑劳，并可能會使項目延誤。相反夭拌，設(shè)想一個為期兩年的項目。在這種情況下衷咽，開發(fā)人員很放松鸽扁，不考慮緊迫性，可能會計劃休假和花很長時間來吃午餐镶骗。架構(gòu)師需要更多的控制桶现，以確保項目能夠及時進行，并首先完成復雜的任務(wù)鼎姊。
在大多數(shù)項目中骡和，通常利用這些因素來確定項目開始時的控制水平；但隨著系統(tǒng)的不斷發(fā)展相寇，控制水平也在不斷變化慰于。因此，我們建議在項目的整個生命周期中不斷分析這些因素唤衫，以確定對開發(fā)團隊施加多少控制婆赠。
為了說明如何使用每一個因素來確定架構(gòu)師在團隊中應(yīng)該施加的控制級別，假設(shè)每個因素的固定比例為20分佳励。分值減少更偏向成為扶手椅架構(gòu)師（較少控制和參與）休里，而分值增加則更偏向成為控制狂架構(gòu)師（更多的控制和參與）蛆挫。該級別說明如圖22-6所示。
當然妙黍，應(yīng)用這種級別并不準確悴侵，但它確實有助于確定對團隊施加的相應(yīng)控制。例如拭嫁，考慮表22-1和圖22-7中所示的項目場景可免。如表所示，這些因素指向控制狂（+20）或扶手椅架構(gòu)師（-20）噩凹。這些因素加起來累積得分為-60巴元，這表明架構(gòu)師應(yīng)該扮演更多的扶手椅架構(gòu)師的角色，而不是妨礙團隊的發(fā)展驮宴。
在場景1中逮刨，所有這些因素都被考慮在內(nèi)，以證明一個高效的軟件架構(gòu)師最初應(yīng)該扮演協(xié)調(diào)者的角色堵泽，而不是過多地參與與團隊的日常交互修己。架構(gòu)師需要回答問題并確保團隊走上正軌，但在大多數(shù)情況下架構(gòu)師都應(yīng)該放手迎罗，讓經(jīng)驗豐富的團隊做他們最了解的事情：快速開發(fā)軟件睬愤。
考慮表22-2中描述的另一種場景，如圖22-8所示纹安，其中團隊成員彼此熟悉尤辱，但團隊很大（12個團隊成員），并且大部分由初級（無經(jīng)驗）開發(fā)人員組成厢岂。這個項目比較復雜并歷時六個月光督。在這種情況下，累計得分為+20塔粒，這表明高效的架構(gòu)師應(yīng)該參與團隊內(nèi)的日辰峤瑁活動，并承擔指導和指導角色卒茬，但不至于擾亂團隊船老。
很難將這些因素具體客觀化，因為其中一些因素（比如整個團隊的經(jīng)驗）可能比其他因素更重要圃酵。在這些情況下柳畔，可以很容易地對指標進行加權(quán)或修改，以適應(yīng)任何特定的場景或條件郭赐。不管怎樣荸镊，這里要表達的主要信息是，軟件架構(gòu)師對團隊的控制和參與程度因這五個主要因素而不同，并且通過考慮這些因素躬存，架構(gòu)師可以判斷對團隊施加何種控制张惹，以及開發(fā)團隊可以在其中工作的范圍應(yīng)該是什么樣的（嚴密或松散的邊界和約束）。
團隊告警標志
如前一節(jié)所述岭洲，團隊規(guī)模是影響架構(gòu)師應(yīng)該對開發(fā)團隊施加的控制量的因素之一宛逗。團隊越大，就越需要控制盾剩；團隊越小雷激，就越不需要控制。在考慮最有效的開發(fā)團隊規(guī)模時告私，有三個因素起作用：
- 過程損失
?-多元無知
- 責任分散
過程損失屎暇，也被稱為布魯克定律，最初是由弗雷德.布魯克斯在他的書《神話人月》中創(chuàng)造的（Addison-Wesley）驻粟。過程損失的基本思想是根悼，您添加到項目中的人員越多，項目所需的時間就越多蜀撑。如圖22-9所示挤巡，組織潛力由團隊中每個人的集體努力來定義。然而酷麦，對于任何一個團隊來說矿卑，實際生產(chǎn)力總是低于團隊潛力，不同的是團隊的過程損失沃饶。
一個高效的軟件架構(gòu)師將觀察開發(fā)團隊并探索過程損失母廷。過程損失是確定特定項目或工作的合適團隊規(guī)模的一個好因素。過程損失的一個指標是糊肤，在將代碼推送到存儲庫時徘意，經(jīng)常發(fā)生合并沖突。這表明團隊成員可能在互相踩踏轩褐，在相同的代碼上工作。在團隊中尋找并行區(qū)域并讓團隊成員處理應(yīng)用的不同服務(wù)或區(qū)域是避免過程損失的一種方法玖详。每當一個新的團隊成員加入到一個項目中把介，如果沒有創(chuàng)建并行工作流的區(qū)域，一個高效的架構(gòu)師就會質(zhì)疑為什么一個新的團隊成員被添加到團隊中蟋座，并向項目經(jīng)理展示這個額外的人將對團隊產(chǎn)生的負面影響拗踢。
當團隊規(guī)模過大時，多元無知也會發(fā)生向臀。多元無知是指每個人都同意（但私下里反對）一個規(guī)范巢墅，因為他們認為自己遺漏了一些明顯的東西。例如，假設(shè)在一個大型團隊中君纫，大多數(shù)人都同意在兩個遠程服務(wù)之間使用消息傳遞是最好的解決方案驯遇。然而，團隊中的一個人認為這是一個愚蠢的想法蓄髓，因為兩個服務(wù)之間有一個安全的防火墻叉庐。然而，這個人并沒有說出來会喝，而是同意使用消息傳遞（但私下里反對這個想法）陡叠，因為他們擔心自己遺漏了一些明顯的東西，或者擔心如果他們說出來肢执，可能會被視為傻瓜枉阵。在這種情況下，拒絕規(guī)范的人是正確的预茄，消息傳遞將不起作用兴溜，因為兩個遠程服務(wù)之間有一個安全的防火墻。如果他們大聲說出來（并且團隊規(guī)模小一些）反璃，原始的解決方案將受到挑戰(zhàn)昵慌，而使用另一個協(xié)議（比如REST），在這種情況下淮蜈，這將是一個更好的解決方案斋攀。
多元無知的概念因安徒生的丹麥童話故事《皇帝的新衣》而聞名。在故事中梧田，國王確信他的新衣服對任何不配去看到的人都是看不見的淳蔼。他全裸著大搖大擺地走來走去，問所有的人他們喜歡他的新衣服嗎裁眯。所有的臣民鹉梨，害怕被認為是愚蠢或不配，而回應(yīng)國王他的新衣服是最好的東西穿稳。這種愚蠢的行為一直持續(xù)到一個孩子最終向國王喊道他根本沒穿衣服存皂。
一個高效的軟件架構(gòu)師應(yīng)該在任何形式的協(xié)作會議或討論中持續(xù)觀察面部表情和肢體語言，如果他們感覺到多元無知的發(fā)生逢艘，應(yīng)該充當協(xié)調(diào)者的角色旦袋。在這種情況下，高效的架構(gòu)師可能會打斷并詢問該人員他們對所提議的解決方案的看法它改，并且在他們發(fā)言時站在他們一邊并支持他們疤孕。
第三個表明適當團隊規(guī)模的因素稱為責任分散。責任分散是基于這樣一個事實：隨著團隊規(guī)模的增加央拖，它會對溝通產(chǎn)生負面影響祭阀。搞不清誰應(yīng)該為團隊中的哪些事情負責鹉戚，以及事情被落下都是符合團隊規(guī)模過大的跡象。
請看圖22-10中的圖片专控。你觀察到了什么抹凳？
這張照片顯示有人站在一個小鄉(xiāng)村路邊一輛壞了的汽車旁邊。在這種情況下踩官，有多少人會停下來問司機一切是否正常却桶？因為這是一個大概每個人都會路過的小社區(qū)里的一條小道。然而蔗牡，有多少次駕車者被困在一個大城市中心繁忙的高速公路邊上颖系，數(shù)千輛汽車只是開過去，沒有人停下來問是否一切正常辩越？一直都是這樣嘁扼。這是責任分散的一個很好的例子。隨著城市變得越來越繁忙和擁擠黔攒，由于大量的人目睹了這一事件趁啸，人們認為司機已經(jīng)打電話或救援已經(jīng)在路上。然而督惰，在大多數(shù)情況下不傅，救援不在路上，司機被一部壞的或被遺忘的手機卡住赏胚，無法呼叫救援访娶。
一個高效的架構(gòu)師不僅有助于指導開發(fā)團隊完成體系結(jié)構(gòu)的實現(xiàn)，而且還可以確保團隊健康觉阅、快樂崖疤，并共同努力實現(xiàn)一個共同的目標。探索這三個告警標志并幫助糾正它們有助于確保開發(fā)團隊的高效性典勇。
利用檢查表
航空公司的飛行員在每一次飛行中都使用檢查表劫哼，即使是最有經(jīng)驗的資深飛行員。飛行員有起飛割笙、著陸和其他數(shù)千種情況的檢查表权烧，包括常見和不常見的情況。他們使用檢查表是因為一次錯失的飛機設(shè)置（如將襟翼設(shè)置為10度）或程序（如獲得進入終端控制區(qū)的許可）可能意味著安全飛行和災(zāi)難之間的區(qū)別伤溉。
Atul Gawande博士寫過一本名為《檢查清單宣言》（Picador）的優(yōu)秀的書般码，他在書中描述了檢查清單在外科手術(shù)中的作用。Gawande博士對醫(yī)院中葡萄球菌感染率之高表示震驚谈火，于是制定了手術(shù)檢查表來試圖降低這種比率。在這本書中舌涨，他證明了使用檢查表的醫(yī)院的葡萄球菌感染率下降到接近零糯耍，而沒有使用檢查表的對照醫(yī)院的葡萄球菌感染率繼續(xù)上升扔字。
檢查表起作用。他們提供了一個很好的工具温技，確保一切都涵蓋和得到處理革为。如果檢查表這么好，那么為什么軟件開發(fā)行業(yè)不利用它們呢舵鳞？通過個人經(jīng)驗震檩，我們堅信檢查表對開發(fā)團隊的效率有很大的影響。然而蜓堕，對于這一說法有一些警告抛虏。首先，大多數(shù)軟件開發(fā)人員不會駕駛客機或進行心臟手術(shù)套才。換距話說迂猴，軟件開發(fā)人員不需要所有事情都有檢查表。使團隊高效的關(guān)鍵是知道何時使用檢查表背伴，何時不使用沸毁。
考慮圖22-11所示的創(chuàng)建一個新的數(shù)據(jù)庫表的檢查表。
這不是一個檢查表傻寂，而是一套程序步驟息尺，因此不應(yīng)包含在檢查表中。例如疾掰，如果表單尚未提交搂誉，則無法對數(shù)據(jù)庫表進行驗證！任何包含依賴性任務(wù)過程的流程都不應(yīng)該包含在檢查表中个绍。簡單的勒葱、眾所周知的、經(jīng)常執(zhí)行且不會出錯的流程也不需要檢查表巴柿。
可以很好地利用檢查表的流程是那些沒有任何程序順序或依賴任務(wù)的流程凛虽，以及那些容易出錯或經(jīng)常遺漏或跳過步驟的流程。使檢查表有效的關(guān)鍵是不要把所有的事情都列到檢查表上广恢。架構(gòu)師發(fā)現(xiàn)凯旋，事實上，檢查表確實使開發(fā)團隊更加高效钉迷，因此開始將所有內(nèi)容都作為檢查表至非，引發(fā)所謂的收益遞減規(guī)律。架構(gòu)師創(chuàng)建的檢查表越多糠聪，開發(fā)人員使用它們的機會就越小荒椭。創(chuàng)建檢查表的另一個關(guān)鍵成功因素是使其盡可能小，同時仍然捕獲流程中所有必要的步驟舰蟆。開發(fā)人員通常不會遵循太大的檢查表趣惠。尋找可以通過自動化執(zhí)行的項目狸棍，并將其從檢查表中刪除。
提示
不要擔心在檢查表中聲明顯而易見的事情味悄。顯而易見的東西通常會被遺漏或錯過草戈。
我們發(fā)現(xiàn)最有效的三個關(guān)鍵檢查表是開發(fā)人員代碼完成檢查表、單元和功能測試檢查表以及軟件發(fā)布檢查表侍瑟。以下各節(jié)將討論每個檢查表唐片。
霍桑效應(yīng)
向開發(fā)團隊引入檢查表的一個問題是讓開發(fā)人員實際使用它們。對于一些開發(fā)人員來說涨颜，在沒有實際執(zhí)行任務(wù)的情況下费韭，將特定檢查表中的所有項目都標記為已完成是很常見的。
解決這個問題的方法之一是與團隊討論使用檢查表的重要性以及檢查表如何在團隊中發(fā)揮作用咐低。讓團隊成員閱讀Atul Gawande的檢查表宣言揽思，以充分理解檢查表的力量杆故，并確保每個團隊成員理解每個檢查表背后的理由以及為什么使用它久锥。讓開發(fā)人員在檢查表上應(yīng)該和不應(yīng)該列出的內(nèi)容上進行協(xié)作也會有所幫助瓤逼。
當所有其他方法都失敗時蝙昙，架構(gòu)師可以援引所謂的霍桑效應(yīng)瓷们∷芫叮霍桑效應(yīng)本質(zhì)上意味著葡盗，如果人們知道他們被觀察或監(jiān)視审磁，他們的行為就會改變酒来，通常他們會做正確的事情卢未。例如，建筑物內(nèi)和周圍的高可視攝像頭實際上不起作用堰汉，或者沒有真正記錄任何東西（這是非常常見的Ａ缮纭）以及網(wǎng)站監(jiān)控軟件（實際有多少報告會被真正查看？）翘鸭。
霍桑效應(yīng)也可以用來監(jiān)管檢查表的使用滴铅。架構(gòu)師可以讓團隊知道檢查表的使用對團隊的效率至關(guān)重要，因此就乓，所有檢查表都將得到驗證汉匙，以確保實際執(zhí)行了任務(wù)，而實際上架構(gòu)師只是偶爾抽查檢查表的正確性生蚁。通過利用霍桑效應(yīng)噩翠，開發(fā)人員將不太可能跳過項目或?qū)⑵錁擞洖橐淹瓿桑鴮嶋H上任務(wù)并未完成邦投。
開發(fā)人員代碼完成檢查表
開發(fā)人員代碼完成檢查表是一個有效的工具伤锚，尤其是當軟件開發(fā)人員聲明他們已經(jīng)“完成”了代碼時。它對于定義所謂的“完成的定義”也很有用志衣。如果檢查表中的所有內(nèi)容都完成了屯援，那么開發(fā)人員就可以聲稱他們已經(jīng)完成了代碼剂娄。
以下是開發(fā)人員代碼完成檢查表中要包含的一些內(nèi)容：
- 自動化工具中不包括的編碼和格式標準
- 經(jīng)常被忽略的項目（如吸收的異常）
- 項目特定標準
- 特別小組指示或程序
圖22-12展示了一個開發(fā)人員代碼完成檢查表的例子。
注意檢查表中明顯的任務(wù)“運行代碼清理和代碼格式化”和“確保沒有異承海”。有多少次開發(fā)人員匆忙在一天結(jié)束或一次迭代結(jié)束時和二，忘記從IDE運行代碼清理和格式化徘铝？無數(shù)次。在檢查表宣言中惯吕，Gawande發(fā)現(xiàn)了與外科手術(shù)相同的現(xiàn)象——明顯的往往是經(jīng)常被忽略的惕它。
同時注意條目2、3废登、6和7中的項目特定任務(wù)淹魄。雖然這些都是檢查表中的好條目，但架構(gòu)師應(yīng)該經(jīng)常檢查清單堡距，看看是否有任何條目可以自動化或作為代碼驗證檢查器的插件來編寫甲锡。例如，雖然“Include@ServiceEntrypoint on service API class”可能無法進行自動檢查羽戒，但“Verify that only public methods are calling setFailure（）”肯定可以（這是一種使用任何類型的代碼爬蟲工具的直接自動檢查）缤沦。檢查自動化區(qū)域有助于減少檢查表中的規(guī)模和噪音，使其更有效易稠。
單元和功能測試檢查表
也許最有效的檢查表之一是單元和功能測試檢查表缸废。這個檢查表包含了一些軟件開發(fā)人員往往會忘記測試的不尋常的和邊緣的案例測試。每當QA人員發(fā)現(xiàn)基于特定測試用例的代碼有問題時驶社，應(yīng)該將該測試用例添加到此檢查表中企量。
由于可以針對代碼運行的所有類型的測試，這個特定的檢查表通常是最大的檢查表之一亡电。這個檢查表的目的是確保盡可能覆蓋全部的代碼届巩，這樣當開發(fā)人員完成檢查表時，代碼就基本上可以準備部署生產(chǎn)環(huán)境了逊抡。
以下是典型單元和功能測試檢查表中的一些條目：
- 文本和數(shù)字字段中的特殊字符
- 最小值和最大值范圍
- 異常和極端測試用例
- 缺少字段
與開發(fā)人員代碼完成檢查表一樣姆泻，任何可以作為自動測試編寫的項目都應(yīng)該從檢查表中刪除。例如冒嫡，假設(shè)股票交易應(yīng)用程序的檢查表中有一個項目用于測試負股票數(shù)（例如買-1000股蘋果[AAPL]）拇勃。如果此檢查可以通過測試套件中的單元或功能測試自動進行的，則應(yīng)從檢查表中刪除該項孝凌。
開發(fā)人員有時不知道在編寫單元測試時從哪里開始方咆，也不知道要編寫多少個單元測試。此檢查表提供了一種方法蟀架，確保在軟件開發(fā)過程中包含了一般或特定的測試場景瓣赂。在由不同團隊執(zhí)行這些活動的環(huán)境中榆骚，此檢查表還可以有效地彌合開發(fā)人員和測試人員之間的間隙。開發(fā)團隊執(zhí)行完整測試的次數(shù)越多煌集，測試團隊的工作就越容易妓肢，從而使測試團隊能夠?qū)Ｗ⒂跈z查表中未涵蓋的某些業(yè)務(wù)場景。
軟件發(fā)布檢查表
將軟件發(fā)布到生產(chǎn)環(huán)境中可能是軟件開發(fā)生命周期中最容易出錯的地方之一苫纤，因此可以形成一個很好的檢查表碉钠。此檢查表有助于避免失敗的構(gòu)建和失敗的部署，并顯著降低與發(fā)布軟件相關(guān)的風險卷拘。
軟件發(fā)布檢查表通常是檢查表中最不穩(wěn)定的喊废，因為每次部署失敗或出現(xiàn)問題時，它都會不斷更改以解決新的錯誤和情況栗弟。
以下是軟件發(fā)布檢查表中通常包含的一些項目：
- 服務(wù)器或外部配置服務(wù)器中的配置更改
- 添加到項目中的第三方庫（JAR污筷、DLL等）
- 數(shù)據(jù)庫更新和相應(yīng)的數(shù)據(jù)庫遷移腳本
每當構(gòu)建或部署失敗時，架構(gòu)師應(yīng)該分析失敗的根本原因乍赫，并在軟件發(fā)布檢查表中添加相應(yīng)的條目瓣蛀。這樣，該條目將在下一個構(gòu)建或部署中得到驗證雷厂，從而防止該問題再次發(fā)生揪惦。
提供指導
軟件架構(gòu)師還可以通過使用設(shè)計原則來提供指導，從而提高團隊的效率罗侯。這也有助于形成邊界（約束）器腋，如本章第一節(jié)所述，開發(fā)人員可以用來實現(xiàn)架構(gòu)钩杰。有效地傳達這些設(shè)計原則是創(chuàng)建成功團隊的關(guān)鍵之一纫塌。
為了說明這一點，請考慮向開發(fā)團隊提供有關(guān)使用通常稱為分層堆棧（即構(gòu)成應(yīng)用的第三方庫（如JAR文件和dll）集合）的指導讲弄。開發(fā)團隊通常有很多關(guān)于分層堆棧的問題措左，包括他們是否可以自己決定使用各種庫（哪些可以，哪些不可以）避除。
使用此示例怎披，一個高效的軟件架構(gòu)師可以通過首先讓開發(fā)人員回答以下問題來為開發(fā)團隊提供指導：
1、建議的庫和系統(tǒng)內(nèi)現(xiàn)有功能之間是否有重疊瓶摆？
2凉逛、使用建議的庫的理由是什么？
第一個問題引導開發(fā)人員查看現(xiàn)有庫群井，看看新庫提供的功能是否可以通過現(xiàn)有庫或現(xiàn)有功能得到滿足状飞。根據(jù)我們的經(jīng)驗，開發(fā)人員有時會忽略此活動，從而創(chuàng)建大量重復的功能诬辈，特別是在大型團隊的大型項目中酵使。
第二個問題促使開發(fā)人員質(zhì)疑為什么新的庫或功能是真正需要的。在這里焙糟，一個高效的軟件架構(gòu)師會詢問一個技術(shù)理由和一個商業(yè)理由來說明為什么需要額外的庫口渔。這是一種很有效的技巧，可以讓開發(fā)團隊意識到業(yè)務(wù)合理性的需要穿撮。
商業(yè)理由的影響
您的一位作者（Mark）是一個非常復雜的基于Java的項目的首席架構(gòu)師搓劫，擁有一個大型開發(fā)團隊。其中一個團隊成員對Scala編程語言特別著迷混巧，非常想在項目中使用它。這種使用Scala的愿望最終變得如此具有破壞性勤揩，以至于幾個關(guān)鍵的團隊成員通知Mark咧党，他們正計劃離開項目，轉(zhuǎn)向其他“低毒”的環(huán)境陨亡。馬克說服了兩個關(guān)鍵的團隊成員推遲他們的決定傍衡，并與Scala愛好者進行了討論。Mark告訴Scala愛好者负蠕，他將支持在項目中使用Scala蛙埂，但是Scala愛好者必須提供使用Scala的商業(yè)理由，因為這涉及到培訓成本和重寫工作遮糖。Scala的狂熱者欣喜若狂绣的，說他會馬上開始，他離開會場時大喊：“謝謝你欲账，你是最棒的屡江！”
第二天，Scala愛好者走進辦公室赛不，態(tài)度完全變了樣惩嘉。他立刻走近馬克，要求和他談?wù)勌吖省Ｋ麄兌甲哌M了會議室文黎，Scala的狂熱者立刻（謙卑地）說：“謝謝〉罱希” Scala愛好者向Mark解釋說耸峭，他可以想出世界上所有使用Scala的技術(shù)理由，但這些技術(shù)優(yōu)勢在所需的架構(gòu)特征（“ilities”）：成本淋纲、預算和時間方面都沒有任何商業(yè)價值抓艳。事實上，Scala愛好者意識到成本、預算和時間的增加不會帶來任何好處玷或。
意識到自己之前制造了混亂儡首，這位Scala愛好者很快就把自己變成了團隊中最優(yōu)秀、最有幫助的成員之一偏友，這一切都是因為他被要求為自己想要的項目提供一個商業(yè)理由蔬胯。這種對正當性認識的提高不僅使他成為一個更好的軟件開發(fā)人員，而且形成一個更強大位他、更健康的團隊氛濒。
作為后記，兩位關(guān)鍵的開發(fā)人員一直堅持到項目的最后鹅髓。
繼續(xù)以管理分層堆棧為例舞竿，傳達設(shè)計原則的另一種有效技術(shù)是通過圖形化的解釋，說明開發(fā)團隊可以對什么或不能對什么做決定窿冯。圖22-13中的圖示是控制分層堆棧的圖形（以及指南）的示例骗奖。
在圖22-13中，架構(gòu)師將提供每一類第三方庫的內(nèi)容以及指導（設(shè)計原則）的示例醒串，說明開發(fā)人員能和不能做什么（本章第一節(jié)中描述的方框）执桌。
例如，以下是為任何第三方庫定義的三個類別：
特殊用途
這些是用于類似PDF呈現(xiàn)芜赌、條形碼掃描和不需要編寫自定義軟件的情況的特定庫仰挣。
一般用途
這些庫是開發(fā)語言API之上的包裝器，它們包括像Apache Commons和Guava for Java等內(nèi)容缠沈。
框架
這些庫用于持久化（如Hibernate）和控制反轉(zhuǎn)（如Spring）膘壶。換句話說，這些庫構(gòu)成了應(yīng)用程序的整個層或結(jié)構(gòu)洲愤，具有很強的侵入性香椎。
一旦分類好了之后（前面的分類只是一個例子，可以有更多的定義）禽篱，架構(gòu)師便圍繞這個設(shè)計原則創(chuàng)建一個邊界畜伐。請注意，在圖22-13所示的示例中躺率，對于這個特定的應(yīng)用或項目玛界，架構(gòu)師已經(jīng)指定對于特殊用途的庫，開發(fā)人員可以做決定而無需咨詢架構(gòu)師悼吱。但是請注意慎框，對于一般用途，架構(gòu)師已經(jīng)指出后添，開發(fā)人員可以進行重疊分析和論證以提出建議笨枯，但使用該類庫需要架構(gòu)師的批準。最后，對于框架庫馅精，這是架構(gòu)師的決定严嗜。換句話說，開發(fā)團隊甚至不應(yīng)該對這些類型的庫進行分析洲敢；架構(gòu)師已經(jīng)決定對這些類型的庫承擔責任漫玄。
總結(jié)
使開發(fā)團隊高效是一項艱巨的工作。它需要大量的經(jīng)驗和實踐压彭，以及強大的人際交往能力（我們將在本書后續(xù)章節(jié)中討論）睦优。也就是說，本章中描述的關(guān)于彈性領(lǐng)導壮不、利用檢查表和通過有效溝通設(shè)計原則提供指導的簡單技術(shù)實際上是有效的汗盘，并且已經(jīng)證明能夠有效地使開發(fā)團隊更聰明、更有效地工作询一。
有人可能會質(zhì)疑架構(gòu)師在此類活動中的角色隐孽，而不是將使團隊高效的工作分配給開發(fā)經(jīng)理或項目經(jīng)理。我們強烈反對這個前提家凯。軟件架構(gòu)師不僅為團隊提供技術(shù)指導，還領(lǐng)導團隊完成架構(gòu)的實現(xiàn)如失。軟件架構(gòu)師和開發(fā)團隊之間的密切協(xié)作關(guān)系允許架構(gòu)師觀察團隊動態(tài)绊诲，從而促進使團隊更有效的轉(zhuǎn)變。這正是技術(shù)架構(gòu)師與高效軟件架構(gòu)師的區(qū)別所在褪贵。
