座谈php技巧_阿里技能专家座谈软件工程20年变革和趋势

作者：凡提 阿里技能风险与效能团队

天下格局在进入 21 世纪之后风云变幻，软件领域同样风起云涌。
从硬件到软件，从单机到分布式，从孤岛到互联，程序员的创造力无比强大。
但究实在质，软件工程和土木工程实在没有太大的差异，只不过一个是在码字母，一个是在码砖头。
至于建筑的主体，设计毛病，或者地基没打好，一样会垮塌，不管是楼塌了还是软件崩了，都可能成为全体天下都能感知到的大事宜。
本文将从 2003 年淘宝网成立那年开始，回顾总结这些年来软件工程体系的主线技能，磋商变革和趋势，并从自己的视角给出一些不雅观点和思考。

选择何种模型对软件工程的事情开展至关主要，乃至对一段期间的技能特点都会产生实质性影响。
以是，第一节必须从这里开始讲起。

20 年前还是以单机软件为主的时期，以操作系统、办公套件、ERP 系统等为代表的大型互助类型软件工程，特点是研发周期长、进度缓慢，一旦分发到个人电脑上则不随意马虎被召回更换。
一旦软件比较精良，知足了用户的基本需求，就很难推动用户再去升级，以是当年 Windows 升级换代替换任何一个成功版本都非常困难。
在这样的背景下，瀑布模型是最主流的一种开拓模型，险些垄断了所有大型软件的工程开展。
瀑布模型的优点和缺陷已经被总结的很好，本文不做展开，仅以我自身参与的瀑布模型工程体验来大略说一说。
全体瀑布模型，便是大家常常提到的 V 字形，从需求到交付，位于 V 字最低真个是真正的编码过程，V 代表瀑布模型，切实其实是再恰当不过的字母，由于编码过程在这个模型中，真的就只占用那个端点的长度，其他韶光都被各种谈论过程和文档霸占。
彷佛一个武林高手，在擂台上做了几个小时的准备事情，万事俱备后，溘然脱手用手指示了一下目标，然后就立即罢手又搞了几个小时的整顿现场事情，大家都沉迷于这位高手脱手前后的花式展示，而真正出招的那个瞬间却都被大家忽略了。
据此出身的 CMMI 认证，专门用来衡量高手出招前后姿势漂不俊秀，热身动作到不到位。

受此影响，早期的互联网 Web 工程的开拓也是屈服瀑布模型的组织形式来进行的，大概在实行上有所变形，但从系统架构上看，瀑布模型的痕迹非常明显。
比如我们公司十八罗汉之一的一指主导的 WebX 框架（刚入职那会我有幸通过旺旺向还身在加拿大的一指请教过技能问题），通过配置和 Package 将工程切分的非常细致，让每一个工种都能找到自己该当按部就班的地方，卖力写 SQL 的，卖力写 HTML 的，卖力写 JS 的，卖力展示层模板的，卖力事务层的，卖力数据模型的等等，当页面上须要新增一个功能的时候，如果分工的每一层都须要一名专职程序员来做，那么很可能就要驱动 10 来位程序员进行修正，由于框架明确了这些人的事情范围和职责，以是这些人须要坐在一起谈论需求，通过文档来沟通对接细节，谈论单测和集测的展开，终极这些文档和沟通事情都完成后，武林高手们终于在一瞬间脱手，页面上添加的那个活动页终于在末了一瞬间涌现了，这时候，收到交付产物的运营抬开始一看日历，双十一大匆匆已经是半个月前的事情了，忙活了大半年，大家什么都考虑到了，便是没考虑到耗时排期的漫长。

