标签：模版 前端 技术 接口 架构图 文档 https 设计
以前写业务，评审完，差不多就开撸，不怎么会做详细设计。大部分情况还好，遇到复杂交互，就歇菜了，组件写着写着，接口变动，得配合后端变动，不得不强行写一些逻辑，导致业务组件耦合严重。如果遇到开发工时较少的，那真的就是能跑就行，可维护性，可扩展，代码质量根本顾不上了。
为什么系统到后来改不动了，出现巨石屎山项目，没做好设计也是其中一个原因。
所以，现在稍微复杂的页面，或者交互，我都会提前设计一下，在项目立项之后，就开始技术调研，提前跟相关产品，后端沟通好一些前提条件，对于一些重要的外部组件、库和服务，在文档中详细记录资料及用法，后面就是堆代码，撸起来会很开心。
类似把一团缠绕的线，前面理清以后，后面直接编织即可，不用编织一下理一下线，也能保证高质量。（对，我就是这样保证产出的高质量哒～）
下面总结一下：
不做设计的坏处：
- 开发时才发现有些没提前想到的事情，导致速度慢，效率低，经常Delay、返工。
- 新人来了没有可参考的文档，不好理解当前的项目，难以上手。
- 技术方案没有文档沉淀，其他团队也难以借鉴和复用。
做设计目标：
- 提升开发效率，以及程序的可维护性。
- 提升团队成员内架构设计能力。
- 通过技术设计和各种方案的不断优化，增强全公司的前端技术能力，提高产物的复用性。
设计注意事项：
- 需求是否相符：评判技术设计文档与产品需求是否相符，主要体现在功能、性能、安全性方面。
- 实现是否合理：主要体现在可扩展性、实现成本、对接成本方面。
- 在需求变更、后端接口发生较大变化，或其他因素使得前端方案改变时，需要及时修改设计文档。
实践：
之前写的设计，截取部分（获得产研老大，架构老大点赞）：
设计模版
设计要考虑哪些呢？
-
需求说明
可以简单介绍需求，把PRD帖过来。
功能需求
性能需求
安全需求
- 名词解释
- 数据层
数据调用层的设计，这里要明确说明后端接口的风格，如何调用。
-
整体设计
-
技术选型，为什么用这些技术，有什么好处、坏处，可以持续用多久，是否在产品的生命周期内一直用，还是未来需要重构……
-
程序整体架构图，技术实现的粗粒度体现。
-
整个项目/产品的模块如何拆分的，层次结构是怎样的。如果比较复杂，就用图体现一下。
-
整个项目的主要业务流程，可以体现在架构图中，也可以单独画一个流程图。
- 外部依赖
其他非业务的依赖，如第三方公共库，如何调用，如何传参数…… 可以把相关文档贴过来。
- 业务API依赖
与后端的对接方式，贴上接口文档地址。
前端的数据层实现方案，用什么网络库调用接口？
-
详细设计
-
每个模块的详细说明。有些模块要是简单，没啥可讲的，直接做的那种，可以不用写啥。与以前项目中的差不多的，也贴个链接。
-
复杂模块，要画架构图、流程图。
-
特别的技术方案。如果有复杂的算法，或者视觉、动画效果，可以在此写一下实现方案。
- 部署、运维
如果有必要，画出部署图。
- 性能优化和保障
- 安全防护和保障
学习一下大型项目的架构
https://repository.genmymodel.com/qa4862741/netty
https://blogwavi.wordpress.com/react-class-diagram/
https://thenewstack.io/microservices-node-js/
画架构图，可以参考C4模型：https://c4model.com/
用到的软件：excel，xmind，draw.io
标签：模版,前端,技术,接口,架构图,文档,https,设计 来源： https://www.cnblogs.com/youqiancheng/p/15719560.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。