體面編碼之程式碼提交

提交訊息註釋
總結前70個字元的變化。這使得在閱讀日誌時可以一目瞭然。預設情況下，許多源控制工具會隱藏其餘的訊息。

包括“為什麼”以及“什麼”。簡要解釋一下正在做什麼。這是在提交的上下文中 - 它需要比一個大功能的標題名稱更精細。請記住，差異的細節可以在差異中找到。然而，“為什麼”並不總是顯而易見或立即明確，因此請將其包含在訊息中。對於更復雜的更改或重構，對“什麼”的簡要描述可能會有所幫助。

根據專案約定引用相關問題跟蹤器ID。這些識別符號允許方便地找到關於變更的進一步資訊。最常見的是，它適用於目前正在處理的問題，但也可能是其他有用且相關的問題。前一種情況可以使用源控制分支檢測提交訊息鉤子（例如這一個）自動化。

有關優秀提交訊息為何如此重要的更多資訊，我建議介紹部分，特別是Chris Beams 撰寫的“如何撰寫Git提交訊息”一文。

提交
保留行歷史記錄。原始碼控制工具可以顯示每行所做的最後一次更改的逐行檢視（通常稱為“註釋”或“責備”）。提交更改然後再提交將程式碼更改回原來的方式，使得此功能不那麼有用。編輯此類提交，或組合（“擠壓”）有大量流失的提交組，可以在這種情況下提供幫助。

看看承諾了什麼。新增工作資料夾中存在的所有更改非常容易，可以快速提交。然而，單獨新增每個檔案，快速檢視每個檔案以及每個檔案的更改，讓您有機會發現任何不對勁的事情。

拉請求
拉取請求和程式碼審查流程高度針對個別團隊的情況和偏好。這裡的要點不可避免地反映了我的經歷，但其中許多應該是一般的/適應性足以與其他團隊相關。做適合您的團隊的工作，以便從作者和評論者花費的時間中獲得最大的收益。

要閱讀有關拉取請求和程式碼審查的更多資訊 - 包括文化，行為，實踐和工具 - 請從程式碼審查真棒列表開始。

一般（拉動請求）
爭取小拉請求。大量拉動請求更難以審查，導致較差的反饋，未被注意的問題，“速度審查”，以及進展批准的進展緩慢。如果您無法拆分大型功能的工作項（由於流程或政治原因），請考慮將一系列較小（例如200-400行）拉取請求的增量技術引入“收集器分支”，最終形成一個大的從該分支向主/主幹拉請求。

爭取短暫的拉動請求。任何正在進行或正在審查的分支機構工作尚未成為其他人基於其工作的主/主幹的一部分。這可能導致衝突，這些衝突既費時又容易解決。長時間開啟會增加拉請求在更長時間內開啟的可能性 - 因為它需要在其他拉取請求合併之前進行更新（可能涉及衝突解決）。考慮設定一些通用和“SLA型別”基本規則來促進短期PR，例如：在提交後的n小時內進行稽核，並在開始新工作之前稽核PR或解決反饋。提出小拉請求有助於保持短暫的生命。

自動化繁瑣的事情。配置構建以要求傳遞程式碼樣式和靜態分析檢查。透過工具比人們更快，更便宜，更一致地檢測到這些問題。

預先設定期望。使貢獻者可以輕鬆提交將首次批准的拉取請求，或者至少不需要進行重大更改。有助於此的事情包括明確的要求，對應用程式架構和程式設計模式/實踐的共同理解，以及在實現開始之前共享設計思想。

在提交之前
構建成功。這包括執行測試和自動程式碼質量檢查。

分支是最新的目標分支。這是確保要合併的更改與最新版本的目標分支相容並整合的唯一方法。這是透過將目標分支合併到源分支（或在目標上重新定位源）來完成的。

自我審查程式碼。閱讀要求，並檢視您自己的程式碼。這是一個發現錯過的任何問題或事情並立即修復的機會 - 增加首次批准的可能性。

完成預提交清單。清單可以幫助每個人記住需要完成的事情。提交前檢查清單需要的是取決於團隊和專案，並且應該隨著時間的推移而發展 - 例如，什麼事情總是作為反饋出現。為了避免稀釋其重要性，它不應該太長或包括瑣碎的事情。如果儲存庫支援拉取請求描述的模板，請建立一個包含核對表的模板 - 否則，快速填充拉取請求描述欄位的書籤可以提供幫助。

更新問題跟蹤器票證（如果適用）。如果透過其他渠道（電子郵件，即時通訊，面對面）對要求進行了澄清，更正或修改，請記錄這些內容。這有助於確保每個人（審閱者，測試人員，產品所有者）使用正確的資訊，因為功能/修復程式正在釋出。