对付交付到个人电脑上的产品来说，瀑布模型可以供应质量稳定、交互良好的产物，当然也是有失落败的可能，只能说产出精良产品的概率相对付其他模型来说会更高。
但由于多级开拓实在和真正的用户之间的沟通是完备脱节的，以是有时候用户希望得到一个圆柱体，拿得手的却是一个长方体，项目经理只能敷衍用户：“这两个物体的截面都是矩形”。
到了个人电脑上，软件毛病就很难再通过大略便捷的升级来填补。
这有点像专有云，交付出去了，再想升级，可能要到半年后了，那么期间出了故障，只能请 ISV 到现场帮忙检测，有时候乃至只能通过拍照供应一些资料回来，碰到军工政府类型的专有云项目，审核更加严格，周期更加漫长。
把全体专有云想象成当年你桌上那台没有网卡的单机电脑，还是比较形象的。

但是，互联网怎么可能静下心来逐步欣赏你的瀑布。
过程做的再好，交付出一个过期的产品都是不可接管的，以是坚持这个模型走上互联网之路的公司大多都去世了，乃至有些过于看重过程的国家（比如日本）都因此在互联网时期偃旗息鼓。
短平快地贴近用户需求进行极限开拓才是互联网不变的主题，以是敏捷（Agile）开拓快速在互联网的天下大行其道。
因此带来的极限编程、结对编程，在 2010 年前后迅速点爆全体软件工程界，险些不敏捷就跟不上时期了。
乃至由于深受瀑布模型缺陷困扰多年的一些公司，会报复性地去履行敏捷，看到谁准备事情多了点，谈论得深入了些，那些还没进入行业几年的“资深”程序员就会斥责新人们不足 Agile。
而互联网时期的指数级增长，动不动一个风口，使得大家都深陷暴躁之中，激进到乃至连缺点的不雅观念都被增长所粉饰，而得不到纠正的机会。
由于吸引人们眼球的永久都是成功表面的浮华，谁会进去看看背后那堆臃肿凌乱的稻草呢？

​到 2015 年前，互联网技能风向标开始倡导全栈，对研发职员的哀求也越来越多，最基本的是前后真个全栈通吃，测试、运维也转向做事化，设计了大量的测试和运维平台，环绕研发过程的自动化探索效率与质量的平衡点。
而随着硬件性能的提升，虚拟机技能越来越成熟，传统运维不雅观念逐渐改变，开拓测试运维的边界也越来越模糊，DevOps 观点呼之欲出，在敏捷的根本上连续推进变革，容器、弹性扩缩容、高可用等新技能的涌现，终于将软硬件在 DevOps 这个模型上结合到了一块，就像 DevOps 的经典图形 ∞ 符号那样，未来乃至还看不到这一趋势的终点。
​

二、技能的演进

技能是做事于开拓模式的，在一种开拓模式下，适配的技能体系总是与之呼应，并相辅相成。
以是随着瀑布到敏捷再到 DevOps，随着硬件性能的提升，也随着大神们改变天下的驱动力，技能在各种探索和繁盛热闹繁荣中不断演进。

1、做事框架

上文提到我们阿里早期利用的 WebX，实在这个框架和当时盛行的 SSH（Struts+Spring+Hibernate）思路差不多，发展到 3.0 版本之后，就逐渐退出了历史舞台，但是历史包袱还在，ATA 上还能看到有人在撰文写一些 WebX 的学习心得，大多数情形该当是接手了某个相称沉重的历史运用，不得不去面对这个古老的框架。
WebX 在互联网还没那么繁芜弘大，软件根本模块也没有封装得那么完善的年代，是一个精良的框架，它乃至让淘宝网躲过了 Struts 的 0day 漏洞满天飞的恶运。
从 PHP 过渡来的淘宝网，正是在这个性能一样平常般、开拓效率很低的框架下逐渐开始走上正轨。

WebX 无论是在开拓还是支配上，都属于相称笨重的一套框架，而险些是同年起步的 Spring 则轻巧灵巧了许多。
2017 年，我去湾区参加 Spring 大会，还有幸与 Spring 之父 Rod Johnson 要了合影，只是那会他已经淡出了 Spring 社区。
（Spring 的编年史见附录 1）

在 Spring 的根本之上，面向企业级的 MVC 框架 SpringMVC ，更加轻量灵巧、运用约定大于配置思想的 SpringBoot，还有关注微做事整合的 SpringCloud，终极组成的 Spring 家族，完全供应了面向不同需求的做事端办理方案。

