社区驱动开发：技术选型的另类浅析

Posted by: Phodal Huang June 27, 2022, 8:43 p.m.

PS：一篇纯吐槽而主的文章，请不要过分代入。

六月，在探索一些技术选型的发展趋势 —— 除了研究国内的技术趋势，也研究了一部分的国外技术趋势。当然，结果是显而易见的，国外的技术选型上，依旧还是比国内领先的。但是呢，国内也没有那么差，只是受限于基础不够扎实的原因，还处于追赶状态。为了简化大家的理解，我把这种选择趋势称之为：社区驱动开发。

简单来说，就是技术社区上流行什么，那么这个区域就会流行什么。也是一种关于技术理念的竞争游戏。

流动率游戏：从郑州到杭州、北上广的差异

郑州。2020 年的时候，我曾经到郑州出差过一段时间，有感于当地的开发人员的基本水平。受限于当地的培训环境、公司水平等，前端开发人员依旧在笑后端开发人用缓慢的 Eclipse，前端开发人员使用 JavaScript，而不愿意去接触 TypeScript。而从社区的活动来看，当地在各种技术网站也没有什么技术活动。所以，什么样的公司才是当地最好的技术水平呢？我不知道，找不到一个合适的参照物。从另外一个角度来说，技术公司少的时候，人员的流动率也变低，那么在技术选型上也就趋于保守。因为大家在技术选型上也倾向于使用一致化。

杭州。杭州因为存在大厂的缘故，所以在技术人员的流动率上会比较高。而正是这种人员流动率，会使得技术的交流更为频繁。而受于杭州也算是准一线的水平，在各种技术大会上也相对较多 —— 当然了，和一线城市相比，还是少一点。而也正好，杭州有阿里、网易、字节等的存在，使得在技术选型上，会稍微靠前一点。只是呢，对于不是技术驱动的业务条线来说，也就只是保持一种跟随的状态。不过呢，由于研究院、实验室的存在，有一些部门会在技术驱动与业务驱动之前平衡，因而会有更好的技术选型。

一线城市。在诸多的一线城市的软件公司里，也包含了银行之类的传统公司，他们会购买 IDEA 作为开发人员的工具。管理人员经常会参加各种技术大会，多做一些技术上的碰撞与交流。花更多的钱去人员招聘上，带来的新鲜血液，也带来了一些新的技术选型。在这样的一线城市里，传统公司遇到的另外一种挑战是，程序员都是简历驱动开发。JD 上使用 Spring Boot 的薪资大于 JSP 时，那么市面上的 JSP 程序员就会越来越越少。于是，对于这些公司和团队来说，他们需要被迫选择新的技术栈。于是乎，对于他们而言，就不得不开始追赶技术趋势，这也是一种相当糟糕的现状。低技术流动的情况下，就会出现中间的技术断层。随着，这种断层的加剧，那么就会出现高薪 COBOL 程序员。

在这场物竞天择的游戏里，几乎每个人都是赢家，输的只有 “遗留” 技术栈。

激进的技术战略：从业务部门到云厂商

与上面的业务部门相比，云厂商技术路线上就是：以激进而著称。业务部门会从技术趋势中，挑选最适合自己的技术，而云厂商则会去创造技术趋势。所以，云厂商在这个游戏里，是真正的玩家之一。还有热衷于宣传新技术的布道师们，只要能在老一代学阀里割开一道空间，就是胜利。

几年前，经常有人在问我们微服务之后会流行什么？在几年前，可能没有，现在的话：无服务器架构（Serverless）、服务网格架构（Service Mesh）、单元化架构（Cell based）。除了各种先进的架构之后，还有更多先进的基础设施会带来更好的性能。这一系列的先进技术，最热衷于对他们进行布道的就是云厂商了。以前，需要大量地资深程序员、架构师，现在只需要掏出更多的钱即可。顺带地，你也可以认为，国内的各种云厂商卖得不好，原因可以归 “功” 于：程序员便宜。

为了更卖出更多的服务器，云厂商就在各种开发者体验上发力，诸如于：基于 eBPF 的可观测性、性能更好的微服务网关、定制化微服务模板的 Spring Cloud xxx 等，一系列的贴心服务。

也因此在技术、架构的相关会议，远不如云厂商的各种新技术发布会来得精彩 —— 他们都是源自于我们开发服务时，真正的痛点。基于这些痛点，构建出来的工具和技术趋势。

PS：顺便一提，云厂商一般都只卖服务端相关的技术，纯客户端的未来技术，并不能卖出更多的计算资源。

国内 vs 海外：机器与人谁更贵

再回到国内外的技术对比上，现在（2022 年）的趋势上，国内在某些技术领域上的架构是领先，或者说接近于国外的。在互联网领域，主要分为两部分：

1. 功能密集型的客户端架构。领先
2. 功能密集型的服务端架构。相差不多
3. 计算密集型的数据类应用。接近

受限于个人对于领域的理解，所以只感受到了这三点。对于客户端来说，小程序、微前端、模块化、组件化等技术，在国内已经是出神入化。对于国内来说，我们的挑战是，如何上更多的人，以添加更多的功能？同时，让用户的体验不是那么差。对于服务端来说，同样也是相似的，如何更好地做好劳动密集型开发，所以我们需要中台这一类的方案。对于数据计算来说，从国内最近各种进入 Apache 孵化的大数据项目就可以看出来：国内在数据的处理上，真的可以达到国际领先 —— 不过，还没有，只是在逼近中。

所以，结合上面的单元化架构等，从技术上来说，国内在规模上的挑战更大，而国外在招不到程序员的挑战更大。也因此，在人力成本上，我们感概于某个东方大国 —— 印度，他们真的做得很好，程序员比机器便宜多了。他们的领导总会说，机器会出故障的，换个机器不容易。

社区驱动开发

技术趋势本质还是一种技术影响力游戏。它可以分为四步：

1. 深刻把握开发人员的痛点。
2. 构建新的架构，新的技术理念等
3. 制造焦虑。在架构、技术、理念在社区进行传播
4. 让知识流动起来。也应该让人流动起来，诸如于向社会输出这些优秀的人才

所以，只要让社区焦虑起来，那么技术趋势就扩展起来了吗？不，事实并非是如此。首先，得找到一个合适的痛点，比如当前的系统是一个遗留系统，需要一种更好地技术来分析和构建迁移策略。接着，再构建于这样的痛点去构建一些工具，让人们更贴切地感受到真的有工具能解决问题。最后，再尝试用工具，去解决这样的问题。有时候，我们开发的新工具并不一定能立马解决问题。所以，在社区上的人会想到更好的工具，诸如于 Atom 编辑器就是一个很好的跳板

不过呢，社区的精髓是，要吸引越来越多的人参与到这个游戏中来。如此一来，在足够的战斗之力，才能制造焦虑。

所以，你是根据什么来进行技术趋势选型的？