想像一下，您的任務是在您正在開發的產品中實現一項重要的新功能。這就是您一直在等待的機會 - 每個人都會看到您是多麼出色的 10 倍開發人員！你打開一個你想要嘗試的最酷的新庫和設計模式的列表，然後直接進入它，完整的“地下室”模式。一週後，你勝利地出現並提出了你完美的拉取請求！
但是，團隊中的高級開發人員立即拒絕了 - 「太複雜了，你應該簡單地使用庫 X 並重用 Y。」。什麼！？顯然，他們不明白你的解決方案有多天才，很快，你就會看到關於你的 PR 的 100 條評論以及接下來幾天的重構。
如果有一種方法可以在實施一切之前了解 X 和 Y 就好了。是的，它就是 RFC！
我們將透過關於在 Wasp 中實現身份驗證的 RFC 的範例來了解它。 Wasp 是一個建置在 React、Node.js 和 Prisma 之上的全棧框架，提供了大量開箱即用的功能這是建置和部署應用程式的最快方法。它還附帶一個免費的 GPT 支援的程式碼庫產生器 MAGE，已用於建立超過 30,000 個應用程式。
讓我們深入了解一下！
支持我們！ 🙏⭐️
如果您覺得這篇文章有幫助，請考慮在 Github 上給我們一顆星！我們在 Wasp 所做的一切都是開源的，您的支援幫助我們使 Web 開發變得更容易，並激勵我們撰寫更多這樣的文章。
那麼，什麼是 RFC？
RFC 代表 Request For Comments，簡單地表示 「提議更改程式碼庫以解決特定問題的文件。」。 其主要目的是在實施開始之前找到解決問題的最佳方法。 RFC 最初由開源社群採用，但如今，它們幾乎被用於任何類型的開發者組織。
您在業界可能會遇到此類文件的其他名稱，例如 TDD（技術設計文件）或 SDD（軟體設計文件）。有些人會爭論它們之間的區別，但我們不會。
有趣的事實：RFC 是由 IETF（網路工程任務組）發明的，該組織是我們今天使用的一些最重要的網路標準和協議背後的工程組織！不算太寒酸吧？
什麼時候該寫 RFC，什麼時候可以跳過？
那麼，為什麼要費勁去寫你最終將要編碼的內容，而不是節省時間並簡單地去做呢？ 如果您正在處理錯誤或相對簡單的功能，非常清楚必須做什麼並且不會影響專案結構，那麼就不需要 RFC - 啟動 IDE 並開始破解！
但是，如果您要引入一個全新的概念（例如，引入基於角色的權限系統）或更改專案的架構（例如，新增對執行後台作業的支援），那麼您可能需要在輸入「git」之前退一步checkout -b my-new-feature` 並深入到那個甜蜜的編碼區域。
綜上所述，有時很難確定是否應該編寫該 RFC。也許這是一個更突出的功能，但你以前做過類似的事情，並且你已經在頭腦中規劃好了一切，而且幾乎沒有任何疑問。為了解決這個問題，我喜歡使用以下一個簡單的啟發式方法：是否有不只一種明顯的方法來實現此功能？我們是否必須選擇一個新的庫/服務？ 如果這兩個問題的答案都是“否”，那麼您可能不需要 RFC。否則，需要進行討論，而 RFC 是解決問題的方法。做吧。
這對我有什麼好處？
我們已經確定瞭如何決定「何時」編寫 RFC，但這也是您應該這樣做的「原因」：
-
你將整理你的想法並變得清晰。如果您決定編寫 RFC，則表示您正在處理一個不平凡的開放式問題。把事情寫下來將有助於提煉你的想法並客觀地看待它們。
-
與剛開始編碼相比，你會學到更多。你會給自己空間去探索不同的方法，常常會發現一些你原本沒有想到的東西。
-
您將眾包團隊的知識。 透過向您的團隊尋求回饋（因此請求評論），您將全面了解您正在解決的問題並填補任何剩餘的空白。
-
您將增進團隊對程式碼庫的理解。 透過在 RFC 上進行協作，團隊中的每個人都會了解您正在做什麼以及最終是如何做到的。這意味著下次有人必須接觸那部分程式碼時，他們將需要問你更少的問題（===更多不間斷的程式碼時間！）。
-
公關審查將會更順利。還記得本文開頭的情況嗎？當你的 PR 因為「太複雜」而被拒絕時？這是因為審閱者忽略了上下文，並且您在沒有獲得團隊其他成員事先支持的情況下進行了相當大的更改。透過先編寫 RFC，您將永遠不會再遇到這種情況。
-
您的文件已經完成了 50%！ 需要明確的是，RFC 不是最終文件，您不能簡單地指出它，但您可以重複使用很多內容 - 圖像、圖表、段落等。
哇，這聽起來太棒了，我現在就想提出一個新功能，這樣我就可以為其編寫 RFC！開個玩笑，首先瀏覽 RFC 會讓編碼部分變得更加有趣 - 你確切地知道你需要做什麼，並且你不需要質疑你的方法以及建立 PR 後將如何接收它。
好吧，好吧，我被賣了！那麼，我該如何寫一篇呢？
很高興你問了！使用了許多不同的格式，或多或少是正式的，但我更喜歡保持簡單。我們在 Wasp 編寫的 RFC 不遵循嚴格的格式，但有一些共同的部分：
-
元資料 - 標題、日期、審稿人等…
-
問題/目標 - 你要解決什麼
-
建議的解決方案（或更多）
-
實施概述
-
評論/開放式問題
這幾乎就是它的要點！其中每一個都可以進一步細分和細化，但這是您可以開始的基本輪廓。
元資料 ⌗
這是非常不言自明的 - 您可能想要追蹤有關 RFC 的一些基本資訊 - 狀態、建立日期等。
一些模板還明確列出了審查者以及他們對RFC 的「批准」狀態- 我們沒有它，因為我們是一個溝通速度很快的小團隊，但對於不是每個人都認識每個人的大型團隊來說，它可以很方便，並且您希望有更多的流程（例如，在指導初級開發人員時）。
問題🤔
這就是事情變得有趣的地方。 您對問題或需要實現的目標/功能以及為什麼需要這樣做的定義越好，以下所有步驟就會越容易。因此，即使在開始編寫 RFC 之前，這也是值得投資的事情 - 確保與所有相關方（例如產品所有者、其他開發人員，甚至用戶）進行交談，以加深您對要解決的問題的理解。
透過這樣做，您也很可能獲得有關可能解決方案的初步提示和指示，並對您所處的問題空間有一個粗略的認識。
以下是上面範例中的一些提示：
-
從高級摘要開始 - 這樣，讀者可以快速決定這是否與他們相關以及是否應該繼續閱讀。
-
提供一些背景 - 解釋一下世界的現狀。這可以是單一句子或整個章節，這取決於目標受眾。
-
清楚地陳述問題/目標 - 解釋為什麼會出現問題並將其與用戶/公司的痛苦聯繫起來，以便動機明確。
-
如果可能的話，提供額外的細節 - 圖表、程式碼範例… → 任何可以幫助讀者更快到達「頓悟」時刻的內容。使用可折疊部分的額外要點是，RFC 的中心部分保持可消化的長度。
如果您完成了所有這些，那麼您已經踏上了通往優秀 RFC 的道路！由於明確定義問題至關重要，所以不要害怕加入更多問題並進一步分解問題。
非目標🛑
這是“問題”的子部分，有時非常有價值。在此程式碼庫變更中編寫我們不想要或不會做的事情可以幫助設定期望並更好地定義其範圍。
例如，如果我們正在努力為我們的應用程式加入基於角色的身份驗證系統，人們可能會認為我們還將為其建立某種管理面板來管理使用者和新增/刪除角色。透過明確聲明不會完成（並簡要解釋原因 - 不需要，這會花費太長時間，...），審查者將更好地理解您的目標是什麼，並且您將跳過不必要的討論。
解決方案與實作🛠️
一旦我們知道我們想做什麼，我們就必須找出最好的方法！您可能已經在“問題”部分暗示了可能的解決方案，但現在是更深入研究的時候了 - 研究不同的方法，評估它們的優缺點，並概述它們如何適合現有系統。
這一部分可能是最自由的形式 - 因為它很大程度上取決於您正在做的事情的性質，所以在這裡施加許多限制是沒有意義的。您可能希望停留在更高的水平，例如係統架構，或者您可能需要深入研究程式碼並開始編寫您需要的部分程式碼。因此，我沒有一個確切的格式供您遵循，而是一組指南：
寫偽程式碼
RFC 的目的是傳達想法和原則，而不是編譯和涵蓋所有邊緣情況的生產級程式碼。隨意發明/想像/草繪任何您需要的東西（例如，想像您已經有一個發送電子郵件的功能並使用它，即使您沒有），並且不要用實現細節來妨礙您自己或讀者（除非這正是RFC 的內容）。
最好從較高的級別開始，然後當您意識到需要它或其中一位審閱者建議時再深入。
了解其他人是如何做到的
根據您正在開發的產品類型，您發現這一點的方式可能會有所不同，但幾乎總是有一種方法可以做到這一點。如果您正在開發像 Wasp 這樣的開源工具，您可以簡單地查看其他流行的解決方案（也是開源的）並了解它們是如何做到的它。如果您正在開發 SaaS，並且需要弄清楚是否使用 cookie 還是 JWT 進行身份驗證，您可能有一些朋友以前這樣做過，您可以詢問他們。最後，只需 Google/GPT 即可。
為什麼這麼有幫助？ 原因是它讓您（和審閱者）對您的解決方案充滿信心。如果其他人以這種方式成功做到了，這可能是一個有前途的方向。它還可能幫助您發現以前沒有想到的方法，或者作為您可以建置的基礎。當然，永遠不要認為任何事情都是理所當然的，並考慮到您情況的具體需要，而一定要利用他人的知識和專業知識。
留下未完成的事情並保持骯髒
RFC 的要點是「C」部分，因此協作（是的，我知道它實際上代表「comments」）。這不是一個你必須獲得滿分並且不問任何問題的測試 - 如果發生這種情況，你可能一開始就不應該編寫 RFC。
解決問題需要團隊的努力，而你只是第一個嘗試解決問題並推動事情向前發展的人。您的任務是盡可能合理地奠定基礎（完善問題，探索解決問題的多種方法，辨識發現的新子問題），以便審閱者可以快速掌握狀態並提供有效的反饋，指導需要的地方最多。
RFC 的主要工作是確定最重要的問題並將審閱者的注意力引導到這些問題上，而不是解決它們。
您正在編寫的 RFC 應該被視為一個討論區和一個正在進行的工作，而不是一件在展示在觀眾面前之前必須完善的藝術品。
評論和開放式問題 🎯
在文件的最後一部分中，您可以總結主要思想並突出顯示最大的未決問題。在瀏覽所有內容之後，提醒讀者他的注意力在哪裡最有價值可能會有所幫助。
現在我知道何時以及如何寫 RFC！您有任何我可以用作起點的模板嗎？
當然！如前所述，我們的格式非常輕量級，但請隨意查看我們用作示例的 RFC 獲得靈感。您的公司也可能已經有他們推薦的現成範本。
以下是您可以使用和/或適應您的需求的一些內容：
-
您有推薦的範本嗎？我很高興將其列在這裡！
我應該使用什麼工具來寫 RFC？有這麼多選擇！
您使用的確切工具可能是 RFC 中最不重要的部分，但它仍然很重要，因為它圍繞它設置了工作流程。如果您的公司已經選擇了一種工具，那麼當然要堅持使用。如果沒有，以下是我遇到的最常見的選擇，以及快速評論：
-
Google 文件 - 經典選擇。超級容易對文件的任何部分進行評論，這是最重要的功能。
-
概念 - 也非常適合協作，此外還提供一些 Markdown 元件，例如可折疊和表格，這可以使您的 RFC 更具可讀性。
-
Github 問題/PR - 有時會使用它，特別是對於 OSS 專案。缺點是很難對文件的特定部分進行註釋（只能對整行進行註釋），而且插入圖表也相當笨拙。優點是所有內容（程式碼和 RFC）都保留在同一個平台上
我們目前使用 Notion，但以上任何一個都可以是不錯的選擇。
概括
正如在 RFC 末尾編寫摘要是最佳實踐一樣，我們也會在這裡做同樣的事情！這篇文章比我預期的要長，但是有很多東西要提到 - 我希望你會發現它有用！
最後，能夠清楚地表達你的想法，提出問題，並根據團隊的反饋客觀地分析可能的解決方案，這將幫助你開發正確的東西，這是最終的生產力黑客。
這就是您成為真正的 10 倍工程師的方法。感謝您的閱讀，下次再見！
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式