Springboot3+微服务实战12306高性能售票系统-玉户帘中卷不去

预测2024年之后的前端开发形式

Springboot3+微服务实战12306高性能售票系统

download：https://www.zxit666.com/5932/

最近AIGC（AI Generated Content，应用AI生成内容）十分热，技术圈也遭到了很大冲击。目前来看，应用LLM（Large Language Model，大言语模型）辅助开发还停留在十分早期的阶段，主要应用是辅助编码，即用自然言语输入需求，模型输出代码。更近一步的探究也仅仅是在此根底上的一层封装（比方copilot X、cursor）。

但即便在如此早期阶段，也对开发者的心智产生极大震动，AI让程序员失业这样的论调甚嚣尘上。

LLM的迸发对前端意味着什么？本文尝试预测一波2024年之后的前端开发形式，这个预测遵照如下准绳：

尊重技术客观开展规律。以当前已有技术为根底预测，而不是将预测树立在某种虚无缥缈的高端技术，或者假想某些技术打破严重瓶颈
尊重人性。程序员只是营生的职业，新的开发形式即便再凶猛，假如让程序员赚不到钱，那也是很难推行开的
范式迁移的实质
为了预测将来，先看看我们是如何走到如今的。

在前端开发范畴，我们阅历了从jQuery为代表的面向过程编程向前端框架为代表的状态驱动形式的迁移。

当问到该选Vue还是React开发？，这样的问题会惹起很大争议，但假如问到该选jQuery还是框架开发？，这样的问题就不会有太多争议。

为什么前端范畴普遍承受了这种范式的迁移？在我看来，有两个缘由：

1. 开发效率进步
这一点毋需多言，置信前端同窗都有领会。

2. 门槛进步
面向过程编程是十分粗浅易懂的开发形式。君不见，曾经的前端靠一本尖利的jQuery就能打天下。相比之下，状态驱动就有一定学习门槛。

当一项有一定门槛的技术（这里指前端框架）变为行业事实上的规范时，行业门槛就提升了，这为从业者构筑了行业壁垒。

事实上，正是由于：

web应用复杂度进步
前端框架的盛行
才让后端工程师工作职责中的view层，分化出前端工程师这一职业。

关于前端范畴来说，只要同时均衡了提效与进步门槛的技术，才会被市场（这里的消费者指前端工程师）承受。

举个反例，Angular全家桶的形式固然进步了开发效率，但是同时，门槛进步太多了。

而且更糟的是，Angular中的很多概念都是从后端迁移而来，作为一款前端框架，对后端更亲和且门槛高，这对自身就是从后端view层中分化出的前端工程师来说，是比拟排挤的。

再举个反例 —— Vue。有同窗会说，Vue这么盛行的前端框架，你说他是反例？

还是从提效与进步门槛的角度看，Vue提效的同时，由于其模版语法、响应式更新等特性，他是降低了开发门槛的，这意味着运用Vue时：

同样是开发业务，老前端与新前端差距不大
必要时后端经过简单的学习，也能接手局部需求
重申一下，我并不是说Vue不好，相反，他是很优秀的前端框架。这里只是从人性的角度剖析，并且这个剖析很有可能是客观、带有成见的。

再看个正面例子 —— React Hooks。Hooks对开发效率、组件复用性以及他对React将来开展的影响这里不赘述了。主要聊聊进步门槛：

一方面，什么时分封装自定义Hook，如何封装自定义Hook，如何躲避Hook的坑，老前端与新前端有比拟大的差别
更重要的是，后端改改JSX还行，要改基于Hooks的组件逻辑，是有一定难度的
既提效，又进步门槛，我以为这才是Hooks在前端范畴炽热的缘由。

同样的缘由，从人性的角度，我很看好Vue Composition API
所以，前端编程范式迁移的实质是：把握进步效率与进步门槛之间的均衡。

这个结论会成为后面预测将来开发形式的根据。

当范式无法再迁移时
当前端框架成为事实上的规范后很长一段时间，业界也在不时探究新的开发范式。

有一种开发形式每过几年都会被搬出来炒一遍，他就是低代码。用我们上面的结论来剖析下：在市场选择的状况下，先抛开低代码能否能进步效率不谈，显然他的目的是降低门槛。

从人性的角度动身，他就很难在程序员群体中自发传播开。

那么，假如没有新的范式呈现，会发作什么事情？会内卷。

我们会发现，这几年前端的开展轨迹，就是在反复一件事：

