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