BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

CODING王振威:如何有效提升研发组织的效率?
录制于:

| 受访者 王振威 关注 1 他的粉丝 作者 InfoQ 关注 10 他的粉丝 发布于 2018年8月9日 | BCCon2018全球区块链生态技术大会,将区块链技术的创新和早期落地案例带回您的企业
32:18

个人简介 王振威,CODING 研发总监,多年来一直从事软件开发一线的各种前端、后端、运维、管理、产品等各方面工作。在企业研发管理、代码管理流程、敏捷开发实战、容器云技术落地、运维监控方案等方面有极为深刻的认识。在 Linux、Docker、Git、Java、Golang 等技术领域有多年深入经验。作为 CODING 创始成员之一,多年来带领技术团队积极推动研发流程、研发工具、技术能力的升级和产品团队由2C向2B的转型。近来基于CODING自身研发流程的成功做法,以及自身对研发管理、CI/CD、DevOps、敏捷开发等知识的深入研究,帮助多个大型企业进行研发管理升级咨询,实现企业研发效能提升。个人在大数据、人工智能、物联网等技术领域与技术型企业服务的产品结合也有一定经验和见解。

ArchSummit全球架构师峰会是InfoQ中国团队推出的重点面向高端技术管理者、架构师的技术会议,50%参会者拥有8年以上工作经验。 ArchSummit聚焦业界强大的技术成果,秉承“实践第一、案例为主”的原则,展示先进技术在行业中的最佳实践,以及技术在企业转型、发展中的推动作用。旨在帮助技术管理者、CTO、架构师做好技术选型、技术团队组建与管理,并确立技术对于产品和业务的关键作用。

   

2. 首先请您简单的介绍一下自己的从业经历,以及你现在在 CODING 负责的工作?

王振威:ArchSummit 各位观众大家好,我是王振威,现在任职 CODING 的研发总监,目前在公司主要负责产品和技术这块的工作,我从毕业到现在将近有七八年技术方面的工作经验。我在公司主导一系列技术革新和架构的升级工作,包括从开发的底层架构到最后的运维架构,以及相应的监控等方面的支持,包括我们近两年进行的容器化转型,以及现在比较火热的 DevOps 流程。我们公司本身是做企业研发管理系统的,我们自己也会向其他的企业输出一些研发管理的理念,我在这些公司内部的工作之外,还会帮其他企业做一些研发相关的咨询。

   

3. 您曾帮助过很多大型企业进行研发管理升级,您觉得研发管理在进行升级时最需要转变的是哪些方面?

王振威:从我的经验来讲,我接触了国内很多互联网公司、软件企业、包括一些传统公司的 IT 研发部门,在跟他们进行深入沟通之后,我发现他们在研发管理上有很多问题。但我认为,最着急的,或者相对来说可以快速实施的是代码仓库的规范管理,以及代码评审、持续集成和自动化测试这些工作,也就是我们常规所说的软件工程化,和现在比较流行的 CI/CD[CI/CD]、DevOps 这些东西,而不是在人员管理、任务管理等等方面的实践。为什么?因为每个公司的情况不一样,如果我们从人员管理或者项目管理的角度切入来进行研发管理升级,会对现有的管理机制带来比较大的冲击,就会导致很多企业难以推行下去。而代码仓库的规范管理、代码评审、持续集成这些内容,从很多角度上来讲,只是研发内部工具方面的升级,这样对现有的企业机制冲击比较小,而且它可以在短期内帮助企业大幅地提升效率,也可以很明显地看到改观,这是我的观点。

   

4. 像研发绩效考核是个很让人头疼的问题,您对此有什么看法,CODING 的内部是如何考核研发人员的?