盘绕前端框架周边，不时探究各细分范畴的最佳理论
当探究出最佳理论后，就把他集成到框架中
举个例子，React Router作为React技术栈中路由这一细分范畴的一个开源库，经过长期迭代，逐步成为主流路由计划之一。

React Router团队基于React Router开发出Remix这一React框架。

这么做，在没有新的范式呈现前，也能基于当前范式（前端框架），到达上述2个目的：

进步效率：框架集成了最佳理论，开发效率更高
进步门槛：除了学习React，还得学习新的上层框架
相似的，各种CSS处理计划（比方tailwind css）也是同样的道理：

进步效率：进步CSS编写效率
进步门槛：新的概念、语法需求学习
那么，将来盘绕进步效率与进步门槛的均衡，前端开发形式会如何开展呢？

从思索范式到思索流程
首先，我以为，在有限的将来，不会呈现新的更先进的范式能让前端范畴普遍认可并大范围迁移（就像从jQuery到前端框架的迁移）。

那么，为了进步效率，除了改动范式与范式内 内卷两个选择外，还有个选择 —— 让整个开发流程提效。

从需求文档到最终代码，存在4级笼统：

PM用自然言语编写的需求文档
需求评审时，PM给开发描绘需求后，开发脑海里构成的业务逻辑
开发依据业务逻辑划分各个模块或组件
开发完成各个模块或组件的详细代码
当前我们运用LLM辅助编程时（比方以chatGPT为例），主要是用自然言语输入模块或组件业务逻辑，再让模型输出详细代码。也就是借助模型自动完成从3到4级笼统的转变。

比方说下图我们让chatGPT完成一个计时器：

这个计时器可能是我们需求中的某个模块，在此chatGPT帮我们完成了从笼统3（完成一个计时器组件）到笼统4（计时器组件的代码）。

假如仅仅到这一步，只能说这是个更高效的辅助工具，并不能到达整个开发流程提效的水平。为了到达这种水平，我们需求让LLM帮我们完成从笼统1到4的整个过程。

LLM如何完成4级笼统转换
接下来我们来看，基于当前已有的模型，如何完成笼统1到笼统4的自动转换。

首先，来看笼统1（PM用自然言语编写的需求文档）。chatGPT当前曾经控制根底的了解才能，所以他是可以了解需求文档的含义的。

下图是我从网上找的某需求文档中的登录功用流程图：

以当前主流的GPT-3.5举例，固然GPT-3.5不能了解图片（不能了解需求文档中的流程图），但我们能够将流程图用文字描绘出来（最新的GPT-4曾经具有了解图片含义的才能）。

上述登录功用流程图能够用文字概括为：

翻开App后有3个选项，分别是“账号密码登录”、“快捷登录”、“第三方登录”
选择“第三方登录”，进入第三方，同意受权后登录胜利
选择“快捷登录”，输动手机号和考证码并选择身份，点击登录后登录胜利
选择“账号密码登录”，输动手机号，假如已注册，输入密码，点击登录后登录胜利
选择“账号密码登录”，输动手机号，假如未注册，进入注册页，输动手机号，假如手机号已注册，回到“账号密码登录”
选择“账号密码登录”，输动手机号，假如未注册，进入注册页，输动手机号，假如手机号未注册，填写手机号、考证码、密码、姓名、选择身份，点击注册，终了
笼统1到笼统2
如何完成从笼统1到笼统2（业务逻辑）的转变呢？换句话说，如何用一种介于自然言语与实践代码之间的标准描绘业务逻辑？

这种标准应该具有完备的数据构造（相似JSON、XML），由于这样会带来很多益处：

相比于自然言语，用标准的数据构造表示的业务逻辑可以传达更精确的企图
业务需求的不时增加，仅仅对应数据构造体积的增大，即便再复杂的业务，只需求分批将业务逻辑代表的数据构造投喂给模型，模型就能完整了解我们的业务
数据构造能够保管在变量中，经过变量名就能指代业务逻辑，无需再用自然言语大段的向模型描绘业务逻辑
我们能够应用SCXML（State Chart XML）格式。SCXML是由W3C定义的一种表示状态机的XML格式，他可以表示状态之间的变化。

前端应用的实质其实就包括两局部：

状态的变化
状态到视图的映射
其中状态到视图的映射框架曾经帮我们做了。所以，只需能表示状态的变化，其实就能表示业务逻辑。

如今，我们让chatGPT将流程图翻译为SCXML格式：

得到如下构造（你不用细看，理解个大约就行）：

