属于我的三年·第二年

今年成就

「反混沌」计划

正如下面的想法所说——

2018 年年初形成的理念，诞生的名字；2020 年年中明确了方向，坚定了信心。

愿景 - 目标；追赶 - 超越。

If not ME, WHO? If not NOW, WHEN?

经过三年左右的发酵，终于在今年开始着力去建设「反混沌」。

当前在工具层面有三大体系：与日常开发息息相关的各类底层基础设施，如代码校验与格式化、开发套件等的 Infra；以「设计即代码」为目标的跨 JS-based 技术栈、跨平台 GUI 开发的 Fxxk Design；以「需求即代码」为目标，将前端应用各个层次、各个环节之间的通信规范化、标准化的 Future.js。

目前将「反混沌」在工具层面的蓝图划分为四个阶段，正处于第一阶段，其目标就是实践并验证「聊聊前端 UI 组件」与「聊聊中后台前端应用」系列文章所阐述的思想理论，具体体现为 Petals、Kokiri、Zora、Organik、Handie、Bulbasaur、Squirtle 等库/框架。

从年初开始到现在利用非工作时间断断续续地为「反混沌」写代码，至今为止的进展为——

在 Petals 中定义了将近 90 个以上 UI 组件的接口；写了 50 个以上与 Vue 绑定的结构组件基类，12 个以上与 React 绑定的结构组件基类；自研了 30 个以上 Vue 组件；初步适配了 45 个以上 Element 组件，30 个以上 ViewUI 组件和 12 个以上 Ant Design 组件。

在 Organik 中提供了视图、字段、动作、搜索、过滤器、模型、模块等抽象，能够通过收集相关元数据并根据情况创建上下文，在应用中注入后使用，助力配置化开发。

在 Handie 中将基于 Petals 的 UI 组件及 Organik 所提供的机制进行整合，内置了一些无头部件及数据类型定义，并外置了为 CRUD 相关功能拿来即用的部件，可以在中后台前端应用中直接进行配置化、模块化开发。

在公司内我已找到两个试点项目，并进行了小范围「推广」，目的在于寻找潜在的使用者、合作者和共建者。有兴趣者可以加入「Fxxk Design + Future.js 兴趣组」进行讨论交流。

打工生涯

在去年年末，经过几个月的休整后，我加入了一家行业软件公司的数据智能相关团队。这虽然不是一个纯粹的业务部门而是中台部门，但对于前端这个职业来说它就是业务部门——发展瓶颈是一样的。

在决定加入这个部门前，我的目标很明确——先搞基建，解决前端内部问题及与上下游协作问题；然后尝试部门内向架构或产品转型，这样就不存在前端职业发展瓶颈的问题了。

团队中算上我总共有三个前端，在我来之前已经积累了很多技术债：规范缺失，抽象不足导致的强耦合和大量重复代码，程序设计方面的问题等。

作为团队中最「老」的前端，结合现状与我个人的目标，在心里初步定下了前端团队的大概发展方向：

1. 规范化、标准化——让开发流程变得更正规、有序，让项目维护和开发起来更容易；
2. 配置化、低代码化——提高业务从需求到交付的效率；
3. 自动化、智能化——提升部门内部的整体效率。

前两个是解决前端内部问题，最后一个是解决上下游协作问题。

第一个的规范化、标准化已经基本完成。主要是编写并与团队成员讨论确定了《编码风格》、《目录结构划分模式》、《代码审核规则》和《技术方案评审规则》。以这些为思想指导，配以工具和人为干预，提升了一些代码质量。

当前正在进行配置化改造。用 Handie 对一个有几十个业务模块且模块间依赖混乱的项目进行重构，取得了一定成果——前端整体的目录结构按业务模块划分，部分列表页改为配置式；由于 Handie 的设计所带来的约束，促使拆分出高内聚的功能模块，大幅提高了代码可读性、可维护性、可复用性。

因为 7 月中到 11 月底「外出」支援业务部门一个项目的开发，被迫中断了前端项目重构，但也有了另外的收获——

支援的项目主要是做一个长得像电子表格（Spreadsheet）的配置工具，有低代码那味儿了。

看了几个开源库，想要满足业务需求都需要二次开发，并且项目的 deadline 在那呢，没那么多时间深入研究它们那复杂的代码，最后决定 fork 一份 x-spreadsheet 做渲染器，自己写数据逻辑操作部分：合并和取消合并单元格、插入与删除行列等。在魔改 x-spreadsheet 时还顺手帮它摁死几只「小强」。