​2015 年是个分水岭，我们公司 2015 年前 SpringBoot 还只是零散试点，之后几年就立即各处着花，彷佛书上常说的，历史的车轮滚滚向前，框架的车轮显然也不会停歇。
持久层框架也从笨重的 Hibernate 转到了 iBATIS，再到 MyBatis。
前文提及的全栈工程师，到了 2015 年后，随着手持设备硬件性能的提升、浏览器 H5 标准的统一、移动真个兴起，前端三剑客 Vue、AngularJS、React 也开始逐渐引领大旗，一度被后端模板化渲染夺走的技能阵地，竟然在边缘打算这样的观点下，又复活了。
本来全栈的程序员们，也重新被划分成了前端和后端两个 Job Code，而此时两者的职责和最初的定义已经完备不同了。
此时的后端更加看重对业务和需求的理解，专注于性能和架构的优化，而前端则更倾向于交互和体验，尤其在一些重前真个 toB 类产品上，前真个主导性更大。
后端供应零散接口，而前端更希望采纳整合后的统一接口，后来催化了多以 Node.js 措辞为主开拓的 BaaS（Backend As A Service）层微做事，一样平常也是由前端工程师来卖力。
个人觉得，BaaS 的引入更适宜移动真个开拓，对传统 PC 端浏览器运用的协作效率提升较小。
前后端分离还带来了一系列新技能的出身，例如 CDN 技能，使得前端更加独立，乃至在后端做事宕机的情形下，还能供应一定的挽留用户体验。

而在做事端技能上，中间件在过去十年间大放异彩，我们公司在中间件上做出的成绩就不用多讲了，这和当初提出的大中台小前台背景不无关系。
弘大的中间件群体带来的效率提升也常常是变革性的，最初看起来统统都很美好，直到频繁升级开始带来效率反噬的时候，我们才意识到个中的问题。
框架使研发能够通过代码掌控统统，而中间件则通过集中式做事来降落代码事情量。
以是无论是框架的演进，还是中间件的演进，都该当有一个平衡点，完备依赖某一方都会导致失落衡，从而带来工程效率上的灾害。
在做事端依赖的底层根本举动步伐上，虽然从 2003 年至今的大多数年份，电商始终处于风口上，但也依然有一些为了省钱该当要做的事情。
从操作系统、数据库、打算能力等几个方向上节约本钱，是效率最高的，在电商规模起来后，由章文嵩主导的 LVS、淘系的去 IOE 等重大技能变革，一方面为阿里省了钱，另一方面也让自主的技能体系不再受外部技能供应商的掣肘。
进而电商系的技能自研能力逐步开始领导互联网时期。

2、编程措辞

为什么编程措辞放在了框架之后，由于提及措辞，一定会引动身序员们的辩论，假设说一句“ PHP 是天下上最好的措辞”，一定引爆此文，让浩瀚读者弃之如敝履。
上文的框架已经引入了常常被我司同学鄙视的祖传 Java，还有浩瀚 Python、C/C++、Golang 等措辞的大拿正在捋臂将拳，准备群殴本文的不雅观点。
但即便如此，我还是想提出一个意见，即措辞是做事于系统架构的，适配于场景来选择我们须要的措辞是一名程序员的基本素养，而不是基于爱好。
软件工程一旦发展到比较弘大的规模，纵然是再前辈的措辞，如果不能捡拾古人的积累，都会导致不得不重新造轮子，引发效率的低落。
虽然不少措辞都会有一个范例的产品来代表，比如日本人设计的 Ruby 措辞的代表作是 Gitlab，但如果让商业化公司来选用，也不得不面对冷门措辞招聘困难的局势，纵然招到了资深的冷门措辞专家，他们的未来发展也是一个大问题。
以是像 Kotlin 这样可以直策应用 Java 积累的措辞，会更随意马虎被接管一些。
最近在口试的时候，也创造快手和字节的一些主流用 Golang 的团队，正在重构回 Java 体系，问及缘故原由，大多也是由于商业化企业须要的是多快好省。
在风口上没有暴露的问题，正在互联网寒冬下逐渐浮现。

