又到一年规划的时节了，借机看当下，想未来。
把握住大势，才能够掌握未来。这里陈列出一些自身在做技术规划的时候对 Web 应用研发趋势的思考。在这里抛砖引玉，邀大家一起探讨。
正视低代码，用好低代码
Do code-less, but in a right way ~
低代码不是银弹，但对特定领域做厚的低代码产品往往可以产生不可小觑的力量。
低代码的确成为了一种主流的趋势。但我认为，切割特定领域立足，深度耕耘的低代码产品才是好的产品。妄图让低代码颠覆传统，亦或是想要让低代码产品的能力无所不能者，都是不靠谱的。在我看来，典型的场景主要分为以下三类：
- 以 Microsoft PowerPlatform 为代表的低代码产品，将用户群体门槛设置为 Excel 的难度系数，能够让普通非编程专业的用户用这类平台去解决各个领域的长尾需求，拖拖拽拽生成数据模型，配置 CRUD 的表单，拉拽生成常规工作流。国内以钉钉的宜搭为例，也是朝着这种方向去发展。
- 以老牌 CRM 厂商 Salesforce，国内用友等为例的低代码产品，这类产品将重点放在了「二次开发 & 定制」上，在已有的高楼（CRM 产品、ERP 产品等）基础上继续建设，做定制开发。这类产品往往依赖原始技术资产的积累，然后让生态进入玩转整个定制体系，让定制的边际成本变低。
- 以应用生产分工视角切入，让产品、设计师、服务端、前端、客户端、测试等身份，能够在低代码链路上协同产出页面、流程、逻辑的工具性质产品。这块产品在国内内卷比较厉害，但也被挑战得比较多，这类产品往往容易烂尾，加上技术的封闭性、黑盒性和不可控性，往往选择需要谨慎，否则就会变成 Pitfall 👿。
Gartner 2022 低代码象限
低代码的确能够降低应用开发的门槛，让更多长尾需求（阅读《长尾理论》的一些感想）得到满足；其次低代码应用在快速原型和验证产品想法上有快人一步的空间。这一块我想生成一些对未来的判断：
- 「边界能力边界问题」：专业的应用编程和低代码的编程需要有更好的边界，好的产品一定是聚焦特定的领域，并且能够给出相比传统编码爆破式效能提升的解法。比如：宜搭 实现的是让小白哪怕厂里的工人都能够做应用解决自己发现的问题，这种就是一种突破。对于小团队而言，将低代码期望解决的问题往往缩放越小，越精专，给出的解法越通用，越能够被集成和复用以放大价值，这会是比较好的切入点。做低代码切忌心急，伟大的抱负即便是 1 千人的投入也未必能够真正意义上成功。
- 「演进和可持续发展问题」：当应用规模复杂到一定程度的时候，低代码就会出现能力的瓶颈，因为低代码是代码和功能抽象封装后的结果，其表达力永远都是弱于纯粹 Code 编程的。很多产品妄图既要低代码，又要保证完备性，一旦随着业务发展，应用要解决的复杂起来，低代码需要用非常「蹩脚」的方式（比如：开放 CodeEditing）去实现完备性。这种完备性的代价非常高，往往会把产品做成四不像，非专业用户觉得复杂难用，专业用户又觉得鸡肋不屑一顾，因为产品很难照顾好两类用户群体的「习惯」。所以，用低代码产品快速开头，快速原型，后续复杂度提升，招架不住的时候，够降解为专业编码，让低代码应用「顺利毕业」，我个人认为是有价值的。目前大多低代码平台都不具备这类能力，只能够让用户「焊死」在平台上，要么咽气吞声让需求要么让用户提需求，然后用蹩脚的方式满足复杂定制，要么客户只能够另起炉灶，成本大幅增加。这块在后续演进式，或者叫可以自适应式的应用架构中，我想再聊一聊。
- 「开放性问题」：低代码生产的应用，背后的数据资产、技术资产需要比较好地和标准的技术生态进行融合互通，不要让低代码的应用体系成为「孤岛」，以致后续变成孤儿，无人问津。良好的应用开放标准够将核心系统、使命攸关的业务系统、长尾应用等有机地结合在一起，做好数字化。
部分推荐的延展阅读：
- 从实现原理看低代码：这篇力荐，讲述了低代码体系编码的优缺点，个人觉得比较客观中肯的文章
看好 AI 背后的潜力爆发
这段时间 ChatGPT 爆火，Copilot 也让人觉得惊艳。
AIGC 最近是真的热点中的热点。未来 Web 应用研发中 AI 的使用包括但不限于下面的场景：
- 编程顾问：比较快速的搜索引擎，对于部分事实既定的问题，比如：
HTTP CacheControl 缓存头中 max-age 的单位是 s 还是 ms？ChatGPT 的确比 Google 更高效，还可以带上上下文进行持续提问，快速解决编程问题。当然对于部分新手和未知领域的问题，ChatGPT 也可以当一个顾问，给一些编码建议，或者代码解释。这块一旦商用，对于不同水位的编程者都能够收益。在我看来如何将每一个 query 的成本降到普通大众可以接受的水位，是接下来 ML 工程体系要竭力突破的地方。 - 机器人答疑：通过对大型语言模型比如 GPT-3 的迁移学习，加入自身的「料」训练，用于编程领域的常见问题答疑，做去服务的确是好的实践思路。
- 自然语言 => 代码（或 DSL）：以
OpenAPI为基础的 Copilot / ChatGPT 等已经可以由自然语言辅助生成部分代码，虽然是片段，但是可以做实际研发种的编程参考。或者作为入门者参考代码的编写模式。当然使用自然语言生成特定的 DSL（比如 MSPowerPlatform 上生成 workflows 的模式）也是新的门路。 - 机器代码 Review：使用 ML 做代码 Review 已经有不少产品问世了，目前看来可以发现一些基础问题可以被发现，但是大规模地代码输入和工程级别的上下文连接是目前的技术瓶颈，还有待提升。
- 代码 => 代码：以
Copilot为代表的编码辅助的确越来越强，其推荐的代码往往会结合大量工程、项目的上下文进行演算，虽然 600 元一年的价格小贵，但是想一想自己还是靠着卖代码赚钱，能够提升生产力的它，就会觉得这挺便宜的了，不是么？ - 图像 => 代码：这类前几年也玩得比较 6，比如淘系的
ImageCook，可以实现简单的 PSD / Sketch => Code，或者中后台常规的设计图像 => React 组件 Code，或者部分商品图片或者简单的视觉效果卡片 => 卡片 DSL，这类尝试比较多，也有一定的落地空间去提升简单 UI 生成的效率，尤其是弱交互的领域范畴。 - 数字内容生成：最近以
StableDiffusion为代表的图像生成，语音合成，图像优化等等，也百花齐放，可以通过自然语言去生成特定内容还是颇为有趣的，甚至可以用来做技术项目的 logo 生成，颇为有趣 ~
从调研报告视角来看，Generative AI 的确大有所为，把 AI 作为日常生产的武器，加速 Web 应用的研发速度的确空间很大。
图片引用自：Base10 Blog: If You’re Not First, You’re Last: How AI Becomes Mission Critical，侵权立删
由于 AI 的基础设施的打造门槛极高，但应用门槛确乎在降低，持续关注，期待未来的发展。
全栈思考，一体设计，快速创新
作为前端出身的自己，看到近来有不少人在唱衰前端职业，也有文章称「前端已死」。但个人始终认为前端只是因为特定的时间，特定的需要，做了技术领域下特定的分工罢了。正所谓分久必合，合久必分，当 Web 技术逐渐走向成熟的时候，尤其在终端技术、跨端技术、前端技术等开始逐渐成熟的时候，端（Native）到端（Web）到端（Server）的界线就变得越来越模糊。加之云原生和很多虚拟化技术的加持，屏蔽了我们对应用部署运维、中间件调用、微服务架构实现等复杂性的感知，让全栈开发很多都具备开箱即用的 Tech-less（代码重点关注业务实现，屏蔽底层复杂实现）体验。
纯粹把自己的工作界定在 UI 表现层的编码上，那自然不长久，会随着技术发展而弱化，淘汰。
若一个工程师，能够从全栈的视角去定义问题，发现问题和解决问题，并用成熟的基础设施，Tech-less 地解决业务或者技术问题，往往具备较大的生产力提升。这种全栈式的研发过程往往具备如下的优势：
- 整个软件的设计，往往具备高度的 概念一致性，将业务的问题，巧妙地拆解为一个统一的技术栈进行维护，减少了多角色的沟通协作和概念理解成本，让维护者的认知负荷也可以得到有效降低。
- 整体的软件实现，往往会使用统一的编程语言和框架，同时现有的技术或者平台能力又能够比较好地屏蔽 IaaS / PaaS 的复杂性，开发者只需要根据具体的场景去做技术选型，高效率地解决当下的问题，具备灵活度整体较高。技术栈上的一致性可以得到充分保障。
- 在微服务和 DDD 驱动的服务端架构为主流的时代，BaaS 的基础能力已经颇为成熟，跨平台、跨技术栈之间的互相调用，也通过 REST(HTTP based)、gRPC、HSF 等 RPC 协议屏蔽了服务调用兼容的复杂性。让服务精专于特定的业务领域，比如 Node 就非常适合视图层和交互表现层的应用设计和实现，不适合重计算（CPU 密集型）、企业级服务等等的功能实现。这种架构的平衡取舍就需要企业 CTO / 架构师的关键设计了。
- 单兵作战能力强，全栈工程师需要成为瑞士军刀，往往可以在短时间内做应用的研发创造，做出待市场和用户验证的原型系统，后续也可以持续做服务重构拆解为上述更复杂的微服务建构，做「演进式」的架构设计，变为专家系统。
- 全链路，或者说全端地思考问题，让人一个解决一个技术问题的深度和厚度增加，解决方案的维度也会有所增加。比如性能优化上，将不再简单局限在客户端或者服务端，可以激发更好的方案设计，打破已有模式的桎梏。
实现全栈的路径，但是「降低全栈的门槛」一直都是工程师提升全栈能力的重要突破口。近来软件行业做了非常多的尝试，早在 Java 一统终端（Applet）的构想，而后服务端框架出现模板渲染和前后端分离模式的火爆，以至于 SPA（SinglePageApplication）的 UI 视图架构成为主流。
而今在 Node.js 火爆当下，Next.js Next.js 研究学习 破石而出，结合 React Client / Server 渲染同构的思想，尝试更进一步降低前后端视图、API 服务等门槛。在这里我简单绘制一个我对全栈技术的图谱：
JavaScript 编程语言视角下的全栈技术生态
值得一提的是：
- Rust 等高性能语言近期的流行，为全栈的基础设施的高性能奠定了不少基础，目前很多高性能的研发工具都首选 Rust 做研发，Rust 逐渐开始流行，成为趋势。
- Wsam（WebAssembly） 技术的出现，近来开始成熟，以 Figma 使用 Wsam 实现的设计画布让人惊叹浏览器内部的绘图性能。
- JavaScript 生态的近乎狂热级别的建设和普及（作为 Web 应用建设的基础语言），让 JavaScript 的容器化遍布多个端的领域，也为上层应用研发框架跨端的「涉足」奠定了重要的基础。
- Next.js 算是 B/S 跨平台的领导者了，One Project to rule them all，近期更是推出了 ServerComponent First 的应用架构，成为了未来可以选择的一类 UI 渲染范式。
整体可见技术意义和业务意义上的全栈的思想解决问题，是大势所趋。
部分推荐的延展阅读：
- 我看Next.js：一个更现代的海王：狼叔对 Next.js「现代海王」的理解，颇为有趣。
- 深入 Next.js 实现剖析：个人近期对 Next.13 app 新特性的分析，目前基于 canary 版本的代码研读，欢迎一起探讨。
理想主义者：自适应，可以进化的应用架构
这块相对虚一些，偏向一种对理想的 Web 架构的探索。
在时间的向前迈进中，业务会变，技术会变，人也会变，应用系统如何经受住时间的考验，让长时间维护的成本降低，做到灵活自适应。设想一个应用不仅仅能够适应业务的灵活多变，也能够适应技术持续的演进，还可以对新老的维护者都有好。这块似乎是软件工程面向复杂性和不确定性的终极探索。否能够有一种 Web 应用的架构可以接近这种高度自适应并且可以进化适应变化呢？
在 《演进式架构》一书中，作者就尝试给出一种软件架构和研发模型来适应这些「变化」，其思想包括：
- 引入架构适应性（度）函数，基于形式化的建模和数据驱动的形式来评估系统架构的适应度。
- 实施增量变更的高度可控性，包括自动化测试、部署流水线、适应性函数的变化，以此评估新的变化引入对存量体系的影响，又保证存量体系的稳定性。
- 逐渐解耦存量的应用架构，向当先先进的软件架构做「渐进式」演变，比如从巨石架构 => 服务导向的架构 => 抽离部分组件用 Serverless 架构实现，在前两点的基础上持续演进。
- ...
在个人看来：
- 关注核心的实现，关注不变的业务或者技术特性做好 CORE 层的能力建设（比如：领域模型的精炼、业务核心流程的抽象等等），抓住万变中的不变去建立高质量的软件核心。
- 关注平台工程的建设，这块是 Gartner 2023 的技术趋势里面提到的一个点，对于大厂而言，所谓的中台也罢，技术平台也罢，都是卓越工程的剪影。平台工程和应用的「一生」息息相关，在构筑平台能力建设的时候，考虑到应用自适应和可进化的要求，作为一个指标进行设计，也能够
这块的确是一个很大的命题，能够上升到软件工程的整体层面，但是我们作为工程师，何尝不需要在 Web 应用研发的过程中时刻思考，探寻当下应用的结构设计，关乎它的自适应性和「可进化」的特质呢？在这里也就不继续深入了，否则就是一本叫做「2023 当代软件工程」的书籍所要涵盖的方方面面了。
用 Web 技术连接面向未来的技术领域
Web 技术是当下应用的主要形式载体。在面向未来，我们也需要储备一些连接新的技术领域的能力，比如：
2022 年，去中心化思潮的来袭，区块链技术 & NTF 等概念大火 🔥。待这波浪潮结束之后，我们再来看看泡沫破裂后，技术留下了什么？使用去中心化的技术 —— 区块链技术、去中心化的身份、去中心化的存储技术，让中心化的应用具备去中心化的能力，这些能力能够给存量的业务带来什么？或者产生什么样的变革？亦或是使用 Web 技术去打造完全去中心化的应用都是值得探索和实验的命题。
再进一步，元宇宙背景下的 Web 技术的生存空间。不知今年 Apple 是否会发布新的 XR 相关的设备。倘若它能够引发下一波穿戴式设备的浪潮的话，其背后和 Web 技术可能产生交集的 Web AR / VR 的表现力，亦或是诞生元宇宙应用中的 Web 特质的引擎，去消费和创造 Web 技术驱动的内容都会成为技术的热点，值得探索。当然图形技术领域本身就是一个门槛极高的领域，要进入也需要较高的学科基础，更需要跨界的耐心和勇气去探索。
最后
有了趋势，再结合手上的业务看当下，自然可以发掘不少的命题去做，如同 Alan Turning 所言：尽目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。
尽目光所及之处，只是不远的前方，即使如此，依然可以看到那里有许多值得去完成的工作在等待我们。 —— Alan Turning, Computing Machinery and Intelligence, 1950
与大家共勉 ~