在 Shift 會議上，F(xiàn)lightcontrol 的 Brandon Bayer 提出，你可以通過讓另外 10 個人提升 10% 的生產力，來成為一個 10 倍開發(fā)者。

翻譯自 7 Principles and 10 Tactics to Make You a 10x Developer 。

圖片來自 Shutterstock

我們都聽說過 10 倍工程師。不管是真是假， 10 倍工程師被認為比普通同行生產力高 10 倍。互聯(lián)網上充滿了如何成為 10 倍工程師的建議，其中大多數(shù)包括如何提高你的專業(yè)知識或心態(tài)的提示。

Flightcontrol 的 Brandon Bayer 在邁阿密 Shift 會議上發(fā)表了“ 10 種改進你交付軟件的方式”的演講，提供了一個有點不同的視角。他的論點是，你可以通過讓其他 10 個人的生產力提高 10% 來成為一個 10 倍開發(fā)者。

Bayer 分享了 7 個總體原則和 10 種策略來實現(xiàn)這一目標。

這7個原則是：

原則 1 ：速度

開發(fā)者都癡迷于速度。如果他們找到一個比原來快 10 毫秒的工具，他們都會想重寫整個應用來使用它。但是當涉及到部署代碼的頻率時，他們往往會更加謹慎。他們總是更愿意明天或者下周再部署，這樣今天就不用加班去修復可能出現(xiàn)的問題了。

對于部署來說，速度就是安全，小步快跑就是速度。

交付速度有巨大的復利效應。如果你的部署花幾個小時，你就會非常確保沒有 bug ，因為如果你在部署上線后馬上發(fā)現(xiàn)嚴重 bug ，然后你又需要等幾個小時你的修復才能上線。

軟件生命周期的每個部分都要追求速度：

• 快速反饋循環(huán)

• 快速構建

• 快速測試

• 快速部署

• 快速修復

• 快速回滾

原則 2 ：可靠性

你的系統(tǒng)必須可依賴。不穩(wěn)定的 CI/CD 問題是這個宇宙中最可怕的事情之一。不惜一切代價避免不穩(wěn)定性。

原則 3 ：可重現(xiàn)性

為了構建和維護復雜的系統(tǒng)，我們需要知道如果我們做 X ，每次都得到 Y 。如果一次你做 X 得到 Y ，而另一次卻得到 Z ，你就會對系統(tǒng)失去全部信心。

使用腳本和代碼來控制你所做的一切，而不是手動點擊、手動命令等。

原則 4 ：平靜的輪崗

平靜的輪崗很重要，因為人們通?？梢栽诠ぷ魅粘惺軌毫?，但是如果這種壓力侵入到他們生活的其他方面，那就是他們開始更新簡歷的時候了。

原則 5 ：易于調試

每個人都會引起 bug 。即使是高級工程師，即使測試覆蓋率 100% 。你會把 bug 部署到生產環(huán)境，所以你必須準備好修復生產環(huán)境的 bug 。如果調試很困難、部署修復很慢，那會拖慢你，因為你會增加冗長的 QA 流程，等你意識到的時候，你的部署頻率可能只有每幾周一次。

但是即使有大量的 QA ，你仍然會有生產環(huán)境的 bug 。生產環(huán)境是找到所有 bug 的唯一可靠的方式。所以我們的系統(tǒng)必須易于調試。

原則 6 ：自助基礎設施和部署

做基礎設施和代碼部署的傳統(tǒng)方式是，你有兩個獨立的團隊，開發(fā)和運維。如果開發(fā)需要新的數(shù)據(jù)庫，他們會給運維提交工單。如果需要新的服務，也提交工單給運維。需要部署代碼?也提交工單給運維。

這種方式往往導致開發(fā)者被阻塞并等待運維去處理某個工單，開發(fā)者不監(jiān)控基礎設施，也不了解他們的代碼是否快或慢，高效或低效。

作為一個行業(yè)，我們發(fā)現(xiàn)讓開發(fā)者自己部署和運行自己的代碼要好很多。

這更高效，開發(fā)者受阻塞更少，溝通開銷更小，開發(fā)者也從真實世界中得到更多他們代碼性能的反饋。

原則 7 ：周五部署

健康的工程組織每天部署多次，包括周五。

如果你害怕在周五部署，很可能是因為：

• 你的部署不夠可靠。

• 你的部署很慢。

• 你沒有好的監(jiān)控和報警。

• 你的應用難以調試。

• 你沒有測試。

這些都是你必須解決的問題。

Bayer 然后分享了 10 種實用策略，可以用來成為 10 倍開發(fā)者：

1. 解耦部署和發(fā)布

