我如何為降低代碼評審的強度辯護？

解答動態(tài)

• 

  公司的利益相關(guān)者如何看待他們的開發(fā)人員的生產(chǎn)力？我以前的老板曾經(jīng)給我講過一個關(guān)于這種狂熱的故事。開發(fā)團隊把這種狂熱作為拖延時間的借口。因此，實施最簡單的更改花費了數(shù)月時間。他說解決這個問題需要解雇一半的開發(fā)人員，所以幾個月后，他繼續(xù)工作。但是每個故事都有兩面性。關(guān)于正在開發(fā)的應(yīng)用程序的性質(zhì)，您沒有說太多。如果這是一個涉及潛在生命損失（如醫(yī)療設(shè)備）或數(shù)百萬美元資產(chǎn)處理的任務(wù)關(guān)鍵型應(yīng)用程序，那么這種嚴(yán)格程度可能是完全合理的。
  在我工作的地方，每個軟件項目都要經(jīng)過一個“特征化”過程。基于這一特征（“它是控制戰(zhàn)斗機，還是僅僅是一個命令行實用程序”），每個項目都要經(jīng)歷不同程度的審查。正式評審的成本很高；這一成本必須根據(jù)軟件項目的性質(zhì)來確定。
  在任何情況下，作為新的團隊成員，您的想法都會遇到很大的阻力，特別是如果團隊長期以來一直以這種方式運作，而沒有任何人質(zhì)疑他們的觀點。你必須與你的團隊成員建立信任，按照他們的方式做事一段時間，并逐漸建立起改變的理由。
  進(jìn)一步閱讀帕金森瑣碎定律
  
• 

  你提出了一些需要解決的實際問題。但你提出的解決方案不太可能使事情變得更好。沒有人只是在推理，如果我們首先沒有50個方法在同一個類中，可能它不會有太多的方法定位的問題。在我的經(jīng)驗中，最好的方式讓人們看到“更好的方式”是跳進(jìn)去，并編碼它。一旦你有了一個好的例子，不要強迫它進(jìn)入代碼庫。邀請別人和你一起復(fù)習(xí)。讓他們自己看到好處。我完全重新設(shè)計了別人創(chuàng)建的課程，然后謙恭地詢問他們的意見。一開始他們表現(xiàn)出一些抵觸情緒，但如果你表現(xiàn)出你足夠認(rèn)真地對待他們，向他們學(xué)習(xí)，他們也會冷靜下來，開始向你學(xué)習(xí)。
  對我?guī)椭�最大的是，我去找人看我的代碼，而代碼在我腦子里還很新鮮。而我仍然愿意重寫它。我坐在他們的書桌旁，或者他們坐在我的書桌旁（玩我的書桌玩具）。我們花時間在一起編碼。只有電子郵件的代碼審查往往只會演變成腦殘的檢查。他們會挑刺，因為沒有人覺得他們可以讓你真正改變代碼，所以他們只想讓它看起來像他們審查了它。這是真的，因為這些通常發(fā)生在你完成并開始其他工作的幾天后。這些都是浪費時間。抱歉，對于一個好的代碼審查來說太晚了。你對合并工具所做的任何事情都無法解決這個問題。愿意互相學(xué)習(xí)是協(xié)作工作的基本要求。否則這是委員會設(shè)計的。我怎樣才能證明和辯護這篇呢那就是：合并按鈕應(yīng)該由default 啟用，你應(yīng)該有一些分支，你可以合并到你喜歡的，每個人都可以看到。這不一定是發(fā)布分支。
  代碼評審應(yīng)該是建議，而不是強制 強制代碼評審！=正式代碼評審。在你考慮其他事情之前，讓別人看看你的代碼。
  代碼作者應(yīng)該有權(quán)在6小時內(nèi)合并代碼，比如說創(chuàng)建拉取請求，不管是否有批準(zhǔn)。 我完全贊成在6小時內(nèi)完成（這是一個很長的時間），但未查看的代碼需要停止在某個地方。我寧愿完全取消代碼檢查清單，也不想把東西留著看。
  
• 

  如果你認(rèn)為開發(fā)人員應(yīng)該有權(quán)忽略某些注釋，比如方法不符合首選順序，你在注釋中拼寫的“Exception”錯了，等…
  重要的是，所有參與的人都知道并理解哪些類型的評論是可忽略的。
  如果其他開發(fā)人員意識到這些評論通常會被忽略，他們可能會停止吹毛求疵。在某種程度上，我已經(jīng)完成了這項工作。
  
• 

  值得提醒的是，當(dāng)代碼評審正確完成時，它們會產(chǎn)生奇妙的結(jié)果。我提醒自己，在發(fā)現(xiàn)可能導(dǎo)致生產(chǎn)崩潰或根本不符合預(yù)期結(jié)果的代碼之前，我主要是在進(jìn)行橡皮圖章審查。在回顧中抓住它為我們節(jié)省了寶貴的時間。
  我理解，你實施它們的方式帶來了幾個問題，我有幾個建議要解決那個：吹毛求疵細(xì)節(jié)，而不是把重點放在一般的問題上，在新來者感覺很糟糕的敵對氣氛中，這些請求無法得到批準(zhǔn)
  如果公關(guān)因為細(xì)節(jié)而不被接受，先問問自己，這是商業(yè)問題嗎？我想這取決于不同的公關(guān)。開發(fā)任務(wù)很少是時間關(guān)鍵，但在許多情況下，額外的公關(guān)延遲幾天是可以接受的。你可以想象通過評審作為開發(fā)過程的一部分，并對其進(jìn)行解釋。
  如果延遲是不可接受的，或者你看到了改進(jìn)的空間，有幾種方法可以加速你的復(fù)習(xí)過程，而不需要花費太多的時間目標(biāo)：更靈活代碼標(biāo)準(zhǔn)在評審前通過代碼標(biāo)準(zhǔn)系統(tǒng)地通知新評審/評審接受/評審拒絕評審員修改請購單的可能性，并批準(zhǔn)修改后的請購單，當(dāng)建議的變更很小時，這些變更必須得到整個團隊的同意。如果你建議這些過程中的一些改變，對大多數(shù)人來說是合理的，那么你成功的幾率會比完全取消審查過程（這使得它是可選的）要高。值得提醒的是應(yīng)該：不要指向事情（命名，設(shè)計等）壞，差，臟等，而不是不符合準(zhǔn)則，你應(yīng)該同意和書面某處。包括當(dāng)事情不順利的時候，偶爾會向公眾征求意見和/或見解被檢閱人。什么時候必要的（當(dāng)事情復(fù)雜時）處理 在這個框架內(nèi)，即使我不喜歡評審，也已經(jīng)同意系統(tǒng)評審是一件很好的事情。使評審成為可選的愿望源于您對當(dāng)前代碼評審過程的失望。我不能責(zé)怪你。
  在做代碼評審時，我會尋找3件事（按此順序）：
  明顯的錯誤-如果我第一眼看不到，我會繼續(xù)前進(jìn)。
  正確的架構(gòu)和設(shè)計-我可能在這里花的時間最多。
  S
• End