熱情高漲
代碼走查作為一種流程形式，起初大家的參與熱情非常高漲。
因為，自己可以學習到別人一些巧妙的思想，自己的代碼和習慣都暴漏出來。
這個過程中不斷地吸收和改正。
但是。。。。。。
我們一開始組織的代碼走查是一個很重的會議形式。
參加的人有寫這段代碼的人（小菜）、比較有經驗的開發（大佬）
如果為了再隆重一些，請一些領導也參與其中。
但是。。。。。。
我上面提過了，會議很重，協調時間這個事情就是一個很費時間的事情。
還有就是，大家恨不得對每一句代碼都發表自己的意見，往往非常的細枝末節。
導致會議時間經常在2小時以上，3小時時間就一般不得不停止。
大家都很累，再就是效果如何呢？
如果小菜自律性不夠，甚至沒人進行監督，這次的審查的代碼不是都會修改。
因為有一些確實太過於雞蛋挑骨頭，根本改不動。
熱情褪去
不知不覺中，這種方式慢慢褪去。代碼走查成為了一個優先級、頻次都不高的活動。
有很多原因，上面說的形式太重是一個，還有就是大家都很忙了，沒有進行持續跟進導致效果不佳。
但是。。。。。。
也都知道代碼走查對一些新人來說，成長史毋庸置疑的。收獲也是毋庸置疑的。
慢慢大家也都放下了。只是每次項目迭代中作為一個硬性要求執行一次罷了。
痛
我們小組里面只有我還有一個剛畢業一年多的女生。
在我們組內的一個項目中，我總是以任務重為由，沒有進行代碼走查。這個持續了很長時間。
一個字 —— 懶
在處理客戶反饋的問題時候，我突然發現，她寫的代碼確實出現了比較粗心的失誤。
我心一想，長達3個月的時間都沒有對她的代碼進行任何關注。
於她於我於項目，都是極其不好的。我這塊做得太自私了。
改
於是我在gitlab上加上了 【合並請求權限】，逼迫她去仔細思考自己的代碼，逼迫我必須去看她寫得每一行代碼。
合並請求權限
提交合並請求
代碼走查
其中有規范、命名、優化、風格、bug
......
收獲
是的，這些時間付出是有價值的。是潛移默化的。很多時候我們為了Review一個問題點，討論20分鍾。
一方面深入挖掘她當時的思路：是知識面問題？還是偷懶？還是知道這樣后期再優化？
另一方面，也把我的想法和思路進行交流。有幾次是我認知就是錯誤的，通過討論發現了更好的實踐。
其實代碼Review真的是一種非常好的實踐，我們不能以我們過來的人的眼光看待新人。
他們有他們的優點，當然他們也很可能會犯錯。我們使用一點時間，就能把這個問題給找到，對我們對他們都是一件好事。
再加上，代碼review也是把團隊和部門甚至公司的制度流程以及規范進行一種培訓。只是換了一種方式。
至少我覺得我是有收獲的，通過幾次交流，成員也說明自己確實有收獲。
剛剛進入社會，剛剛入行的軟件工程師們，不都是自律能力非常強的。都有惰性。
通過這樣的形式，讓她感知提升，增加自信心，所以后期很多時候她都會把一些好的想法，反過來給反饋給我，我覺得確實是。於是我就偷偷回去改我的代碼。
這也是一種溝通渠道，我覺得很多時候軟件就是在解決溝通問題。如何讓溝通做得有價值，有效率。
進
有了收獲，我依然想進行再一步的精進。找到一本書，能完全肯定我們現在做的事情是一種有價值事情的書籍。
《代碼整潔之道》 《重構2》
規定時間里閱讀完一章，找出系統中不好的，並按其思想進行修改。或者系統中已經這樣做的，找出來分析一下。時間不用很長。
從命名規范、函數分解、同一抽象層次分層、硬編碼、效率、類、模塊、甚至文件夾構成
為什么要做這些？
首先，我們先不去追蹤復雜的效率問題，先解決簡單功能實現，后期有人能看懂的問題。
這些實踐容易，並且效果明顯。有效果，我們就喜歡更深層次提升，再深入提升，就會自然而然晉升到了性能層面。
現在我覺得我和成員的一些討論都在討論執行效率。因為代碼的命名、分層已經潛移默化養成了習慣。
有了成就感，就有了動力，有了動力，再去研究就會更加主動一些。
我也因此偶爾再總結一下，確實好的代碼，令人心曠神怡，賞心悅目。更有讀下去的沖動，甚至更有模范的沖動。
K.I.S.S 原則、單一職責、多用組合少用繼承、最少知道原則等
很多時候，功能很簡單，我們卻寫得天花亂墜。
我幻想了一下，如果我們的客戶他喜歡編程，非要看源代碼實現呢？如果他看到源碼實現如此簡單優美，心中如何感慨？
有時，我也時不時小結一下。
新人需要我們的指導，才能避免一些彎路；
我們也需要不斷回爐鍛造；
對代碼多一些敬畏和欣賞~