從根本上說，改變生產環(huán)境代碼有兩種可能的操作：部署和發(fā)布。發(fā)布是指以有意義的方式改變用戶體驗的過程。部署是指構建、測試和將更改推送到生產軟件的過程。傳統(tǒng)流程是你在分支上改變代碼，當準備好時，合并并部署。一旦部署，用戶就會看到新代碼。

但是今天的現(xiàn)代工程組織使用特性標志。什么是特性標志?它允許你在舊代碼旁邊編寫新代碼，然后根據(jù)運行時的特性標志，你的應用決定運行舊代碼還是新代碼。這是巨大的改進。

記住，速度是關鍵原則之一。將部署與發(fā)布分離可以加快兩者的速度，因為工程師可以在產品管理準備好發(fā)布之前，在代碼準備就緒時就部署。

它也加快了發(fā)布速度，因為現(xiàn)在你可以立即發(fā)布一個特性。并且無需部署就可以立即回滾一個特性。產品經理可以按照自己的時間表進行發(fā)布。

然后，更高級的事情也成為可能，比如漸進式發(fā)布，其中你為某個百分比的用戶啟用特性標志。因此，你可以從 5% 開始，如果一切正常，然后增加到 10% 、 20% 等。這是推出更改的最佳方式，因為如果有問題，只有一部分用戶會遇到問題，而不是全部用戶。

與長期特性分支相比，特性標志要優(yōu)越得多。你會有更少的合并沖突、更少的陳舊代碼、更好的團隊動力、更好的團隊士氣和與真實用戶測試東西的更大靈活性。

2. 持續(xù)部署（CD）

部署是工程組織的心跳。就像人的心臟一樣，你希望有穩(wěn)定的心跳節(jié)奏。有了這穩(wěn)定的部署節(jié)奏，你就有了動力。動力對組織來說就是生命。

隨著動力的到來，你也具備了將代碼盡可能快地在編寫后交付到生產的效率。

你想要盡可能頻繁地部署，每天多次。每個提交都應該被部署。小的、可理解的更改意味著你擁有可調試和可理解的部署。

編寫代碼的工程師應該合并自己的拉取請求，然后監(jiān)控生產中是否有任何意外問題。特性標志是此的先決條件，因為它允許你的團隊持續(xù)交付小的更改，而不是擁有長期的特性分支。

3. 設置通知

確保你為以下內容設置了通知：

• 構建失敗

• 部署失敗

• 服務停機時間

• 不健康的服務器

• 意外錯誤

• 不尋常的流量

• 第三方服務狀態(tài)

許多第三方服務有可以在 Slack 訂閱狀態(tài)頁面。

這個好處相對明顯，但是它確實需要至少一些努力來設置通知，所以這是許多團隊可以快速獲益的地方。

而且如果你已經有了通知和報警，你應該審核它們，并問自己這三個問題：

• 它們有用嗎?

• 你是否收到太多誤報，以至于你開始忽略它們了?

• 是否應該為某些事項新增報警?

4. 優(yōu)化部署速度

你的目標是讓團隊擁有 15 分鐘或更短的部署時間。

明顯長于此會明顯痛苦。但是明顯快于此可能需要比價值更多的工作，這取決于你的情況。

有幾種方法可以提高部署速度：

a. 跟蹤和測量你當前的部署時間

你需要了解起點，以及哪些過程花費了很長時間。這些是你要著力優(yōu)化的地方。

b. 加速依賴安裝

這個步驟通常是部署中最長的部分之一，所以它可以是一個不錯的第一步。

1. 如果使用 JavaScript，切換到 pnpM 。它是 npm 和 Yarn 的直接替代品，具有顯著的性能和緩存改進。

2. 緩存整個安裝步驟。

使用你的構建系統(tǒng)完全緩存這個步驟，所以如果你的依賴沒改變，這個步驟甚至不會運行。

Docker 示例：

Nixpacks 示例：

c. 提高構建速度

主要的方法是切換到更快的打包工具。

如果使用 create-react-app 和 webpack ，可以切換到 Vite ，它要快得多。

如果使用 nextjs，升級到最新版本，并確保你沒有?.babelrc?文件。這會使用 SWC (Speedy Web Compiler)?而不是 Babel ，會快很多。

如果你喜歡靠近前沿，可以在 next dev 中傳 --turbo 標志使用 Turbopack ，但它目前只能用于開發(fā)，還不能用于生產構建。

d. 設置構建緩存

如果使用 Docker ，有幾件事可以做。

優(yōu)化構建層。使用多階段構建。設置遠程緩存。

Docker 在本地默認會緩存，而且很快，但在 CI 中你沒有永久的機器。所以你需要自己設置緩存。參考 Docker 文檔。

