如何提高团队的研发效率？阿里工程师这么作

背景

大约在5年前，也就是2013年我刚加入阿里的时候，那个时候 DevOps 的风刚吹起来没多久，有家公司宣称可以一天发布几十上百次，这意味着相比传统软件公司几周一次的发布来讲，他们响应商业需求的能力能够甩后者几条街，并且这差距根本不是加班能遇上的。今天的 AliExpress 技术团队小几百人的规模，可一天发布几十次也已经司空见惯了，这主要得益于三个方面：

● 很是完全地微服务化，拆分粒度很细，且旗帜鲜明地反对重二方库。
● 阿里集团总体的运维标准化，尤为是 Docker 技术的全面覆盖。
● AliExpress SRE 团队不断努力保证稳定性。
然而，效能这个东西，你永远不会说：“够了，够快了”，尤为是在当下的消费型社会，人人都是消费者，而消费者巴不得脑子里的欲望刚闪现出来，你的商品或服务瞬间就到他面前。何况，随着咱们不断国际化的步伐，新的因素必然会影响原来的高效能。

沟通带宽衰减问题

第一个因素是研发团队自身的发展和变化，今天的 AliExpress 技术团队已是一个名副其实的分布式国际化团队，工做地是杭州+深圳+莫斯科+马德里+其余欧亚都市，外籍同窗的比例是 15%，并且能看到这个比例会不断提升，新的国外工做地点也会增长。而这样的团队，对比在同一层楼里的一群中国人组成的团队，是有本质的区别的。

咱们能够将人与人之间的沟通和网络通讯作类比，咱们知道网络通讯是有带宽的，从早期的拨号上网几十K，到如今的家庭宽带主流的几十上百M，再到数据中心内部局域网内部G级别的数量级，带宽越大，能传输的信息也就越多（一般浪费也就越多）。而人与人之间沟通也能够认为是有带宽的，例如充分信任的全由中国工程师组成小团队，平时相互一块儿吃饭散步聊天，你们彼此都特别了解，沟通起来就特别顺畅，想到一个点子转个朝向说两句对方就懂了。可对于一个分布式国际化团队来讲，这个沟通带宽但是衰减得厉害：

● 中文到英文的转换，衰减一次。对于大多数人来讲，英语不是母语，沟通的效率天然会下降。
● 单地到多地，衰减一次。电话，视频，钉钉，都没有面对面沟通来的高效。（不然你们都不会不约而同地刷脸了）
● 时差，再衰减一次。杭州和莫斯科的时差是5个小时，因此基本上北京时间上午咱们是联系不上莫斯科的同窗的。
● 文化的差别，再衰减一次。例如不少咱们能够用来加强感情的团建方法，撸串K歌王者吃鸡，外籍同窗可能彻底不感冒。
那有人可能会说，既然沟通成本这么高，那直接在一个地方所有招中国工程师多简单？这么作简单是简单的了，可都这么搞的话，怎么在全球范围吸引优秀的人才呢？更况且 AliExpress 的用户基本都是老外，这后面的人才若是全是中国人，听起来这生意就不太靠谱对不？谷歌微软亚马逊，哪家不是在全世界搜罗顶尖人才？

因此说，既然沟通带宽的衰减是难以免的，那咱们惟有把对这带宽的利用率提上去。具体咱们已经作了，或者在作一些事情：

● 尽量和行业主流技术接轨，下降工程师学习成本。咱们基于开源 Spring Boot 作的阿里巴巴生态集成，摒弃 antx, webx, pandora，都是这个思路。
● English First：注释，文档，工具，英文必选，中文可选。
● 服务发现，让全部微服务可见，加强自描述，可搜索。

拥抱 Kotlin

关于开发效率，我我的认为全部 Java 程序员都应该认认真真、仔仔细细去看下 Kotlin，由于这门语言太简洁了，并且和 Java 能够无缝互操做，彻底具有生产环境使用的条件。

有关简洁，我这两天把一块 Java 代码改为了 Koltin，在丝绝不下降可读性的状况下（实际上可读性是提升了），代码行妥妥地减小了 1/3 。

此外我忍不住分享一下最近我基于 Sergey 的 Kotlin HSF DSL 写的一个将函数发布成 HSF 服务的功能：

只须要不到 15 行代码，就能够启动一个 Spring Boot 应用，把一个字符串小写的功能发布成 HSF 服务，你们能够对比下 Java 须要写多少东西。语言层面的升级，给框架，中间件，API设计带来更多的可能性，这就能使咱们砍掉更多的所谓脚手架代码，让业务代码更精简，更优雅，进而带来效率提高。

