技术栈的选择没什么好纠结的

[Mark24]

技术栈的选择，应该是每个人都会遇到的。就简单聊聊这个话题。

我们看到过 Flask VS Django 的争论，或者 Sinatra VS Rails 的争论。前端框架 React VS Vue 。 这种争论时常会发生，也总会让初学者陷入困扰。

我就尝试来解决一下这个问题：

首先，技术框架产品的特点，或者包装的形态，一般就是两种形式：

1. 微框架流派

   提供一个小小的 core，一切通过插件围绕产生。 他比较纯粹，工作原理也简单明了。比如：web 框架的例子，Flask （ Python ），Sinatra （ Ruby ），Koa （ JavaScript ）。 前端框架 React 思路

2. 大而全保姆式框架流派

   提供从零到一的技术方案，方方面面照顾周全。比如：web 框架的例子，Django （ Python ），Rails （ Ruby ），Egg （ JavaScript ）。前端框架 Vue 以及 Vue 生态。

这两种流派都各有拥趸，实际上也难分伯仲。技术不能以此届划分好坏。

这里我们要拒绝一种偷懒的想法：我们的脑袋里不应该总是想象出一本武学秘籍，类似《葵花宝典》《九阳神功》，只要得到他学会它就万事皆休。没有这样子的事情。要看我们要解决的事情。要具体问题具体分析，我们要做什么，能坚持多久，他会发展多大？

微框架的特点就是微小，可控。它提供一个简单可靠健壮的基础。这里往往适合去搭建一些轻量级需求，亦或者是短频快的小需求服务。未来也不会更复杂。

还有一种情况是，未来会特别复杂。也适合。有人会问了为啥未来特别复杂也选这个？因为特别复杂的业务，存在大量定制性。而一个简单的基础意味着稳定、可靠，即使出问题也可以自己 debug 找出来，看源码也能解决。所以也适合长线构建的超复杂的程序。

这个观点不是空中楼阁，空穴来风。现实中有很多的例子。 像 React 、Vue 是前端这两种流派。React 是一个 Core，Vue 是大包大揽。实际上越来越多的商业公司逐渐转向 React 构建更复杂的应用。Vue 停留在中小型公司，服务一些中后台业务。

后端的框架比如 Python 的 Flask，和 Django 也是，Flask 是一个 Core，他也用于从零构建公司业务网站，比如国内的豆瓣就是从一个 Flask Like 的 Core 基础上构建出来的。Django 更适合快速搭建一些定型的业务后台。

大而全的保姆式框架，虽然面面俱到，你刚开始会用的很爽，但是对你的束缚也是真真切切。我们应该明白，任何一个软件、程序都有设计目标，功能范围。 如果你在他的设计目标里使用就会如鱼得水，但是如果你超越他的设计目标，你就不得不要和这个技术框架做对抗。要去 hack 他的设计，组件。最终你会碰钉子—— 你会发现还不如从头自己来。

简单得出结论：

大而全的技术方案适合构建一些中规中矩，非常规律性的东西，比如后台服务，近乎标准化的业务。果用微核心的框架去构建，反而是在重复劳动。

微核心的技术方案适合构建本来就不复杂的东西，或者是定制型高、原创性、复杂的东西，尤其是长线设计的东西。

好了现在你已经知道如何去选择，或者说学习什么样子的技术框架。

---

我的博客： https://mark24code.github.io/%E9%9A%8F%E7%AC%94/%E7%BC%96%E7%A8%8B%E6%80%9D%E8%80%83/2021/06/25/%E6%8A%80%E6%9C%AF%E6%A0%88%E7%9A%84%E9%80%89%E6%8B%A9.html

[AlexChing]

我覺得說的很有道理呀

[stkstkss]

你说得都对

[mightofcode]

你说得对

[lesismal]

"好了现在你已经知道如何去选择，或者说学习什么样子的技术框架。"
——对于 pyer 、phper 之类的服务端开发者，最正确的选择是转 go/java，除非自己不打算往更高层次提升、去有机会处理超大业务量级

看看近几年的各大明星企业大量用 go 起步或者用 go 重构的情况吧，连知乎都用 go 重构了

[lesismal]

