【方法论】 代码管理的发展、工作流与新使命中篇原创

关于什么是get out的这个问题，一位工程师给出了三句很精辟的描述，第一句是deep as the single source of the truth of a system，意思就是说代码仓库是整个系统的单一可信数据源。第二句是it as the single place where we operate create change and destroy，意思就是说所有的变更活动都围绕着代码仓库来进行的，包括创建、修改和销毁等动作。第三句描述是all changes are observable veryfiable，意思就是说所有的变更都是可察觉、可检验的。除了这三句描述以外，我们还可以用一条公式来定义街道，就是基础设施及代码合并请求加持续集成或者是持续部署。接下来，我们一起来看看如何在codings平台上实现街道S吧。首先，我们创建两个不同的代码仓库，其中一个用来存储应用程序的代码，另外一个用来存储应用程序的配置文件。之所以将应用程序的代码和应用程序的配置文件存储在不同的代码仓库，主要是基于两点考虑，第一点是为了实现持续集成和持续交付，我们的持续集成流水线默认会启用一个触发器，这个触发器一旦监到应用程序的源代码有变更，就会自动触发相应的CI流水线。如果我们只是变更了配置的话，则没有必要发应用程序的CI，因此需要将配置相关的文件存储到一个单独的代码仓库，并关闭相应的处罚规则。第二点是我们修改业务代码的频率会远多于修改配置的频率，如果存储在同一个代码仓库，提交记录会很多很杂，很难进行问题的追溯。接下来再来看看我们的。

整个街道工作流下面讲解的是push模式，还有另外一种po的模式，因为时间关系就不展开了。首先开发人员会提交程序代码到coding代码仓库，这个时候我们会进行代码评审，只有评审通过以后，我们才会将他提交的代码合并到主干分支。一旦有新的程序代码提交到主干分支，就会自动触发相应的coding只持续集成流水线并构建产物。这里是多可镜像推送到coding制品库，当coding的持续部署模块监听到有新的多可镜像被推送到coding制品库后，就会自动触发相应的持续部署流水线，将新的高可镜像发布到K8S集群。

对于运维人员而言，他们将无法像以前一样直接执行诸的命令来操作KS集群，所有的操作都将围绕着代码仓库来进行。比如，当运维人员将要修改某项配置时，他需要将更新后的配置文件提交到Co代码仓库，当评审通过以后，相应的配置文件将会合并到主干分支。

当Co的持续部署模块监听到相关的配置文件有变更以后，就会触发相应的持续部署流水线，将新的配置发布到我们的KS集群。这么做的好处在于，所有的权限控制都将通过代码仓库模块来进行集中管理，我们将不再需要给所有的运维人员开放KS集群的访问权限，大大提高了集群的安全性。此外，由于所有的操作都是围绕着代码仓库进行的，因此所有的操作都会有相关的提交记录，方便我们快速追溯问题。coding的持续部署与应用管理obbi正是基于get道的理念设计的，这是obbi的截图，它的一大特点在于以应用为中心，在左上方是应用的概览，右上方显示的是当前未发布的变更与已发布的记录，下方则是不同的环境信息，所有重要信息一目了然。此外，OB。

支持一键回馈功能，支持模板化和版本化。通过结合coding的代码仓库模块，可以实现云资源的代码化管理，所有的变更都可追溯、可审计。在介绍coding代码管理解决方案之前，我们先来了解一下代码评审的重要性吧。做一件事情之前，我们要清楚为什么要这么做。那么代码评审能带来哪些收益呢？具体而言有以下几点，第一，代码评审可以帮助规范化代码，提高代码质量。第二，通过代码评审，我们可以熟悉其他团队成员正在开发的功能，从而保证每项开发任务都有后备人员。这样一来，如果某个同事有急事临时休假了，我们的工作仍然可以有条不紊的进行，而不是停滞不前。

第三，在代码评审的过程中，我们可以聆听到不同团队成员的建议，学到一些新的技术，并将其应用到我们的项目中去，而避免技术债的积累。第四，借助代码评审，我们能够在早期阶段发现一些错误，从而将影响范围降到最低。第五，通过代码评审，我们可以更深入的了解每个团队成员的任务完成情况，从而更好的把握项目进度，提前识别潜在的风险。第六，在代码评审的过程中，资深的员工可以给初级员工传授经验和知识，从而提高团队的整体水平。第七，借助代码评审，我们可以发现同事正在编写功能，在之前是否已经编写过，从而避免重复造轮子。第八，在代码评审的过程中，我们可以借助同事的反馈意见对程序进行优化，从而提高程序的性能。

