📖 前言
前端技术文档是什么？为什么要写前端技术文档？带着问题先看个小片场
张三和李四两家子分别计划去珠海长隆一日游。张三是稳健派，早早就做好了旅行规划和物资准备，李四则是随性派，看了一眼园区地图就“心有成竹“了。
旅行当日，李四状况百出，1)驾车路线不熟，开错了1个路口，导致延误到达园区附近；2)未提前了解停车区，绕了不少弯路停车；3)未提前规划游玩路线，匆匆忙忙赶剧场和表演，错过很多精彩景区和节目；4)未提前准备物资，忍痛购买高价食物；5)游玩结束，想订购附近住宿，却发现全部定满了，只能拖着疲惫的身体驾车回家。
再回头看看张三，按照提前规划好的路线，有条不紊的游玩了大部分景区和节目，虽然中间有些小岔，比如食物不够，简单补充后就继续游玩了，晚上看完烟花后入住提前定好的酒店，结束美好的一天。
前端技术文档其实就好比小片场中旅行规划
对个人而言，编码前设计好程序整体架构和核心流程，编码时更丝滑，避免边想边写边改，最后可能产出自己都看不懂的代码；其次在设计过程可以提前发现一些坑和风险，及时规避，为项目上线保驾护航，老板看了直呼老哥稳。
对团队而言，技术文档是对业务或技术的沉淀，团队其他成员接手项目时能通过文档快速了解前因后果，假如每个项目从0开始阅读代码，时间成本可想而知。
技术文档怎么写？其实国内几大文档平台都有内置模板，如某雀、某书、某微，模板核心内容都少不了方案设计，而方案设计依赖需求分析，故接下来重点讲这两点
🔍 需求分析
一个基本原则：对业务负责大多数情况下，技术是为业务服务的，业务搞起来，技术才有价值。业务搞砸了，可能饭碗就没了。
二个思考维度：全面、闭环。全面指覆盖需求的全部场景，流程判断完善等；闭环指通过数据分析用户行为和业务增长等（pv/uv），需要数据支撑，比如埋点、监控，日志等
对于需求分析，不同的人有不同的套路，比如个人就喜欢 5w1h 切入
-
what-需求是什么
-
who-需求用户是谁
-
where-在哪里用到
-
why-为什么做这个需求，有什么价值
-
when-什么时候需要
-
how-怎么做，是否有更优方案
分析需求一般从大到小，先梳理整体流程，分析可行性，最后再到细节实现，避免一上来就纠结代码实现。分析过程借助流程图或思维导图，事半功倍。
接下来以我司某签到活动举个例
-
what-用户签到
-
who-所有用户
-
where-个人中心面板
-
why-促活、留存
-
when-立刻、马上、现在
-
how-登录->签到->弹窗->领奖
再来个签到流程图
到这一步，看山是山的分析基本完成，但总觉得少了些什么，尝试再深入分析下
- 签到入口有点深，有签到提醒吗
- 手动签到还是自动签到，支持补签吗，签到失败如何处理
- 奖励发放是自动还是手动（即“开心收下“逻辑）
- 签到数据上报（埋点）
- 奖品中心入口隐藏了，影响范围有哪些
- 签完到还能做些什么？
示例需求比较简单，分析中基本包含了整体签到流程和异常场景，有疑问的找产品沟通，沟通ok后就开始设计方案吧
🛠 方案设计
方案设计涉及的内容点较多，如技术调研、技术选型、技术架构、技术风险、技术成本等等，在前后端分离的协作模式下，还需要评估后端相关技术实现，最后整理输出方案
本文示例较简单，按照UI稿脑补一下组件结构就能开发了。复杂功能则需要调研，考虑下手写复杂度，实现成本，是否更优解，比如开源库之类的。但不要过度设计，一切从简，有个大概架子和模型就行，下方是组件设计示例
至此，一个简单的前端技术文档算写完了，再进一步还可以设计组件入参、状态扭转等逻辑，考虑代码复用、页面性能、用户体验等。
🧩 题外话
工作多年，最喜欢的就是新项目，因为不用考虑历史包袱。但现实很残酷，大部分公司都有自己的成熟产品，需求内容往往是功能迭代类，看似不以为然的代码，手贱改了，可能就出生产事故了。那如何应对此类需求？
参考上文，首先梳理业务逻辑，运气好的能找到历史需求文档或开发文档，有历史测试用例那是更好；假如没有，那就只能自己动手梳理了，梳理过程要考虑几点
- 新增逻辑是否影响旧功能
- 修改逻辑是否兼容旧功能
- 删除逻辑三思而后行
梳理好流程，整理出风险点，在文档加个 checklist ，应该挺稳的了
再聊聊需求拆分和工时评估，这也是老板最关心的点。个人比较喜欢按需求模块进行拆分，根据需求模块进行功能拆分，每个功能工作量控制在2天内，假如超出，说明还可以继续拆。那么怎么拆分功能，怎么评功能要多少工时？
用框架开发的话，按组件去评。借用 React 的经典公式 ui = fn(state)，万物皆组件，页面也可以是组件，组件包含dom、js，这时应该可以评估出 dom 和 js 的时间了。除了开发时间，还要考虑前期设计投入、沟通成本、自测时间、改bug时间等，有风险的项目还要乘个风险系数，这样应该八九不离十了。