某乎社区核心业务 Golang 化实践
https://zhuanlan.zhihu.com/p/48039838

[jones2000]

给出技术框架的时候怎么没有给出上线以后硬件， 运维人员等配置呢？ 越高大上的框架， 后面运维的成本比开发都贵。

[zoharSoul]

@lesismal #4 是的, 京东到家是 py 转 java

[wellwell]

这些同一类型的确实没啥好纠结的。但是 C++客户端 vs java 后端，C# vs JS Java 呢？

[Mark24]

@jones2000 容器化，集群。 来应对上线部署。这个思路已经是很通用的思路了。

常见的是 docker，k8s 。云服务商也提供。

容器化的方案也有 大而全的比如 k8s，
也有一些简化版 k3s，以及其他。替代品很多。

看当下的市场吧。docker 可能要被新的好像叫 podman 的替代了。

这方面我不是研究很深。

思想方法可以通用。

[Mark24]

@lesismal

我们的互联网公司喜欢切换语言，然后对人力把业务重写一遍。这样的事情每天都在发生。

Ruby/PHP/Python/Nodejs/Go/Java

未来也可能有 Rust, Elixir ……

其实这也不是什么坏事。不过我个人的角度认为这不够好。为什么不够好呢? 这就放弃了—— 代码其实是一种资产 的特点。

我看到的更好的方向是，Instagram 改造了 Python，Facebook 改造了 PHP，Github 改进了 Ruby ……我的代码不用改变但是性能提高了。社区因此受益。


另一个角度，给我的感觉 Go 还在发展中，我可能没有什么发言权，但是 Go 的周边似乎还不成熟，还倚仗大家造论子式的工作。老的语言，并不是不能完成，也不是不能完成的更好。Go 的替换就像有一阵子，非要用 Nodejs 替换。

编程语言成为一种话语权。成为新人替代旧人的工具。

我为什么就这点多说一点呢？因为我的本职工作是前端。技术工具变化的比后端频繁多了，工具多了有什么坏处呢？他会消灭你多年的经历和经验。简单说，你会用一万种乐器演奏小行星，但是未能用一种乐器演奏 更加深入的某种乐曲。
就是这个意思，一直在一个水平在努力。没有深度、高度。当然这个是很个人的事情，不过大环境，太疲惫了。他会影响你，因为你身处其中。

[Mark24]

对人力 -> 堆人力

[Mark24]

@wellwell 这里其实不是在讨论选择语言。

而是语言之上的某种框架选择。可能我标题不够严谨。


语言的选择，C#,Java 我没什么发言权，我没学过没用过。
一些通用的规律也可以聊聊。

构建大型项目，强类型是有帮助的。
Java 的设计特点是保守的，也称做蓝领语言，简单说谁来了写出来都差不多。他刻意设计成这样。适合企业。
这些都是书里看来的。应该是符合现实的。

动态语言出活快，适合构建原型。当然也看水平和熟悉程度，有的人也可以通过动态语言支持庞大的业务，比如 Instagram 、Github 。

这些是语言特点。

站在玄学角度，如果你自己为自己挑一个语言。看你是什么样子的人，或者你倾向什么。
C/C++/Java …… 他们都很束缚，要让你管理好一切。Java 还会限制你的自由。
你可能觉得本应该如此。所以可以选择他们。

Python，Ruby 更加自由。
Python 的魔术方法，可以让你的类成为语言的一部分。
Ruby 的元编程甚至允许你修改语言本身。猴子补丁不被当成 BUG 而被当成 feature，赋予你自由相信你可以处理好。
喜欢的自由，笃信创造力，创造规则的人可能更偏爱他们。

没有什么好和坏，绝对的准则。更多看你的选择，你要做什么，你打算做多久，你和谁一起做。

[lesismal]

@Mark24 #10
我在前面给出了这句："除非自己不打算往更高层次提升、去有机会处理超大业务量级"

其他方面的楼主说了一大堆，但是兄弟，你可能没 get 到为什么那些巨头要用去换掉 py 、php 。可以搜些帖子、新闻，稍早点的 B 站用 go 重构大量服务，往前大概还有七牛、猎豹移动、滴滴、头条大量用 go，或者我上面发的那个知乎的那个改造应该是近期一两年内的，好像前年还在知乎上看到有人说知乎 py 性能垃圾然后知乎技术大佬出来回复有好方案愿意怎么样怎么样的