王振威:研发岗位不像传统的销售,或者是业务部门,有一个明确的客观指标,比方说销量之类的,但是研发也有一些客观指标可以拿来做评测。有些外包公司会拿代码的行数,或者是工作量的人/天来考核,但我认为这种考核形式不太适合现在的互联网公司。从我的角度来讲,尤其是现在以产品为王的角度,研发团队的考核应该绑成一个团队来考核,而不是针对个人。因为一个团队在一起要有凝聚力,才能有战斗力。KPI 考核是考察团队,如果团队做得不好,大家一起来承担后果,如果团队做得好,大家一起来分享成果,这是一个大的前提。如果真的需要有一些客观的指标来评价这个事情做得好不好,也是有一些可以选的,比如说工作完成度[工作完成度],因为不管怎么样的研发工作都可以提前把要做的功能列出来,像我们这种做 SaaS 产品的,还对稳定度有比较高的要求,除此之外发布完成率等等,这方面的一些客观指标都是可以作为辅助手段的。但主要来讲,还是以这个团队最终有没有发挥出它对应的价值为目标,往往还需要领导者有一定的主观判断能力。

   

5. 但是像您刚刚说按团队来考核的话,也有可能会出现一个问题,就是类似大家吃大锅饭的问题,有可能一个团队里面有几个比较骨干的技术人员,但也有几个可能不怎么干活的人,但整个团队产出不错,那对于个人来说这个绩效考核怎么办?

王振威:一般情况下,首先这个团队我们不会定得太大,像我们公司内部的开发小组,一般人员在六个人以内,在这么小的团队规模情况下,每个人平时工作中做的内容,组内的人都可以看得比较清楚,混饭吃这种现象基本上来讲存在的可能性不大。另外,我们一般情况下在配置团队的时候,习惯把比较有经验的老员工和刚入职的新员工配在一起,这样新员工会明显感受到自己和老员工间为这个团队做的贡献的差距,他会更快速地去学习成长,最终成为团队重要的一员。当团队真的需要有人来承担后果的时候,是一定需要有人站出来的,这个时候就不是讲哥们义气了,而是真的看成员间谁做的贡献比较大。大家在一起是创业,是做工作,并不是交朋友处关系[交朋友处关系],从这个角度来讲,团队内当需要有人承担后果的时候,这个相应的人员必须得站出来承担。

   

6. CODING 从 2C 到 2B 转型时,遇到过哪些挑战?是如何应对的?为此在组织的结构和技术架构层面做过哪些调整?

王振威:这是个好问题。今年,尤其 18 年开始很多公司注意到企业级市场的重要性,CODING 也是其中之一。本身我们是做研发管理工具的,从 17 年推出企业版到现在,更为深刻地认知到,研发管理工具带来的价值更多是面向企业的,而企业也拥有更强的研发团队,以及对应的付费能力。我们面临的最大挑战是我们的产品特性,由 2C 转向 2B。具体来说,比如我们之前会为了用户量做很多运营活动,推出过很多比较讨人喜欢的黑科技功能,一些看起来很极客的功能,那是为了吸引个体的程序员,因为这个用户群体本身是这样的特性。而我们现在转向 2B,我们会大量砍掉这些看似能够帮助公司获得一些用户量,但实质对企业级客户意义不大的东西。造成的具体影响就是我们内部的员工,大家当初加入 CODING 的时候,都抱着一种“这个公司很有个性、很极客”这种想法进来,而现在渐渐去掉这种特性之后,大家心理上会有些转变。但这个问题,最终我们也解决了,为什么呢?其实我们只要跟大家讲清楚这个事情,也就可以理解了。有一句话,我们内部是这么讲的,叫做“没有程序员为自己写代码”。软件市场的调查结果也显示,大多数软件都是写给企业,而这部分软件的价值是更高的,个体用户写的代码更多是自己出于学习或者是兴趣爱好产生的,给个体程序员提供的产品价值难以在短期内获得对应的回报,长远来看,这部分的价值也是比不上为企业提供服务的。我不是说它不重要,但是不是那么重要,从这点出发,我们去跟团队讲。另外我们整个团队的作风从 2B 往 2C 转变,我们也更严格地要求自己做一个更专业的研发管理系统,这时候大家也就能接受这一点,我们的目标不是更极客,而是更专业。

   

7. 自动化是 DevOps 实施的关键之一,在实施 DevOps 之前 CODING 产品研发的自动化程度有多高?为了提升自动化程度你们做过哪些努力?

