【在公司前端项目中落地 】是 一系列 的篇章,总结笔者目前在公司做的事情,将会持续更新。

分享出来是希望和优秀的社区一起 探讨在前端更多的可能性 ,相互学习、交流、一起成长。

上篇【在公司前端项目中落地 】初探成果 描述了笔者使用基于公司的单个UI组件,编写出符合规范的、完整的、可运行的组件。

其中最重要的是 符合规范,因为这和组件的后期可维护性强相关。如果写出来的组件不符合规范,就算能跑,一旦业务形态发生变化,需要程序员介入修改代码,所需要的维护成本就会急剧上升,最终的结果很可能就是重构。

当然,对于那种「一次性」的活动界面,用完即丢,这种界面不存在后期的业务拓展,也就不存在代码的可维护性之说。这种场景使用常规的低代码平台来实现可能更加合适,毕竟可视化托拉拽能搞定的事情,不需要来调教。

既然说到低代码,仔细想想,在这个等AI产品大爆发的时代,后续低代码项目的发展方向将是什么?

给低代码平台一份需求文档,直接生成符合规范的、可维护的、拓展性强的系统代码?

开篇介绍

大家好,我是LV。

回归正题,本篇 聊天式编程 是基于上篇进行的一些拓展,因此还未看过上篇的同学需要先去熟悉一下,因为其中用到了一些概念,如新项目架构的工作流、业务组件等。

本篇通过与的几轮较量,来调整在前端项目中的落地方案。笔者将会基于实际业务场景,组合多个UI组件,使用封装业务组件。

下面先介绍一下对于开发一个业务组件来说,传统的编码思维和使用进行开发的编码思维。

编码思维的碰撞

如上图,对于开发一个规范的业务组件来说,从工作流上拆分为了3步,下面针对 程序员 和 工作流分别描述:

程序员

Step1:拆分业务需求

在动手写代码之前,先仔细拆解业务需求,并定义清晰的接口。同时按照规范搭建组件的目录结构,形成统一的规范,这样便于团队成员更容易理解代码的布局和结构,增加可维护性。

Step2:手撸代码

根据设计稿和接口的指引,开始正式编码,按照业务需求,逐步实现组件的各个功能模块。同时在写代码的时候,保证代码的 可读性、可维护性和可扩展性。

Step3:文档和测试

当代码写完之后,编写组件的 文档。可以理解为就是一份组件文档。建议根据不同props的组合,编写清晰、详细的 用例,在方便同事使用的同时,也方便后期自己快速回顾组件,不至于再去看代码逻辑,耗费时间。

最后需要编写组件的单元测试,保证后续的每次迭代不会对之前的组件功能产生影响。

一步步手撸业务组件,程序员表示很nice,毕竟是自己亲手一行行创造出来的,就像是自己下的崽一样,反正我的崽最好,什么怎么牛逼,都跟我没关系。

Step1:定义角色

为了高效开发业务组件,首先要为定义一个具体的角色,并提供其开发业务组件所需要的资源,这些资源可以包括组件声明文件文档,组件使用示例等。

Step2:描述业务组件生成代码

这一步是整个开发流程中最重要的一步,如何描述你需要生成的组件至关重要,描述地越详细,生成的组件越符合你的预期。

但是描述的越详细,也会带来一定的问题,因为编写描述信息本身就是一项繁碎的工作了,甚至还不如直接手撸代码,我们使用的目的是为了提高编码效率,不是为了使用而使用。

如下是笔者一开始在描述组件信息这块犯的错误,越写越不对劲,越写越怀疑人生…

因此如何描述组件信息,需要用户不断探索实践,并且在不同业务场景下均衡来使用。比如说简单的组件可以描述的详细一点,生成出来的代码可能直接就能运行。但是比较复杂的组件就得打住了,别想着能一把给你搞出来,心急吃不了热豆腐,要懂得聊天、循序渐进…

Step3:提供规范,优化代码

经过Step2,已经写出来了一个它理解的业务组件,此时组件还不符合我们的组件结构规范,因此需要提供给它一个规范的模板,让它按照这个模板来进行优化,这个模板就包括了规范的组件文件结构、文档自动生成、组件的单元测试等。