e. 未來緩存

如果你想要真正冒險，以好壞參半的方式，對 JavaScript 項目，還有另一種風格的緩存可以給你一些重大收益。未來緩存的工作原理是在你的整個團隊和 CI 之間共享一個緩存。

這意味著如果你在本地構建了一個提交，然后將該提交推送到 CI 。CI 構建將只是下載你做的緩存構建，并在幾秒內完成。

或者，如果你團隊中的其他人已經構建了一個提交，然后你在本地運行構建，它同樣會下載緩存，在幾秒內完成，而不是從頭再構建一次。

5. 用預覽環(huán)境替代暫存環(huán)境

預覽環(huán)境是與拉取請求生命周期相關的臨時環(huán)境。當你打開一個拉取請求時，基礎設施可以為該 PR 自動配置環(huán)境。

這使利益相關者可以輕松地在類生產環(huán)境中查看更改。然后當拉取請求被合并或關閉時，其環(huán)境將被自動清理。

它們是特性標志的配套。較大的更改應該使用特性標志，并且通常會有多個 PR 。但是對于小的更改，預覽環(huán)境通常比為其管理特性標志更簡單。

與長期的暫存環(huán)境相比，預覽環(huán)境通常是一個更好的替代，因為暫存環(huán)境無論是否需要都一直在運行。而且你必須合并 PR 才能驗證更改。

6. 基礎設施即代碼

希望你已經具有了自動化部署，但你可能還沒有基礎設施自動化。沒有基礎設施即代碼(IaC)，你通常通過點擊儀表盤來定義你的基礎設施配置。

以 IaC 的形式為你的基礎設施配置帶來自動化，具有巨大的好處：

• 可重復性 / 可重現(xiàn)性

• 一致性和標準化 - 可預測性

• 版本控制

• 協(xié)作和審查

7. 平臺工程

在很久以前，你需要在數(shù)據(jù)中心架設自己的服務器?；A設施的抽象級別非常低。然后出現(xiàn)了亞馬遜網絡服務(AWS)，引入了云和提高了抽象級別。但對于普通開發(fā)者來說，它仍然太低了。

這導致了 Heroku 的誕生，全世界的開發(fā)者都為此歡呼雀躍。但這種興奮并不持久，因為運維人員并不高興。事實證明， Heroku 這樣的抽象在大公司是無法擴展的。

所以運維接手，在 AWS 和 Heroku 之間試驗了一件新事物，即 IaC 和 Terraform。這非常有效，但開發(fā)者又不高興了。

此外，公司領導層希望提高運營效率，一種方法是為開發(fā)者提供自助基礎設施，于是我們開始創(chuàng)建內部平臺，以提供更好的開發(fā)者體驗。通過這種方式，業(yè)界找到了一種同時讓運維和開發(fā)雙方滿意的方法。這就是所謂的平臺工程。

現(xiàn)在許多公司都在構建某種內部開發(fā)者平臺，它可以更像是一個內部 Heroku，也可以只是 Terraform。

三個關鍵概念是：

• 它部署到你自己的 AWS/GCP 帳戶。

• 自助基礎設施具有良好的開發(fā)者體驗。

• 運維可以規(guī)定和自定義底層原語。三個主要工具是 Backstage、Humanitec 和 Flightcontrol 。

8. 團隊協(xié)作

• 小團隊( 2 至 6 人， 4 人最佳)

• 整個團隊一次只在一個項目上協(xié)作

• 開工會議(深入討論如何構建)

• 將項目分解成小任務(通常在開工會議上)

• 并行處理子任務

• 小型 PR ，每天至少一個

• 快速審查/不要成為阻礙

• 自我解除阻塞 - 如果沒有人審查，合并你自己的安全 PR

9. 基于主線的開發(fā)

不要拉取請求，直接提交到主分支。這稱為基于主線的開發(fā)。

想象它像一個自助餐廳。你的托盤是主分支。當你的漢堡做好時，放到托盤上。薯條準備好時，也放到托盤上。奶昔倒好后，也放到托盤上。一旦托盤裝滿，就有人叫你的號。

基于主線的開發(fā)就是這樣工作的。每個特性在準備就緒時直接進入主分支。子任務還是整個項目無關緊要，因為它們都是完全獨立工作和可部署的。

如果直接提交到主分支對你來說太激進，那么第二好的做法是短期分支。PR 不應該超過一天。對于一個項目，你應該有許多簡短的 PR ，便于他人快速審查并易于合并。這就是如何獲得動力。

10. 飲食健康并鍛煉

我們都需要這個提醒，整天彎腰盯著電腦。一定要照顧好自己。