代碼走查復盤
代碼走查的目的是什么？
首要目的自然是保證代碼質量
從參與者角度分為兩個目的：
代碼Show；
代碼指出問題或者更好的方案等，提升編碼能力
聚焦在哪里？
第一層級：
* 有沒有實現功能，業務邏輯的正確性，有沒有實現功能（首要），如果有大量的用例作為保證，其實這些都不是問題
第二層級：
1. 編碼規范
2. 算法范疇 or 業務邏輯本身
3. 編碼思想
團隊走查代碼的痛點在哪？
1、團隊代碼提交代碼過多，在壓縮走查時間的時候，團隊部分代碼無法排上檔期
2、代碼走查的人員構成
新員工
語言層面不熟悉，只能CC層面上的
老員工
功能沒參與，對詳細方案不太熟悉，容易成為局外人
沒有統一的標准，有些問題如何提
走查前期表述太過於粗略
部分模塊不熟悉，而走查代碼又基於現有模塊邏輯
3、代碼走查遇到爭議的時候如何快速化解（代碼沒走查幾段，討論了半天），討論發散或者糾纏在某個具體細節中，導致時間把控不好。
4、評審的同事對代碼不熟悉，發現不了問題
5、提問題的總是那幾個人，其他人都是圍觀群眾
6、任務緊的時候走查可能受影響
其他的思考？
1、怎樣的代碼算過
2、復雜的邏輯用ft守護，特別的算法
3、代碼評分
4、代碼走查各自的收益
5、走查的代碼一般都是編碼者權衡利弊之后
1、走查代碼主講人
代碼走查可以理解為講故事，作為講故事的人，要考慮如何讓聽眾聽懂你故事。
1、交代背景，講你設計思路
如何表述設計思路，要考慮如下：
1.1、 方案評審
方案評審這一過程做的怎么樣，或者方案是否比較細
1.2、 對代碼進行分類
代碼量的多少
代碼是否比較集中
代碼是否比較分散
代碼是修改現有功能
代碼是否一個新的模塊
1.3、 走查代碼的人
對涉及的模塊是否熟悉
是否參與了這個方案的討論
是否參與這個功能開發
一些技能的掌握情況
考慮這些之后，選擇粒度粗的還是細的表述，來比較直觀的表述設計思路。
口頭上表述可能比較模糊，不夠直觀，可以結合圖：流程圖，UML圖等
2、走查代碼方式
magiceye和其他網元對比有不同的業務場景，例如：前端呈現配置等。
1. 涉及前端
簡單的配置，或者前端的就能表述后端復雜的邏輯，這種功能相對比較容易走查，大家很容易理解思路
2. 業務邏輯不涉及前端，比較內聚的
這一種比較復雜，最好慢一點。最好講講如何建模的。
3. 偏向於流程的
可以快速過一下
4. 一個完整的功能
應該從設計層面來講解
總之，關注如下幾個方面：
* 有沒有實現功能
* 編碼規范
* 算法范疇 or 業務邏輯本身
* 編碼思想
3、增加互動環節(提問)
讓走查代碼的人有機會表達自己想法 ;對自己走查效果的檢驗，提高參與度，相互督促。
4、由參與者對上述環節進行評定，結合之前的代碼打分措施2020-08-07 *001 需求代碼梳理評分活動
2、走查代碼參與人
大家的代碼風格相似，走查代碼會相當輕松，錯誤有比較少， 走查代碼的效率會比較高，發現因為粗心或者其他原因導致的問題。
走查代碼前
走查代碼的人平時的自我修行
走查代碼中
參加走查提出問題（依據如下）
* 有沒有實現功能（易用性角度）
* 編碼規范：建立團隊的編碼規范
* 算法范疇 or 業務邏輯本身
* 編碼思想
* 其他 （並發和鎖、 性能問題、等）
當自己跟不上的時候，要提出疑問
@ 走查代碼主講人 的互動，來校驗參與走查代碼的人是否理解和跟上（上一條措施）， 形成了相互督促，避免走查代碼形式化
走查完代碼，看看收獲是什么，結合之前的代碼打分措施2020-08-07 *001 需求代碼梳理評分活動