王振威:CODING 整个研发的自动化,也是一步一步走过来的。可以先讲一下现在的情况,首先我们使用自己的 CODING 企业版来管理我们的研发过程,也使用自己的代码托管和持续集成系统。每次开发者把代码提交到代码仓库之后,我们都可以在大概 20 分钟左右构建出所有微服务组件的 Docker 镜像,已经做到了这个地步。其次,我们还实现了一键式的测试环境搭建,在测试需要测某个版本的时候,只需要在我们的持续集成系统里触发相应的部署,就可以在十分钟左右构建一个完整的干净的 CODING 测试版出来。这个时候,测试就可以自主地在上面进行一系列自动化的 UI 和人工测试,这两方面的改变是比较大的。除此之外,在运维方面,大概在 15 年左右,当时容器领域 Kubernetes 还不够成熟的情况下,我们就研发了一套叫 CodingJob 的系统,用来管理线上的容器集群。我们现在内部从开发到最终运维的自动化过程已经全部打通了,但是我们为了保证稳定性在一些关键的节点会要求人工干预,比方说开发将代码提交入主干分支之前,会要求有强制的代码评审。此外在真正的服务上线之前,会有运维人员去检查整个操作的可靠性,所以目前来讲,自动化程度还是做得比较好的。另外我们不单自己现在做得比较好,还把这套系统输出给了一些企业客户,他们也得到了相应的效率提升。这个过程说简单点,就是以前我们的手动操作,现在让机器自动做;说复杂点中间还有很多细节,最终效果是我们的发布效率有了明显提升,以前可能一周才能发一个版本,现在一周至少可以发四个常规版本,而且我们有更多的发布能力,一周可以发更多版本,但是目前因为我们的业务量各方面的诉求还没有到那个程度,所以现在还没有发挥出这套系统的容量。除此之外还有一个明显的收益是,各个小组之间的权责更分明。因为我们会要求开发在发布一个版本的时候,提供一个标准的交付物给运维,如果这次发布失败,我们就可以检查交付物是不是按标准来写的,如果是按标准写的,运维又有相应的运维失误,那就是运维的问题,这从某种程度来讲也是一个收益。

   

8. 您刚刚也提到说,过程中间会有强制的代码评审,这个代码评审怎么去做到尽量保证评审的效果,但是效率又比较高呢?

王振威:这是个好问题,其实很多管理都会有这样的问题,就是你定了规则,规则必然会影响效率,但是定规则很多时候是为了保障质量,或者保障稳定。我们内部是这样的,有若干个开发小组,我们会要求开发小组内每一次代码的变更都以我们提供的合并请求工具[合并请求工具]来提交。在代码合并之前会要求组内的人至少有一个评审通过,因为组内的人对组内的代码改动逻辑是比较清楚的。此外,一个人评审的力度往往是不够的,这个时候我们又无法强制要求组外的人去做,于是设立了一个奖励机制,部门内部有一个月度评审排行榜,我们会统计出哪些人在评审代码上做的贡献最大,会有现金奖励。通过这种形式,既保证了质量,又能够让大家多关注别人的代码,让一份代码被多次评审,这样最终的质量和稳定度都有一定的保证。

   

9. CODING 在推行 DevOps 时是否对开发、测试和运维都提出了新的定义或要求?

王振威:这个是必然的,因为整个流程在变化的时候,权责也在分明,而对应的交付物就必须得标准下来,这是我们做的一个比较大的改变。以前不管是开发测试还是运维,可能大家因为沟通比较方便,我说一下给你听,口头上表述一下大家就明白了。现在我们有几个方面的要求:一,因为使用了容器化集群的形式来做部署,我们要求内部所有的微服务必须是无状态化的[无状态化的,支持环境变量配置的],支持环境变量配置,方便运维做横向扩展、负载均衡和对应的监控;除此之外,我们要求开发在发布版本的时候,写一个正式的 Release 发布报告,这个报告的格式我们有定义,比方说要求更新哪些组件,要求数据库结构有什么改变,需要有什么配置项的变更,以及本次改动代码的 ChangeLog[ChangeLog] 是什么,需要测试的重点是什么,都会在里面写的非常清楚。当他在把这个东西交付给测试的时候,测试去看 ChangeLog[ChangeLog],去看测试要点,而且测试还可以回头再评审一遍他当时写的代码,这时候就形成了一个标准的交付。开发不需要去问测试你要什么,我提供这样的东西就是一个标准物。对于运维也是一样的,他看到相应的发布报告,就可以做完对应的操作。当然内部还有很多其他细节的规范在定义,但我觉得比较重要就是这几个。

   

