作者：chieh
重新思考前端开发以及自己未来的规划。先说结论，再展开。
- 烂程序员关心的是代码，好的程序员关心的是数据结构和它们之间的关系。—— Torvalds
- 编程也是内容创作，认清自己是哪个层级的创作者。
亲身经历公司在去年选择了一款 Plasmic 这个低码平台，希望未来由业务部的人来使用低码平台构建页面，由开发部的人负责研究平台的使用方法、解决复杂的问题。后来，公司有 100+ 个问卷需要制作，并且这个业务是在内网中，不方便使用第三方的表单服务。这 100 个问卷中，有几十个在另一个 Vue 系统中有实现过，还有一些可能需要新增。我推荐让开发部来写这部分代码，但领导还是决定让业务部门的人使用低码平台（基于 NextJS）来构建。理由是这些问卷在另一个 Vue 中有实现过（我实现的），照着页面抄就行了。
在业务部的人经过一个星期的折腾之后，做了几十个问卷，最终因为难以维护而停止。这几十个问卷每个都是单独的页面，每个页面都需要对接口，需要一个问题一个问题的拖拽然后配置。在检查的时候，出现了各种各样的问题，量表出现问题时，还得一个问题一个问题的排查，排查起来不如重做。更何况，业务部的人也不会排查页面，她们没有什么编程基础。
这个问题并不难解决，只是这个决策让人有点令人匪夷所思。我的解决步骤大致分为两个步骤：将 NextJS 中的 Form 的编辑变成声明式的、对 Vue 中的 Form 进行迁移。
将 Form 的编辑变成声明式的，也就是用 JSON 来配置。例如在 Vue 中可以使用FormCreate 、在 NextJS 中可以使用nice-form-rect 。我其实并不喜欢拖拽式的低码，拖拽之后再通过点击来配置其实很费时间，在经过我的实践发现，这种声明式的配置配合 GPT 来使用非常妙，只需要把配置相关的要求告诉他，就可以让他完成大部分的工作。把编写 Form 页面变成编写 JSON 文件，复杂度直线下降。业务部的人可以直接通过 ChatGPT 生成 JSON，我只需要给他们一个工具来校验和展示 JSON 所对应的量表即可。
将 Vue 中的 Form 转换到 Next 中，有些人可能会考虑思考 FormCreate 底层的逻辑，然后在 NextJS 中再实现一遍，这样就能无缝迁移。并不需要这么做，这么做工作量非常大，只需要看数据结构怎么转换即可。
总结：Vue 中的 FormCreate 经过了魔改，支持根据题目算分。在 NextJS 先实现类似的声明式构建的机制，然后再将数据库中的 JSON 配置进行转换。
最终，加上业务部的配合，使用 GPT 来生成 JSON 文件，两三天的时间就全部迁移完成。大胆预测一下，拖拽式低码平台后面会被懂 DSL 的平台所替代，利用语义化的 DSL 配合大语言模型，效率应该会非常高。
重新思考前端开发Linux 的创始人 Torvalds 曾说过一句话：“烂程序员关心的是代码，好的程序员关心的是数据结构和它们之间的关系”。
上面的声明式的 Form 工具是我构建的，由业务部的人来使用，当他们有什么需求的时候，我能很容易知道现有的结构能否实现。将 React 想象成一个更复杂的声明式的 Form 工具，那么熟悉它底层原理的人应该也可以拓展它的边界。
于是我尝试着阅读了一些 React 相关的源码，理解了 React 本质上是 DSL + 高效更新树的算法。JSX 作为 DSL 来引入组件化和简化树形结构的编写，Fiber 树和 Diff 算法来高效的更新树。
沿着树形结构稍微发散一下，就知道为什么会有 React Native 了。在网页中使用 DOM 树，在安卓中使用 View，在 IOS 中使用 UIView，这些都可以被称为布局树。当然除了更新视图，还有很多需要兼容的问题，例如：
- 解决布局不一致：采用Yoga布局引擎。
- JS 和原生代码交互：跨语言通信都会利用 Bridge 这种机制。例如调用 rolldown 会使用napi-re 。
我还继续沿着树形结构去探索 React 的可能性，想到了 Svg、Canvas、Three.js 这几种技术。我并不是特别了解这几种技术，只是简单的 check 是否有人将 React 用于这些方向，最后发现React Three Fiber 这个项目。Three.js 中需要渲染场景树，Fiber 树现有的逻辑为什么不能用，非常好奇作者是如何将 Fiber 应用于 Three.js、为什么需要再实现一个 Fiber。
学会用 React 写页面非常简单，从零基础开始学，最多几天就能写出基本的页面，最麻烦的可能就是调 CSS，但是这些问题的复杂度都并不高，多搜索多尝试多问 GPT，基本也花不了多长时间就能解决。
但如果我们遇到的需求是制作Su7在线预览 、制作Win98在线版 、制作 Figma（通过 Webasmbly 与浏览器 Canvas 交互，让用户在浏览器端体验到了 Native 软件能力），那我们应该怎么办？薪资水平上不去的原因有部分原因就是这个了吧。我想到的解决方案是：重视源码阅读、重视数据结构和算法、甚至重视底层的数学。虽然上大学的时候就一直听说这句话，但是一直感悟不深。
在我重视了源码阅读之后，开始尝试去阅读 React 源码，然后顺着树形数据结构更新这个核心概念，延展出了 React Three Fiber。假设将时间线往前移动几年，并且我的设计和开发能力足够，可能我就成为了 React Three Fiber 的 Creator。也就是说，我顺着这样的思路再往后学习，可能也会发现一些新的场景，然后做出一些还不错的工具。
在 React 源码中有很多对于树这种数据结构的操作，让我重拾了对数据结构和算法的乐趣。在了解到还有 React Three Fiber 之后，我意识到常见的 Web 页面只是 2D 上交互，未来可能还有很多 3D 交互（比如在 Vision Pro 上），我想自学一下计算机图形学（在这之前可能得补一下线性代数、物理的光学）。
内容创作者作为一个前端开发者，有时候会逛到一些特别好看官网，就会特别羡慕这些开发者那么强。如：ONEUPSTUDIO/GSAP。后面我发现，网站好看与否很大程度上取决于设计师，软件好不好用取决于产品，功能能否实现取决于程序员。
开发者的职责是用代码将他们的想法表达出来，或者制作更好的工具帮助他们去创作和表达。工具之间的区别在于表现力、使用场景和使用范围大小，并且这些工具通常都是声明式的。设计师能使用 Webflow 这样的软件开开发出好看的网页，但是前端开发不一定能做到。作为程序员，最好的做法是制作更好的工具，如果直接表达想法，就会写出维护性和拓展性很差的代码。就像我上面提到的 Form，我应该提供一些制作 Form 的工具，而不是一个页面一个页面的绘制。
我们常见的 CSS 就是表现力非常强大的工具集，里面包含了 Table、Flex、Grid 等等工具。在没有 Flex 的时候，我们可以用 table-cell 这种这种的办法来实现垂直居中，但是在很多场景下使用起来比较麻烦，这就是工具的表现力差。后来引入 Flex，可以轻松的实现垂直居中。
程序员也是一种内容创作者，我大致的划分了一下互联网上的内容创作者，大致有如下的观点（不一定准确）：
- 内容创作者可以大致分为：数学/物理、框架/库、软件/游戏/网页、视频/图片/文字
- 内容创作者如果从上到下排布，创作人数会呈现金字塔形状，从上到下创作难度从高到低、内容的数量会由少到多。
- 上层创作者为下层创作者提供基础设施（声明式的工具），并且可以简化下层创作的难度，但有可能会让下层创作者失去工作。
我在写 mini-react 的时候，相当于自己处于「框架/库」的内容创作者，我尝试直接在 codepen 中找一些有意思的作品，然后尽量去提供相关的机制（渲染、Diff、Hook）。作为「框架/库」的内容创作的的时候，可以很容易分析出整个软件的边界，我能知道 mini-react 能否做到某些功能。具体的页面绘制可以交给另一个层级的内容创作者，也可以尝试去复用他们的作品。
不同人有不同的喜好和擅长点。我很喜欢好看的软件，但我在绘画和艺术方面没有非常高的热情 ，往「数学/物理」这个方向去拓展应该会更适合我。有些人可能喜欢画画，会往「视频/图片/文字」这个方向，最终成为设计师。
过早优化是万恶之源“过早优化是万恶之源”来源于 Donald Knuth 的《计算机编程艺术》一书，其原话是：
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
真正的问题在于程序员在错误的地方和错误的时间花费了太多时间去关注效率；过早优化是万恶之源（或至少是大多数问题的根源）。
在学习 mini-react 的时候，我想到了一些问题：
- React 中还有很多种 API 和配置，那我是不是要都实现一遍？
- React 有很多优化手段，我是否都要看看？
答案都是“不”。通过 React 能实现的网页，用 JQuery 也能实现。这些优化手段和 API 是通常都针对非常具体的场景，其通用性是比较低的。在掌握了整个 React 的核心原理之后，遇到这些场景再去学习会更好。它们大多也是基于核心原理去拓展的，理解起来并不会非常耗时间。比如 React Hooks 和 Fiber 树紧密关联。
半年计划用以终为始的眼光来看，我十年之后还会在现在这家公司吗？答案是绝对不会。不在沉默中死亡，就在沉默中爆发。继续在公司苟着也只是将问题隐藏起来，所以还是决定了离职（技术大厂，前后端测试机会）。
现在找工作难度越来越大，前端更是重灾区，一个岗位可能几十个人投。在这种环境下，调整好自己的心态比较关键。苦思冥想后，想到了一句可以让自己保持 Passion 的话：“找不到工作这段时间就是提升能力，找到工作就是幸运的”。
最近看到一篇博文非常喜欢，这里转载《前端开发的瓶颈与未来之路》中的一段文字：
我在 2018 年有幸参加了 TypeScirpt 的推广大会，TypeScript 的作者 Anders Hejlsberg 亲自主讲。一位将近 60 岁的程序员在讲台上滔滔不绝的讲技术方案，TS 的设计理念。你真的很难想像这样一位处于「知天命」阶段的老头子（实际上很年轻）讲的东西。
QA 环节有个年轻小伙问到 Anders「在中国做程序员很累、很难应该怎么坚持下去（类似这样的描述，细节记不清楚了）」的问题。
Anders 几乎毫不犹豫的说出了「Passion」这个单词。我瞬间就被打动了。因为在此之前我对于「激情」这个词的认识还停留在成功人士的演讲说辞层面，当 Anders 亲口说出 Passion 一词的时候，让人感觉真的是一字千金。
|
楼主
标题置顶
标题高亮
