https://blog.csdn.net/uxyheaven/article/details/49773619

最初來到這個新組建的團隊是木有code review的. 頭說, 這個月你來搞吧.

當我第一次知道必須得搞review的時候, 其實我是拒絕的! 因為我覺得…呀…你不能叫我馬上搞立馬搞, 第一, 我要試一下, 我又不想說…團隊之前就沒有這個習慣. 我搞了以后, 那個耽誤每天的工作時間啊. 結果同事一定會罵我, 給他們增加額外的工作量. 我說先讓我嘗試嘗試. 現在呢…每天都在review!每天都在review呢…我還推廣到了其他團隊!來!來!來!大家試試看!

覺得困難, 開展不起來, 想拒絕的原因有很多:

• 團隊成員寫完需求就不管了, 沒有code review意識
• 技術氛圍不強
• 水平參差不齊
• 沒有合適的工具
• …

但是總的來說就是一條, 木有code review. 如果已經有了, 無論是真的在搞, 還是形式主義, 主持一下都是不難的.

從零到一, 從無到有總是困難的, 咱開始了若干次嘗試之路:

第一次嘗試

最初的版本是其他團隊的寫的, 到我們團隊接手的時候, 啥都木有. 什么逗號等號左右不空格, 類名首字母小寫, 方法名首字母大寫; 依賴亂七八糟; 在view里寫業務, 在view里發網絡請求. 看到這樣的代碼我當時心里是崩潰的.

我先嘗試一個人幫整個團隊review. 零散看了幾天, 問題代碼貼了幾十張ppt, 槽點太多, 看起來很感人. 后來自己放棄了.

結論

Code Review 一個人看所有人的代碼是不可取的.

第二次嘗試

結對編程可以看做是一種敏捷化的Code Review. 直接結對會被頭劈死. 于是我想著采用新的結對編程方式.

兩位程序員新成結對小組, 每人一臺電腦, 坐在臨近的工位上, 兩人合作完成一組功能(可以是兩個或多個獨立的模塊)的設計, 代碼實現. 但對已某一個模塊來說設計和代碼是分開的, 一個人負責設計, 另一個人負責寫代碼, 對于其他模塊則反之.

當我在團隊里尋找可以結對的伙伴的時候, 發現木有可以設計模塊, 項目進度又差不多, 可以結對的小伙伴.

結論

Code Review的模式需要接地氣.

第三次嘗試

第三次嘗試, 我想用一個游戲的方法去開展review

• 每次的review主持輪流當, 由大伙推舉當前找得bug最少的同學來主持.
• 每輪開始的時候,先貼出代碼來, 由下面的同學說問題.(大伙這個時候關注下哪位同學次次都木有發現問題)
• 最后由主持的同學將所有的問題列出來.
• 進入下一輪
• 如果經常是下面的同學說的比主持人多,主持人第二天繼續.
• 主持的同學,每日最少準備6張問題ppt斷.
• 指出的問題由主持人來指定一個修改的同學修改.
• 第二天的主持人負責把當天得bug錄入jira, 并且負責跟蹤這些修復.

太理想化了, 根本開展不起來.

結論

不要自己覺得好就是好, Code Review是團隊的事情, 方案定了得拿出去溜溜.

第四次嘗試

無奈之下, 我去請教我的頭, 如何去開這個頭. 頭就給了兩個字: 強壓.

于是小伙伴們便在我的淫威之下開展了第一次的code review. 我用的是之前第一次整理出的ppt. 效果竟然好的意外. 小伙伴們互相吐槽被我指出來的渣渣代碼, 氣氛很是歡樂.

不過關鍵問題還是沒有一個統一的標準去改. 于是咱緊接著就安排了一場代碼規范的分享. 再接下來的一次review, 大貨吐槽的點就相對集中了.

結論

Code Review初期需要有標準. 讓小伙伴們知道如何去review.

第五次嘗試

由于之前的氛圍很好, 有小伙伴A提議拿出他負責的模塊來集體review. 有主動的, 當然不能拒絕. 后面幾天安排的都是review他的模塊了. 順帶還做了一次他的模塊的設計分享.

在有天的review中, 有個小伙伴B表示這樣現場重構不是他擅長的. 我們: 那你擅長啥? 小伙伴B: 我擅長xxx. 我: 那下周你來給大貨分享下吧. 小伙伴B: 好, 我準備一下.

結果小伙伴B深藏不漏, 連續分享了一整個系列.

結論

聞道有先后, 術業有專攻, 不要低估你的小伙伴們. 給他們展示自己的機會.

第六次嘗試

我被掛的任務是code review, 所以偶爾還是會看看小伙伴們代碼的. 有天突然發現有個小伙伴C, 在重構優化代碼了. 咱順勢和他說了一些編程方面的思想和技巧, 告訴他還可以這么重構, 用查表發代替條件語句, 用多態代替提條件語句, 用runtime生成方法名, 用runtime 執行方法. 于是他也出來一個技術分享. 可惜的是關于編程思想的分享討論起來就木有那么激烈了, 這個只能慢慢來了. 不過當咱吃完飯快8點回到公司的時候, 發現有兩個小伙伴DE在寫demo, 在討論之前C的技術分享.

結論

不能急于求成, 一股腦的灌; 編程的思想需要慢慢悟, .

第七次嘗試

有次review, 我有事提前走了. 但是呢, 本是半個小時分享大伙覺得還不盡興, 又延長了二十分鐘. 之前有幾場分享, 也都不是我主持的. 后續的review我將嘗試進一步淡化我的主持. 讓我們的review可以自組織的進行下去.

結論

Code Review需要達到理想的狀態 - 不需要我也能自如地運轉, 不然最后就會輪為政治任務.

第八次嘗試

到了第八次嘗試,基本已經定型. 感謝公司提供gitlab代碼托管平臺. 我們再第一時間將團隊多個項目遷移到了新平臺上去, 然后開發流程改成了gitflow, 當一個功能開發完成后, 會發起Merge Request, 大伙在這個時候便可以開始code review了,互相吐槽的言語和片段也都被記錄了下來, 當收集齊了兩個贊的代碼, 才允許合并進來. 整個過程感覺良好.

結論

Code Review需要有工具, 需要有不reivew不讓合并的規矩.

建議

如何做出從零開始code review呢, 我的建議是:

• • tech leader 強壓所有人開始 code review, 這是最重要的一步
  • 安排一次編碼規范的技術分享
  • 前期經常回顧, 這次的code review開展的怎樣, 有哪些地方可以改善
  • 對于積極的同學表示鼓勵, 支持現場重構代碼
  • 每天不光可以review代碼, 也可以安排整場的技術分享

轉載于:https://www.cnblogs.com/davidwang456/articles/9443416.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的从零开始Code Review的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。