第九，通过代码评审，我们可以更好的了解某项任务的复杂度，从而更好的预估成本。第十，借助代码评审，我们可以检查开发人员在开发的过程中是否严格按照功能设计文档中的要求进行开发，从而保证设计和实施的一致性。当然了，以上这些只是很小的一部分例子，代码评审所带来的收益远不止这些。虽然代码评审能为我们带来很多收益，但是有一点不可否认的是，代码评审确实需要花费不少的时间。不过从长远来说，只要采取科学的方法进行代码评审，最终的效果是可以为我们节省大量的时间的。接下来我带大家一起学习这方面的最佳实践，帮助大家科学有效的进行代码评审吧。代码评审的第一条最佳实践是我们要明确目标和期望，只有这样做，我们才能更好的朝着这个目标和期望去开展相关的工作。第二条，代码评审应该遵循solid原则，至于什么是solid原则，我会在稍后给大家解释。第三条需要创建一个评审清单，在这个评审清单中应该明确我们要从哪些方面去评审代码，比如说可读性、安全性、可重用性和架构设计的。

第四条我们一次应该写评审200~400行代码。根据国外的一项研究表明，评审代码的数量并不是越多越好，超过这个量，我们发现缺陷的能力就会降低。右边的图描述了缺陷密度与评审代码函数之间的关系。缺陷密度就是说每一些行代码中所发现的bug数。当评审代码函数数量超过200时，缺陷密度就会急剧下降，当评审代码函数超过400时，缺陷密度几乎为零了。因此，一次最好是评审200~400行代码，这样才能获得最大的收益。

第五条单次评审时长不宜超过90分钟。人的精力是有限的，在进行大约60分钟的代码评审后，评审者就会感到疲劳，此时的他就很难找到额外的缺陷了。因此，我们应该将评审时间控制在90分钟以内。第六条在代码评审的过程中，我们应该给予建设性而不是情绪化的反馈意见，因为所有负面的情绪其实都会对我们的工作效率造成不好的影响。因此我们应该互相尊重，在处理问题时应该对事不对人，只有这样我们才能营造和睦的团队氛围。第七条写完代码以后应该先自测，自测没有问题以后，我们应该通过自动化流水线来进行自动检测，当自动化检测也通过以后，我们再提交给同行进行评审。这么做是将一些明显的低级错误先排除掉，从而节省评审者的宝贵时间。

以上就是一些最佳实践，希望我们分享的这些最佳实践可以帮助大家更科学有效的进行代码评审。接下来就来聊聊前面提到的so原则到底是什么吧。so原则起源于敏捷宣言的17位作者之1MARTIN，他在2000年发表了一篇名为design principle and design partners的论文。在零四年前后，有人对Martin提出的设计原则进行了提炼，最终得到了现在所说的solid原则。它其实包含有五条原则，SOLID1词中的每个字母分别来自于这五个原则中每个原则的首字母。其中S所代表的原则是single responsibility principle，翻译过来就是单一职责原则，O所代表的是open close principle，翻译过来就是开闭原则，L代表的是底是替换原则，I是接口隔离原则，D是依赖倒置原则。由于时间关系，我们就不逐一讲解每个原则的含义了。我们这里就选取open close p开辟原则来做一个简单的介绍。开立原则指的是我们所编写的软件实体，例如类核方法应该是可扩展而不可修改的。接下来我就用一个具体的例子来详细讲解。我们先来看一张截图。

展示的内容就是扣点代码仓库模块的代码评审功能，它支持主行评论功能。当我们将鼠标选停到某一行代码下面时，左侧就会出现一个蓝色的加号按钮，通过点击这个按钮，我们就可以针对开发人员提交的代码进行逐行评论。除此之外，Coding的代码评审功能还支持文件对比和代码高亮显示等功能。接下来回到开辟原则吧。在左边的代码块中，我们可以看到开发人员写了一个名为C类total order的方法，在这个方法中，他使用了多个if和LC来针对不同的商品类型进行不同的价格计算。显然这种写法是不利于他人对这个方法进行扩展的。

按照当前的写法，如果有一天增加了一个新的产品类型，我们就不得不修改这个现有的CC total order方法了，这就违背了solid原则中的开辟原则。根据开立原则，我们所编写的软件实体，例如类和方法，应该是可扩展而不可修改的。更理想的一种实现方式是添加一个名为product的负类，并在这个名为负类中添加一个用于计算产品价格的抽象方法，然后为每种产品类型分别创造一个类，并继承这个名为product的负类，再去重写product这个负类中用于计算产品价值的方法。

