896
關於技術問題和解決方案的多方麵觀點
多年來，一些人詢問有關Etsy的建築審查過程的細節。
在這篇文章中，我將重點介紹架構審查工作組在促進技術決策對話方麵的作用。其中一部分實際上隻是關於一般的工作組（職業，缺點，格式等），另一部分則依賴於丹麥·麥金萊（Daniel McKinley）在他的講話中的一般哲學，所以我會考慮閱讀這些然後回到這裏。
基礎：工程決策是一個社會建設的活動
但首先，我們需要從一點基礎理論入手。1985年，比利·沃恩·科恩（現任德克薩斯大學榮譽教授）介紹了我以前寫過的“工程方法”的想法。關鍵的觀點是他的觀察結果表明，工程師的定義不是他們生產的，而是他們的工作方式。他簡潔地描述了工程方法，它說：
“在現有資源範圍內做出最不了解或不確定情況的最佳變化的戰略”
請注意規範性條款最好和不好。
換句話說，工程（作為活動）對問題沒有“正確”的解決方案。除此之外，如果您正在尋找解決問題的正確方法，我建議您在不同的領域工作（如數學）; 工程很可能會讓你失望。
我完全同意這個想法，我會再說一遍，說成功的工程團隊很大程度上是通過對話找到問題的解決方案。我的意思是，他們從事各種形式：
描述他們認為需要解決的問題。這可能或可能不是直接的解釋或描述，所以一個組織通常需要一個來回來來完全掌握它。
生成關於所描述的問題是否需要或多或少完整或窮舉的解決方案的假設。一些問題描述可能真的很狹窄，或者說真的很廣泛，一些問題不一定要全部“解決”，等等。問題會永久存在嗎？
評估解決方案的選項。優缺點都有什麼？需要支持解決方案的團隊能否維持或維護該解決方案？某些解決方案是否有“到期日”？可能的意想不到的後果可能會導致依賴於此解決方案的上遊/下遊係統？
建立對實施給定解決方案的信心。集團如何以積極或消極的方式發揮解決方案的不確定性（以及在什麼方麵）？
等等。
我意識到這應該是顯而易見的，但我將這個觀點納入其中，因為我不斷驚訝，當這個主題是公司選擇使用特定技術（框架，語言，架構等）時，這是多麼的困難，或不。
一旦你可以理解工程決策在社會上構建的概念，那麼你可以理解我相信“架構審查”的設置和設置是至關重要的。
的概念和意圖
當凱蘭和我2010年第一次來到Etsy時，我們製定了一個過程，一個工程師（或一個小組）正在尋求實施新的東西（不同於我們已經在做或正在使用的）將提出他們是試圖解決，為什麼他們認為Etsy的現有解決方案不是理想的解決方案。我們稱之為架構審查。
我們稱這些“新事物”的事情離開了。再次，丹的帖子/談話已經過去了，但基本思想是有成本（其中許多在許多方麵都可以隱藏和驚奇），用於在不考慮全局影響的情況下嚐試解決本地問題的出發可以在組織上
出發可以包括以下內容：
用已經在公司不廣泛使用的語言編寫功能或功能
重新設計功能或功能（即使是已經廣泛使用的語言）
引入了一種尚未使用的模式或架構
使用新的服務器軟件來存儲，緩存或檢索尚未使用的數據
基本上，任何有可能驚奇和挑戰的團隊（最終）破裂的事情
上麵那些子彈很模煳，我相信你注意到了。那麼你怎麼知道什麼時候應該要求架構審查？問你的同事 如果你正在辯論你的事情是否需要一個，那麼你可能會這樣做。
那麼這個建築評估會議呢？真的很簡單 這隻是工程師的一個演示文稿，就他們提出的解決方案尋求反饋，而凱蘭和我會提出問題。會議開放給想參加的公司的任何人。希望許多工程師實際上會參加。這裏的意圖是幫助工程師盡可能徹底地描述他們的問題，通過提出問題，我們可以幫助我們提出他們在思考問題時所做的默認假設。簡而言之，這是一個批判性思考的工作，我們希望工程師想要做到這一點，因為它是理想的提供反饋。
從這個角度來說，這個想法可以從一個想要反饋的工程師的角度來看：
“嘿，大家 - 檢查一下：我相信我必須解決問題X，而且我已經考慮過使用A，B和C來做，但是它們似乎都不是理想的。我想我必須以離開Y為解決方案。請嚐試跟我說這個。“
這種方法導致了上麵提到的對話的一些非常好的提示。提示如：
“可能我甚至不需要解決問題X？”
“我錯過了A，B或C的東西嗎？他們有可能工作得很好嗎？“
“如果我和Y一起去，我們需要做些什麼來確定支持Y作為這種類型問題的解決方案？”
在很高的水平上，我們在早期的這種做法是相當成功的，因為我們能夠讓工程師來到，談論他們所做的判斷和假設，並就他們的理解細節提出問題和建議的問題和潛在的解決方案。即使它開始主要是凱蘭，我提出問題，我們也積極鼓勵他人。慢慢地，他們做到了，它成為了一個真正強大的信心來源的團隊，集體。
做這些審查有一些非常令人驚訝的結果。不止一次，房間裏的某個人會認識到所提出的問題，並且繼承了他們也在與代碼庫的不同部分過去一樣幾乎相同的問題。他們說，有一些微小的變化，它可以解決手頭的問題，而不是重新發明一些新的東西。大！
有一次，工程師走過一個相當複雜的圖表，概述了他們將如何收集，總結，存儲和處理數據以提供新功能。他們的解決方案不僅將新語言納入應用程序的關鍵路徑，而且還向堆棧引入了一個新的（並且在當時相對不成熟的）數據存儲區。來了幾個問題後，很明顯，他們需要的數據已經存在，而且隻有一個SQL查詢和一個cron工作遠離實現新功能。
這些結果並沒有經常發生。但是當他們這樣做的時候，這是相當滿意的。
其他時候，一位工程師會出麵對話，很明顯，從多個角度來看，出發（新的和新穎的建議）似乎是最好的路線。
總的來說，我想說，從早期的架構審查實踐中我們獲得了很多好處。工程師在職業生涯中開始了很好的做法，介紹他們的工作和思考，老員工有機會分享一些他們不會擁有的知識或專長。就像我提到的，有時工程師通過走一條更簡單的路線可以節省大量的時間和頭痛。從領導層麵來看，我對組織關於設計的建設性談判能力的信心增加了。
多視角對話如何演變
但是，有一個問題：當你是首席技術官和高級副總裁時，當你邀請他們來參加會議時，你不會感到驚訝。我經常想知道有沒有問題和意見，因為在房間裏的力量動態不被說。我知道，除非房間中的大量工程師證明了實踐的精神（即創造和支持一個批判性思維對話，旨在幫助工程師，個人和組織），那麼將有一個很好的機會它將成為一種分層次的“美國偶像”風格的判斷小組，嚴肅的政策掌握。
當然，這個想法是，更好的決策來自於人們對提出可能被視為“愚蠢”或“天真”的可能被看到的問題感到放心，並且主持人的聽證會作為評論意見的設計，而不是在評論他們的技能。這意味著設計的起源（當時打算解決什麼問題，當時人們關心的是什麼）可以被記錄下來
組織越多，單個人（甚至CTO或SVP）就越難以維持這種方法，並將工程師帶入建築評估中的假設。
特定類工作組的開始
因此，開發了一個建築評估工作組或“ARWG”。主要思想是，如果沒有高級工程領導層，這樣一個團隊可以保持這種做法，為會議帶來專製風格，並不斷地為行為所需的行為提供模型，以鼓勵需要離開的多個視角。
一個小組成立，4或5人。原始的工程師將來自產品，基礎設施和運營團隊，但是其他團隊的工程師則在之後加入。在某些時候，一些成員旋轉進出。
該團隊的章程基本相同，在高層次上，正如我們打算如何早期的建築評論一樣：提供一個穩定和受歡迎的環境，工程師可以公開地描述他們如何在解決問題時解決潛在的新穎和新穎的技術和模式。這個環境需要支持組織其他部門的關於權衡，假設，約束，壓力，維護以及離職的責任的問題和意見。最後，記錄如何確定出發的決定，因此存在一種人類學的工件來為未來的決策和對話提供信息。
你可能會在想：“但決定的時間和地點 何去何從？”
ARWG的作用不是作出決定。
ARWG的作用是創造和維持可以進行對話的條件，同時在既定時期內就可能遇到的問題和解決方案提出許多觀點，然後便利圍繞決定進行討論。
在這一點上，我想在“對話”和“討論”之間進行語義上的區分，我將從之前的博客文章中提到，在那裏我提出了“對話：思考的藝術”
對話是探索選擇的本質。選擇是選擇替代品。對話是關於喚起洞察力，這是一種對我們的知識進行重新排序的方法，特別是人們把握的假設。
討論就是作出決定。不同於對話，尋求開放的可能性和看到新的選擇，討論尋求關閉和完成。這個詞決定的意思是“通過削減他們解決困難。”其根源字麵意思是“謀殺的替代品。”
ARWG的作用是首先促進對話，然後討論。關鍵思想是在離開（問題和解決方案）之前通過“開放和好奇的心態”輕鬆地散發光，然後進入選項的評估階段。對話旨在首先引起注意事項的細節（並假設必要性），然後隻能討論不同選項的優點。
根據我的經驗，當一個架構審查引起了一個問題的注意，並從多個角度提出了解決方案，決策變得不那麼有爭議。當一個廣泛群體的決定似乎是顯而易見的（“問題：我們（或者我們不應該）是否對關鍵數據庫進行備份？決定：是的）”決策的做法幾乎消失了。
隻有當一個決定沒有普遍的協議（或者即使有必要的決定）時，知道如何，誰以及何時作出決定變得重要。架構審查的想法是以足夠的方式將問題空間和提出的離職思想暴露給對話，盡可能地減少對它們的混淆。關於這個話題的較少的混淆可以幫助減少解決方案的不確定性和/或焦慮。
現在，這裏存在一些陷阱：
工程師（無論是呈現還是作為觀眾參與）都需要了解架構審查的目的是開發更好的結果。而已。它不是展示他們的技術實力。
如果沒有什麼隻關注“但是誰做出最終決定”呢，這就是一個信號，即批評和反饋（再一次是關於問題和解決方案）並不是真正的需要，而工程師則認為他們的偏離想法應該從任何理由得到通過批評。問這些原因是有用的。
沒有強烈和持續地強調“批評代碼，而不是編碼器”，這種方法可以（並且將會保證它）在多個方麵發揮防禦性的作用。首先，正在尋找有關出發點的反饋意見的工程師需要將其視為作為成熟工程師的角色的一部分。
有時候，您可能會發現一位工程師對於他們針對特定問題開發的解決方案非常的熱心，他們開始將重點放在演示文稿上，作為“銷售點”，而不僅僅是表達了獲得反饋的願望。好消息是，檢測發生的時間相對來說比較直觀。壞消息是，審查的目的並不普遍。
其他時候，您可能會找到一組負責開發解決方案的工程師，這些解決方案與負責維護解決方案的團隊不同。這個權威責任“雙重約束”確實揭示了自己甚至是最小的組織。在這種情況下，恭喜！建築審查能夠將潛在的大象帶入桌麵。
在幾乎每一種情況下，無論結構如何，建築審查的結果都將永遠在人們心中留下深刻的懷疑，就是離開而不是一個很好的決定。這些揮之不去的陰影是正常的。
歡迎來到工程部門，解決問題歸結為“ 在可用資源範圍內對知識不足或不確定的情況進行最佳變化的戰略”。
雖然我不能指出，采用這種方法是在技術離職時總是做出最好的決定的氣密方式，但我可以這麼說：沒有從技術上的不同群體獲得多個觀點，比如這種方法，你是所有這些都是保證不太理想的決定。
所以下一次你確定一個特定的新方式做得更好，組織的其他部分應該落後於你的想法，我會告訴你的：
“很好，聽起來你有一個假設！我們要做一個架構審查。如果您認為它是一個明顯的解決方案，組織的其餘部分應該很容易得出相同的結論，這將使實現和維護更容易。如果有一些不明顯的缺點，我們至少有機會挑逗出來！“
最後更新：2017-08-14 23:02:12