V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
Mark24
V2EX  ›  程序员

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

  •  1
     
  •   Mark24 ·
    Mark24Code · 2021-07-08 15:55:08 +08:00 · 4863 次点击
    这是一个创建于 1252 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    我们看到过 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

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

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

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

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

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

    这方面我不是研究很深。

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

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

    Ruby/PHP/Python/Nodejs/Go/Java

    未来也可能有 Rust, Elixir ……

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

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


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

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

    我为什么就这点多说一点呢?因为我的本职工作是前端。技术工具变化的比后端频繁多了,工具多了有什么坏处呢?他会消灭你多年的经历和经验。简单说,你会用一万种乐器演奏小行星,但是未能用一种乐器演奏 更加深入的某种乐曲。
    就是这个意思,一直在一个水平在努力。没有深度、高度。当然这个是很个人的事情,不过大环境,太疲惫了。他会影响你,因为你身处其中。
    Mark24
        11
    Mark24  
    OP
       2021-07-08 23:28:48 +08:00
    对人力 -> 堆人力
    Mark24
        12
    Mark24  
    OP
       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
        13
    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
        14
    lesismal  
       2021-07-09 00:31:09 +08:00
    @lesismal 再补充一点,也正是 go 基本成型、可以被大家广泛采用之后的时间段,py 之父离开了谷歌。虽然没有人直接说是什么原因或者把 py 之父跟谷歌的语言技术栈变革直接关联,但是那个入职离职谷歌的时间点,恰恰对应了 py 、go 在谷歌内部的发展情景,即使非直接影响,也是从侧面可以看出谷歌 go 、py 的大体发展过程

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

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

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

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

    但是很多人使锄头有经验,就拼命夸锄头可以顶个半联合收割机。
    dengshen
        21
    dengshen  
       2021-07-09 13:35:01 +08:00 via iPhone
    工具灵活,框架统一。多人协作肯定要用框架来限制。自己玩就随便
    musi
        22
    musi  
       2021-07-10 12:18:10 +08:00
    问题不在于团队引入新技术栈的成本么?
    比如本来一个团队用的是 Vue 相关的技术栈
    突然换到 React
    代码写法上的改变先不说
    UI 组件库,打包配置等各种基础设施都得换
    自己的项目就随便用了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2982 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 11:00 · PVG 19:00 · LAX 03:00 · JFK 06:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.