如何防范代碼審查力度的降低？

解答動態(tài)

• 

  我如何證明和捍衛(wèi)這篇那就是：合并按鈕應(yīng)該由默認值啟用代碼審閱應(yīng)該是一個建議，而不是代碼作者應(yīng)該擁有的強制命令在6小時內(nèi)合并代碼的權(quán)利可以說是拉請求的創(chuàng)建，無論是否有批準(zhǔn)。 我不認為你應(yīng)該嘗試和證明任何這些，因為它們幾乎肯定是壞主意。代碼評審只是一件一直被證明能顯著提高代碼質(zhì)量的事情，你實際上是在建議停止這樣做。相反，把你的努力放在改進代碼評審上流程：團隊不關(guān)注什么是重要的（模式、接口、封裝、分層、方法簽名），但是這是你需要解決的問題。與您的團隊合作，提高他們的能力，包括編寫代碼和審閱代碼。然后你就把一個糟糕的過程變成了一個好的過程。哦，永遠不要在討論這個問題時使用“宗教原教旨主義”這樣的語言。我希望我不需要解釋為什么。
  
• 

  公司的利益相關(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)用程序，那么這種嚴格程度可能是完全合理的。
  在我工作的地方，每個軟件項目都要經(jīng)過一個“特征化”過程�；�于這一特征（“它是控制戰(zhàn)斗機，還是僅僅是一個命令行實用程序”），每個項目都要經(jīng)歷不同程度的審查。正式評審的成本很高；這一成本必須根據(jù)軟件項目的性質(zhì)來確定。
  在任何情況下，作為新的團隊成員，您的想法都會遇到很大的阻力，特別是如果團隊長期以來一直以這種方式運作，而沒有任何人質(zhì)疑他們的觀點。你必須與你的團隊成員建立信任，按照他們的方式做事一段時間，并逐步建立你的改變理由。
  進一步閱讀帕金森瑣碎定律
  
• 

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

  我不太關(guān)心檢查和簽入/合并過程，而更關(guān)心吹毛求疵的問題的數(shù)量。
  理想情況下，我們編寫的功能在使用時非常簡單，即在使用我們的抽象時，錯誤的空間盡可能?Ｎ頤竅Ｍ�设计晤U塹某橄�，使使訅纛U塹目突Щ�（通常是晤U親約海┞淙氤曬Φ南葳濉?br/> 我們有時可以使用類型系統(tǒng)來防止非法的中間條件，因此，某些不好的事情不會通過編譯器。我們應(yīng)該將兩個（或更多）通常存儲或一起完成的事情到一個可直接使用的單一抽象中，從而簡化消費客戶機。
  如果我們能夠做到這一點，那么希望通過使用清晰的抽象和精心選擇的名稱，代碼能夠更直接地自文檔化-如果我們能夠在那里，評論就不那么重要了，也不需要爭論（有時甚至不需要寫出來）。我總是發(fā)現(xiàn)，定好基調(diào)是很重要的。把軟件產(chǎn)品放在一切之上，并考慮最終用戶。我不同意你所說的話，因為我不相信你所說的每一句話都賦予了你在沒有得到團隊適當(dāng)認可的情況下進行合并的權(quán)利，但問題應(yīng)該放在誰是利益相關(guān)者以及他們在開發(fā)/設(shè)計系統(tǒng)時是否被優(yōu)先考慮上。
  如果你理解的話，我認為你的論點會更有分量更好地從更高的層次、您的最終用戶、他們需要什么以及從系統(tǒng)行為（相對于您的pull請求）來查看項目。你可能也會受益于放低和觀察初步了解這些動態(tài)。也許你的系統(tǒng)的用戶被劃分了優(yōu)先級，但是由于沒有成為這些會議的一部分，這些信息還沒有被傳遞給你。潛在客戶在整個項目中都具有開發(fā)人員所不具備的可見性，并且可能會實施程序/流程來反映這一點。
  我不確定哪家軟件公司允許開發(fā)人員在沒有審查的情況下合并代碼，是否允許蓋茨驗證系統(tǒng)穩(wěn)定性（在構(gòu)建和行為方面），或者是否有6小時的超時時間，在此之后才允許合并。這似乎妨礙了團隊提供反?⒋�播知识的能力，并抠犥蒂Z碌橢柿看�職枘房z鍘?br/>
• 

  過去對我起作用的是爭論相對的優(yōu)點。例如，本文闡述了為什么代碼評審不如其他機制對提高產(chǎn)品質(zhì)量、提高代碼質(zhì)量、傳遞信息或提高工程師的編碼能力（代碼評審主要是在編碼周期結(jié)束時進行的手動過程）有用的許多論點。就像你提到的那樣，這種敵對的審查環(huán)境對建立一個安全、協(xié)作的團隊環(huán)境是不利的。
  TL；DR——不要反對他們的目標(biāo)，認為NoToCy代碼評審是一種低效的方式。
• End