字字珠玑，高级技术专家带你了解阿里的开发流程规范

此前，阿里高级技术专家孔凡勇（云狄）老师撰写了在 Alibaba 成为优秀的技术主管，需要在“开发规范、开发流程、技术规划与管理”方面有自己的深入思考文章。受广大读者的需求，我们邀请云狄老师解读了部分读者提出的问题，帮助大家深入了解阿里的开发流程和规范化实践过程。以下是 Q&A 形式的文字整理。更多细节关注 7 月 12 日深圳 ArchSummit 全球架构师峰会上云狄老师的演讲

 https://sz2019.archsummit.com/presentation/1523

我目前一多半时间用在开发、任务分解分配、开发实践、技术架构评审、代码审核和风险识别上，剩余的时间则花在为保障系统按时交付所需的各种计划、协作、沟通、管理上。

像 Google、Facebook 都有自己制定的一些开发规范，阿里去年也开源了内部的一套开发规约，其实这些标准的开发规范都是长期积累的一些经验值。

制定这些开发规范，主要基于以下几点考虑：

1. 降低故障率：尤其是杜绝重复故障率，防患于未然。如：集合的 SubList 使用方式、SimpleDateFormat 的线程安全等问题。

2. 提升协作效率：现在很多公司都提倡中台化与标准化，团队内部协作、跨团队合作都需要保证高效率，高效协作的一个前提是规范统一标准化。

3. 工匠精神：工程师对于代码，一定要“精益求精”，不论从性能，还是简洁优雅，都要具备“精益求精”的工匠精神，认真打磨自己的作品。

最重要的一点是提升开发效率，提高代码质量。如果个人的代码模板和团队不一样，会增加代码的 merge 成本；如果你的 API 不规范，会额外带来开发与沟通成本；如果你的命名不规范，有同样会带来沟通成本。

应用命名规范、模块的划分、目录（包）的命名，我觉得非常重要，如果做的足够好，别人导入项目后可能只需要 10 分钟就可以大概了解系统结构。

也许有人会问，开发规范如何从 0 到 1 开始做，而且还不能影响开发进度？制定规范，更多是改变一些传统做法，去适应新的变化。现实情况下肯定会影响进度，开发规范不一样，流程可能也变化，具体影响范围需要根据具体项目来评估，不存在标准答案。

如何做好需求管理，对于技术 TL 来说是非常重要的。对于产品经理提过的需求，首先要有一个初步的过滤，到底是真实的客户需求还是伪需求。其次按照产品需求的重要程度和时间迫切度可以分为四种类型：紧急重要型、紧急非重要型、重要非紧急型和非紧急非重要型。

对于有效的需求管理，首先是关注重要紧急型需求，其次才是不紧急重要型需求、紧急非重要型需求、非紧急非重要型需求。在判断其重要性和迫切性上有个基本的概念：先解决负面灾难，再追求正面功能，“查缺补漏优先，锦上添花其次”的原则。

很多时候需求的变更或增加是因为我们面临太多选择和想要的太多，没有适当的控制自己的欲望，并以自己的喜好来决定需求，这些因素很容易导致产品没有明确的方向、团队成员疲于奔命，但是却没有实际的成果。所以技术 TL 一定要能够评估出重新审视产品和筛选需求的优先级，识别每一个需求的必要性、重要性和实现成本。通过深思熟虑给团队明确方向并专注，聚焦资源的支配，确保团队的精力都聚焦在产品的核心需求上。

可扩展性，是将软件未来的发展过程也考虑在内，而进行的一种设计选择，可看作是一种面向未来的柔性设计（Supple Design）。

系统架构可扩展性设计需要把控好当前需求架构与未来不确定性架构，如果权衡不好会有两种情况，设计不足与过度设计，对于支撑业务的发展会有一定的损害。

设计不足，则意味着系统复用性扩展性和灵活性都很差，系统僵化，不能应对将来的需求变化，或者将来修改和维护的代价和成本会很高，这当然是设计错误。

过度设计，则意味着为了实现这个设计要付出的额外代价，例如成本上升，缺陷可能性加大，提升维护成本，甚至降低系统性能。而可维护性和系统的高性能都是系统的隐性需求，这些需求没实现好，当然也是设计错误。

无论是面向当前需求还是未来变化需求，我们都需要遵循一个简单之美的原则。最简单的才是最好的。大巧若拙，大道至简，有时候越简单的反而越难实现，而且越接近真理。

我极力推荐大家多了解下微内核插件架构，比如我们经常使用的 jQuery、Eclipse 都采用的微内核插件架构，使用微内核架构，用户代码就可以通过插件的形式，集成到已有的核心系统中，具有高度的可扩展性。

大家都期望当前维护的系统具有高度可扩展性，以减少眼前的工作负担。但是一方面这类系统实际上需要很强的预见性才能设计出来，难免出现偏差。另一方面，高可扩展性也未必没有弊端，是否具有优势也与当前的项目场景有关。这个需要架构综合去做权衡，有时候维护一个高可扩展性的软件系统，可能反而不如简单系统外加合适的变更方案更有效。

首先来讲，规范必须是大家的共识，每一条规范都需要说清楚原因，并且给大家讲清楚，让大家知其然也知其所以然。知道为什么这样子做比较好之后，执行的意愿会大大加强。而不会有太强的抵触情绪。

推动一些规范化的事情主要包括技术规范和一些流程规范。技术规范推进整体来说还算比较顺利，作为工程师对于的技术追求大家基本都是一致的，比如 CodeReview 规范、架构设计规范、发布计划规范等。