10. 怎么去确保这些规范真的能很好地实施?可能跟刚刚的问题有点像,因为本来口头沟通挺高效的,但是确实在流程上不太好,现在加了规范之后,又会导致对效率有点下降,怎么去保证推行的规范能真正地实施?

王振威:关于规范的定义和工具的选择,我也遇到很多客户会问这样的问题,就是说,我知道定义好规范可以让大家的沟通容错性更高,就像函数调用一样,我传一个对应的参数给你,你就可以得出对应的结果,那这个时候就需要工具能够跟上来了。因为工具会大大减轻这个过程给员工带来的工作负担,如果工具选择的不够好,你要求大家进行代码评审,但又没有一个合适的评审工具,那当然是执行不起来的。如果对应的工具能跟上,比方说我们现在使用 CODING 的合并请求,使用持续集成、使用 Jenkins,开发者只要按照我们的规范一次性写好 Dockerfile[Dockerfile] 的构建过程,然后把代码提交上去,程序就会自动帮他们把镜像构建好,这个时候他甚至都不用去主动关注这个事情,反而是降低了他自己的工作成本。就是说你需要用更现代化的生产力工具来提升开发者的体验,包括各个环节内每个人的体验,包括我们使用容器云的方式解放运维,现在运维根本不用关注微服务到底需要 JDK8 还是 JDK7,因为开发给他提供的是一个 DockerImage,他只要在有 Docker 的环境里面运行起来就可以了,镜像里面包含了所有的程序和对应的运行环境。我认为一个好的规范的推行,必须要搭配一个好的工具,这个体现在各个环节里,不管是运维、开发还是测试。

   

11. 您刚刚说到的 CODING 的部署工具不仅内部在使用也提供给了外部客户,市场上也会有很多类似的 CI/CD[CI/CD] 工具,那么 CODING 的优势是什么?

王振威:CODING 本身提供的有代码托管、项目管理和持续集成对应的工具,另外我们还有一个产品叫 CloudStudio,是一个在线写代码的工具。这里我着重讲一下 CODING。当然市场上有很多其他类似的工具,比如说 GitHub、GitLab、Gitbucket 等等,我们一个最大的特点是本身集成了轻量级的项目管理功能。从公司内部的使用情况来讲,首先我们会有需求进来,需求在我们的系统里面是以任务的形式来管理的;如果需求最终决定要做的话,我们会用里程碑的形式把这些任务规划成对应的发布阶段。同样的,每个开发者最终在做这个任务的时候,他可以把他当时改的代码跟这个任务做深度关联。这个过程的价值其实非常高,因为以我们公司自己的实践来讲,往往很多时候写了代码之后,可能过了很久要回头维护这个代码,如果找不到代码对应的业务的含义是什么,就会显得非常被动,你可能会看到一段莫名其妙的代码。而如果我们能够把对应的开发任务跟对应的代码,甚至当时做这个任务需要的一些技术调研文档完全关联起来,事情就会好做很多。这就解决了很多传统企业非常头疼的问题,就是我给这个团队发了任务,但是我根本不知道这个团队写了哪一段代码是处理这个任务的,后续再找另外一个人维护的时候,别人根本无从维护。尤其是在一些有外包性质的合作场景里:有很多金融企业在做项目的时候,自己内部人员的人力不足,就会招一些外包的人,把开发任务交代给他们,等外包做完之后,这个项目就交付给这些金融公司,外包的人可能就走了,或者就不再介入这个项目了,他们再做后期维护就会非常头疼。这个时候他们又不得不找另外一家公司来接手,而另外一家公司看了上面的代码,同样也是一头雾水,很多时候就只能选择重建或者类似的形式。而 CODING 能从轻量级的代码管理到托管,再到持续集成,将这一系列环节全部打通,最终再对接给第三方容器云平台,或者是其他的 OPS 平台,我认为我们最大的特点就是能够帮客户把业务跟具体的代码做一些深度的关联,另外有些知识沉淀在里面。

   