上面这个只是个小收获，更大更有意义的是帮我验证了 Handie 的模块化和跨环境的能力。

我开发的长得像电子表格的配置工具，姑且叫它「底稿电子表格」，在两个相互独立的应用中都用到这个功能，虽然它们都是基于 Vue 的，但用的 UI 组件库不一样，分别是 Element 和 ViewUI。

大部分人遇到这个场景可能要头疼了——在两个应用中用 Element 和 ViewUI 各实现一遍功能？这显然不可能，后期维护成本会高得离谱！并且，如果再要集成进其他应用中呢？用其中一个 UI 组件库去开发那个模块，然后在集成的应用中再额外引入那个 UI 组件库？别想了……怎么保证模块的样式与应用的风格统一并且低维护成本？

由于在项目中引入了 Handie，所以我一点也不头疼——归功于 Handie 及其配套是基于接口编程的，在开发底稿电子表格模块时只考虑 API 的调用、拼接就好了，什么 UI 组件啊请求服务的，都在集成的应用中注入进去。

上图中红色部分是 Handie 及其配套与我自研的电子表格库；蓝色部分是具体的业务应用；绿色部分是底稿电子表格这个被集成的模块，它单独存放在一个 Git 仓库里，作为 NPM 包被业务应用依赖。

另外，在「外出」期间与对接的前端应用的 owner 及公共体验团队的前端负责人和其他人员针对 Handie 有过一些交流，为日后的合作及推广做下铺垫。

个人网站

在去年年终总结中谈到关于个人网站的来年期望时，我提到——

上面列出的那些模块基本已经能够看到雏形，就差将分散到其他平台的数据转移过来了，然而这正是耗时耗力的体力活，尤其是在当前这种直接编辑文件的方式下。为了稍微提高点编辑效率，我要做个基于 Git 的 CMS；为了能够随时发想法和方便分享内容，需要做个移动客户端。

由于这一年将精力主要投放在「反混沌」计划工具层面的体系建设上，因此在「以个人为中心的服务」的工具开发上没啥进展，只是有些数据上的积累，令我的个人网站首页浏览起来更像是在看豆瓣动态、微信朋友圈或是微博——这也算是我的目的。

在积累网站数据的过程中，我进一步地想要将 Teambition 上的任务、Google Sheets 上的每日记录、语雀上的笔记等全部个人化，让我的个人网站不仅是「个人版豆瓣」，还是「个人知识库」——（尽量）任何由我产生的记录、内容都掌握在自己而非平台手中，集中在我的个人网站上，通过 Git 仓库去组织与管理。

同时，产生了一些开发消费 Git 仓库中数据的工具的想法。除了去年所说的基于 Git 的 CMS，另一个比较重要的应该是基于浏览器的工作台（Browser as a Workbench），主要用来处理每日的任务、工作记录以及其他不向互联网公开的内容。

日常生活

在工作与生活方面，去年的期望是今年能够达到「work-life balance」——

工作日，也就是非节假日的周一到周五，绝大部分时间是「工作」。以「下班」为分割点，一般情况下不去处理公司相关的工作；下班后不看工作用聊天软件，有重要事或急事电话联系。回家后到睡觉前这段时间，可以做 side project，学习或总结知识，陪老婆等。

休息日，也就是非节假日的周六和周日，一天绝大部分时间是「工作」，另一天绝大部分时间是「生活」；默认是周六用来「工作」，周日用来「生活」。休息日进行的「工作」不是公司相关的工作，而是去做 side project 或写文章等事情。

节假日，也就是有法定假期的那几天，绝大部分时间是「生活」，好好陪老婆。

今年差不多是按照上面所描述的规则去做的，能够达到「work-life balance」，自我控制是一方面，更大的影响因素是公司或者说所在团队的文化，因此我十分感谢目前所在的团队，这样可以在各种意义上健康发展。

因为疫情，很多时候想江浙沪周边游甚至到更远的地方都没法去，顶多到人烟稀少的山上转转，生活情趣少了点。希望疫情早日过去吧！

除此之外，在聚焦注意力方面也有一点点小进展——

现在是信息大爆炸时代，并且那些资本家为了流量，想方设法尽可能多地吸引每个人的注意力，蚕食十分有限且无价的时间。不是说时间不能拿去浪费，我要主动地去浪费，而不是被动或被迫浪费。

现在那些内容平台，越做越同质化：想法、视频、文章。每个平台都提供差不多的功能，都想去抢人然后圈养起来，再一点点割韭菜。他们没给用户实在地带去多大价值，却总想着收割。没准儿坚持不了多久就跑路了，留在平台的用户个人信息和产生的内容被怎样就不知道了。

