程式碼審查。
你知道它們有多重要。
它們是獲得可靠程式碼的支柱之一。
然而，這是您在超級忙碌的日子裡需要擠出時間做的事情之一。
如果您不審查程式碼，那麼您可能會向用戶發送地雷，因為您永遠不知道它什麼時候會爆炸。 🤷
顯然，你知道這一點。你來這裡不是為了被告知「嘿！你應該進行程式碼審查！這是一件至關重要的事情！
我的團隊已經做了評論。我為什麼要在乎？
如果不小心和勤勉地處理程式碼審查流程，可能會產生嚴重後果。
在我之前的一個組織中，程式碼審查通常沒有徹底完成，因此需要多次審查。它們也是由地球兩端的審查者完成的！ 🌏
因此，處理任何評論幾乎花了一整天的時間。再說一次，因為評論通常不全面，所以 PR 的返工時間可能會因為一些瑣碎的事情而花費幾天的時間。
“如果不衡量，就無法改進”
通常被認為是彼得·德魯克（Peter Drucker）的作品，但我還沒有找到真正的證據。
但我發現這句話對我的經驗來說意義深遠。
我過去曾向我的領導階層提出必要的組織變革，使所有團隊能夠減少跨時區的相互依賴，從而使人們能夠更快地協作。
我知道這樣做有多麼困難，但如果沒有可靠的資料支持理由來解釋為什麼需要改變，就更難實現任何改變。
PS：這就是 Dhruv 和我創辦Middleware 的部分原因。 🚀
{% 嵌入 https://github.com/middlewarehq/middleware %}
好的，我聽到了。我有什麼選擇？
您理想的情況是進行徹底的程式碼審查，也就是說，明顯的危險訊號、效能或安全缺陷或其他難以閱讀的程式碼不應被忽視。
但您也希望所有這一切都在合理的時間內發生。
在合理的時間內合併經過嚴格審查的程式碼，這意味著您的團隊的交付可預測且具有高可靠性。
除非有一種經過充分研究、結構化的方法來掌握這一點。 🤔
……
您聽過…DORA 指標嗎？
好吧，這不是另一部《DORA GOOD！文章。
這些是我過去專注於四鍵（正如出色的Nathen Harvey所解釋的）如何幫助我改善我自己和我的團隊的程式碼交付體驗的經驗。
在中介軟體開源中看到的 DORA 指標
使用 DORA 探索程式碼審查
評論會延長交貨時間多久
審核週期長直接影響變更的前置時間。
交貨時間基本上由 5 個部分組成。
-
從第一次提交到 PR 開放的時間
-
然後 PR 收到第一次審核（可能是評論、更改、批准）
-
更改 PR 直至最終獲得批准所花費的時間
-
批准和 PR 合併之間的時間
-
PR最終部署的時間
當然，任何需要花費時間的部分都會增加您團隊的時間。但有兩個部分是造成延誤的特別嚴重的因素。這是#2 和#3。
#2. PR 收到第一次審核的時間（首次回應時間）
PR 公開後，開發人員實際上無法對其做太多事情。公關可能完全可以順利進行！它可能需要切實的改變。在這一點上，只有評論才能告訴我們答案。這也是開發人員可能無法承擔更多任務的時候，因為從技術上講，審查可能隨時發生，並且他們會遭受上下文切換的困擾。
上下文切換是開發人員最大的生產力殺手之一。
對「每次審核時間」的誤導性關注
這討論了提前期指標的第三個子部分。
#3。更改 PR 所花費的時間（返工時間）
這裡真正的問題不在於在這裡花了多少時間，而是來回發生了多少次。我們稱之為「返工週期」。
因為如果因為PR被批准而只有1個返工週期，那麼在批准之前可能仍然需要很長時間，但這是實際的實施時間，而不是空閒時間。可以透過更好的培訓、程式碼庫入門、上下文共享等來減輕這種返工。
但是…如果您要來回很多次，那麼每個週期都有一些與之相關的空閒時間，就像第一次回應時間一樣。
在此期間，開發人員無法接受新的工作，因為這將不可避免地導致快速的上下文切換。
這種情況很可能發生在PR太大而無法一次審完，或是審查者因為其他原因沒有審透徹底的情況下。當作者和審稿人位於相距甚遠的時區時，情況尤其嚴重。由於每次審核和返工都可能發生在各自時區的工作時間內，因此返工更改之前的時間可能會被誇大到很多小時。
這就是滾雪球效應
像這樣被屏蔽的 PR 越多，團隊交付的速度就越慢。通常新工作不會停止出現，這使得開發人員準確管理和評估他們的工作變得更具挑戰性。
如果這種情況持續發生，也會對團隊士氣造成打擊。
博士
僅僅專注於減少「每次審查的時間」可能會適得其反。
目標應該是在不犧牲徹底性的情況下優化審核流程，確保每次審核都能增加真正的價值。
低於標準的審查和變更失敗率
團隊始終在壓力和緊迫的期限下運作。期望這種情況會神奇地改變是不合理的。但認為不會偷工減料以確保貨物不能按時發貨也是不切實際的。
由於我們談論的是程式碼審查，因此經常被削減的角落之一是：
-
建立的大型 PR 包含某個功能的所有程式碼，而不是包含良好的較小且更易於審查的 PR。
-
PR 的審核只需略讀即可，因為審核者目前可能沒有足夠的心理能力或時間來正確處理它。
這兩件事時常發生。開發人員也是人。你不能僅僅把責任歸咎於他們或強迫他們「正確地」複習來解決這個問題。
最重要的是你首先要知道它正在發生。因為這樣你就可以做點什麼。你問，你怎麼知道這件事？
-
您的交貨時間應該會縮短。因為審核速度更快（通常比應有的速度快）
-
您的變更失敗率可能會上升。當然，如果評論低於標準，您可能會帶來更多錯誤。
1. But, even if your CFR isn’t going noticeably down, your team might still be shipping low performance or quality code that would bite you back later, and will likely show up as higher Lead Time down the line. But by then it’ll be too difficult to correlate with the reviews of today.
現在是時候提一下《朵拉》是一位很棒的嚮導，但它並不完美。
不要將其視為明確的規則手冊。不要用它來衡量個人。
為您的團隊全面使用它，但也要參與其中，以確保它真正幫助您的團隊。畢竟這就是目標，不是嗎？
偉大的！如何？ 👉 更快、更有效的審核策略
這是一個快速預審清單
- 測試：確保所有相關測試都已編寫並通過✅。
1. This can be done by a CI bot (or Github Actions)
-
文件：更新相關文件，包括內嵌註解和自述文件。
-
清晰的提交訊息：編寫描述性提交訊息，解釋更改背後的「原因」。
2. This could also be enforced via [commit-lint](https://commitlint.js.org/)
3. You could also use [aicommit](https://github.com/Nutlope/aicommits) to help write good and detailed commit messages!
4. My team often uses GH Copilot to create commit messages that actually end up being totally satisfactory to me!
提交訊息範例：
feat: add user authentication
- Implemented OAuth2 for secure login
- Added unit tests for authentication flows
- Updated API documentation with new endpoints
正確的審稿人，正確的時間
將審閱者與其專業知識和當前工作量相匹配，以避免超負荷。複雜的變更交給高階開發人員，簡單的變更交給同業。
但您還需要了解開發人員對特定程式碼庫有多少上下文。
這裡有一些挑戰：
-
如果您的開發人員在單一特定儲存庫中高度專業化，那麼由於需要時間來加入和共享上下文，因此在單獨的程式碼庫上使用他們的技能將非常困難。
-
如果您的開發人員對所有程式碼庫過於籠統，那麼由於缺乏特定程式碼庫的深層上下文，他們可能很難更快地解決某些問題。
-
如果團隊中的一位開發人員對事物有很多背景知識，那麼很容易讓他們負擔過重。您需要儘早騰出時間來分發上下文，這樣您的工作就不會在最關鍵的時候受到阻礙。
您希望確保將兩者結合起來，並且只需與您合作的 2-3 名開發人員即可實現這一目標。
了解誰被阻止對誰進行程式碼審查至關重要。您不希望您的團隊因為有人需要休假而根本無法交付。
貿易工具
使用靜態分析、程式碼檢查和自動檢查在人工審查之前捕獲簡單的問題。這讓審閱者可以專注於更複雜的回饋。
範例工具：
超重要提示：
爭論空格和製表符、分號與否、尾隨換行符很容易浪費大量時間。
但這一切並不重要。
決定並同意團隊最終確定的任何程式碼風格，並將它們作為 linter 規則的一部分強制執行。
這些東西不值得你花時間。 👍
回饋的藝術
給予可操作的、具體的評論，重點是改進，而不是吹毛求疵。避免模糊的陳述並提供明確的指導。
分享如何將一個文件重組為多個文件，以及為什麼這樣做是個好主意。
分享為什麼在循環中多次呼叫資料庫可能是一個壞主意，因為我確信我不需要在這裡解釋。 😆
如果挑剔的問題主要是可以由 linter 處理的事情，那麼就使用其中之一。
人們討厭那些大多只有蝨子的評論。但同樣，糟糕的變數名稱、拼字錯誤等不能只是去生產！ 😁
例子：
# Ineffective comment
"Fix this."
# Effective comment
"Consider using a map here to improve lookup efficiency. This will reduce the time complexity from O(n) to O(1)."
使用中介軟體簡化流程
中介軟體如何提供協助
我能夠具體了解我的團隊在哪裡陷入困境、原因以及如何解除困境。
這就是我工作的一半，現在我能夠比以前更快地完成這些工作！
我重點關注以下幾點：
-
審核指標：追蹤審核所需的時間並確定發生延遲的位置。
-
流程洞察：了解整個審核流程並找到需要最佳化的領域。
我不會對此進行太多討論，因為那樣聽起來就像是推銷！ 😂
超越技術細節：人的因素
培養建設性回饋文化
倡導一種將回饋視為成長機會的文化。建設性的、相互尊重的溝通有助於提高程式碼品質和團隊士氣💬。
平衡速度與徹底性
平衡速度與徹底性。快速審查不應影響審查，徹底審查不應拖延。
心理安全
確保審稿人和作者的心理安全。鼓勵公開討論不加指責地解決錯誤，營造持續改進的環境🌱。
請記住，當您分享改進回饋時，人們常常會保持警惕。考慮周到，思路清晰。
結論
有效的程式碼審查對於保持程式碼品質和交付速度至關重要。透過與 DORA 指標保持一致、使用正確的工具並培養建設性的回饋文化，團隊可以簡化其審核流程。採用這些實踐可以使您的程式碼審查既高效又具有影響力。
嘗試使用中間件來更深入地了解您的程式碼審查流程並確定需要進一步改進的領域。 🚀
同樣，這些只是指導方針以及我們如何看待程式碼審查。請分享您的組織中如何進行程式碼審查！
程式碼審查對於整體產品可靠性起著至關重要的作用。有些情況下，糟糕的程式碼審查（不是糟糕的程式碼！）會造成負面的品牌影響。總而言之，更好的程式碼審查流程有助於降低故障率。
像DORA這樣的框架被設計為輕量級的，可以幫助工程團隊提高工作效率，而無需工程師甚至領導者付出太多的努力。 Middleware 的使命是幫助工程團隊交付高效率的程式碼。請查看我們的開源中間件，我們的開源 DORA 指標解決方案，它是本地託管的。如果您喜歡，請考慮給我們一顆星！
原文出處：https://dev.to/middleware/the-senior-engineers-guide-to-the-code-reviews-1p3b
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式