如何進行更好的共同審查
今天，我想談談如何進行更好的共同審查。無論你是在工作中審查他人的 PR（Pull Request），還是現在正在被審查，今天我都會分享一些方法，讓你團隊的共同審查過程更好、更有效。
嗨，如果這是你第一次來到這個頻道，我是 Bruce。我從事軟件開發已經超過 10 年，並且在新加坡工作了一段時間。我目前在台灣經營一個在線學習平台。在下一個視頻中，我將分享代碼審查過程的意義以及五個可以實施和改進的具體技巧。讓我們開始吧。
為什麼需要審查過程
首先，我問你一個問題。開發的功能是解決問題。為什麼還需要審查過程？我自己升級代碼快速解決問題不是很好嗎？
當然，原因有很多。但讓我們談談其中之一。想象一下，你已經成為一名高級工程師。然後你的團隊中有一位初級開發人員。他可以非常快速地編寫代碼並非常快速地解決問題。代碼也會運行。有時它會出錯。難道你要等到有一天它出錯了才有機會學習如何處理嗎？也許他還會告訴你，我自己寫代碼快速解決問題不好嗎？你能接受嗎？
如果你不想走到那一步，你認為該怎麼辦？讓我告訴你，不要合併得那麼快。在合併之前，你幫助我，我幫助你。也許我們可以解決問題。或者你向我學習，我向你學習。然後我們可以提高彼此的知識。也許我們可以避免一場災難。
此外，共同審查還可以讓團隊之間的知識相互流通。如果有一天你們需要緊急互相替補，你們會更快地進入狀況。
當然，以上並不是絕對的。每個團隊的需求都不同，每個階段的需求也不同。如果你遇到兩個人，犧牲代碼審查更具成本效益。當然，這是為了犧牲代碼審查。如果在審查期間可以進行代碼審查，為什麼不做得更好呢？
如何在團隊中實施和改進代碼審查
接下來，我想分享一些具體的方法來實施和改進團隊代碼審查的一些方法和技巧。
我想提醒你，如果你不是團隊的經理，並且如果你的想法不被團隊的經理接受，你應該怎麼辦？我認為最簡單的方法是在不破壞前提的情況下自行採取行動。也許其他人看到你在做這樣的事情，發現還不錯，那麼他們可能會跟隨你。逐漸地，它可能會改變團隊的氛圍。
這種方法不僅用於指導代碼審查過程或文化，還用於許多其他事情。
技巧一：不要只專注於捉蟲和編碼風格
在代碼審查中，很容易自然而然地專注於這兩件事。雖然這也很重要，但這就像回購股票的故事。我們會花很多時間討論簡單易懂、容易發現的問題。
每個人對懸掛的顏色都有很多意見。但真正重要的是核電廠的工程問題。但就是這樣。如何對抗這個問題？
首先，編碼風格部分可以參考我上一個視頻。只需選擇一個主流標準，大家都使用它。就不會有歧視。
然後是需要增加的部分。除了捕捉明顯的錯誤之外，你還應該花時間和精力專注於以下領域。
第一個是業務邏輯是否符合需求，甚至該需求是否真的解決了問題。例如，票據中提出的開發方向，是否實際上是解決該問題的最佳方案？嗯，可能不是。因為 PM（產品經理）和老闆也是人，他們也可能有思維盲點。
然後是結構層面。有沒有什麼你可以預測會導致維護問題的？如果有，現在做出決定是否值得？如果不值得，你可以在哪裡寫下這個問題？或者打開一個票據記錄並按下一個時間。
然後是安全方面。有沒有漏洞？例如，最常見的 SQL 注入和 XSS。因為這些事情有時很容易被忘記。
即使初級開發人員當時不知道。代碼審查是他學習的好機會。
接下來是自動測試。自動測試在代碼審查中其實很容易被忽視。因為測試結果是雙面的。你通過了還是沒有？如果你通過了，可能就沒問題了。
所以在代碼審查期間很容易被社交媒體看到。但這樣一來，YFoam 很容易從這個地方成長起來。而且實際上，測試代碼也是代碼。如果測試代碼寫得不好，也是一種技術債務。
此外，如果你仔細查看測試，還有一個優勢。因為測試實際上是一種文檔。所以你可以從測試中看到它的業務邏輯是如何覆蓋的。從這個角度出發，有時很容易發現意想不到的盲點。
技巧二：冷審查不是審判，請使用友好的詞語
在 K 博士談論為什麼軟件開發人員容易倦怠的視頻中，他說其中一個原因是你的同事可能很懶。這個行業有很多人不禮貌、不客氣。你為什麼看著我？我不禮貌。
雖然我們不能讓所有同事都有高情商，但至少在核心觀點上，如果有明確的標準，可以減少被言語傷害的機會。
具體來說，當你提出建議時，你應該說，你有沒有考慮過使用這個解決方案？如果有，為什麼後來沒有使用？而不是你不知道怎麼用這個？
技巧三：將你的建議分為三個級別
-
Merge Blocker：這意味著如果你不重寫它，那麼這不適合合併，因為它可能是一個重大問題。
-
True Discuss：這也是一個阻礙因素，但它可能是一個疑似重大錯誤，但我不確定。但如果你不確定並且沒有討論，那麼誰知道呢？所以這也是一個必須討論的過程，以決定是否更改或跳過。
-
Minor：這意味著它已經超過了可接受的限度。但如果你想有這個解決方案或那個解決方案，你可能在這裡有不同的意見。或者可能有一些小的改進。即使對方不改變，你也可以接受。
之所以這樣劃分，是因為有時你說，我認為這個地方可能不會這樣改變。對方可能會認為你太在意了。所以你可能花了很多精力來反映它。
但如果這是一個非常重要的問題，你可能需要在解決問題後再次審查它。那是因為你沒有很好地溝通哪一個是重要的。
此外，你必須回復每條消息。即使你決定不改變它，你也必須回復並解釋為什麼你不改變它。
技巧四：讓啟動 PR 的人合併自己的 PR
這不一定是這樣。這取決於團隊。但這其實並不罕見。如果你的團隊還沒有，你可以認真考慮是否適合使用。
具體來說，審查後，當 PR 的作者認為符合要求時，作者將自行合併。這種方法的前提是每個人都必須有主人翁意識。
這個代碼庫是我的。如果出了問題，我會負責。我不會指望有人幫你。通常，當有事情要上線並且你想發布時，會有一條警戒線。但如果 PR 團隊不能自行合併，這將反映出你的團隊是否有主人翁文化。
但你仍然需要澄清這是否取決於項目的質量。並不是所有的團隊對每個人來說都是好的選擇。
技巧五：不要打開一個大的 PR
這個建議是給那些即將被審查的人。原因是如果一個 PR 中有太多東西，審查者將不得不花很多時間來理解它才能給出意見。但他們也有工作要做。所以如果你突然丟掉一個大的 PR，
這會讓對方非常困擾。它將進入這樣一種困境，即我有自己的工作，然後是你的工作。我之前其實做過一個關於這個的視頻。你可以在這裡觀看。
由於視頻的時間，我無法在這裡完成所有細節。例如，你不允許強制推送。你必須等待代碼審查多長時間？團隊應該澄清這些細節，然後命名它們。
但這些都是相對簡單的小細節，我在這裡就不多說了。
以上就是我這次的分享。如果你想了解更多關於軟件開發的幫助，歡迎觀看這個視頻。再見。
{#