為測試人員新增“內部見解/建議”。根據您實施/修復需求/錯誤的經驗，這是您認為可以幫助他們的任何有用資訊 - 在不審查程式碼更改的情況下無法知道的事情。將其新增到問題跟蹤器票證。示例包括：難以實現的事物，受影響的看似無關的區域/功能（例如，如果修改了公共元件），以及重構更改或技術任務的範圍。

提交
提供資訊標題。能夠快速識別儲存庫中開啟的許多拉取請求是有幫助的。僅將問題跟蹤器ID用作標題時，這是不可能的。

提供資訊以幫助稽核人員嘗試更改。示例包括合適的測試資料的位置，所需的特定使用者型別/配置以及服務端點詳細資訊。將相關部分新增到問題跟蹤器故障單中。

新增帶有省時提示的註釋。作為評論者考慮，並新增評論，這將有助於他們充分利用他們的時間。例如，指出簡單移動的程式碼，解釋一個嘈雜的差異區域，其中幾乎沒有實際的變化，或解釋一個可能提示解釋請求的區域。

請注意需要注意的程式碼區域。避免依賴評論者接受事物（或希望他們不接受）。完成這項工作後，您可能會比審稿人更深入地瞭解它。評論那些感覺不太合適的事情（新的或現有的），您不確定的事項（要求或技術），或您所做出的利益決定。

審查並提供反饋
檢查整個變化。程式碼庫中的所有內容都直接或間接地為應用程式的功能和質量做出貢獻。避免考慮某些不值得審查的區域，並跳過它們 - 例如測試，構建配置或樣式表。

執行程式碼。僅僅因為它看起來不錯，並不意味著它做對了。如果專案工具使人們難以在他們自己的工作和執行審查分支之間切換，那麼解決這個問題。

注意......一切，真的。利用您的經驗，知識，指南和其他任何東西。它是做正確的事情，它是否有意義，它是好的，它是可維護的，是否經過測試，假設/解釋是否清晰有效等等。

問問題。程式碼審查有助於在團隊中分享程式碼庫的知識，並幫助貢獻者相互學習。如果某些事情不清楚或不明白，請詢問。如果整個變更難以審查並且難以掌握，則可能需要改進。

做出明確的評論，解釋不明顯的推理。直接的好處包括避免澄清請求（延遲進度），以及避免因錯誤解釋的註釋而進行的意外修訂。長期利益是作為作者和評論者的其他參與者的升級。這有助於提高整體質量，因為單個人審查所有更改通常是不切實際的。

尋找拼圖的缺失部分。當前程式碼，加上正在審查的更改，以及其他積壓工作專案 - 將在某個時候構成軟體的可釋放版本。指出您認為缺少但需要的任何內容 - 可能需要為其建立積壓工作項。

解決反饋問題
解決註釋適用的所有例項。審稿人可能沒有注意到評論適用的所有地方，或者沒有對所有評論都進行評論以避免引起噪音（這是一種很好的做法）。考慮評論所作的觀點是否適用於其製作的特定行以外的其他地方。

使審閱者可以輕鬆檢視修訂版。根據使用的儲存庫/工具，編輯現有提交可能會使檢視更改的內容變得困難。針對個別評論（或其邏輯組）的細粒度提交便於檢視並與原始評論相關聯 - 允許審閱者檢視響應他們的反饋所做的更改。它們還可以建立更好的版本控制歷史 按照“地址pr評論”的標題進行的單一廣泛提交沒有任何這些好處。

儘量減少反覆來回。透過對話更容易解決一些問題，而不是重複更改和評論迴圈，或長時間執行的評論執行緒討論。當您發現其中一個來回/流失情況時，請進行對話或建議短對程式設計會話。

在合併之前
構建成功。在允許合併之前，配置工具（儲存庫和CI伺服器）以要求成功構建最新版本的分支。

分支是最新的目標分支。在允許合併之前，將儲存庫配置為要求源分支不在目標之後。

所有評論都已得到解決。這通常意味著進行修改，回答評論者的問題（令他們滿意），或結束討論。跟蹤未完成的評論可能很困難 - 諸如反應（豎起大拇指等）或任務核取方塊等儲存庫功能可以提供幫助。配置儲存庫（如果支援）要求在允許合併之前完成所有任務。

檢查所有核對錶專案。拉取請求核對表除了預先提交的專案之外還可以包括合併前專案。

審查人已經給予了充分的批准。什麼是足夠的取決於團隊和專案。通常需要最低數量的批准。可能有必要進一步要求一組被認為負責任的人批准一個/幾個。在允許合併之前，配置儲存庫（支援的任何程度）以要求這些批准。此外，使用良好的判斷來決定是否應該從區域/域/技術專家等特定人員那裡尋求批准。

如果批准後更改，批准仍然有效。在另一位審稿人批准後，一位審稿人提供的反饋有時會產生重大修改。在這種情況下，已經批准的審稿人可能希望重新稽核。可以將儲存庫配置為在進行後續更改時撤消批准，但由於合併或微不足道的更改會觸發它，這往往會變得乏味。