对于跨团队的一些流程规范，这里面是有些挑战的。很长一段时间以来，也许每个人都习惯了自己的工作方式，处于一个舒适区。今天突然要换一种协作方式，或多或少有些抵触情绪。这里我更多是拿一些数据说话，这样能够去说服别人，比如 PRD 一些输出规范，必须要有一些上线后的期望值数据，无论营收还是 UV、PV，最后落实到客户价值和商业价值，如果达不到期望值，你给协作团队的信任值会降低，后面你的需求优先级也会被降低。

技术团队也需要紧密衔接业务团队做一些技术规划，一方面我对一些创新业务要用到的技术做一些储备和研究。另外随着已有的业务不断发展，系统架构的腐蚀是避免不了的，我们需要制定一些技术规划，来保障业务的健康发展，思考如何对现有系统架构、性能进行优化，作为技术人我们也要有自己的技术 KPI。

一言以蔽之，技术规划是融合多因素的发展愿景，基于对未来整体性、长期性、基本性问题的思考，制定设计全面长远的发展计划和行动方案。

如何去做技术规划，需要结合业务产品和技术，思考三个问题：Why、How、What。

Why：为什么要做这方面的技术规划，目前的性能有问题还是架构存在问题？例如财年的订单量预估翻番，相应的订单查询 RT 有所保障。

How：如何去实施对现有架构、性能等方面的优化，结合业务现状以及未来规划出发，整理潜在的技术方案、架构、技术栈。

在技术规划落地前，我们首先要有明确的目标，比如查询 RT 降低 50%，采取缓存、分库分表方案。

系统架构存在耦合的情况，目标需要进行解耦，以及面对未来不定性业务发展方向，我们如何保障系统的可扩展性，支持业务的快速发展，采取一些微内核、微服务架构思想快速支持新业务发展。

What：技术规划是为了更好的适应明天的变化，目的是变的更好。技术规划在执行过程中，将任务计划拆解成阶段性里程碑，要把控好技术风险和管理风险，需要进行定期检查，定期总结，有问题要及时去调整。

一提到工程师文化，大家首先想到的应该是 Google、Facebook 之类的公司，在《重新定义公司：谷歌是如何运营的》这本书里对工程师文化有更详细的解读。这里简单谈下我对工程师文化的理解。

简单来说工程师文化就是一切以解决问题为导向的工作文化，工程师有一定的自由度和技术创新。层级尽量扁平化，第一线要具有极大的自由度，权责要向下转移。

阿里以及我们团队的的一些工程师文化主要如下几点：

1. 建立共享代码所有权

2. 建立合理的软件抽象

3. 工作中重复劳动力，抽象为工具自动化

4. 注重代码审查，编写高质量代码

5. 保持一个开放、尊重的工作环境

6. 工程师的决策权

7. 建立学习与分享的组织

8. 招聘最优秀的人

第一要建立共享代码的所有权，阿里包括中间件等很多代码都是可以共享的。

第二是要建立合理的软件抽象。比如说像 Dubbo、RocketMQ、RPC 等中间件，都是基于业务场景抽象出来的中间件，这就是对软件的一种抽象能力。

第三是工作当中的重复劳动力抽象为工具的自动化。尤其像 Google，Facebook 是非常崇拜这种文化。这种文化在阿里内部也是极度盛行的。如果你的日常工作有好多重复性的工作，那你一定可以开发出一种自动化工具来解决重复性工作。

第四是注重自动代码审查，编写高质量代码。去年阿里开源了一些整体开发规约，包括开源了 P3C，Eclipse 等插件，目的都是为了能够保障编写出高质量的代码。

第五是要保持一个开放，互相尊重的工作环境。工程师要有足够的决策权，比如在需求评审时，技术人员对于产品需求是有一票否决权的，当需求规范不够标准的时候，技术人有权利拒绝你的需求。大家在这种互相尊重的工作环境中才能更好的行使权力。

第六是建立学习与分享型的组织。我的团队基本上每周都会举行一些技术分享会，包括读书分享会，轮流做一些基础的分享，引导大家共同学习。

最后是要招聘最优秀的人。几乎所有人都希望和比自己优秀的人合作。像 Google 也贯彻这类招聘理念。

这是肯定的。每一个财年每个季度都会做一些技术上的规划。比如目前的系统存在耦合性问题，要对代码模块做优化和重构。比如说在代码质量的圈复杂度相对比较高，可能会进行抽象、重构，这是经常要做的一件事情，它对于一个系统未来的可扩展性非常重要，我认为多投入一些时间是非常值得的。

技术人员的绩效不能和运营、销售人员类比来做可量化的指标衡量。不可能根据提交代码的行数来评价一个人的工作量。也不可能根据代码 bug 数来界定到底是产品方还是业务方导致的。

我更看重一个人的整体工作效率和质量，在横向比较中这些是能够可视化的，在保证效率的前提下，能够保证质量，甚至说在团队中能起到一些正面的积极的影响。另外我比较关注他是否能遵守团队制定的一些标准规范，包括整个集团的开发规约。

关于整个系统的稳定性非常重要的一点是，必须能保质保量不出现生产环境问题。

其次是 KPI 里会体现出关于系统设计，分析命题，解决问题的能力，我比较关注。最后一点是对这个团队的贡献和影响力，比如说在团队能够推广一些技术，包括一些相关的规范，引入一些核心的技术，能够提高团队的生产力。