敏捷開發：代碼Review

熱情高漲

代碼走查做爲一種流程形式，起初你們的參與熱情很是高漲。

由於，本身能夠學習到別人一些巧妙的思想，本身的代碼和習慣都暴漏出來。

這個過程當中不斷地吸取和改正。

可是。。。。。。

咱們一開始組織的代碼走查是一個很重的會議形式。

參加的人有寫這段代碼的人（小菜）、比較有經驗的開發（大佬）

若是爲了再隆重一些，請一些領導也參與其中。

可是。。。。。。

我上面提過了，會議很重，協調時間這個事情就是一個很費時間的事情。

還有就是，你們巴不得對每一句代碼都發表本身的意見，每每很是的細枝末節。

致使會議時間常常在2小時以上，3小時時間就通常不得不中止。

你們都很累，再就是效果如何呢？

若是小菜自律性不夠，甚至沒人進行監督，此次的審查的代碼不是都會修改。

由於有一些確實太過於雞蛋挑骨頭，根本改不動。

熱情褪去

不知不覺中，這種方式慢慢褪去。代碼走查成爲了一個優先級、頻次都不高的活動。

有不少緣由，上面說的形式過重是一個，還有就是你們都很忙了，沒有進行持續跟進致使效果不佳。

可是。。。。。。

也都知道代碼走查對一些新人來講，成長史毋庸置疑的。收穫也是毋庸置疑的。

慢慢你們也都放下了。只是每次項目迭代中做爲一個硬性要求執行一次罷了。

痛

咱們小組裏面只有我還有一個剛畢業一年多的女生。

在咱們組內的一個項目中，我老是以任務重爲由，沒有進行代碼走查。這個持續了很長時間。

一個字 —— 懶

在處理客戶反饋的問題時候，我忽然發現，她寫的代碼確實出現了比較粗心的失誤。

我心一想，長達3個月的時間都沒有對她的代碼進行任何關注。

於她於我於項目，都是極其很差的。我這塊作得太自私了。

改

因而我在gitlab上加上了 【合併請求權限】，逼迫她去仔細思考本身的代碼，逼迫我必須去看她寫得每一行代碼。

合併請求權限

提交合並請求

代碼走查

其中有規範、命名、優化、風格、bug

......

收穫

是的，這些時間付出是有價值的。是潛移默化的。不少時候咱們爲了Review一個問題點，討論20分鐘。

一方面深刻挖掘她當時的思路：是知識面問題？仍是偷懶？仍是知道這樣後期再優化？

另外一方面，也把個人想法和思路進行交流。有幾回是我認知就是錯誤的，經過討論發現了更好的實踐。

其實代碼Review真的是一種很是好的實踐，咱們不能以咱們過來的人的眼光看待新人。

他們有他們的優勢，固然他們也極可能會犯錯。咱們使用一點時間，就能把這個問題給找到，對咱們對他們都是一件好事。

再加上，代碼review也是把團隊和部門甚至公司的制度流程以及規範進行一種培訓。只是換了一種方式。

至少我以爲我是有收穫的，經過幾回交流，成員也說明本身確實有收穫。

剛剛進入社會，剛剛入行的軟件工程師們，不都是自律能力很是強的。都有惰性。

經過這樣的形式，讓她感知提高，增長自信心，因此後期不少時候她都會把一些好的想法，反過來給反饋給我，我以爲確實是。因而我就偷偷回去改個人代碼。

這也是一種溝通渠道，我以爲不少時候軟件就是在解決溝通問題。如何讓溝通作得有價值，有效率。

進

有了收穫，我依然想進行再一步的精進。找到一本書，能徹底確定咱們如今作的事情是一種有價值事情的書籍。

《代碼整潔之道》 《重構2》

規定時間裏閱讀完一章，找出系統中很差的，並按其思想進行修改。或者系統中已經這樣作的，找出來分析一下。時間不用很長。

從命名規範、函數分解、同一抽象層次分層、硬編碼、效率、類、模塊、甚至文件夾構成

爲何要作這些？

首先，咱們先不去追蹤複雜的效率問題，先解決簡單功能實現，後期有人能看懂的問題。

這些實踐容易，而且效果明顯。有效果，咱們就喜歡更深層次提高，再深刻提高，就會天然而然晉升到了性能層面。

如今我以爲我和成員的一些討論都在討論執行效率。由於代碼的命名、分層已經潛移默化養成了習慣。

有了成就感，就有了動力，有了動力，再去研究就會更加主動一些。

我也所以偶爾再總結一下，確實好的代碼，使人心曠神怡，賞心悅目。更有讀下去的衝動，甚至更有模範的衝動。

K.I.S.S 原則、單一職責、多用組合少用繼承、最少知道原則等

不少時候，功能很簡單，咱們卻寫得天花亂墜。

我幻想了一下，若是咱們的客戶他喜歡編程，非要看源代碼實現呢？若是他看到源碼實現如此簡單優美，心中如何感慨？

有時，我也時不時小結一下。

新人須要咱們的指導，才能避免一些彎路；

    咱們也須要不斷回爐鍛造；

    對代碼多一些敬畏和欣賞~