12. 大数据、云计算、人工智能等技术日新月异,这就要求技术人员需不断学习以跟上步伐,CODING 的技术人员是如何协调时间以满足任务工期和学习的双重需求呢?公司如何组织员工一起学习、研究新技术并做交流分享的呢?

王振威:说起学习这个事情,以我个人的观点来讲,我认为学习一定要有主动性,首先这个人他有学习的想法,他愿意学习,我们才能再配以学习的环境,他才能学得好。如果他本身对这个东西不感兴趣,或者说是他不愿意在这方面有所成长,可能心思在其他方面,这个时候你即便提供了相应的工具和环境,也无法发挥实际的作用。我们公司的做法是这样的,首先公司内部的技术开放性是很强的,基本上所有的技术人员可以接触到所有系统的代码。我们认为内部的代码跟数据、密钥是分离的,线上的东西当然是由运维来主管,但是代码跟线上这些东西关系不大,代码只是跑在线上而已,它也可以跑在线下。代码层面,我们是开放给所有的技术人员的,他都可以去学,不管你是前端还是后端。另外,我们内部倡导全栈工程师这样的文化,不论你入职进来的时候是 JS 工程师,还是后端 Java 工程师,还是运维,甚至是测试,我们都希望你能在 CODING 工作一段时间之后成长为全栈,这就要求他必须熟知很多方面的技术知识,单纯这些东西已经可以让他学习很久了。你要知道一个网页上的 UI 组件,CSS 怎么写,怎么选 CSS 框架,到最终服务怎么编译,怎么构建,怎么持续集成,怎么构建容器镜像,最后部署怎么监控,怎么分析日志,甚至运营的数据分析怎么弄,SQL 怎么写,有很多知识在里面,这是公司内部的第一个原则,技术开放性,他可以有条件去学。其二,公司内部会不定期地针对一些特定的知识进行培训,甚至我们可能会找一些外部的讲师过来讲,比较火的区块链知识,包括 AI 背后的原理是什么,我们会找一些外部讲师。如果内部员工愿意分析更细的知识也是可以做的,这个是不定期举办的,看具体的话题和大家关注的程度。我还是觉得,强制去讲意义不大,一定要观众有心去听才好。最后是我认为很好的,比如像 ArchSummit 这样的平台,他们提供了非常高质量的会议和课题,包括我自身也给 ArchSummit 讲过课,像这次会议我们公司也有技术人员到现场来参会,因为 ArchSummit、QCon 这样的会议,有很多主题和分会场,里面有各种类型的主题,员工过来之后,完全可以在这个会场里面找到对应自己喜欢的课题。总体来讲,对于学习,我们的看法是首先你要主动,然后在我们提供的资源和工具范围内去发展。

   

13. 有些产品在启用新技术时显得很生硬,有为了用新技术而用的感觉,CODING 在应用新技术时做了哪些考虑,从而更好地让新技术为产品相结合,发挥新技术的优势来为产品服务的呢?

