譯者 | 布加迪

審校 | 孫淑娟

公司在迅速擴(kuò)展規(guī)模、招兵買馬，有可能公司創(chuàng)辦時(shí)有效的方法將不再有效。員工們?nèi)绾谓涣鳎咳绾谓鉀Q技術(shù)債務(wù)？一位工程師做出的選擇影響眾多人，所以現(xiàn)在是時(shí)候制定戰(zhàn)略，以確保更龐大的員工隊(duì)伍協(xié)同工作。

GitHub工程副總裁Rachel Potvin在她領(lǐng)導(dǎo)的團(tuán)隊(duì)規(guī)模擴(kuò)大至三倍（達(dá)到500人）后解決了許多擴(kuò)展難題！以下就是其經(jīng)驗(yàn)之談。

1.處理技術(shù)債務(wù)，保持士氣高昂

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

2.為分散式工作創(chuàng)建流程

分散式（fan-out）工作是當(dāng)你決定完成某件事時(shí)——這也許是大規(guī)模的基于代碼的演變，以清理一些技術(shù)債務(wù)；這并非僅僅一個(gè)團(tuán)隊(duì)就能完成的事，而是許多不同的團(tuán)隊(duì)都必須齊心協(xié)力才行。

過去是這樣：某個(gè)部門的工程師有一個(gè)好主意，他們會(huì)在GitHub內(nèi)部寫一篇討論帖子或團(tuán)隊(duì)帖子，說‘嘿，我意識(shí)到我們使用的這個(gè)API/技術(shù)不好。我們應(yīng)該重構(gòu)并刪除它，看看這是我的合并請求（PR），我從我的項(xiàng)目中刪除了它?，F(xiàn)在大家盡管這么做?！蹦阋苍S知道，只有少數(shù)工程師時(shí)，讓有影響力的人完成這樣的事情可能奏效，但我們的規(guī)模很龐大。現(xiàn)在我們是一家跨國公司，員工遍布全球各地——GitHub的工程副總裁Rachel Potvin說。

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

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

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

GitHub處理這個(gè)分散式流程的方法是，為每個(gè)項(xiàng)目統(tǒng)一配備一群干勁十足的人，這群人心里想“是的，我們確實(shí)很想做這件事。我們想完成這件事。這對每個(gè)人都有好處?！痹搱F(tuán)隊(duì)調(diào)查了每個(gè)功能標(biāo)志圖，以確定誰擁有它、是否可以安全地刪除。GitHub以這種方式在產(chǎn)品方面取得了重大進(jìn)展。

3.使用設(shè)計(jì)指導(dǎo)簡化設(shè)計(jì)審核

隨著工程部門不斷擴(kuò)大、日趨成熟，需要明確的路徑和設(shè)計(jì)指導(dǎo)是另一個(gè)有待解決的問題。構(gòu)建新服務(wù)的團(tuán)隊(duì)如何知道要使用哪些構(gòu)建模塊或語言？或者如何設(shè)計(jì)代碼的架構(gòu)，好讓代碼能與另一個(gè)團(tuán)隊(duì)對單體應(yīng)用程序所做的工作很好地兼容？

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

說到設(shè)計(jì)審核，您應(yīng)該權(quán)衡工作量與變更的重要性——并非所有事情都需要記錄完備的設(shè)計(jì)，但應(yīng)仔細(xì)審核和溝通對工程技術(shù)會(huì)有重大持久影響的變更。

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

4.利用委員會(huì)會(huì)議做出一致的技術(shù)決策

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

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

當(dāng)然，GitHub建立在GitHub平臺(tái)上，并使用GitHub平臺(tái)。所以GitHub使用GitHub Discussions甚至代碼存儲(chǔ)庫進(jìn)行交流。有時(shí)，他們會(huì)編寫Google Docs，因?yàn)镚oogle Docs非常適合迭代式注釋和工作。但是如果某個(gè)代碼庫被鎖定，他們將其引入到存儲(chǔ)庫。

5.分配DRI以實(shí)現(xiàn)高效決策

大型組織中出現(xiàn)的另一個(gè)問題是，有時(shí)決策花費(fèi)的時(shí)間太長。不僅應(yīng)該有正常逐級(jí)上報(bào)的流程，每個(gè)團(tuán)隊(duì)還需要一個(gè)DRI（直接負(fù)責(zé)人）。DRI能夠做出決定，進(jìn)行迭代，并確保團(tuán)隊(duì)有合理的節(jié)奏，在不妨礙自身的情況下推進(jìn)工作。

6.制作DevSat調(diào)查表

DevSat調(diào)查表是一項(xiàng)開發(fā)人員生產(chǎn)力和幸福感調(diào)查。GitHub DevSat調(diào)查側(cè)重于內(nèi)部GitHub開發(fā)人員體驗(yàn)。他們需要回答一系列問題，比如：

• 什么導(dǎo)致開發(fā)人員的工作困難？
• 用戶對我們的工具和系統(tǒng)的滿意度如何？
• 要完成的哪些工作面臨最大的困難？
• 團(tuán)隊(duì)心理安全
• 團(tuán)隊(duì)決策
• 隨叫隨到的體驗(yàn)
• 完成的計(jì)劃外工作有多少？完成的計(jì)劃內(nèi)工作有多少？

GitHub利用這些回復(fù)向經(jīng)理和領(lǐng)導(dǎo)層提供匿名報(bào)告，這有助于為他們的投資決策提供依據(jù)，從而真正提升決策能力。這方面的一個(gè)例子是GitHub在DevSat中詢問在GitHub內(nèi)部使用Codespaces所遇到的任何困難。他們從內(nèi)部開發(fā)人員那里獲得了Codespaces團(tuán)隊(duì)可以利用的大量信息，因?yàn)槿藗兺趨⑴c匿名調(diào)查時(shí)提供更多的信息，因此GitHub可以根據(jù)看似更重要的內(nèi)容發(fā)現(xiàn)真正的趨勢。這最終還有助于使他們的外部產(chǎn)品變得更好！

7.結(jié)語

擴(kuò)展規(guī)模并非易事。如果您是一家有多個(gè)團(tuán)隊(duì)的大公司，就需要在如何開展工作方面確立流程。沒有人可以了解所有正在做的工作的細(xì)節(jié)，因此您需要有效的開發(fā)實(shí)踐和溝通策略。我們在本文中討論了在公司規(guī)模大得多的情況下，如何做出設(shè)計(jì)決策、處理技術(shù)債務(wù)以及與開發(fā)人員保持聯(lián)系。

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