4

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

 3 years ago
source link: https://www.v2ex.com/t/788321
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

V2EX  ›  程序员

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

  Mark24 · Mark24Code · 13 小时 39 分钟前 · 1319 次点击

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK