譯者 | 布加迪

審校 | 孫淑娟

公司在迅速擴展規模、招兵買馬，有可能公司創辦時有效的方法將不再有效。員工們如何交流？如何解決技術債務？一位工程師做出的選擇影響眾多人，所以現在是時候制定戰略，以確保更龐大的員工隊伍協同工作。

GitHub工程副總裁Rachel Potvin在她領導的團隊規模擴大至三倍（達到500人）后解決了許多擴展難題！以下就是其經驗之談。

1.處理技術債務，保持士氣高昂

如果工程師因技術債務而一再遇到同樣的阻力，他們的士氣就會低落。因此，發布新功能很重要，但公司的投資組合健康也很重要，這時候就需要處理技術債務

2.為分散式工作創建流程

分散式（fan-out）工作是當你決定完成某件事時——這也許是大規模的基于代碼的演變，以清理一些技術債務；這并非僅僅一個團隊就能完成的事，而是許多不同的團隊都必須齊心協力才行。

過去是這樣：某個部門的工程師有一個好主意，他們會在GitHub內部寫一篇討論帖子或團隊帖子，說‘嘿，我意識到我們使用的這個API/技術不好。我們應該重構并刪除它，看看這是我的合并請求（PR），我從我的項目中刪除了它。現在大家盡管這么做。”你也許知道，只有少數工程師時，讓有影響力的人完成這樣的事情可能奏效，但我們的規模很龐大。現在我們是一家跨國公司，員工遍布全球各地——GitHub的工程副總裁Rachel Potvin說。

在過去，一位有影響力的開發人員可能希望修改代碼以解決技術債務，為此將PR重構作為項目的一個方面，并要求其他人采取如出一轍的做法。但在像GitHub這么龐大的公司，不是每個人都相互認識，很可能最終變成了只做了一半的重構。而我們都清楚，唯一比需要重構的代碼更糟糕的是重構了一半的代碼！但這并不意味著不應該開始處理技術債務和重構，而是說需要有條不紊地進行。您需要統一決定：

• 擬議的分散式項目的范圍是什么？
• 要花多少錢？
• 有什么好處？

以這種方式比較所有潛在的分散式項目，并精選出每個季度開展的少數幾個項目，目的是完成幾個有影響力的項目。每個選出來的分散式項目都予以適當的跟蹤（由技術項目經理和項目經理負責跟蹤），確保該項目切實帶來顯著的成效。GitHub最近開展的一個此類分散式流程是清理單體應用程序（monolith）中的功能標志（feature flag）。眾所周知，功能標志是一種出色的部署工具，但如果太多的功能標志停留時間過長，就會影響代碼可讀性。15年來，GitHub積累了始終打開的功能標志、從未打開的功能標志，以及為一些特定企業客戶而不是為其他客戶部署的功能標志。沒有客戶會喜歡使用GitHub未充分意識到的定制的功能標志！

GitHub處理這個分散式流程的方法是，為每個項目統一配備一群干勁十足的人，這群人心里想“是的，我們確實很想做這件事。我們想完成這件事。這對每個人都有好處。”該團隊調查了每個功能標志圖，以確定誰擁有它、是否可以安全地刪除。GitHub以這種方式在產品方面取得了重大進展。

3.使用設計指導簡化設計審核

隨著工程部門不斷擴大、日趨成熟，需要明確的路徑和設計指導是另一個有待解決的問題。構建新服務的團隊如何知道要使用哪些構建模塊或語言？或者如何設計代碼的架構，好讓代碼能與另一個團隊對單體應用程序所做的工作很好地兼容？

GitHub不僅層次分明的設計審核體系，還日益致力于明確的路徑，這樣工程師就可以專注于所做的新穎工作，并擁有可依賴的基礎設施，不必操心太多。

說到設計審核，您應該權衡工作量與變更的重要性——并非所有事情都需要記錄完備的設計，但應仔細審核和溝通對工程技術會有重大持久影響的變更。

GitHub還有一個首席委員會（Principal Council），由公司最資深的技術個人貢獻者（IC）和副總裁組成，負責審核最重要的設計決策。首席委員會制定整體架構路線圖，為諸團隊簡化設計指導。委員會可能會說，如果項目滿足條件X，這里應該用Go構建，但如果滿足條件Y，應該在單體應用程序中構建。當然，選擇一種編程語言只是表層，所以首席委員會現正在制定更廣泛的未來架構計劃。

4.利用委員會會議做出一致的技術決策

GitHub希望團隊對于所做的新穎工作積極主動地做出決策。但也需要有一種方法讓任何工程技術人員可以將他們認為無法在自己團隊內解決的重大問題（比如更重大的基礎架構問題、投資問題或工程技術問題）交給高層，讓高層進行全面深入的討論，并給予反饋。

這就是委員會會議上發生的事情。任何工程技術人員都可以提交GitHub問題單，從事平臺各部分工作的人展開討論，他們能夠就一些方面做出決定，比如“我想開始使用這種數據庫技術。我不確定這在GitHub企業服務器（我們的本地服務器部署環境）或我們未來基于云的SaaS產品上會如何運行。這是我能做的事情嗎？受到什么制約？”

當然，GitHub建立在GitHub平臺上，并使用GitHub平臺。所以GitHub使用GitHub Discussions甚至代碼存儲庫進行交流。有時，他們會編寫Google Docs，因為Google Docs非常適合迭代式注釋和工作。但是如果某個代碼庫被鎖定，他們將其引入到存儲庫。

5.分配DRI以實現高效決策

大型組織中出現的另一個問題是，有時決策花費的時間太長。不僅應該有正常逐級上報的流程，每個團隊還需要一個DRI（直接負責人）。DRI能夠做出決定，進行迭代，并確保團隊有合理的節奏，在不妨礙自身的情況下推進工作。

6.制作DevSat調查表

DevSat調查表是一項開發人員生產力和幸福感調查。GitHub DevSat調查側重于內部GitHub開發人員體驗。他們需要回答一系列問題，比如：

• 什么導致開發人員的工作困難？
• 用戶對我們的工具和系統的滿意度如何？
• 要完成的哪些工作面臨最大的困難？
• 團隊心理安全
• 團隊決策
• 隨叫隨到的體驗
• 完成的計劃外工作有多少？完成的計劃內工作有多少？

GitHub利用這些回復向經理和領導層提供匿名報告，這有助于為他們的投資決策提供依據，從而真正提升決策能力。這方面的一個例子是GitHub在DevSat中詢問在GitHub內部使用Codespaces所遇到的任何困難。他們從內部開發人員那里獲得了Codespaces團隊可以利用的大量信息，因為人們往往在參與匿名調查時提供更多的信息，因此GitHub可以根據看似更重要的內容發現真正的趨勢。這最終還有助于使他們的外部產品變得更好！

7.結語

擴展規模并非易事。如果您是一家有多個團隊的大公司，就需要在如何開展工作方面確立流程。沒有人可以了解所有正在做的工作的細節，因此您需要有效的開發實踐和溝通策略。我們在本文中討論了在公司規模大得多的情況下，如何做出設計決策、處理技術債務以及與開發人員保持聯系。

原文鏈接：https://hackernoon.com/how-to-overcome-scaling-challenges-in-technical-architecture