微做事起步后，给予更多小众措辞以更好的生存环境，Service Mesh 技能让小众措辞也可以通过接口或者系统调用得到更多中间件体系供应的便利。
虽然当前还远未到完备成熟运用的阶段，尚处于前沿，但的确是一个很好的方向，让编程天下的多样性和竞争性充满了希望。
但在微做事之下的 SOA，大多数还是建立在传统措辞之上。
我司发展了那么多年的 Java 体系，带来的群体上风是其他措辞无法比拟的。
不少措辞，虽然在编程效率上优于 Java，但一旦用来做大型工程，则会在到达一定规模的时候陷入自洽性抵牾：要么放弃措辞的灵巧性，要么放弃工程的可持续性。
在做事端技能上，当前我司还是以 Java 为主的，这就好比引擎层，大多是 C/C++ 为主，而算法层则是 Python 为主，成体系的事情，我们没必要多做谈论。
至于更加冷门的措辞，比如 Lisp、Scala 等更常见于特定的领域。

这一节就到此为止，不再引战。

3、大数据

2003 年是个神奇的年份，淘宝网在这一年出身，Rod Johnson 正在编写 Spring 的初版，而 Google 则在这一年揭橥了奠定大数据根本的三大论文的第一篇《Google File System》，随后又在 2004 年揭橥了 MapReduce，2006 年揭橥了 BigTable。
有了这三篇划时期的论文，在当时的搜索行业老二雅虎的支持下，Hadoop 迅速发展了起来。

在 21 世纪的第一个十年，大数据体系 HDFS + MapReduce 就已经完成了奠基事情（参照附录 2），对未来软件工程带来的积极影响无法估量，乃至可以说没有大数据的发展，后来的机器学习和 AI，都将由于没有土壤而无法顺利商用。
建立在这个根本之上，打算的弹性也被明确定义，进而发展成云打算，再到后来与资源的弹性结合，促进了天下范围的云厂商的繁荣。

我认为，这里最主要的是第二篇论文 MapReduce 编程思想，它将繁芜的问题划分成小块，然后逐一破解，再将结果汇总。
如果一次 MR 不足，可以利用上一个任务的输出进行第二次、第三次、第 N 次的 MR，直到取得终极须要的结果。
后来，无论是大量利用内存从而使打算更快的批处理产品 Spark、Impala、Spark Streaming（微批），还是流式打算 Flink、Kafka，在打算的核心思想上都沿用了 MapReduce。
这有点像微积分，Map 相称于微分学，Reduce 相称于积分学，当两者结合，就可以降落问题的繁芜度，险些就可以办理现实中的统统难题。
数学上微积分用来对付无穷，而 MapReduce 用来对付趋近无穷的海量数据，的确是最恰当不过了。

​图片引自：https://www.oreilly.com/library/view/distributed-computing-in/9781787126992/5fef6ce5-20d7-4d7c-93eb-7e669d48c2b4.xhtml

最初我们利用 MapReduce 的时候，是直接通过编写 MR Job，通过 Split、Map、Shuffle、Reduce 等过程完成一个任务的设计开拓。
这对程序员的哀求还是比较高的，编写过一些 MR job，就会意识到这样的任务在编程开始前，就要在头脑中形成数据全局不雅观，从结果数据倒推初始数据的切分，稍有不慎就可能造发展尾打算或者数据倾斜。
上手难度大、调试本钱高、开拓周期长，这统统到了 2010 年利用 MySQL 解析引擎的 Hive 涌现后，终于通过大略易学的 SQL 措辞避开了上述难题，数据开拓的效率像坐上了火箭一样平常迅速提升。
也是到了此时，环球范围随着数据量的积累，大数据的威力逐步展现，数据开拓工程师这个全新的 Job Code 也在此时出身。