借助coding所提供的代码评审功能，我们可以将以上的反馈信息填写到右上角的这个文本框中，然后可以在下方选择需要改进选项，最后点击完成评审按钮。这样做代码的提交者就可以根据我们的反馈意见对代码进行优化，优化完毕以后再次提交代码合并请求。我们在这里展示的是一个错误的写法，那么正确的写法应该是怎样的呢？如图所示，这是正确的做法。首先我们会创建一个名为product副类，在这个副类中我们会添加一个名为get base price和一个名为calculate test price的方法。我们还会创建一个名为shopping car service的类，这个类主要用于计算整个订单的总价。除此以外，我们会为每一种商品类型添加一个类，并继承product大负类在重写里面的get base price和chocolate类test include price方法。在这种方式下，当需要新增一个新的产品类型时，就不需要改动任何现有的代码，只需要为这个新的产品类型添加一个类，并让这个类进行product复类并重写里面的方法即可，这就很好的符合了开辟原则的要求了。

讲完开辟原则，我们再来看看使用相关的一些最佳实践吧。第一条最佳实践是频繁更新功能分支。比如每天下班的第一件事就是先执行get po，拉取最新的代码。这么做的好处是可以提前发现冲突，降低代码合并的复杂度，同时也能保证我们所有的工作都是基于最新的代码进行的。第二，及时删除那些已经过时的分支。如果我们不及时删除那些已经合并到主干分支的功能分支的话，分支就会越来越多，影响工作效率。第三，分支名称要做到顾名思义，如用图所示，我们给分支命名时可以分成四个部分，第一部分是分支类型，比如这个分支主要是用于开发功能的，我们可以使用feature啊，如果这个分支主要是于修复线上问题的话，就可以使用host。这么做的好处在于，我们可以根据其类型对分支进行分组和筛选。

第二部分是功能模块。比如使用这个分所开发的功能是跟平台相关的，我们就可以使用platform，如果使用这个分支所开发的功能是跟计费相关的，我们就可以使用B。第三个部分就是是像ID，比如这次开发的功能所对应的需求ID是123，那么这部分我们就可以使用123。最后一部分是功能描述，比如这次开发的功能主要是为了支持o of验证，那么我们在这部分就可以使用of two。第四个最佳实践是规范化commit message。我们先来看一张图，图中有两个com message，第一个就是一个错误的例子，因为里面的信息太含糊了，只是说添加了一个Java类，缺乏有用的信息。而第二个例子只是一个正确的写法，因为它说明了添加这个Java类的作用是什么，方便后期进行问题回溯。此外，还可以借助一些第三方工具来帮助更好的去编辑commit message。右边的这个截图呢，就是其中一款名为c that工具的运行效果图，借助这类工具可以有效的规范化。com message。

第五，尽量缩短功能分支的存活时间。随着时间的推移，功能分支和主干分支的差异就会越来越大，合并的难度和风险也会随之增加。因此，我们应该提高开发的效率，尽可能缩短分支的使用时间。第六，提高commit和push代码的频率。这么做一方面是为了减少代码合并的复杂度，另一方面是为了保证其他同事可以尽早知道我们改动了哪些文件。

第七，每组变更都要单独执行一次代码提交。这样做是为了保证每次代码提交记录中被修改的文件都是相关的，也就是我们所说的原子性提交。这么做的好处在于，我们的回滚操作就会变得更加简单。举个例子，假设我们修改了一个变量的名称，相应的变更跟着我们修复一个bug所做的变更混在一起进行提交了，事后发现那个变量的名称不能随便修改。当我们决定回滚的时候，就会面临一个困境，因为变量重命名所做的变更跟修复某个bug所做的变更混在一起进行提交了。现在如果回滚了此次提交，那这个bug就会再次出现。因此，更理想的方式是每次提交所包含的变更内容都应该是相关的，不相关的内容应该进行合理的拆分，然后进行多次提交。在前面的分享中，我们已经学习到代码评审能带来很多的收益，但是也会花费较多的时间。那么有没有办法可以帮我们提高代码评审的效率呢？答案是有的，就是使用Co所提供的代码扫描能力来对开发人提交的代码进行持续扫描。

静态代码扫描的优点在于，由于是使用机器执行扫描，因此执行速度更快，效率更高，还可以更频繁甚至无间段的执行。另一个优点在于，Coding的代码扫描功能可以帮助我们精确定位问题所在的位置，从而缩短漏洞的修复时间。除此以外，我们还可以根据代码扫描结果设置安全门禁，如果扫描结果不通过，就不允许用户将其提交的代码合并到主干分支，从而持续提高代码质量。第四个优点在于，通过设置触发器，开发人员每次提交后都会进行一次代码扫描，开发人员可以针对扫描结果中给出的修复建议对问题进行修复。