<scxml version="1.0" xmlns="http://www.w3.org/2005/07/scxml">
<state id="mainMenu">
<transition event="THIRD_PARTY_LOGIN" target="thirdPartyLogin" />
<transition event="QUICK_LOGIN" target="quickLogin" />
<transition event="ACCOUNT_LOGIN" target="accountLogin" />
</state>
<state id="thirdPartyLogin">
<onentry>
<send event="AGREE_AUTHORIZATION" />
<send event="LOGIN_SUCCESS" />
</onentry>
</state>
<state id="quickLogin">
<onentry>
<send event="INPUT_PHONE_NUMBER" />
<send event="INPUT_VERIFICATION_CODE" />
<send event="SELECT_IDENTITY" />
<send event="LOGIN_SUCCESS" />
</onentry>
</state>
<state id="accountLogin">
<state id="inputPhoneNumber">
<transition event="PHONE_NUMBER_SUBMITTED" target="checkRegistered" />
</state>
<state id="checkRegistered">
<onentry>
<send event="CHECK_REGISTERED" />
</onentry>
<transition event="REGISTERED" target="inputPassword" />
<transition event="UNREGISTERED" target="register" />
</state>
<state id="inputPassword">
<onentry>
<send event="INPUT_PASSWORD" />
<send event="LOGIN_SUCCESS" />
</onentry>
</state>
<state id="register">
<state id="inputPhoneNumber">
<transition event="PHONE_NUMBER_SUBMITTED" target="checkRegistered" />
</state>
<state id="checkRegistered">
<onentry>
<send event="CHECK_REGISTERED" />
</onentry>
<transition event="REGISTERED" target="inputPassword" />
<transition event="UNREGISTERED" target="inputUserInfo" />
</state>
<state id="inputUserInfo">
<onentry>
<send event="INPUT_PHONE_NUMBER" />
<send event="INPUT_VERIFICATION_CODE" />
<send event="INPUT_PASSWORD" />
<send event="INPUT_NAME" />
<send event="SELECT_IDENTITY" />
<send event="REGISTER_SUCCESS" />
</onentry>
</state>
</state>
</state>
</scxml>
至此，我们完成了笼统1到笼统2的转变。

笼统2到笼统3
SCXML格式没法直接在JS代码中运用。为了用代码完成逻辑，我们需求运用遵照SCXML标准的库。xstate是JS中比拟盛行的状态机开源库。

所以接下来我们让chatGPT将上述SCXML格式转换为xstate语法：

得到结果（同样，详细代码你不用在意，理解我想表达的转换意义就行）：

import { Machine, sendParent } from 'xstate';
const loginMachine = Machine({
id: 'login',
initial: 'mainMenu',
states: {
mainMenu: {
on: {
THIRD_PARTY_LOGIN: 'thirdPartyLogin',
QUICK_LOGIN: 'quickLogin',
ACCOUNT_LOGIN: 'accountLogin'
}
},
thirdPartyLogin: {
onEntry: [
sendParent('AGREE_AUTHORIZATION'),
sendParent('LOGIN_SUCCESS')
]
},
quickLogin: {
onEntry: [
sendParent('INPUT_PHONE_NUMBER'),
sendParent('INPUT_VERIFICATION_CODE'),
sendParent('SELECT_IDENTITY'),
sendParent('LOGIN_SUCCESS')
]
},
accountLogin: {
initial: 'inputPhoneNumber',
states: {
inputPhoneNumber: {
on: {
PHONE_NUMBER_SUBMITTED: 'checkRegistered'
}
},
checkRegistered: {
onEntry: sendParent('CHECK_REGISTERED'),
on: {
REGISTERED: 'inputPassword',
UNREGISTERED: 'register.inputPhoneNumber'
}
},
inputPassword: {
onEntry: [
sendParent('INPUT_PASSWORD'),
sendParent('LOGIN_SUCCESS')
]
},
register: {
initial: 'inputPhoneNumber',
states: {
inputPhoneNumber: {
on: {
PHONE_NUMBER_SUBMITTED: 'checkRegistered'
}
},
checkRegistered: {
onEntry: sendParent('CHECK_REGISTERED'),
on: {
REGISTERED: 'inputPassword',
UNREGISTERED: 'inputUserInfo'
}
},
inputPassword: {
onEntry: [
sendParent('INPUT_PASSWORD'),
sendParent('REGISTER_SUCCESS')
]
},
inputUserInfo: {
onEntry: [
sendParent('INPUT_PHONE_NUMBER'),
sendParent('INPUT_VERIFICATION_CODE'),
sendParent('INPUT_PASSWORD'),
sendParent('INPUT_NAME'),
sendParent('SELECT_IDENTITY'),
sendParent('REGISTER_SUCCESS')
]
}
}
}
}
}
}
});
export default loginMachine;
初始状态能够转移到3个状态（这些状态都是chatGPT生成的），其中：

