软件技术栈的鄙视链合理吗?——从SpaceX的软件技术栈说起

 SpaceX 把宇航员送到国际空间站了,一级火箭还稳稳当当回了家,可喜可贺。但是这和我们软件行业有什么关系呢?


关系可大了,因为有人把他们的技术栈给扒出来了。而阅读这份资料,可以有助于我们理解一个在行业里肆虐很久的奇怪想法。


f37781d0382eb29208a54192e6a3bb7.png


不知何时,软件行业内慢慢形成了一种奇怪的鄙视链条,那就是,玩  C/C++ 的瞧不起 Java,搞 Java 的瞧不起 Python,接下来是以上外加 RUBY,GO, Golong 一波新秀对于 .NET/C# 的鄙视,以及以上全体对于 PHP 的鄙视,再是以上全体对于 JavaScript 的鄙视,当然还有近年来以上全体对于安卓和 Objeet-C 的鄙视。这种鄙视链始于何时已经很难考证了,但其流传之广,以至于对于很多非本行业的客户来说,只要道听途说过一些技术员们的只言片语,也能熟练地表达出一些诸如 Java 对于 .NET 的鄙视出来,并且觉得自己逼格很高的样子。(当然,这样说的人,一般他的技术团队都是只会 Java 的。)


也因为这个,作为一个技术供应方,我经常听到这类言论:


“你们到现在还在用 xxx,真Low”


或者“那谁谁的产品居然是 xx 做的,逼格被你们甩了几条街”


等等,但我也一直没有合适的机会去严肃回应,而且,我说了他们也未必信。但是,SpaceX 的技术栈足够有说服力吧?要注意,SpaceX 虽然是一家高科技公司,但并不是一个软件公司。所以,他们在软件上的一切努力,都是为了自身某个特定的应用场景,和世界上 99% 的非软件公司处境是一致的。


能够查阅到的资料中,SpaceX 用了这些技术栈:


  • C#、MVC4、EF、MSSQL (REST);

  • Java、Knockout、Handlebars、LESS;

  • C++、Linux、C、Python、LabVIEW、MATLAB;


这份单子一出,是让很多人大跌眼镜的。其跌碎处有:

  • 居然一个百十号人的团队,不仅没有用单一技术栈,干脆是弄成一锅大杂烩?
  • C# 这种被无数中国程序员,尤其是大行其道的阿里系程序员鄙视得无以复加的平台,居然在如此顶级的体系里也能占有一席之地?
  • 同为微软系,因而同样被大加鄙视的 MSSQL 居然还能作为御用数据库堂而皇之地登上 SpaceX 的体系?那些被吹到天上去的分布式数据库呢?


可惜的是,如果你的眼镜真的跌碎了,那只能说明,那些流传于程序员界的鄙视链条流毒太深。是的,程序员往往比非程序员懂技术,但出于现实原因,绝大多数程序员都做不到能够自如选择技术栈的地步,而只能被技术栈所选择,而这些流行的鄙视链条,恰恰正是由于这个原因而导致的奇怪的流行的误解。

全栈(3).jpg

事实上,唯一正确的理解是,并没有一个绝对的“好”的技术栈,也没有任何基于事实的鄙视链存在的原因。如果任何人试图脱离应用场景来提炼技术栈的好坏,那么他就是一个极度不合格的架构师。每一个技术栈都有它非常适用,以及非常不适用的应用场景,一个架构师的优秀之处,就是认识到这一事实,理解各技术栈对于应用场景的适用性之后做出的选择。这样才能解释 SpaceX 的大杂烩技术栈:因为火箭发射涉及到的场景和相关方实在是太多了,绝无可能被一种技术栈包打天下。

举例来说,在这个体系中 C#/.NET 的存在的确并不是最高精尖的所在,它并没有参与到真正火箭发射、控制以及高性能计算的体系当中去,所以那些对它的鄙视也并不是完全没有道理。但问题是,中型企业的事务性管理是一个永恒的存在。无论是看似高大上的发射火箭,还是Low爆的造肥皂修下水道,都有无穷的事务要管理和处理,有报表要制作,而C#的强项恰恰就在这里。SpaceX 用它来管理采购,人事等等非科研类事务,(要知道 SpaceX 总员工数超过 6000 人)就是基于它的平台特性:易于搭建,方便与微软体系整合,适应规则的频繁调整,对高吞吐性能没有太高要求,逻辑容易建立,代码容易读懂。如果一个架构师不能跳脱流行的鄙视链条视角,在这些事情上也盲目上 Java,那就如同非要用造火车的钢材来造菜刀,钱花了无数,效果还没法看。

数据库的选用也是一样。一个典型的企业级 2B 内部 MIS/ERP,并发强度不高,计算深度却挺深的场景,为什么要用以并发性能见长,而深度计算能力有限的分布式数据库呢?

还有更多的佐证。比如,在自动化领域图形化编程场景中,没有比古老的 LabVIEW 更好的选择,而 Python,和其他一众技术栈中的后浪们,比如 RUBY,GO 等等,其实应用范围远没有我们感受到的那么宽。Python 用来测试或校准算法也许非常常见,但一旦一个软件工程师离开校园和科研环境,进入商业环境以后,他就会发现,Python 的流行是一个巨大的误解。

还有,任何一个技术栈的特点,也不是一成不变的。还拿 .NET 来举例,虽说大家的刻板印象一直是它不适用于高流量高并发的 2C 场景,但又有几个人知道整个腾讯财付通的后端都是用它的次世代跨平台版本 .NET CORE 搭建的呢?当很多人认为 PHP 已经是 40 岁以上的程序员的专利,即将被扫入历史垃圾堆的时候,又有几个人知道即将发布的 PHP 8.0 带来了多么巨大的平台级变化呢?

4444.jpg

当然,公平来说,那个鄙视链条理论也并非一无是处,某些局部逻辑也是真实的,比如,对于直接操控硬件,希望硬件发挥最大效率的场景需求来说, C/C++ 仍然是不二选择。但是,真正需要贴近硬件,压榨硬件性能的应用场景,除了火箭发射这类并不常见的例子,或者某些对单机性能高要求的游戏以外,在日常商用场景里又有多少呢?如此说来,C/C++ 的上古神兽的地位,——又牛逼,又稀缺——恐怕只会日益加强了。

放弃鄙视链,专注分析应用场景,这是 SpaceX 的技术栈清单传递出的清晰的信息。当然,对于并不从事软件行业的客户而言,有一个更容易理解的指导原则:如果你的程序员告诉你,C++ 一定比 PHP 要强,不要听他的,给自己找一个专业架构师来;如果你的架构师认为 Java 一切都好,那么换掉他;最后,如果你实在摸不准自己的架构师是不是靠谱,不妨来找我们聊一聊。


回到顶部