当我们在项目协同过程中，把要做的需求确认清楚后，接下来就要考虑如何将这些用户故事，转换为可运行的代码程序，这时候就轮到开发者们登上舞台开始表演了。
云效代码管理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、开放：开放是导航，拓展边界，我们拥抱外界丰富的连接。
本文为阿里云原创内容，未经允许不得转载。