当时的中国，能够利用这些大数据产生商业代价的，只有百度和淘宝。
而作为承载数据开拓的平台，从云梯 1 时期的天网，到当前的 DataWorks，进一步降落了数据开拓的门槛，就算没有什么根本，产品和运营也都可以通过大略的学习，就能在 DataWorks 之上具备基本的 ETL 能力。
而 DataWorks 通过其核心的调度系统，组装了千万级任务，通过每晚 0 点到清晨 9 点的大规模集中计算，实现了阿里巴巴体系下所有离线数据的生产。
海量数据领域的门槛降落，效能却大幅度提升，轻易就可以将数据间的交互打算任务挂载到我司数百 PB 的商业大数据中，从而通过数据来引发工程能力。
此外，还可以通过 UDF 函数，在 DataWorks 平台上能够快捷的实现繁芜打算逻辑，再通过 Function Studio 进一步提升编码调试效率。
此外，由于数据开拓措辞具备一定的通用性，因此在 OLTP 和 OLAP 领域，为提升数据的利用率和复用开拓职员的产出，流批一体（一条 SQL 既可以跑在流也可以跑在批）和数据湖（同一份数据可跑多种打算引擎）技能在持续演进。
至此，到了 21 世纪的第二个十年结束前，大数据领域的核心事情基本上已经全部完成，如今只剩下在古人根本上的修修补补，以及不断的压榨集群硬件的利用率和提升运维效率这几件事了。

还有 NoSQL 领域，代表作 HBase 在 2010 年景为 Apache 的顶级项目，我是在 2009 年跟随我当时的同事，身为 HBase 社区 Committer 的“Andrew Purtell”进入了 NoSQL 的天下。
当时的 HBase 还完备是个玩具，动不动就彻底崩溃，回忆起来，当时 Base 在美国的 Andrew 绕过大半个地球跑来中国满头大汗地给我讲解 NoSQL 的实现事理，虽然这项技能当时还很挫，但很快 HBase 就成熟并实现了商用。
NoSQL 成为当前主流的能够供应在线做事的 BigTable，也和 Google 的搜索引擎的实现技能有很大关联，尤其记得当年第一次来杭州口试阿里云的时候，当时的口试官问我 Google 如何实现海量数据索引，当我回答 NoSQL 的常规实现方案后，口试官甚为不解，进而和我为是否须要 NoSQL 吵了一下午。
当年的云打算和大数据的前沿性可见一斑，领域内的里手屈指可数，虽然那次争吵非常不愉快，终极不欢而散。
但在半年后，我还是参加了淘宝的口试，终极来到了杭州。

我在 2011 年加入淘宝云梯 1 团队的时候，当时的 Hadoop 集群只有一千多台机器的规模，到 2014 年云梯 1 的 Hadoop 集群下线前达到了单集群双机房 1 万台物理机（当年的单体规模环球最大）。
当时的 C 和 Java 性能之争，开源和自研之争，激烈的不雅观点冲突放到现在来看都是上乘的技能磋商典范。
然而嫡黄花，斯人已去，唯有当初那台签满研发职员名字，承载过 Hadoop Master 的刀片做事器，还留在云智能的飞天博物馆永久陈设。

​4、机器学习与 AI

数据到了海量之后，机器学习才有了生根萌芽的土壤，通过机器学习的积累，人工智能的威力在最近的 5 年间开始爆发。
2010 年 Hadoop 上的机器学习工具 Mahout 成为 Apache 的顶级项目，但真正在深度学习领域发挥实力的还是大神贾扬清的 Caffe 和他参与的 TensorFlow。
这个领域在商业上的运用相对来提及步很晚，基本上到了 2015 年后，才在千人千面、猜你喜好、无人驾驶等领域开始大放异彩。
对付 21 世纪第三个十年的软件工程来说，可以看得见机器学习与 AI 必将成为产品上不可分割的一部分，算法工程师不再沉迷于和人类对战国际象棋，而开始深度参与到直面用户需求的过程中。

