編寫良好的提取要求

提取要求就像存放區的生命週期。它們可以保持一切 健康和運動。本頁將詳細說明如何建立完整且易於審查的 PR，以便提高 PR 遭到合併的可能性。

你可以採取下列步驟，盡可能建立最佳的 PR 內容。

  1. 通訊
  2. 開始設定
  3. 保持精簡
  4. 保持清潔
  5. 測試變更
  6. 通訊 (pt2)

溝通交流

在開始編寫程式碼之前，建議您先與核心團隊溝通，讓他們瞭解您有興趣的內容。

如果你對某個問題有興趣，請留言告訴我們，你會開始處理該問題。這可確保我們沒有多位使用者同時負責同一件事接著會有團隊成員回覆 確認身分就是你本人

如果您的想法不在問題涵蓋範圍內，請先撰寫相關說明再開始作業。這讓團隊有機會在開始建構「之前」討論如何最有效地建構變更，這樣您長期下來就能節省工作量。

進行設定

如果您是第一次為 Blockly 或區塊範例做出貢獻，請先從開發設定頁面開始。

保持精簡

請盡量縮小變更範圍並保持專注。我們寧願審查數個較小的 PR，而不是審查一個巨型公關。這裡有個良好的經驗法則：

  • 修正一個問題。請勿嘗試一次處理多個問題，
  • 限制範圍。公關通常應花費少於 8 小時 (視您您對程式碼集的熟悉程度而定)。
  • 使用修訂版本。如果 PR 覺得有點困難，請使用 Git 修訂版本將變更分成邏輯群組。

保持清潔

為何需要關注程式碼樣式？我們致力於長期運作，而一致的風格 有助於簡化維護工作樣式表示變數的命名方式，但同時也涵蓋程式碼結構、撰寫註解等。我們會盡可能使用 lint 等工具自動進行樣式檢查。

除了 Lint 之外，也請遵循下列指南：

測試變更

制定 PR 前，您應一律測試變更是否正常運作，這樣之後就不必回頭修正項目。以下是測試不同專案類別的建議：

  • 外掛程式：編寫涵蓋變更的自動化 Mocha 測試。
  • 如果是範例：手動測試所有展示的功能。
  • 針對程式碼研究室：在乾淨的環境中執行整個教學課程，並測試您提供的任何程式碼範例。

溝通交流

這是建立 PR 的最後一個重要部分：撰寫摘要。

撰寫出色的公關摘要有助其他開發人員審查您的變更，並藉此加快接受速度！

摘要應包含以下資訊：

  • 您的公關相關問題。
  • 公關新增了哪些內容。
  • 您如何測試變更。
  • 你希望審查人員檢查的任何內容。
  • 您認為審查人員需要的任何其他資訊，

如果您在建立要求時採用公關範本，應該就能繼續操作。但請記得盡可能「簡明扼要」和「完整」。

祝您程式設計愉快！