前端须要什么样的方案设计

背景

对于咱们平常工做来讲，写代码可能占去了大部分时间，但当咱们回头看之前代码的时候，咱们每每会以为之前本身写的很糟糕。

或者在向前看看资历比较老的同事，每每均可以写出比较清晰的代码，有一种莫名的优雅。
也许经过时间的历练，在几年以后本身也能够达到对方的水平，可是这个时间过久。
可不能够总结出一些能够复制的方法、套路，让新人也能尽早写出一套漂亮的代码？

本篇文章就是针对前端的研发状况，讨论这些方法、套路的。

现状

咱们每每都会陷入这样一种循环，在拿到需求文档时候，咱们会大体看一下，感受开发上没有什么太大的问题，而后就看看交互、UI 稿上有哪些页面，接下来就开始着手写了。

在写代码的过程当中，咱们也许会发现有些实现不合理的地方，这时咱们会稍微动一下咱们的大脑，而后抽象一下流程和模块，重构一下部分代码。遇到简单点的状况，咱们发现加个参数传过去作一下判断也能实现，因而咱们也就这么作了。

开发完后，咱们会以为比较知足，代码在脑中的逻辑比较清晰，里面也许有些地方写的不太稳当，可是也无妨吧。

而后项目就开始测试了，QA 会针对各类边界问题给咱们提 bug，在改 bug 的过程当中咱们痛苦不堪，以前的代码逻辑变得支离破碎，咱们不得不为了各类 bug 去为代码修修补补，方法的参数加了一个又一个，逻辑里的条件判断加了又加。每每到这个时候，咱们开始对 QA 提出的 bug 表示质疑，咱们会用“如今的表现是符合逻辑的”，“这种状况没问题”等等这样的说辞来避免对代码的更改。

过去几个月以后，咱们接到一个需求，要对这部分代码增长几个新功能，翻开代码的时候，整我的都崩溃了。之前代码的逻辑本身早就忘记了，面对本身已经看不懂的代码，咱们会问“这个方法什么意思？为何逻辑这么复杂？”，“代码在不一样页面之间跳来跳去，他们的逻辑究竟是什么样的？”，“为何会有这么多标识位，他们都是干吗的？”。注释什么的是不存在的，即便存在，也不明白在讲些什么。

在经历过阅读源码的痛苦过程以后，咱们看了看排期，嗯。。。还有 30% 的 buffer，因而咱们决定把这部分代码重写掉，而后再重复这个痛苦的循坏。

那么咱们应该如何从这个循环里跳出来呢？

对比

咱们相比一下后端，会发现他们在写代码以前都会作方案设计。方案设计是软件工程里的一个最佳实践，一般作技术方案的过程当中会体现出软件总体的架构，当对核心流程梳理完成以后，最后基本都能落实到代码上。也就是说好的技术方案能体现出最后代码的逻辑，经过看方案就能知道代码怎么写。这样就防止了在写代码过程当中边写边改，最后致使代码结构混乱的问题。

可是咱们尝试按照后端的方法来作方案设计发现根本写不出来什么内容：

• 后端的流程图是系统间交互的流程，而咱们大都数场景下只须要和一个后端交互
• 后端须要列举出来数据库表结构，而咱们都是把数据丢给后端
• 后端有业务模型，而对咱们来讲，从后端拿数据就好了
• 后端有核心业务流程，而咱们调用他们 API 就好了

从上面咱们能够看出，前端只运行在浏览器里，业务上只和后端有交互，并且 API 都是后端定好的，因此按照后端方案设计的套路，前端是写不出来什么东西的。

因此咱们会发现，咱们大多数设计文档都是偏 Node 层的东西，由于咱们每每都是按照后端设计方案的模式去作的，可是浏览器内部运行的代码却没有文档去描述。

分析

这时候咱们要从新审视方案设计的套路，来发现先后端的不一样：

• 业务分析
• 业务模型
• 核心流程
• 逻辑架构、类图、部署图
• 接口
• 实施方案
• 风险控制

业务分析与业务模型可能先后端都是一致的，毕竟咱们是解决同一个业务问题。但其中也有稍许差异，前端有些数据不是从后端获取的，或者说不必定非要从后端获取，这点咱们须要在作设计的时候考虑进去，好比一样是获取地理位置，咱们能够经过 GPS 也能够经过访问后端服务经过 IP 地址来判断，google 甚至有经过 WIFI 惟一识别码来定位的。

先后端对于「核心流程」的定义也不一样，对于后端来讲核心流程是数据的产生、流转、消费，可是提到流程，在前端来讲更多的是页面的流转、组件的交互。一样一件事情，在先后端来看彻底是两个东西，好比保存一项数据，后端须要关注的多是如何校验，如何存储，如何索引，如何关联。但前端要关注的倒是校验结果的展示形式如何，生成一个结构化数据须要调用多少页面，这些页面在不一样的屏幕下面如何展示，是跳转仍是覆盖或者弹窗。

后端其实更注重逻辑架构与部署图，由于后端须要为服务化，服务间边界的定义要很是清晰、具体，对于一个服务内的代码后端有 Spring 等明确的框架去规范如何写。前端与微服务对应的，应该就是组件 了，可是组件覆盖的范围太广，从一个按钮到一个页面均可以称之为组件，因此前端的组件须要被划分红模块、控件等不一样封装水平的单位。在这个划分的过程当中，逻辑架构和类图就天然体现出来了。同时先后端解决的问题不一样，致使关注点也不一样，前端须要关注页面的还原，好比页面的元素应该如何抽象，样式应该如何复用，这个是后端不用考虑的。

后端须要关注暴露出去的 thrift 或者 http 接口，由于这体现了系统间交互的逻辑。而对于前端来讲对应的也应该明确独立模块或者页面之间的交互逻辑，因此也就须要明确这些接口。

关于实施方案和风险控制，各方的关注点也有稍许不一样，后端更关心系统之间的集成，旧数据的兼容。而前端应该关心的是和移动 Native 的集成，或者微信、支付宝的集成，若是是桌面 web 的话就该考虑 iframe 集成的场景。

结论

做为软件工程的最佳实现，方案设计在前端开发过程当中仍是十分必要的，那么为何前端领域长时间不注重这个事情呢，我以为有如下缘由：

1. 方案设计依赖技术能力，而前端技术栈变化太快，今天的设计套路放在明天可能就失效了
2. 前端业务变化太快，通过半年的迭代以后，可能初版的方案就反应不出现有代码逻辑了
3. 前端的业务流程、交互流程比后端复杂太多，并且可复用性差，须要花费大量时间去思考和整理，并且对抽象能力有比较高的要求
4. 前端开发效率高，不会有历史包袱，有时候直接重写的效率反而更高

可是这些缘由其实都不是咱们不作方案设计的理由，方案设计是个结构化思惟的过程，他不光是能让项目更好执行，也能提高开发者自己的架构能力和宏观意识。

因此同窗们在平时开发的时候多想想如何作设计吧。