但是，当前承载算法，如神经网络、深度学习的平台还不足精良，间隔 Hive 之于 Hadoop 这样的效率提升还有不小的差距。
我司的 PAI 平台已经在探索算法优化的道路长进步了一大步，它将数据和算法当做材料，通过 DAG 组织算法序列，在易用性上已经提升了不少，但对付普通开拓者来说还是过于繁芜了。
Jupyter Notebook 则另辟路子，将论文与代码相结合，可以让算法研究者一边写论文一边写代码，待论文完成后，就可以在 Jupyter 平台上实行新的算法验证效果，由于算法大多属于文档远多于代码的一种开拓过程，因此 Jupyter 的创意带来的沉浸式体验提升了学者的创新效率，也降落了他们进入工程领域的门槛。

更早的时候，淘系搜索推举采取效率更高的线上分桶办法，快速验证算法的效果，类似于工程上的灰度，将不同算法灌装到不同的桶里供应给用户，通过用户的成交率、客单价等指标快速优选出得当的算法，这样的产品比如 TPP（The Personalization Platform）。
虽然业界已经在快速发展，但整体来说，算法还是相对付工程之皮毛当独立且门槛还没降到足够低的一个领域，如果能够涌现类似 Hive 这样跳跃式降落大数据门槛的产品，那么机器学习与 AI 领域的发展可能就会被直接引爆，人类社会的进化进程说不定都会因此而加速（大概是机器代替人类，谁知道呢）。

5、其他

环绕软件和互联网行业，技能新进展层出不穷，还有一些相对来说没有在聚光灯下，但也非常主要的技能领域，本文限于篇幅没有提及。
比如安全技能、测试技能、运维技能、存储技能等。
在软件工程中，这些领域不可或缺，但每每对工程的效率影响并不一定都是正向的，比如安全技能对互联网软件工程进度的影响每每便是负面的，而且还做不到对程序员无感。

运维领域在最近的十年里面发展迅猛，这一方面有赖于企业级硬件性能的大幅度提升，另一方面和开拓模式的演进、思维不雅观念的转变不无关联。
十年前，机房中还在利用 God 系统来对刀片机进行物理式断电和重启，到后来的虚拟机技能 VMWare、Xen，再到 Docker 的涌现，然后 K8s 做事编排进一步模糊了运维和研发的边界，结合云做事供应商的业务，终极匆匆成如今的云原生时期。
还有区块链技能、做事网格（Service Mesh）等，提升工程效率的新技能如雨后春笋一样平常不断呈现。
这让我常常想起 2008 年我在日本富士通沼津市软件工场出差的那段光阴，在巨大的一望无际的地下机房里，看到无数台密密麻麻的磁带阵列组成的存储矩阵，每一台阵列中都有一只机器手在一直的高下翻飞，快速插拔着几百盘磁带，实现寻址功能。
而到了本日，单块磁盘的存储容量都已经达到了 20 TB 以上，大量的企业级存储已经被更快更稳定的 SSD 所替代，无论是硬件还是软件，摩尔定律始终在操控着打算机的天下，这么想来，软件工程的效率该当也是遵照着每 18 个月翻一倍的速率提高的吧。

三、漫谈软件工程

20 年是个不短的过程，一个发展中的孩童都有可能经历完了自己的青春，逐渐步入中年。
但对付软件技能来说，彷佛永久无法超越青春。
我们能看到一个个技能从出身到壮大再到成熟，直到被新的技能汰换而走完生命周期，但是全体技能界随着新技能的出身，又开始再次沸腾。
如果说过去的 20 年有什么永恒的主题，那一定是环绕着工程效能展开的。

技能领域的素材散落在各处，如果都依赖架构师和程序员的组合拼装，效率显然极低，且无法复制。
因此软件工程须要有一个组织体系，这就好比交响乐须要一名指挥家，邮轮须要一名舵手。
下面这幅图展示了当前云体系下的产品舆图：

