前言
百度百科对计算机软件的的定义为：“计算机软件(Software，也称软件)是指计算机系统中的程序及其文档，程序是计算任务的处理对象和处理规则的描述；文档是为了便于了解程序所需的阐明性资料。程序必须装入机器内部才能工作，文档一般是给人看的，不一定装入机器”。
可以看到概念里提到了"文档"，说明写文档是软件开发过程必不可少的一个环节，如果文档没有写好，那么软件也不能算是优秀的软件。
可对于一般软件开发人员来讲，写代码要比写文字容易得多。很多时候我们都能看到类似的事情，项目做完了，设计文档还没有；当别人问起，某个功能当时为什么这么设计，一时语塞；项目代码里没有注释，时间长了，自己都忘记当时代码为什么要这么写；当接手别人的项目的时候，要排查个问题只能一行行读代码，唯一的文档就是随脚手架自动生成的README.md。以上这些都是我们平时开发中可能会遇到的问题，为什么会这样？其实就是因为平时没有写文档的习惯，文字没有得以保留，只靠记忆，时间长了确实记不住。
下文就想和大家一起探讨一下，前端为什么写技术方案，怎么写前端技术方案。
写技术方案目的在讲为什么要写前端方案文档前，先讲一个我的好朋友小明的故事。
小明也是一个前端，在接到需求的时候，他会大致看一下需求文档，感觉没有什么太大的问题，然后就看看交互、视觉稿上有哪些页面，接下来就开始迫不及待地写代码了。
新建一个文件、写模板、写样式、写交互逻辑，一气呵成。新模块的需求是小明最喜欢的，因为不用去理解其它功能的逻辑，可工作中还是少不了维护历史代码。小明很聪明，他发现有个功能加个参数传过去做个逻辑判断就能实现，于是他也就这么做了。
开发完后，小明觉得很满意，因为很快就实现了需求，代码在脑中的逻辑比较清晰，里面也许有些地方写的不太妥当，但是也无妨吧。虽然不是全局最优的，但可以说是局部最优的。
版本提测之后，QA开始针对各种边界问题和极端场景给小明提bug。譬如输入框输入emoji表情后提交接口报错、按钮连续点击触发了多次请求、买家角色页面展示正常但是供应商角色展示错误……
在改bug的过程中小明渐渐带上了痛苦面具，代码逻辑被改的支离破碎，不得不为代码打各种补丁，方法的参数加了一个又一个，逻辑里的条件判断加了又加。到这个时候小明的开发积极性已经被消磨的差不多了，开始对QA提出的bug表示质疑，他会用“原来就是这么设计的呀”、“这个问题不在这次的需求范围内”等等这样的说辞来避免对代码的更改。
过了一段时间，小明又接到一个需求，需要对上次开发的模块增加一些功能。翻开代码的时候，小明整个人都崩溃了。以前代码的逻辑自己早就忘记了，面对自己已经看不懂的代码，开始对自己进行灵魂拷问“这个方法有什么用？这个方法怎么有这么多参数？为什么逻辑这么复杂？”，“代码在不同页面之间跳来跳去，还有长得几乎一模一样的代码，他们的逻辑到底是什么样的？”，“为什么会有这么多标识位，这么多魔法数字，他们都是干嘛的？”。注释什么的是不存在的，即使存在，也不明白在讲些什么。
刚接手项目的时候小明还不断吐槽之前开发的人不写文档、不写注释，没过多久小明也成了别人口中的那个"他"。
以上故事根据真实事件改编。
我觉得写技术方案文档是能解决小明的一部分问题的，“谋定而后动，三思而后行”，都是在说这个道理。当然写文档也不是万能。对比一下后端，会发现他们在写代码之前都会做方案设计，好像难道后端的开发时间很充裕或者说前端的技术方案不值一提吗？肯定不是。方案设计是软件工程里的一个最佳实践，通常做技术方案的过程中会体现出软件整体的架构，当对核心流程梳理完成之后，最后基本都能落实到代码上。也就是说好的技术方案能体现出最后代码的逻辑，通过看方案就能知道代码怎么写。这样就防止了在写代码过程中边写边改，最后导致代码结构混乱的问题。
怎么写技术方案如果我们按照后端那一套方法论和模板来做前端方案设计，发现根本写不出来什么内容，这时候我们要重新审视方案设计的套路，来发现前后端的不同。
业务模型可能前后端都是一致的，毕竟我们是解决同一个业务问题。但其中也有稍许差别，前端有些数据不是从后端获取的，或者说不一定非要从后端获取，这点我们需要在做设计的时候考虑进去。譬如同一个H5页面在