theme: awesome-green
highlight: agate
前端
在实际开发场景中，无论是哪个岗位上的问题，最终都会在前端界面呈现，从而将问题汇总到前端处；那么在目前团队的协作上，前端还需要在哪方面去做的更好呢？
1. 更认真仔细地联调
目前现状：
目前在接口联调时，大多数场景都是由前端根据接口文档去进行阅览绑定；但当出现接口字段过多或者字义相近的情况时，就难免会出现字段绑定出错，或者把逻辑字段应用到业务字段上等情况
聚焦问题：
根据问题缺陷分析，近40%的 BUG 都是由此产生
解决方案：
根据这个情况，需要对前端开发提出更细节的要求；在接口联调完成后，对接口文档有疑问的、字段绑定不明确的、涉及财务金额类的，都需要记录下来，然后找后端同事进行帮忙确认；如下图所示
那么这么做的好处是什么呢？
从便捷性的角度讲： 便于自测时快速确认字段是否绑定正确，而不需要在接口文档的众多字段中去进行核对
从准确性的角度讲： 跟后端二次确认的过程也是对前后端代码准确性的一次保障，这个过程中前后端都会因此对代码逻辑进行检查，大大地提高了代码准确度
2. 绘制逻辑流程图
目前现状：
在前后端分离盛行的模式下，各司其职所带来的弊端越发地成为所有团队难以解决的痛点：前端对需求不够了解，在面对复杂需求时，不得不依赖后端对于逻辑的实现
聚焦问题：
但是在面对复杂需求时，后端的开发时间也会随之愈发紧凑，便难以在联调中投入更多时间精力
而此时由于前端对需求的不够了解，将会造成 需求任务停滞，联调难度更高，后端压力更大，问题缺陷产生次数更多 等问题
解决方案：
那么面对这个问题时，从前端的角度出发，要怎么样才能做的更好呢？
在面对复杂逻辑时，前端应提前设计好方案，画好对应的逻辑流程图；通过流程图，可以更直接地反映出逻辑是否有缺失，以达到查漏补缺的作用
以上就是我在完成某部分较复杂需求时绘制的流程图，在完成某个相对复杂逻辑节点时，通过提前构建解决思路、流程扭转来进行流程图的绘制；通过该流程图可以实现以下几大好处：
- 可以一目了然逻辑有可能出现问题的节点，从而提前做好兼容，减少问题的产生
- 在提测前做代码自测时，可以结合流程图来检查自己的代码是否有问题
- 可以请后端同事帮忙二次确认逻辑是否存在问题，是否与后端一致，是否达到需求，达到二次确认的效果；可以更好地扼杀问题的产生
- 可以在该模块后续迭代维护时，更好地应对逻辑遗忘的问题，从而可以更快更稳地上手，而不会改一个问题时又会引发新的问题出现
3. 更主动地完善需求
目前现状：
目前的开发场景中，前端在开发过程中是较少提出优化交互以及完善产品意见的，总是按部就班完成需求上描述的任务，缺乏对于需求的思考
聚焦问题：
我认为需求来源不应该全是由产品提出，而是应该由开发在过程中去进行完善，去增加友好的交互和必要的验证，才可以完成一个好的产品
而目前的现状长久以来也会不断地增加产品同事的压力，因为所有的交互体验都得由他们去进行制定和描绘，从而也会直接导致前端丧失团队口碑
解决方案：
那么作为前端，我们应该怎么去优化交互和完善产品呢？
在接到产品原型进行开发前，应该仔细阅览原型，以前端专业的维度去进行分析，对应到每一个字段的显示，每一个交互的改良
比如：
- 涉及表单提交，流程流转处，增加防抖，避免短时间内发送多次请求
- 能筛选搜索的，就不要让用户一项项去阅览
- 该做验证的地方，就自己加上验证，严谨的要求可以体现平台专业感
- 做好空数据的兼容，不要展示
null等程序字符，征求产品意见后直接隐藏或者提示对应空文本 - 自己都觉得不好用的地方，更应该及时反映和想办法处理
- ……
而后端作为实际开发场景中前端与产品的 「中间件」 ，我们又需要后端同事在哪些方面去做得更好呢？
后端
1. 对得上的字段
目前现状：
在面对复杂需求，后端分身乏术时，前端会更依赖接口文档的描述和备注
聚焦问题：
前端在不了解后台字段设计的情况下，大多数情况会参照原型的字段去进行一对一联调，但是会经常在接口文档中找不到该字段，如下图片所示，原型给出的字段名是「储值本金」：
但是匹配上的接口文档字段给出的却并非这个字段，这个时候前端也只能去叨扰后端去进行确认
而一旦询问次数过多或者后端同事也忙着手头的工作，那么沟通成本就会瞬间增大，给双方都造成很大的压力，使效率变得很低，更加深了前端对于后端的依赖
解决方案：
字段的参数说明需要尽量与原型保持完全一致，由此让前端可以直接一比一地将接口文档代入原型进行开发，减少联调压力，使前后端分离模式愈加明确
2. 数据唯一索引
聚焦问题：
相信到目前为止前端同事都会有一个困扰，特别是表格数据的 list 经常会缺少唯一索引或者无法确定哪个是唯一索引；所以需要后端确保列表数组有唯一索引，比如 ID Code 等，因为前端遍历需要确保唯一性
解决方案：
那么针对可能会发生的情况，以下也提供了两种场景：
如果后端返回了唯一标识：
如上所示，后端返回了唯一标识，但问题在于就算这样，前端也无法确定应该使用哪个；因为 ID以及 Code一般都会被作为唯一标识，甚至一些特殊场景，会存在数据间的ID以及 Code是一致的
所以需要后端同事加上备注，来告知前端应该使用哪一个作为唯一标识
如果后端无法返回唯一标识：
如果遇到特殊性数据，后端实在无法提供唯一标识的，也需要提前跟前端沟通清楚，让前端同事从前端的维度去进行解决（通过取数组的下标）
3. 必要的备注
聚焦问题：
很多时候为了实现一个需求，不管是前后端都会去新增制定很多字段，比如下面的字段：
这个字段的意思是为了判断某个卡券的使用范围，但是这个卡券又分为「折扣卡」、「赠金卡」、「无权益卡」，而这个字段是仅适用于「折扣卡」的；但当前端看到接口文档上的参数说明时，其实是没法能理解后端创建该字段的用意的
解决方案：
但是当加上必要的备注后，前端稍结合原型需求，其实便能理解该字段的意思
因此可以减少很多无效沟通，一旦后期需求需要优化或者迭代，后续新参与的同事也可以结合原型、接口文档去对需求更好更快地去理解
团队
1. 更规范的修改流程
目前现状：
需求在落地过程中难免会需要完善修改，目前的流程基本是由产品在群里@对应的开发进行传达，原型有时会忘记修改，或者小改动就没有通知UI设计师随之同步到设计图
聚焦问题：
造成的问题是
- 一旦产品同事忘记修改原型，会造成开发在自检的过程中疑惑，发现功能对不上
- 测试同事在测试时发现原型、设计图、开发的产品对不上
解决方案：
所以应该强调的流程是
- 产品将需要修改的内容同步到原型
- 产品通知UI设计师同步原型到设计图（目前了解得知测试同事是会根据设计图来对比进行测试）
- 产品将修改的内容总结，最好是截图对应原型，标注出哪里是需要修改的发到群里，并通知对应开发
- UI设计师同步完原型至设计图后，最好是截图对应修改位置，并通知对应开发
这样就能确保开发可以准确得知修改的内容，并针对次提前排期，以应对需求有可能延期的风险；测试过程中，三方的产出也能保持一致
2. 更清晰的 UI 设计图目录
聚焦问题：
目前的大多数设计图都缺乏明显的目录结构，造成开发的过程中经常混淆，找不到对应模块的设计图
解决方案：
前端在目前的开发场景下，通常是同时打开原型以及设计图进行开发，所以最好是：
UI设计图的目录结构与原型的结构保持一致
如下图所示，在我跟对应的设计同事沟通过后，产品目录以及UI设计图目录基本保持一致，可以更便捷地找到对应功能的设计图，方便开发，也更方便后续测试（目前方案有待统一成规范）
产品原型图
UI设计图
作者：黄勇超
职位：前端开发工程师 | 技术部门主管 ｜ 字节跳动签约优秀创作者
团队：Kylin Development Team
暂无评论内容