​组织好这些产品，让其在合理位置上支撑业务的发展，并勾引工程师的心智，倡导精确的方向，这些掌舵的事情正是研发效能团队该当承担的任务。
现阶段的软件工程，已经不再是过去那种大略的环绕着数据库 CRUD 的编排做事，当一个工程在代码仓库里落下第一行代码，就意味着它须要和资源、网络、中间件、离线打算、搜索引擎、实时打算、算法、运维、测试、安全等一系列技能体系打交道。
这个时期对程序员的哀求越来越高，但软件工程领域的抽象也随着这样的哀求在不断聚合，从而使得门槛降落，繁芜度也越来越简化。
持续集成、持续支配、持续发布在软件工程领域成为每个人都在谈论的话题，尤其当蓝海逐步转向红海，从烧钱转向比拼效率，研发效能以及做事工程师的底层根本举动步伐的主要性尤其凸显。
最近看到一张图很好地诠释了研发根本举动步伐在组织软件工程上的主要性。

图片引自：《一文看懂云原生时期 DevOps 如何选型》

当我们站起身来环顾天下，Google 作为技能界风向标，正在通过大库探求工程的端庄和灵巧的平衡点，Github Actions 正在通过代码驱动持续集成，而 K8s 社区正在努力探索 IaC 的可行性。
未来的天下统统皆为代码驱动，元宇宙正在向我们走来，而这统统都要基于一套易用好用且可靠的根本举动步伐，来帮助未来的工程师们高效研发。

四、研发根本举动步伐

何谓根本举动步伐，类比于生活中的水电煤，美好的生活离不开这些当代化的举动步伐，但每个人都已经习以为常他们的存在，乃至感知不到这些举动步伐在生活中的主要性。
而研发根本举动步伐也正是要向这样的方向努力。

过去 20 年间，与研发效能干系的工具很多，但平台实在寥寥无几。
每每也只有大型软件公司才能够自建配套的根本举动步伐体系，供应从需求到编码再到发布上线的全套赞助。
作坊式的小企业，大多通过人工伺服软件工程的开拓流程。
以是在 2015 年前的阿里巴巴，虽然 Aone 不算好用，但毕业的同学大多会在别的公司怀念 Aone。
直到虚拟技能的发展，K8s 的涌现，终于冲破了大公司才能拥有自己的发布体系的神话，纵然是小作坊，也可以快速搭建一套符合自身业务特点的发布管控平台。
发布运维的门槛在软硬件的配套发展下，也终极臣服于工程师的脚下。
而正好在过去的 5 年光阴里，我司的 CICD 体系却由于各类缘故原由结束不前，错过了最好的发展机遇。
然而统统并未太晚，我们引以为傲的数万工程师群体，必将鞭策我们热爱的研发根本举动步伐连续进化，并超越时期。

而好的根本举动步伐，最好是对用户来说是透明的，无感的，丝般顺滑的。
这对付深后台类型的根本举动步伐来说，做到对用户无感相对会更随意马虎些，但对付代码仓库、CICD、协作、运用等前台功能为主的研发根本举动步伐来说，优秀的体验能够极大的提升工程师的幸福感从而提升研发效率。
程序员的日常事情沉浸在个中，代码仓库在评审体验、搜索体验、阅读体验上逐步精进，环绕代码做文章，引入我们想要倡导的代码规范和度量指标，让工程师们能够像享受一杯咖啡一样享受写代码的过程。
而工程师之间的技能磋商、需求沟通，我们可以通过功能极简的事情项体系进行相互之间的协作。
到了编码之后，所有事情通过自动化流程实现快速可靠的 CICD，我们须要的是将这些根本举动步伐串联成一个有机的整体，终极还能够通过度量洞察体系来汇总全体集团的效能。

美好的愿景，在波澜壮阔的20年中常常被提起，可以瞥见的未来，史诗般伟大的工程必将出身于即将到来的万物互联的智能化时期。
当社会的组织与研发的协作在追光灯下同频共舞，开启的必将是更加大气磅礴的人类聪慧之光。
曾经的技能梦想在大神的努力下已经成为历史，镌刻在博物馆的石牌上，还有更多理性的憧憬和创新的火花在更加迢遥的未来闪耀，静候着年轻的大神们踩过古人的脚印前来捡拾，待多少年后，会有另一位记叙者重新开始漫谈这个天下曾经的辉煌，记录这从属于人类独占聪慧的软件工程。

五、附录