做为程序员，若是只掌握一种语言，是很是危险的，由于这种语言的各类设计会禁锢你的思惟。我本身会在业余看一些其余语言，不过在平常工做中基本也只能写 Java（若是 shell 也算一种语言的话，仍是写过些 shell 的）。不过从如今开始，我会开始尽量地用 Kotlin 写代码，个人团队也全面把平常编程语言从 Java 切换到 Kotlin，其实咱们都已经不算 Early Adoptor 啦，雷卷在一年多前就已经不停在鼓吹 Koltin 并上线了一个应用，AliExpress 俄罗斯办公室的 Sergey 等同窗也已经在生产用上了 Kotlin，Sergey 我的也在不少地方分享他的经验。

咱们会推进 AliExpress 拥抱 Koltin，从语言层面来提高咱们的效率。

阿里资深技术专家雷卷，在他最近的一篇谈程序员学习的文章中写了不少东西，我都是很认同的，其中一段话尤为想点赞：

不要和程序员谈本身的编程历史，不少经验今天已经不适用啦，可能有一些，可是会给别人带来甄别成本，别人也懒得来甄别。2-3年不关注技术，基本快和程序员和编程绝缘啦，不是绝对，可是一般不会错。

持续学习，与诸君共勉。

FaaS
Function as a Service，又一个新的 Buzz Word？是的，不过我还真的相信这个 Buzz Word，行业里 AWS Lambda, Google Cloud Functions, Microsoft Azure Functions 等服务相继推出，你们都在尝试把本身的业务往上面搬，这其中的道理在哪？

若是做为云服务提供商，这个道理是很显而易见。你的对手按照 docker instance 收费，2 core 4g 起，一小时多少钱；若是你能作到按调用次数收费，一小时内运行了 30 次。那这个价格差必然是数量级的，用这一招就能够秒杀对手了。

上面所说的纯粹是硬件成本的考量，但咱们还须要从效率方面看这个事情。

首先因为 Function 天生是无状态的，并且是足够轻量的，那么理论上作到 ms 级别的 auto scaling 是没有问题的，例如 graalvm 就在这方面颇有潜力。

ms 级别的 auto scaling 不只可以大幅提高资源利用率，更是提高了运维效率，开发几乎就再也不须要考虑容量的事情的。例如在双11的时候，咱们作大量的压测，很大程度上是为了保证系统各个部分的水位在预测的安全的线上，若是作到了实时扩缩，那么当流量高峰来的时候再扩容好了。

什么是轻量？

今天不少工程师可能已经忘了轻量的概念是什么，你们就是各类侵入，写个简单的应用，打出来的 jar 包，业务代码的占比每每不到 1/10。

先不说这里可能无谓浪费了多少内存，无谓增长了多少启动时间。这个 client 那个 share 满天飞带来的最麻烦的后果就是，开发常常要作各类升级，并且一升就挂，一查就半天。打着所谓性能旗号的各类重客户端，就是反服务化的；各类缺少细心设计的 API 致使的不兼容升级（并且是暴力推进，不升级卡发布），就是反工程师操守的。

微服务化作得好的，应该积累一大批轻量的接口，使用这些接口甚至都不须要引入什么 share/open/client 的依赖，直接用 HSF 的泛化调用便可，这样的接口才不对用户有代码侵入。

咱们已经在 AliExpress 尝试（并已经上线）基于 Koltin DSL 和 HSF 泛化调用编写 Function，用户只须要依赖很简单的一个 FaaS SDK 就能够编写业务代码，基于前面提到的阿基米德服务发现，他能够快速重用现有服务，作一些聚合和过滤的操做，知足业务需求，这个在贴近无线的业务中很是有用。固然，这个尝试只是一个开始，但咱们已经看到，其实有大量的业务逻辑（在 AliExpress 多是 5/1 至 1/3）其实自身不依赖于数据，能够作成 Function，并且咱们能够作到让这些业务不依赖任何业务二方库，甚至借助 Service Mesh 等技术，不依赖于任何中间件 client。这些业务的 owner 不须要关心各类乱七八糟的升级问题，不须要关心容量问题，真正地只关心本身的业务逻辑。

我认为这是 FaaS 该成为的样子，而我及个人团队，正不断努力去实现之。

本文做者：许晓斌

阅读原文

本文来自云栖社区合做伙伴“阿里技术”，如需转载请联系原做者。