如何做 Code Review 讀後感

最近在看一篇文章《如何做 code review》原文，文章裡面大佬的一些總結很經典很明了，值得我學習和借鑑。通過幾個知識部分做一下總結。

什麼是code review

code review是**評審,**評審也稱**複查，是指通過閱讀**來檢查源**與編碼標準的符合性以及**質量的活動。

keep it ****** stuped!（保持簡單,並且一目了然）

減少**重複使用，但是這個在我看來是高階開發人員才能考慮，對於初級者來說，在有限的時間內，先解決問題，然後在沒有問題的情況下，尋找乙個最佳的解決辦法替換，所以這是乙個不斷學習的過程，學好本領之後才能做到讓**簡潔明瞭。

原則 3 組合原則: 設計時考慮拼接組合

在乙個整體中，無論自己的能力職責多大，都要體現出自己的價值，參與其中。所以組合會更好的讓我們每乙個人都能去找到合適自己的支撐點，然後共同支撐這個「房子」。

原則 6 吝嗇原則: 除非確無它法, 不要編寫龐大的程式

奧卡姆剃刀原理（新學到乙個原理，覺得精闢）

這個原理稱為「如無必要，勿增實體」，即「簡單有效原理」。避重趨輕，避繁逐簡，以簡御繁，避虛就實。

奧卡姆說: 「如無必要,勿增實體。」「勿增實體」被成為奧卡姆提到原則。奧卡姆剃刀是對未知事實由選出概率最大的一種思者方法他是方法不是直理他不保證100%正確,但是可以保證在現有已知事實下，不做無謂思考。

原則 7 透明性原則: 設計要可見，以便審查和除錯

自己要對自己寫的**負責，無論是看還是有需求給其他程式設計師看，或者給沒有**基礎的人看，如果沒有陰暗的角落和隱藏的深度，就要提高質量清晰明了。

原則 10 通俗原則: 介面設計避免標新立異

在通類的**和結構，不要標新立異獨出心裁。如果在開發過程**現了問題，會讓除你之外的人浪費時間去重新理解你的**，耗時耗力。（所以最好讓不同事物有明顯區別，而不要看起來幾乎一模一樣。 – henry spencer）

原則 11 緘默原則: 如果乙個程式沒什麼好說的，就沉默

相信自己，在程式沒有問題的情況下，不要把時間浪費在這個程式上，要審時多度，在沒問題的情況下做些其他有益的事，一旦發生問題則快速定位分析解決問題。

原則 12 補救原則: 出現異常時，馬上退出並給出足夠錯誤資訊

我們都知道滅火的最佳時期是初起階段，所以程式出現問題異常也是同理，及時通知開發和維護人員，快速精準解決才能避免「大事故」發生。

文章寫得很好，畢竟我還沒有達到那個高度，所以覺得大佬說的都特別有道理，很多地方是值得我在接下來學習和注意的，但是這是需要乙個過程的，只有在我有這個基礎之上，才能做到質的東西，所以多學多實踐，才是硬道理。