無人問津的CR
“CR（Code Review）作為工程師日常工作中重要且不可缺少的一環，需要每位工程師積極參與。作為質量部門，培養Code Review的習慣，從白盒更深入的瞭解邏輯，避免漏測，同時加強測試左移，直接從代碼層面開始測試，也是重要的engineering discipline.”。這是FY20 11月初國際質量和技術風險部啟動全員（P7 以上）CR動員郵件中，@木雨 提到的。
CR 是本應該是每一個 QA 同學日常工作的一部分，但可能是項目多，併發高，很多同學並沒有CR的習慣，有些即使參與了CR，也流於形式，在CR會議上，忙碌著自己的工作，被CR同學的講解“若隱若現”飄過耳邊。
慘不忍睹的三連黑榜
即使做了全員動員，但是每週必須一次CR，並未得到團隊同學的重視，理由很多：沒時間，開發沒提交代碼MR，看不懂別人業務邏輯不知道CR啥，CR的問題被開發懟了怎麼辦，CR好像沒什麼用吧。
於是全員CR 啟動後的前三週，連續三次黑榜。
Code Review，21天從入門到精通
既然CR是公認的工程師文化最重要的一部分，那麼正確的事，就應該被堅持。既然靠講道理講不通，那就換個方式“被動習慣養成”，又稱“push”。
某天，義理在看了三次黑榜之後，無法忍受，提出來“誰來解決下團隊CR長期黑榜的問題”。於是，第一代“CR push 一號位” #悟隆 主動承接這個任務。接手後，團隊所有P7 以上人員，拉群，並起名“逃離CR黑榜計劃”，約定3條獎懲制度：
1）群內所有同學每週必須一次CR，忘記的一次罰100，二次200，三次400，依次類推；CR push 一號位如果忘記本週統計，罰款加倍。
2）優秀CR ，通晒，且要得到獎勵。
3）老闆忘記CR，自己看著辦。
據說，一個習慣的養成，只需要3周21天，就這樣，“CR被動習慣養成計劃” 正式拉開帷幕，並於當週脫離黑榜，開啟100% 全員CR之旅。
做一個堅持全員CR 102周的團隊
Push 的手段，可能不算高明，但行之有效。自Push 第二週，團隊全員CR 開始100% 完成，並堅持了下來。
漸漸的，我們開始進入最高連續紅榜候選人（彼時最高紀錄是連續7周）。
漸漸的，我們開始變成了紅榜常客（記錄第一保持者）。
漸漸的，我們開始孤獨的佔據紅榜（身邊的隊友慢慢的時不時落下榜單）。
漸漸的，我們開始從“逃離黑榜”到“爭取第一”再到“爭取連續102周全員CR”（阿里要做102年的企業）。
如同一列遠行的火車，目標清晰，一旦啟動了就無法停止。半年多時間，列車掌控人也從 #悟隆 換成了 #瀚熠 再換成 #秋冬 ，大家為這個目標奮鬥中。
三分之一的優秀CR佔比
團隊在堅持全員CR的同時，還提供了國際質量與技術風險約 1/3 的優秀CR（6/22）。而且，不同於java的研發，在數據域的CR工具和機制還不夠完善的情況下，我們團隊的同學仍然堅持以各種方式參與數據域的CR，發現不少數據質量、性能、運維、安全上的問題。
以下是我們部分CR案例：
勿以善小而不為
今年是安全生產年，質量風險絕不僅僅是測試一道防線可以解決的。CR 本質是測試左移，可以從代碼層面就開始測試。高質量的CR，可以挽回不少問題，甚至是發現測試過程難以發現的問題。
一人一次CR也許無法讓問題數瞬間跌0，但有人說過，今天的0故障，不是因為今天的代碼做的好，而是3個月前，甚至是半年前的代碼做的好。那麼今天，一人一次高質量的CR，是否可以讓未來3個月或者半年不出故障呢，我們相信一定有幫助。