前一阶段时间随着 PHP 7.1 的推出,我推动团队将使用的 PHP 版本从 5.6 升级到了 7.1,投入了一个开发同学约一周的时间。回忆进入公司之后到现在,技术栈中包括 Laravel,CentOS,MySQL,Python,Node.js 都经历了大版本的升级,其中像 Laravel 从 4.2 升级到 5.1,等于把相当部分的代码重构了一遍,其它各种依赖升级更是不能尽举。

笔者所在公司拥有典型的工程师文化,对技术栈的升级都是抱着鼓励和欢迎的态度,所有升级过程加起来确实投入了不少的人力,这不禁让我思考这些投入是否都有必要。

在有的团队推动技术栈的升级极其困难。有的负责人认为升级这种事情,产品层面完全无感知,可能除了支持一些新特性,能帮助程序员“追求时髦”外别无用处,简直是浪费生产力。

其实平时能够听到声音的升级诉求,一般情况下都会有不小的收益。像从 PHP 5.6 到 PHP 7 的升级,性能基本会提升一倍;Redis 从 2.x 到 3.x 的升级,会获得对 cluster 的支持。

如果某个依赖的升级只是提供语法的新特性、新的语法糖,或者提供新的 API,有的 leader 会觉得为这种事情投入资源完全没必要。但是我认为让程序员写代码的时候心情愉快也是一件很重要的事情。比如笔者就很喜欢 PHP 7 的 Null coalescing operator。每次写的时候,想到再也不用 isset() 来判断真的很爽。而且也确实能提高程序员的工作效率,这和为开发同学配台 MacBook 比配台普通的 Windows 本能提高生产力是一个道理。

有的公司体量巨大,历史代码过多,牵一发而动全身,推动某个依赖的升级成本过高,并且风险也难以评估,这种时候选择维持现状似乎也可以理解。但是技术圈变化实在太快了,版本的个位数字都会一年自增一次以上。很有可能过几年后,为了使用某个新特性不得不进行升级的时候,却发现已经升级不动,积重难返了。很多系统推倒重来的原因之一不就是因为技术选型的依赖太陈旧吗。笔者还记得 2013 年在某大厂实习的时候,好像是为了在一台开发机上使用 Python 的 lxml 包,因为各种依赖版本过低,最后把从 Python、pip 到 GCC 的各种依赖都升级了一遍,差点把内核也升了。仅仅是为了装一个包,就花了一天多的时间,这种投入实在很伤。

我一直认为互联网发展如此之快,不断有员工不多的独角兽公司涌现出来,开源社区几十年来的活跃是一个重要原因。大部分问题,社区里都会有可靠的解决方案可以直接使用,大大提高了创业公司的开发效率。 PHP 的包管理工具 Composer 是从 11-12 年兴起的,如今已经是 PHP 社区事实上的包管理标准。但是现在依然有不少公司使用手动的方式进行包管理,效率实在很低。如果不注重技术栈的更新,就等于放弃了开源社区不断提供的巨大福利。

同时由于开源社区的发展太快,一个项目的版本号跳的过快,其中每个版本的维护时间可能也不会很长。同时维护人员可能也没有足够的精力和心情来维护旧版本,这就导致你不得不跟着社区的节奏进行升级,毕竟使用失去社区维护的旧版本也是一件有风险的事情。

当然有的升级确实值得商榷,比如在几年前,从 Python 2 升级到 Python 3 就是一例,当然这个争议这几年已经逐渐消失了。

万事都是基于 ROI 的考量,需要具体情况具体分析,只是因为每个人背景、看问题角度和视野的不同,导致对成本和收益作出的评估也不一样。个人认为在条件允许的情况下,至少技术栈中核心依赖 stable 版本的升级是非常有必要的。