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

2021-07-08 15:55:08 +08:00
 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

4663 次点击
所在节点    程序员
22 条回复
AlexChing
2021-07-08 16:17:31 +08:00
我覺得說的很有道理呀
stkstkss
2021-07-08 16:20:23 +08:00
你说得都对
mightofcode
2021-07-08 19:42:32 +08:00
你说得对
lesismal
2021-07-08 20:36:33 +08:00
"好了现在你已经知道如何去选择,或者说学习什么样子的技术框架。"
——对于 pyer 、phper 之类的服务端开发者,最正确的选择是转 go/java,除非自己不打算往更高层次提升、去有机会处理超大业务量级

看看近几年的各大明星企业大量用 go 起步或者用 go 重构的情况吧,连知乎都用 go 重构了
lesismal
2021-07-08 20:41:14 +08:00
某乎社区核心业务 Golang 化实践
https://zhuanlan.zhihu.com/p/48039838
jones2000
2021-07-08 22:25:40 +08:00
给出技术框架的时候怎么没有给出上线以后硬件, 运维人员等配置呢? 越高大上的框架, 后面运维的成本比开发都贵。
zoharSoul
2021-07-08 22:46:30 +08:00
@lesismal #4 是的, 京东到家是 py 转 java
wellwell
2021-07-08 22:56:15 +08:00
这些同一类型的确实没啥好纠结的。但是 C++客户端 vs java 后端,C# vs JS Java 呢?
Mark24
2021-07-08 23:17:37 +08:00
@jones2000 容器化,集群。 来应对上线部署。这个思路已经是很通用的思路了。

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

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

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

这方面我不是研究很深。

思想方法可以通用。
Mark24
2021-07-08 23:28:20 +08:00
@lesismal

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

Ruby/PHP/Python/Nodejs/Go/Java

未来也可能有 Rust, Elixir ……

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

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


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

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

我为什么就这点多说一点呢?因为我的本职工作是前端。技术工具变化的比后端频繁多了,工具多了有什么坏处呢?他会消灭你多年的经历和经验。简单说,你会用一万种乐器演奏小行星,但是未能用一种乐器演奏 更加深入的某种乐曲。
就是这个意思,一直在一个水平在努力。没有深度、高度。当然这个是很个人的事情,不过大环境,太疲惫了。他会影响你,因为你身处其中。
Mark24
2021-07-08 23:28:48 +08:00
对人力 -> 堆人力
Mark24
2021-07-08 23:38:26 +08:00
@wellwell 这里其实不是在讨论选择语言。

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


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

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

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

这些是语言特点。

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

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

没有什么好和坏,绝对的准则。更多看你的选择,你要做什么,你打算做多久,你和谁一起做。
lesismal
2021-07-09 00:25:05 +08:00
@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
2021-07-09 00:31:09 +08:00
@lesismal 再补充一点,也正是 go 基本成型、可以被大家广泛采用之后的时间段,py 之父离开了谷歌。虽然没有人直接说是什么原因或者把 py 之父跟谷歌的语言技术栈变革直接关联,但是那个入职离职谷歌的时间点,恰恰对应了 py 、go 在谷歌内部的发展情景,即使非直接影响,也是从侧面可以看出谷歌 go 、py 的大体发展过程

另外,其实楼主对 go 的一些描述,说明楼主对 go 真的还太不了解,对 go 的观点可能还停留在 5 年前
dayeye2006199
2021-07-09 02:16:11 +08:00
其实可以换位思考,你要是公司的老板或者 CTO,你怎么在公司现金火烧屁股,只能支持个半年多的时候去选择技术。

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

如果真的有那么一本武林秘籍,那码农就没工作了
laowai89
2021-07-09 09:33:34 +08:00
说到底就是成本问题
Mark24
2021-07-09 11:15:02 +08:00
@lesismal 我还需要学习~
danhahaha
2021-07-09 11:30:15 +08:00
这就跟下地干活用什么工具一样:

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

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

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/788321

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX