如何编写前端设计文档? 在需求详评(三审)后了, 需求的功能和交互已经基本确定, 而在实际进入开发之前, 还有一些 待确定的技术要点需要补全, 这些要点包括: • 需求的可实现性 (理论上能不能做, 是否能支持某个功能, 某个交互是否能实现, 实现功能的成本是否过于巨大),假设你给PM 拍胸口说啥功能你都能实现, 然后Ta 提了一个这样的需求[1]... • 需求的整体架构(前后端交互的流程和方式, 接口的路径、请求和响应参数) • 需求的具体设计(前端页面/组件/服务的设计) 而编写前端设计文档就是补全和完善上述这些技术要点的过程以及过程沉淀出的产物. 为什么写前端设计文档? Measure twice and cut once 三思而后行 如果所有产品的功能都是在页面上展示Hello, World 的话, 那么我们大概是不需要设计文档的，然而现实世界的产品需求功能充满了复杂性, 一个页面可能展示了非常多不同来源数据, 有不同的交互细节, 周密的业务流程, 这就要求我们需要在动手开发之前先想好这个功能能不能实现以及如何实现. 试想一下如果不写设计文档, 撸起袖子就开干可能会有哪些Bad Ending? • Case 1: 需求要你接入一个第三方SDK, 你和第三方的研发同学开了个小会对齐发现没有啥问题, 你没有做详细的技术设计印证是否SDK 能完整支持需求, 也没有测试过SDK, 结果开发到一半发现SDK 的功能不能完整支持你的业务需求, 如果要支持必须得第三方排期支持, 而这个项目本来预计要尽快上线的, 你人傻了 (First Bloodὤ） • Case 2: 需求中的一个功能需要你同时请求多个接口, 你没有充分考虑这些接口失败的容灾, 对这些请求的返回听天由命, 结果上线后用户在使用中经常遇到一个接口请求成功了, 另一个失败了,造成数据不一致, 用户反馈功能不可用, 你人傻了again (Double Kill!ὤ) • Case 3: 需求中需要开发一个弹窗, 你匆匆一瞥觉得这也就半天就能开发完, 结果没有充分考虑到这个弹窗有五个模式三个形态八种流程, 低估了2/3 的排期, 排期到了QA 催促为什么还不提测, 匆匆做完测试之后出现了一堆Bug, 你人傻了one more time (Triple Kill!ὤ) 我是三傻·史塔可吗? 而设计前端文档, 就是尽快能在开发之前将技术上不确定的点确定好, 将需求的设计方式提前构思好, 以减少后续开发出现风险和问题的可能性.虽然技术文档也不能100%预见或者评估出所有潜在的风险和问题, 但是技术文档能在相当程度...