一方面是为了减少自己在没什么价值的事情上浪费时间，另一方面是为了打造「个人知识库」，我在以下平台做了清理退出工作：

• 删除微信公众号「Coding as Hobby」上的文章并注销，微信公众号「欧雷流」暂未处理，但会处理；
• 删除知乎上的文章并卸载客户端，是否注销账号有待考虑；
• 删除 SegmentFault 上的文章并注销账号；
• 删除掘金上的文章并注销账号。

对于内容平台，难听、贬低的话这里就不说了，我有自己比较优质的信息源，不需要它们。除非哪天出现好的去中心化内容服务，否则我不大可能去用。

一点思考

关于 Web 开发本身，我认为它五到十年内会真正进入平缓区——几十年内不会消失，但人员需求不会那么旺盛。

React、Vue 等库/框架让开发者将关注点从 DOM 操作 + 状态操作减为只有状态操作，各种 CLI 的出现助力了模块化、自动化的同时带来了工具配置和构建流程的复杂度，将关注点进行了转移，甚至是分散了。

我认为下一代前端框架所要解决的问题就是尽可能将上层业务与底层技术隔离开——业务线开发人员将精力主要用在业务规则的维护上，对底层的具体技术如 Vue、React 和 Webpack、Vite 等无感知无关心；除了开发框架，还有就是从需求到开发可以针对同一份产物进行协作的工具，也就是「产研一体化」。

上面所说的就是「反混沌」计划在工具层面的目标。其中，实现「产研一体化」的可以认为是一个无代码/低代码的工具或平台。如此发展，业务线就不需要那么多做复制粘贴工作的工具人了。

Web 开发场景的大头是 to B 的企业服务，随着低代码平台、RPA、AI、云计算等的渐趋成熟，在企业中某个业务模块甚至是整个应用根本无需专业人员去开发，业务人员通过可视化的方式就能够自己做出来。

综合上述两点与其他的一些因素，会促使企业组织架构和产业形态发生改变——业务导向的企业中对技术人员的直接依赖大幅降低，也就没必要去招那么多 Web 开发人员，甚至是完全不需要；技术人员会向技术属性更强的低代码平台、RPA、AI、云计算等厂商流动。

那些技术导向的企业对技术人员的能力水平要求更高，再加上单纯 Web 开发方面的方法论和工具（库、框架）都比较成熟了，不太会去重复造轮子，而是在它们基础上进行定制。这样一来，求职门槛变高了，薪水并不会变高，甚至会降低。

说了这么多，只是想说——要想未来有竞争力，赚更多的钱，不能将眼光单纯放在 Web 开发上，应该储备些数据智能、混合现实、图形化、结合生物/生命科学的计算等面向未来的技术相关的知识。

任何工具类事物（如科技、技术、服务等）都有时效性，所以如何将它们所产生的利益、价值最大化是很重要的。

来年期望

明年，即 2022 年，我要努力做的事情整体来说有三方面，它们围绕着同一个中心——

让 Handie 在 Vue 和 React 应用中达到 production-ready 的状态，并提供可用的基于 Web Components 的多技术栈运行时共存方案。

将今年落下的学习研究「领域（domain）」相关知识、方法论、技术的计划补上，夯实自己在这方面的知识体系并提高认知。如果有可能，再去学习研究下类型系统相关知识、方法论、技术。

在前端团队和部门中通过培训、分享的方式帮助其他人理解领域驱动、模型驱动等思想，促进领域驱动团队的推动，为「前后端一体化」、「产研一体化」的落地做准备。

总结

在业务导向的团队中，纯做技术层面的建设是「政治不正确」的，一定要留出比较大比例（至少 45%）的业务支撑，否则考评时必然是「不及格」那群人中的。

所以，要发展只有两条路：要么转到技术导向的团队，专心处理专业技术方面的问题；要么深入业务而非停留在业务表层，比如向架构或产品转型。

想要写出优雅的代码，做出优秀的软件，就要从「写代码」和「做软件」这些事情中跳脱出去，多了解了解世界、人类、社会、经济等看起来与「写代码」和「做软件」无关的事情——因为你是数字世界的「造物主」。

目前来看，近几年我关注和要做的方向主要是从需求到开发的「一体化」提效和「个人知识库」，也许还会有与 Web 3 相关的一些事情。欢迎志同道合且有一定能力的人合作。