撸代码前，写下设计方案
什么是设计方案？
解决一个复杂的问题，一般要经过几个不同的步骤。其中最重要的是问题发现阶段，分析阶段，和构建交付阶段。在分析阶段，工程师们研究哪些方案可以解决客户需求。一个设计方案，不代表已经有了可以上线的代码，虽然在验证方案的过程中，有可能会写一些代码。设计方案，是分析阶段的成果，它告诉大家
- 真正需要解决的问题是什么？
- 为什么要现在解决？
- 如何解决？
为什么要写设计方案？
有始有终的团队，在每个阶段结束的时候，会审视目标是否达成。对于分析阶段，他们会查看设计方案的好坏，来鉴别工作成果。而有些团队，射出去的箭，还没看是否击中大雁，就迫不及待朝大雁跑去。没写设计方案，就撸代码，一是沟通效率低，二是容易在项目后期发现设计上的缺陷而进入令人焦虑的赶工模式。
写下来一次，随时随地用
口头交流，眉飞色舞，固然爽快，可是口说无凭，什么也留不下来。结果，嘴皮子磨烂，一遍一遍得给不同的人讲你们的方案。这里我们要学习Java的设计理念，写一次，哪哪都能用。把设计方案写下来，有助于和团队里不同职能的人沟通：
- 产品经理： 保证对问题一致的理解，并且知道方案的优势及其劣势，不会到后期发现劣势而导致意外
- 项目经理：阐明方案所做的假设以及可能出现的风险，帮助在项目执行过程中追踪这些风险
- 团队成员和其他团队负责人: 收集大家对方案的看法，接受大家对所选方案的挑战，保证你的方案凝聚了各种思维的光辉
- 老板：当成汇报，帮助老板看到你们的成果，并且给他提供一个管中窥豹的机会，让他看到你们整个团队的合作质量
- 质量工程师： 说明你们要构造的是什么，帮助他们写出好的测试
- 团队的新人：帮助新人获取知识，所有的设计方案积累起来，就是一部团队发展史，帮助新人了解大厦是如何一层一层建起来的
真正的学习来自于清单检查
曾有人问一位智者，你是如何成功的？智者答，正确的决定。人又问，如何做正确的决定？智者再答，经验。人仍不解，如何获取经验？智者说，错误的决定。
犯错，大家都难以避免，而有的人错了再错。真正的学习来自于错误到经验的转化。写下来你的设计方案，按照积累的清单，逐条检查，能保证方案质量，虽然不能保证不犯新错误，但至少同样的错误不犯两遍。如果你什么都不写，只是口头说说，就达不到清单检查的效果。
其实清单检查不仅仅适用于设计方案，任何形式的写作都可以从中受益。秋叶在他的《写作七堂课》里也介绍了写作清单的重要性。
如何写一个好的设计方案？
不幸的家庭有各种不幸的理由，而幸福的家庭，都是相同的。好的设计方案里应该都包含下面的这几点。如果你熟悉JDK里JEP(java enhancement proposal)，你会发现下面的这些关键点在JEP里也能找到，我也是受了JEP的启发。
目标
解释你们最终想要获得的成果。目标的缺失，或者模糊的目标，说明没有真正看到问题的本质，没有真正领会用户的需求。这样做的风险是解决一个根本不存在的问题，竹篮打水一场空。
动机
动机是对目标进一步的解释，特别是对现状的解释。你之所以有目标，是因为你不满意当下，在现状和目标之间有差距。这个差距是什么？为什么我们现在必须缩短这个差距？
描述
动机回答的是为什么，描述回答的是如何做。这里要解释如何一步一步的实现解决方案。一个准确完成的描述会告诉读者你问题的复杂度。
风险
你的方案可能无法考虑到所有的限制因素。就像分布式系统里的CAP理论一样，网线拔掉的时候，是各自为政，还是坐等网线插好。解释方案的限制因素，打好预防针，防止惊吓。
测试计划
如果知道怎么测，那么表明你知道成功是什么样子。相反，如果你不知道怎么测，表明你没有想清楚你究竟要的是什么。
替换方案
上面解释的都是被选中的方案。不要小瞧那些被砍掉的方案。写下那些没有被采纳的，可以证明你们想的足够全面，也可以解释你们是如何做决定的。所谓的决策，归根揭底，就是做取舍的方式。
结语
新冠疫情改变了我们工作的方式，越来越多的远程工作，去中心化的办公室，让人们很难一直保持同步，对于那些队员分布在不同时区的团队，更是雪上加霜。写下来你们的设计方案，保证大家朝着同一个方向前进，比以往任何时刻都更重要。你从这篇文章里学到了什么？像以往一样，欢迎联系我。