修复完成后再重新提交，这样就可以保证我们提交给同事进行评审的代码都是经过各项检测的，不存在明显的低级错误，从而有效减少代码评审人员的工作量。第五个优点在于，通过查看代码结果里面的修复建议，我们的开发人员可以积累相关的最佳实践，避免再犯同样的错误。在讲解第六个优点之前，先来看看右边的这张图，85%的bug其实都是在编码阶段引入的，如果我们在这个阶段对这个bug进行修复的话，成本是很低的。相反，如果我们在系统已经上线后再去修复，Bug的修复成本就会呈指数上升。换言之，我们必须及早发现问题，才能降低修复成本。

为了实现这个目标，我们可以在coding代码仓库模块设置触发器，只要监听到有新的代码提交记录，就会自动触发代码扫描，然后针对代码扫描设置质量门禁，如果没有通过质量门禁，则不允许进行代码合并操作，这样就可以实现安全左移，帮助开发人员及时发现问题，缩小影响范围，降低收购成本，提高系统的安全性。这也正是静态代码扫描的第六个优点。在详细讲解coding在代码管理方面的能力之前呢，我们先来看看coding的能力全景图，如图所示，Coding是一站式de研发管理平台，涵盖了软件开发生命周期中的各个阶段。在这一节，我们将会从存储、度量、协作和安全这四个维度去了解coding在代码管理方面所提供的能力。在存储方面，Coding的代码仓库提供CDN加速、PPG签名、邮箱校验。

高可用架构和冷热双备份等功能。在度量方面，Holding的代码仓库提供近期MR列表、近期代码提交、统计代码提交、排名和合并请求排名等报表功能。在协作方面，Co的代码仓库同时支持D和SBN，此外还提供代码评审、问题跟踪、合并请求注释、检查where IDE surface库和open API等功能。而在安全方面，Coding的代码仓库支持HTTPS和SSH2种协议，此外还提供精细化的权限管控、保护分支隐藏、分支锁定文件、代码扫描、两步验证、白名单和审计等功能。接下来我们将对每个功能进行逐一的介绍。coding采用高可用的数据存储架构，各项服务对数据进行实时备份，防止因操作失误或系统故障导致数据丢失。托管至Co的文件都有实时热备机制RPO，也就是恢复时间目标是小于一分钟的，除了热备以外，还有冷备，每天进行增量备份，每周进行全量备份。此外，Coding的代码仓库模块还依托腾讯云提供。

CDN加速能力，通过选取临近节点提供服务，大大提高拉取代码的速度。同时，Coding还支持邮箱校验和GPG签名，可以有效保证数据的准确性。如图所示就是coding所提供的度量功能，其中了丰富的报表模板，其中包括代码提交、成员排名、近期代码提交统计等。在协作方面，Coding同时支持GI和SCN2种仓库类型，支持快速初始化仓库，而且内置代码扫描功能。此外还提供了丰富的预置模板供用户选择，这就是coding代码仓库模块的合并请求功能。我们可以对其他同事提交的合并请求进行评审，并给出相关的改进建议。coding所提供的合并请求功能还包含一些高级用法，比如我们可以选择是否自动删除原分支，还可以选择在内容变更后自动取消授权。而且支持多种合并方式，用。

用户可以根据实际需要进行选择。cloud studio是Co推出的一款I定也支持多人协同编程，还聊天和视频。我们可以使用class studio进行代码评审、在线课堂、低代码开发、远程结对编程和远程技术面试等。借助class studio所提供的协同编程能力，可以让沟通更便捷，缩短反馈周期，从而大大提高我们的协作效率。借助Co所提供的邮箱校验功能，我们可以检查代码提交者和代码提交作者的邮箱是否已经在coding中注册过，如果没有注册过的话，则不允许用户进行提交。通过coding所提供的注释校验功能，我们可以检查开发人员的commit message是否符合相关规范，如果不符合则不允许提交，从而实现com message的规范化。如图所示是coding所提供的问题跟踪功能，通过将代码提交记录与相关的事项进行关联，我们可以实时掌握某个事项的进展情况，同时大大增强数据的可追溯性。这是coding所提供的surface cook功能，借助surface cook，我们可以监听关键变更事件。比如当我们监听到有新的代码提交到代码仓库时，可就可以自动触发代码扫描，并将代码扫描结果发送到相应的企业微信群，方便相关人员快速做出响应。