py 不只是国内这些巨头在海量业务时要抛弃，十几年前谷歌造 go 的时候是因为被 c++虐得快瓶颈了，再往前有点谷歌把 py 之父招到麾下了本来是打算让 py 能帮助谷歌解决很多工程上的问题，但是搞了几年，没办法，py 虽然是真的方便但也是实在太慢了，谷歌根本无法忍受 py 这种性能。
不要用 py 在大数据、AI 等领域仍旧遍地开花来解释 py 性能不是问题，你要看看 py 在这俩领域是怎么使用的——都只是胶水语言 bind 个 c++之类的接口而已。另外就是 devops 领域了，然后呢？还是主要用于非性能敏感领域的工具、简单服务。真正涉及性能的，k8s 也好，周边的 netdata 、filebeat 也好，都是 go 、java 之类的（早期很多人用 java 搞了很多东西，但是后面很多是用 go 比如 EFK 的 F 替代 ELK 的 L，因为 java 的性能和吃内存也是让人无法忍受的）

还是上面那句话："除非自己不打算往更高层次提升、去有机会处理超大业务量级"
至于你解释的那些，兄弟，你首先得搞懂 py 自己的瓶颈是什么、为什么在那些领域被大家抛弃了，然后再来讨论时你的论据才会更具说服力，但是我相信，如果内真的去了解了那些内容，你直接就会站到我这边的观点、不需要再为 py 争取什么了。

[lesismal]

@lesismal 再补充一点，也正是 go 基本成型、可以被大家广泛采用之后的时间段，py 之父离开了谷歌。虽然没有人直接说是什么原因或者把 py 之父跟谷歌的语言技术栈变革直接关联，但是那个入职离职谷歌的时间点，恰恰对应了 py 、go 在谷歌内部的发展情景，即使非直接影响，也是从侧面可以看出谷歌 go 、py 的大体发展过程

另外，其实楼主对 go 的一些描述，说明楼主对 go 真的还太不了解，对 go 的观点可能还停留在 5 年前

[dayeye2006199]

其实可以换位思考，你要是公司的老板或者 CTO，你怎么在公司现金火烧屁股，只能支持个半年多的时候去选择技术。

1. 第一肯定是你们团队对什么东西最熟悉就上什么，短时间就能发挥最大化工作效率。团队大部分人都是 Elixir 老鸟，偏要去赶热门上什么 Go 肯定不合理。人效在企业早期最重要。
2. 第二是要考虑框架 /语言本身的开发效率和对业务的支持程度。这个也是一般意义上大家优先关注的。你们公司开发数据库的，硬要去用 PY 写肯定不合理。
3. 第三才是去考虑长期的计划。这个我觉得可能是最不重要的。长期我们这个框架能不能支持业务的发展？长期是什？我们能不能活过今年？等我有了钱，招个一整个团队来整吧。就像 FB 干的，硬生生要去杠最好的语言 PHP，整了 jit 编译器，运行时虚拟机，类型系统，重写标准库，一整个团队去支持它们的 PHP fork Hack 语言，一样能扛起大量的业务。真是有钱任性。

[ljzxloaf]

说句废话，合适的才是最好的

[kuangwinnie]

对
如果真的有那么一本武林秘籍，那码农就没工作了

[laowai89]

说到底就是成本问题

[Mark24]

@lesismal 我还需要学习~

[danhahaha]

这就跟下地干活用什么工具一样：

锄草就是锄头最趁手，割麦子就是镰刀好用，可能一把圆头锹俩个事都能干。

但是很多人使锄头有经验，就拼命夸锄头可以顶个半联合收割机。

[dengshen]

工具灵活，框架统一。多人协作肯定要用框架来限制。自己玩就随便

[musi]

问题不在于团队引入新技术栈的成本么？
比如本来一个团队用的是 Vue 相关的技术栈
突然换到 React
代码写法上的改变先不说
UI 组件库，打包配置等各种基础设施都得换
自己的项目就随便用了