當我們在項目協同過程中，把要做的需求確認清楚後，接下來就要考慮如何將這些用戶故事，轉換爲可運行的代碼程序，這時候就輪到開發者們登上舞臺開始表演了。
雲效代碼管理Codeup就是這樣一款服務於開發者的產品。在Codeup上，你可以免費託管代碼、進行代碼評審和持續集成，並通過數據圖表跟蹤工作進展。目前已有百萬開發者和數十萬企業正在使用Codeup託管自己的代碼。
在去年，雲效Codeup針對代碼安全進行了全面的建設，從存儲安全、訪問控制，到代碼加密、備份，在風險事前、事中、事後提供了全面的安全保護能力。
除了爲大家保管好寶貴的代碼資產外，我們還希望能夠幫助大家更高效的工作。因此，今年我們在協作流程方面進行了一系列的改進，讓大家能夠更高效地互動，更專注地工作，進而實現更早地下班。
說到協作，作爲開發者，大家可能更喜歡獨自一人靜靜坐在電腦面前寫代碼的感覺，那是武林高手閉關修煉的感覺。但是，現代公司的項目一般不可能一個人100%就能全部做完，再厲害的武林高手也需要隊友。
隨着隊友人數的增加，人和人之間溝通的成本成平方增長，這時候溝通的有效性就變得至關重要了。怎麼溝通最有效呢， “ 神級程序員 ” 林納斯回答了這個問題，翻譯過來就是“多說無益，放碼過來”。在我們的日常工作中，這種溝通活動被稱爲代碼評審。
如何讓代碼評審更簡單
代碼評審可以集聚衆人之智慧，實現1+1>2的效果。沒人評審的代碼，其水準僅是編碼者的水準，而被團隊評審的代碼，其水準可以超越團隊的最高水準。
代碼評審是個好東西，但實際操作起來並不容易。接下來，我們從評審發起人、評審人和企業管理者的視角，去了解一下他們遇到的煩惱，以及通過雲效Codeup如何幫助他們解決問題。
1.評審發起人的煩惱
首先，對於需求開發同學來說：在創建評審時，他不得不頻繁地切出本地IDE，打開瀏覽器登錄代碼服務的網頁端，填寫一堆評審說明和參數，才能完成創建。
接着，評審建好了，但因爲管理員設置了各種合併的條件卡點，他首先得弄清楚哪些條件還沒滿足，然後才能逐個去解決卡點。否則代碼就無法上線，萬一誤了迭代週期，可不好和產品經理交代。
在解決反饋問題時，由於評審回覆是個異步過程，沒人知道評審人什麼時候有空來評審，特別是幾個人共同評審的情況下，評論分散，在動態裏一條一條的找甚是麻煩，效率真不太高。
使用雲效代碼管理Codeup之後，他現在可以這樣做：
無需頻繁地切換 IDE，在本地編輯器裏直接推送代碼，就可以在網頁端自動創建一個代碼評審，本地和雲端鏈接更加流暢；
即使在網頁上創建評審時，也支持分支、標題、評審人蔘數自動填充和描述模板建議，創建評審更輕鬆；
在推進評審的過程中，現在他無需思考太多，在頁面可以清晰地看到聚合的卡點條件和實時的達成情況，像打怪升級一樣解決掉這些卡點，就可以完成合並，推進評審更加專注。
在處理評審人反饋的時候，他無需在分散的時間線動態中尋找蛛絲馬跡，只需要關注待解決的事項面板，一眼可見全部待辦，處理效率大幅提升。
2.評審人的煩惱
另外，我們的評審人段譽同學也很不容易：
在專注工作時，他經常不時收到評審請求，打斷了手上的工作，暫時擱置吧，擠壓的評審一多，又不知從何看起；
在執行評審時，發現問題基本靠經驗，肉眼一行一行看代碼還是可能遺漏風險，肩負審查的責任，壓力山大；
而且，評審交流常常反覆，消息通知不及時，溝通效率起不來；
使用雲效Codeup之後：
在安排評審時間方面，現在，他開啓了雲效的評審耗時預估能力，可以直觀地查看每個評審的預估耗時。再根據預估見縫插針地合理安排碎片時間，利用午飯前的10min間隙也可以完成一個評審，執行力更強了。
在代碼評審的過程中，基於雲效開箱即用的自動化檢查能力，輔助人工評審，彷彿爲代碼上了雙重保險，讓檢查更快速，更精細，大幅降低問題遺漏到線上的風險。
在針對問題的討論交流階段，評審消息可以通過郵件釘釘等方式快捷觸達，消息感知更及時，溝通協作更順暢。
3.管理者的煩惱
我們的管理者也有一些煩惱。我們來看看他的一份聊天記錄：
有一天，產品經理在羣裏着急地催促：咱們功能什麼時候才能上線啊，再不上可要被別人搶先了！
而開發人員這樣回答：功能寫完了，但是還在等評審，而且有一些技術部要求的檢查還沒跑過，需要優化下代碼。
可是業務第一啊，在殘酷的市場上有時候速度就是生死牌，這時候他決定站出來保業務，放棄掉一些質量。
在面對迭代速度和工程質量的選擇上，其實他心裏也很糾結。業務必須跑起來，但是如果不管開發的質量，只會給業務埋下一個一個隨時會引爆的暗雷。
業務開發既要快又要好，使用雲效代碼管理之後，現在，他的團隊可以根據業務性質自行決定 “掃描的規則” 和 “卡點的規則”，讓代碼更快地流動起來。
在掃的規則上，我們知道，規則並不是越多越好。過多的規則只會給開發團隊帶來負擔，因此選擇合適的規則很重要。雲效精選了一批規則內置到了產品中，開箱即用，自動觸發，包括經過阿里集團多年實踐經驗總結的阿里巴巴Java開發規約、敏感信息檢測、源碼漏洞檢測等，將我們的經驗分享給大家。
除了掃描的規則外，他還可以自定義流程卡點的規則。例如對一些必須高速迭代，對工程質量有一定包容度的項目，可以走輕量評審，最低成本做自動化檢查，不設置嚴格卡點，便於必要時快速合併代碼。而對於迭代速度相對穩定，且對編碼水平有高要求的項目，可設置嚴格的評審卡點，確保代碼質量。
使用雲效之後，現在他可以在高速迭代的業務下同時兼顧代碼質量，從一部分合適的業務開始，逐步搭建起評審規範和流程，然後過渡到更多團隊。
雲效的自動化評審能力，平均每月爲每個企業自動發現200多個有效問題。以人工發現一個問題大概需要10min算，累計每月爲企業節省33小時的專家人力，讓他們可以把時間投入到產生更大價值的事情中去。
堅持代碼評審就像堅持運動健身一樣，不要高估它的短期價值，也不要低估它的長期價值。現在就開始吧，雲效將協助你把評審這件事變得更簡單。
分支協作如何才能更順暢
除了評審代碼外，開發者們在分支協作上的互動也非常頻繁。
我曾經遇到過一些團隊，開發者提交代碼沒有流程，生產分支經常衝突，甚至出現強行覆蓋了別人代碼的情況，搞的大家差點友盡。
開發者之間分支協作是否順暢，決定着他們是否能成爲朋友。小團隊尚且如此，協作人數達到十幾或者幾十人呢，多人共同開發一個模塊，這時候就需要約定一些大家都遵守的協作規則了。
對此，業界總結了不少協同的經驗，常見的有三種：Git-Flow、Github-Flow、Gitlab-Flow，每種模式有自己適合的場景：
例如大型項目交付週期長，參與人數多，需要避免不同環境下的代碼互相干擾，這種情況下選擇複雜的Git-Flow能夠更完整地支撐；
而對於以DevOps快速迭代的團隊來說，在開發得足夠快的時候，Master 和 Develop 兩個分支可能經常都是一樣的，而開發過程也會因爲過多的分支而變得複雜。如果不小心切換錯了工作分支，回滾又是另一件麻煩事了。這種情況下選擇github或gitlab的模式會更加輕量一些。
但無論 Github 模式還是 Gitlab 模式，仍然需要創建新的倉庫或者臨時的分支，這些都將成爲資產負債。那麼有沒有一種方式，不需要創建庫，甚至連臨時分支都不用創建呢？這樣管理成本最低，倉庫也更乾淨。
在這樣的思路下，雲效Codeup支持了一種新的Git協同工作流——推送評審模式，也稱爲 Agit-Flow。
使用推送評審模式，當你接到開發需求時，無需新建派生庫和feature或bugfix這類臨時分支了。只需要在本地對目標分支執行git push，就可以在雲端自動創建一個合併請求，發起入庫預評審。
結合自動化的檢查能力，針對每次推送都可以快速掃描和反饋，幫你定位問題並快速修復。持續的推送可以繼續更新合併請求，直到你的功能開發完成了，該跑的自動化檢測和評審也通過了，就可以將代碼正式合併入庫。
當然，如果有不同版本或環境並存需求的團隊，仍然可以基於主幹維護自己穩定的預生產和生產分支，或者不同版本的長期分支。
推送評審模式非常適合敏捷的、對代碼質量有一定要求的團隊。
對於技術管理者來說，推送評審模式還有一個附加收益，讓倉庫權限管理更加簡單了。
在從前，如果你要和隔壁團隊進行共建，或者有一些外包項目需要外部合作時，至少需要給予對方代碼庫的開發者權限，對方纔能進行代碼貢獻。
而現在，你不再需要給對方申請開發者權限了，更不需要給予新建派生庫的權限，只需要讓他能夠查看倉庫就可以了，他們就可以通過推送評審模式自由地貢獻代碼。可讀即可貢獻，合作管理更簡單。
我曾經遇到一個朋友，他們公司推行內源開放的文化，代碼庫對公司同事們開放可讀，鼓勵團隊間代碼共享，而他和他的一個兄弟部門合作比較密切。爲了更好地聯調配合，他抽空了解對方團隊的代碼邏輯，在閱讀中他偶然發現對方引用了一個最近報出高風險的依賴包，於是他直接上手改了代碼，通過推送評審模式發起了一個修改的請求，對方立即收到了釘釘通知，快速確認了改動進行了合併。整個過程10分鐘內搞定，非常高效地將風險扼殺在了搖籃裏。
總結
最後，請允許我總結一下：
在代碼評審的協作場景中，雲效支持了開箱即用的自動化代碼檢測服務，配合評審視圖的體驗改進，合併規則的靈活定製與消息通知的集成，讓評審協作更高效、代碼質量有保障。
在分支協作的場景中，雲效的推送評審模式讓我們不再需要維護複雜的臨時分支，推送即評審，讓開發更沉浸，合作更輕鬆。
在我看來，一個靠譜的代碼管理平臺不僅僅是託管代碼，而是能夠幫助你將代碼變得更好，並且更高效地交付出去。所以，雲效Codeup始終在圍繞如下三方面努力，爲大家打造一個真正好用的代碼管理平臺。
1、安全：安全是基礎，打牢基礎，我們提供了完備的安全能力。
2、協同：協同是引擎，強化引擎，我們改進了協作的高頻場景。
3、開放：開放是導航，拓展邊界，我們擁抱外界豐富的連接。
本文爲阿里雲原創內容，未經允許不得轉載。