QUICK_LOGIN —— 快捷登录
ACCOUNT_LOGIN —— 账号密码登录
THIRD_PARTY_LOGIN —— 第三方登录
每个状态接下来的变化逻辑都明晰可见。比方，当进入ACCOUNT_LOGIN状态后，后续会依据能否登录（UNREGISTERED、REGISTERED）进入不同逻辑：

也就是说，chatGPT了解了需求文档想表达的业务逻辑后，将业务逻辑转换成代码表示。

读者可将上述xstate代码复制到可视化编辑器中看到效果
笼统3到笼统4
接下来，我们只需求让chatGPT依据上述xstate状态机生成组件代码即可。

这时有同窗会问：chatGPT对话有token限制，没法生成太多代码怎样办？

实践上，这可能并不是坏事。在我曾经供职的一家公司，前端团队有条不成文的规矩 —— 假如一个组件超越200行，那你就应该拆分他。

同样的，假如chatGPT生成的组件超越了token限制，那么应该让他拆分新的组件。

拆分组件的前提是 —— chatGPT需求懂业务逻辑。显然，他曾经懂了xstate数据构造所代表的业务逻辑。

更妙的是，我们能够让chatGPT将SCXML格式转换而来的xstate数据构造保管在一个变量中，在后续对话中，我们用一个变量名就能指代他背后所表示的业务逻辑（这里保管在变量m中）。

当我们要生成业务组件代码时，让chatGPT从模块中导出m完成组件逻辑：

关于实践场景下比拟复杂的需求，经过从笼统1到笼统3的转换，我们会得到代表业务逻辑的不同变量，比方：

signin变量代表登录逻辑
login变量代表注册逻辑
PopupAD变量代表弹窗广告逻辑
假如弹窗广告的逻辑和能否登录相关，那么要完成弹窗广告组件代码只需求通知chatGPT：

依据signin、PopupAD完成弹窗广告的react组件，其中signin变量由xxx模块导出，PopupAD变量由yyy导出。

假如你司运用其他框架，只需将其中react换成其他框架名即可。当大家还在争论哪个框架更优秀时，LLM曾经悄然帮开发者完成了框架自在。

新开发形式的优势
让我们从进步效率与进步门槛的角度剖析这种新开发形式的优势。

进步效率
首先，这种新形式能显著进步开发效率。实质来说，他将前端工程师从完成需求的角色转变为review代码的角色。

极端的讲，当需求评审会完毕的那一刻，第一版前端代码就生成了。

其次，他能解放局部测试同窗的消费力（抢局部测试同窗的活儿）。关于维护过屎山代码的同窗，肯定遇到过这样的场景：明明只是改动一个小需求，测试问你改动影响的范围，你本人都不分明会有多大影响，为了稳妥起见只能让测试掩盖更大的回归测试范围。

在运用基于状态机的开发形式后，任何改动会形成的影响在状态图中都明晰可见。同时，由于代码逻辑的完成基于状态机，能够据此自动生成端到端的测试用例，模型也能依据状态机描绘的逻辑本人补足其他单测。

进步门槛
接下来，我们从进步门槛的角度剖析。

首先，可以对模型生成的代码停止查漏补缺自身就请求开发者有一定前端开发程度。

其次，这种开发形式引入了新的笼统层 —— 状态机，这无疑会增加上手门槛。

但这都不是最重要的，最重要的是 —— 这套形式强迫前端开发需求更懂业务。

以前，拿到产品的需求文档后，你能够在做的过程中遇到不懂的再问产品。运用新的开发形式后，你必需很懂业务，做到在需求评审时就能指出需求文档中不合理的中央。

由于当需求评审完毕后，你会将这份需求文档投喂给模型直接生成业务代码（中间会阅历生成SCXML、生成xstate数据构造、保管xstate变量、运用变量生成组件代码）。

当大家技术程度旗鼓相当时，懂业务才是前端的中心竞争力。

综上，这套开发形式在极大进步效率的同时进步了门槛，我以为在将来很有可能成为主流前端开发形式。