有人肯定有疑惑为什么一开始不让按照模板来生成呢?笔者尝试过,但是效果不太好,甚至出来的代码没有按照描述信息生成。在使用现阶段大模型的时候,不要想着把所有的东西一把都喂给它(如果后续.5、.0出来了,那可能无所谓了),要循序渐进,先让它理解你描述的内容,当它符合预期生成了描述的代码,然后再提供模板将上面符合预期的代码优化成规范的代码。这就相当于将一个复杂的任务拆分为了很多个较简单的小任务,人类处理复杂任务都是这样的步骤,更何况是AI大模型呢?

与的几番较量

当你尝试用写业务组件,你会发现一些问题,不要想着可以把代码100%地写出来。如果能100%写出来,那还需要你干啥…

关键是如何才能最好地让给编写业务组件提效,最大程度减少人为编码的工作量。

下面笔者跟GPT展开了几轮较量,主要是针对如何更好地提供组件的描述信息。

下面是一个实际的业务场景:

1、点击 + 按钮,弹出模态框。

chatgpt写复杂代码_复杂代码写不出来_复杂的代码

2、模态框中包含两个选项,点击不同的选项,将展示不同的表单项,表单项中包含 下拉选项、输入框等,用来输入项目信息。

3、填写完表单项,点击提交将表单数据传输到后端创建项目。

第一回合

注意: 定义角色、投喂基础UI组件与【在公司前端项目中落地 】初探成果 保持一致,不熟悉的可以先看上篇,下面的回合仅展示如何描述组件。

如下为第一回合输入的组件描述:

输入描述信息之后省略了一些额外的小步骤,比如按照公司规范模板进行代码优化等,详情请看上篇。

的表现如何呢?

点击 + 按钮,弹出模态框。

模态框中包含两个选项,点击不同的选项,将展示不同的表单项,表单项中包含 下拉选项 、 输入框等,用来输入项目信息。

填写完表单项,点击提交将表单数据传输到后端创建项目。

下面看一看自动生成的-样式、文档和单元测试

如上生成代码的满意度 80%, 整体符合预期,用户的整体交互逻辑都实现了,包括点击按钮弹出模态框、根据不同的选项展示不同的表单、样式抽离到中、文档、单元测试等。

但是有一些缺点,我们说过使用来进行编码是为了提升我们的工作效能。

缺点一: 第一回合的组件描述信息太多了,而且看起来也很繁琐,各种序号融合在一起,写着写着自己都不知道到哪了。

缺点二: 上面大量描述了组件props的定义,从体验上来说,这不就是用大白话在写代码吗,和普通的写代码没太大区别,我需要更加智能地体验,让不怎么懂技术的小白也能过GPT写出符合规范的业务组件代码。

第二回合

基于上述两个缺点,我们尝试优化一下。

如上是第二回合的描述信息,生成的组件最终效果与第一回合相差不大,但是描述信息相对来说比第一个回合更加口语化、没有描述技术层面的组件props,但是整体内容还是有点偏多,看起来有点乱。

思考一下,为什么没有告诉 “大佬” 基础组件的Props如何传递,但是它能够通过大白话推测出来呢?比如说 「弹出的 描述:标题是 、点击弹出层可以关闭、宽度为 720、 中包含两行。」,他知道设置title、width这些props。

原因是组件的声明文件中对于每一个Props写了备注,通过大白话和声明文件的备注就能够匹配到对应的Props

最终回合

既然有很强的上下文理解能力,那我门直接基于第二回合的描述信息分段来给,先让“大佬”搭建架子,然后再优化细节的内容。

先聊整个大架子:

再聊细节:

跟大佬聊完天,代码也写的差不多百分之八九十了,这可能就是聊天工程师吧!

后续规划

收集反馈:目前 聊天式编程 的工作流笔者正在公司内进行实践,同时也希望接收到来自社区的各种反馈,一起进步,一起高效办公。

页面集成联调:目前仅仅是开发了业务组件,还没有进行后台数据的对接。数据对接就涉及到更多的业务场景交互,还包括组件间的通讯,还能和 “大佬” 愉快地聊天吗?

工具开发:这一步上篇简单介绍了一下,简单来说就是类似集成插件,开发可视化的代码生成系统,但是具体的实施还需要看上两步的成效,有兴趣的朋友可以提前与我交流。

粉丝福利

自建免费国内网站:/

互动探讨学习:加入社群,跟LV还有一群优秀的小伙伴一起探讨、AI更多的可能性。进群方式:关注同名公众号,后台回复 ”进群”。