王振威:从我的角度来讲,我认为新技术的出现必须是要解决我们的问题才会用它,如果它不解决我们的问题,或者仅仅是因为它新,那对我们的意义不大。此外,尤其像我们做企业服务,又是做 SaaS 这种形式的产品,就要求我们以稳为前提。这个时候新技术的出现本身对我们是个冲突,因为公司技术发展了这么多年,它有自己的一套做法。具体来讲,为了迎接新技术,我们做了以下几点:第一个是我们的程序是有灰度机制的,当一个新技术引进来之后,我们允许在程序的逻辑上让这些新技术在某种程度对用户不产生影响,即便它上线了,我们只指定一部分用户可以看到,比方说我们内部的员工,或者我们邀请的内测用户,他们可以体验。如果有 Bug 就回退,这是第二个特性,不论什么样的技术,我们都可以回退,它不是破坏性的。第三个是兼容性,当一个新技术替换老技术的时候,最好能够在它所做的范围内不产生对其他组件的影响,就好比我们以前用 Maven,现在用 Gradle,它们两个的替换,需要对其他的组件不产生任何影响。比说我们用 Spring 做 Java 架构,Gradle[Gradle] 还是一样可以用 Spring,那我们用 Gradle 还是一样可以用 Docker,技术的替换最好不要影响到其他组件,这也是一个原则。此外我们内部使用 Git 这样的版本控制工具,这就使得建分支的成本变得比较低。我们现在仓库里有上千个分支,其中有很多都是开发在业余时间基于主干做的一些新产品的想法的测试,我们提供了这样一种测试的机制。此外,我们的持续集成系统是开放的,如果开发愿意把某一个组件换成新的组件,他一样可以在我们的持续集成系统里面编译,完成自动化测试,看这个组件最终对其他东西造成的影响。因为本身机器的运行资源的费用是比较低的,我们有自动构建、自动测试的机制,就使得同事在做新技术尝试的时候成本更低。不像以前如果没有自动构建,一个组件换了以后,想配合其他组件一起工作,你还要了解其他组件怎么弄,这些组件全部跑起来之后,还要联系测试部门帮你测一遍,你才知道这个新技术上线之后会不会造成影响。而现在有了这样的自动化机制,本来周末的时候这些计算资源也都闲置着,现在大家在周末或者任何时间里都可以去尝试自己的新想法和新技术,只要他能够跑通我们的自动化测试,那他就可以往上提,到最后,我们再人工测试验证没问题之后,经过评审就可以把新技术推广开来。

   

14. 在制定研发流程时,较细较严可能会有利于版本和质量控制,但会影响研发效率,CODING 在制定流程时是如何考虑这两者之间的平衡的?怎么在提升研发效率的同时保障质量稳定?

王振威:其实这个话题我在刚开始讲的时候有大概提过,我们内部的开发、测试和运维在衔接过程中有一个强制的规范是交付物。开发强制规范的交付物,第一个,他如果想完成某个任务或者修改某个 Bug,他必须提交一个合并请求,在这个过程中就保证了强制的代码评审。我刚刚讲过,强制的规范需要合适的工具,如果需要代码评审,你要有合适的对应的工具来做,那我们对于代码评审的具体要求是什么?比方说我们会要求代码的格式是什么样的吗?像这些细节,我认为是没有必要做强制要求的,但是我们又不能忽略,怎么办呢?很简单,我们以推荐的形式来做,比方说代码的风格,有很多公司可能要求比较苛刻,要求代码风格也必须一致,但我们公司在比方说对 Java 代码的风格要求上没有那么强,而对 JS,因为本身这个语言可以写得很华丽,我们对风格要求会比较强。我们在持续集成的时候,如果提交上来的代码不符合我们的风格规范,我们会有相应的 Lint 工具,就是查错的工具,可以告诉他对应的错误在哪里,他就无法完成自动化构建,代码是不能发布上去的,这是一种强制的规范。而对于 Java 代码,我们又希望大家能够按照规范来,又不希望规范影响到对应的效率,怎么办呢?我们使用了一些工具,比方说我们部门内的开发都使用 IDEA[IDEA] 这个写代码的工具,然后我们定义了自己组内的比较合理的 Java 代码规范。我们在新人入职的时候会要求他把这个规范文件导入到工具里,那他在提交代码的时候,工具会自动对这些代码进行规范化处理,而我们对这个事情就不再做强制的要求,是希望大家这么做而已。这也是一个像你说的规范和自由,是博弈关系,虽然在中间找到一个平衡点比较重要,但其实为了效率,很多时候我们用倡导的形式去做,或者非强制化的用工具化的方式来解决效果会更好,让大家更容易接受,而最终这个事情的事态又不会不可控。

InfoQ:以上是我今天的采访问题,谢谢。

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT