作爲一名初級工程師，當我看到一些問題時，通常會主動去解決它們，因此我總會進行一些大範圍的代碼修改。
這意味着我需要發出大量的代碼審查。在一次修改中通常會涉及到從UI到數據庫的所有部分。
我對於自己能夠維護整個系統而驕傲，也爲自己的快速處理問題的能力而驕傲。同時也爲自己的勇敢和解決重大問題的能力而自豪。
直到有一天，一位資深工程師把我拉到一邊，給我提出了迄今爲止我收到過最好的代碼審查返回。它告訴我應該將巨型的代碼審查拆分爲更小的增量修改。
我第一反應是感到惱怒。我不理解他爲什麼要我這麼做。我對自己解決重大問題的能力非常有信心！爲什麼他說我的工作做的不好？！一點一點的進行修改只會拖慢我的腳步！
雖然當時我還不知道小規模、增量修改的種種好處，但是我很慶幸當時聽了這位高級工程師的意見，很高興我開始學着進行小規模、增量的修改。
這種方法給我後來的職業生涯帶來了巨大的好處。
增量修改的好處
進行增量修改有諸多好處，下面我來列舉一些。
- **更少的合併衝突。**你改的文件越多，和其他人的修改發生衝突的可能性就越大，小規模的修改可以有效的避免衝突，即使有衝突時也能更快的解決。
- **更快的代碼審查。**對代碼審查人員來說，審查5個文件無疑要比審查50多個文件輕鬆許多。與那些需要面對面交談十分鐘才能開始看的代碼相比，小規模的修改能夠更快速的開始審查並且更容易解釋。當審查人員面對大量的代碼審查工作時，他們有可能會犯懶，非常希望能找個人替他們完成這項工作。因此你可能需要花費很長時間才能找到一個願意審查你的代碼的人。
- **更早的修正。**你的代碼審查者可能與你的思路相左。他們可能會要求你重做所有的事情。如果你之前只花了幾個小時進行修改，那麼這對你來說可能不是什麼大問題。但是如果你在這個問題上已經花費了兩天時間，那麼重做可能是一件非常痛苦的事情。
- **更快速的測試。**如果你的代碼修改涉及到了從UI到數據庫的所有層級，你可能需要對整個產品進行重新測試。而如果你只進行小規模修改，那就只需要測試你所修改的那部分。如果你需要解決很多代碼審查反饋或者是合併很多代碼時，這種好處就非常明顯了。重新測試所有東西會花費大量的時間，特別是手動測試。
- **更少的bug。**小規模修改意味着你不需要同時將所有東西都裝進腦子裏。你可以專注於你進行優化的這一部分代碼，保證你可以把它做到最好。（我曾經見過一個工程師，它對自己的大規模改動感到不知所措，後來他養成了檢查和修復都追求完美的習慣。希望你不要成爲那樣的人，即使沒人抱怨，但是你的同事將會慢慢變得不信任你的代碼。）
- **更容易排除故障。**如果你需要改動一些代碼，那麼小規模的改動可以幫助你更加容易的定位問題。
- **增量部署。**如果你想要不停機更新，那麼更小的、增量的改動會幫助你解決這個問題。（但這並不是全部解決方法）
- **還原更加簡單。**當你寫了bug時，你的改動越小，還原就更加簡單。如果你合入了大量代碼，並且其他人又在後來進行了改動，那麼還原你的代碼就會是一件非常痛苦的事情。也許你可以進行快速修復，但這並不是一定奏效，生產環境出現事故時，剔除有問題的代碼會使團隊的其他人更加放心。
- **部署回滾更加簡單。**如果單次部署更新了web服務和即時生效的UI功能，那麼如果你想要回滾後端服務就必須先要回滾UI的改動。由於這樣部署方式，想要做到不停機更新可能並不容易。最好的辦法就是把它們分別合入代碼倉庫並部署。
- **更低的風險。**這實際上是上述所有情況的結果。
爲你的未來交學費
那天我從那位高級工程師那裏收到的代碼審查反饋，已經被證明是職業生涯迄今爲止收到的最好的代碼審查反饋了。
多年後，我遇到了另一名工程師，他一直在進行大規模、徹底的變更。我把相同的反饋分享給了他，他看起來很生我的氣，但是我完全可以理解他。在我看到他有進步之前，我離開了那家公司，希望他最終能體驗到小規模修改帶來的好處。
相信他以後會是一名優秀的工程師。
譯者點評
小範圍的修改確實是很有必要的。我自己在做code review的時候看到那種幾百行的代碼修改也是很頭疼的。作者對於小規模修改的好處總結的還是比較全面的，希望大家能有收穫。
原文地址
https://medium.com/better-programming/the-best-code-review-feedback-i-ever-received-43313a503517