透顶还提供了丰富的open API，用户可以很方便的将coing与第三方应用进行集成。在安全方面，Co的代码仓库同时支持STTPS和SSS2种协议。此外，我们还可以设置保护分支，开启保护分支后，只有特定成员可以将代码提交至该保护分支。除了保护分支以外，我们还可以设置隐藏分支，设置完成后，只有具有相关权限的用户才能看到隐藏分支，这就是保护分支的相关规则。我们可以禁止强制推送，还可以开启状态检查功能，开启后只有通过状态检查才能进行合并。此外，我们还可以设置自动添加科技管理员作为合并请求的提升者。coding还提供了精细化的权限控制，我们可以统一配置所有代码仓库的权限，也可以针对指定仓库配置权限。

此外，Coding还提供了审计功能，我们可以实时查看代码仓库相关的操作日志。这是coding所提供的文件锁功能，我们可以锁定某个文件或者某个目录。文件被锁定以后，其他人将无法修改或者删除该文件，可以有效防止重要文件被误改或者误删。借助这个功能，我们就可以防止其他人修改某个文件，从而有效缓解合并冲突。前面我们有讲到所原则中的开运原则，借助文件锁功能，我们就可以将那些不应该被改的文件进行锁定，从而强制进行开立原则。coing还支持两不验证功能，用户登录时不光要输入账号、密码，还需要提供已经进行绑定的两部验证APP上的临时验证码，从而保证企业的信息安全。coding还提供ID白名单功能，开启后只有添加到白名单的IP才可以访问该团队的资源，对于不在白名单里的IP，在尝试拉取代码时，就会到右边截读中的错误。coding代码扫描由腾讯云代码扫描提供能力支持，是一款为团队提供代码分析、代码质量度量的平台。

借助静态代码分析的技术，对代码进行综合的分析和度量，并输出多维度的质量报告，帮助团队达成测试左移，并与coding上下游工具链联动，提升软件交付质量和速度，降低企业研发成本，实现研发效能提升。

Holding的代码扫描功能，内置棕色的扫描规则，用户可以按需选择，如果这些现成的规则不能满足用户的需求时，还可以添加自定义规则，此外还支持路径和问题的过滤。左边的截图是扫描方案的一个模板，我们可以设置圈复杂度、重复代码本指标的衡量标准。右边的截图是创建扫描方案时的输入界面，在这个界面中我们可以配置要扫描的语言以及规则包的。左边的截图是质量门禁的设置页面，我们可以根据实际情况来设定不同类型的质量门禁的门禁阈值。右边的截图是代码扫描任务的触发规则，我们可以在用户推送代码时触发代码扫描，也可以在用户创建合并请求时触发代码扫描，这是代码扫描结果盖览页截图左上角质量评分功能，通过对代码质量进行评分，可以让我们更直观的了解代码质量的变化趋势。

除了质量评分以外，他还提供了多种分析指标，帮助用户从多个维度去分析代码的质量问题，这些指标包括代码重复率、圈复杂度等。这是con的持续提成流水线的截图啊，支持文本编辑和可视化编辑两种模式。在可视化编辑模式下，用户可以通过菜单快速创建代码扫描步骤，再通过添加相关的触发器配置，可以实现用户每次提交代码都自动触发这个代码扫描的流水线，并将相应的扫描结果发送至企业微信群，方便相关人员快速做出响应。值得一提的是，Co的代码扫描功能支持增量扫描，可以大大节省扫描所需的时间，这就是这条代码扫描流水线的执行效果图。通过配置这么一条代码扫描流水线，我们不需要进入相关的界面去查看代码扫描结果，因为系统会自动将代码扫描的结果推送给我们，帮助我们实时跟踪代码指量问题进行发展趋势。这是代码扫描的问题列表，我们可以将这些结果进行导出，也可以对其进行排序和筛选。这是某个问题的详情页面，我们可以根据代码的提交者自动匹配责任人，同时还支持自动检测问题的发现版本，并自动定位问题的具体位置。此外，我们可以对指定规则进行屏蔽。这是合并请求的详情页面，从图中可以看出，所有的关键信息都在一个页面展示，我们不需要切换页面就可以看到代码扫描结果，如果没有通过质量门禁的话，允许合并按钮就会被屏蔽掉。

这样可以帮助我们自动拦截有问题的代码，持续提高代码质量。那么本次课程就到此结束，感谢大家的收看，Coding代码协作与代码扫描的完整演示视频将由来自腾讯云coding团队的解决方案架构师钟其翁为大家进行演示与解说。由于时长原因，演示部分将在三个工作日内同本视频一起上传至视频号，感兴趣的同学可以关注本视频号进行观看与学习。同时欢迎截图并微信扫码添加coding官方小助手，加入公开课专属群聊以及讨论技术，交流观点，了解coding并获取本次课程的课件以及下次课程的通知，让我们下次课程再见。