在你编码之前（转）
很多开发者，将自己限定为程序员，觉得自己就是一个专业写代码的，和代码稍微远一点东西，就不感兴趣。
在前一篇文章 《软件开发之未来》 中， 我已经阐述了技术的时效性以及快速更新。
如果我们紧紧把目光局限在代码，而不是分析、解决问题的综合能力，我们将迟早陷入中年危机， 被奔腾的技术潮流淘汰。
这篇文章我想讲讲分析问题、解决问题的基本套路，这是我多年总结下来的习惯，希望对大家有帮助。
绝对不是立刻写代码
有些同学钟情代码，收到一个任务，马上就想到代码实现。
问题都还没弄清楚，工作原理还没分析透，就开始整出几个类，然后思考如何用这些类。
找人讨论，直接看代码。
这是准备死 1000 次的节奏。
动笔头: 设计文档
有些新人，很有责任心，碰到问题也会找我沟通讨论。 但是怎么也不能深入下去，执行效果千疮百孔，各种返工改进，考虑不周，不能产品化，弯路不少。
问题在于，不善于动笔头。动笔头的目的:
-
沉淀思考结果：
每次思考，每次讨论，达成一步认识，就固定下来。上一步台阶，步步为营才能达到目标。
如果不记录，就会焦虑，就会低水平原地重复思考。
大多数人的大脑内存有限，必须借助文档这种外存进行交换才能顺畅运行的。
-
文档是 alpha 版本的程序
大脑就是运行文档的计算机。
看一遍文档，让整个系统在运行之前，在大脑里面运行一遍。
每次运行一遍，才能发现是否会抛出异常。对这些异常，在文档修正。然后再次运行，再次寻找处理异常。
不仅仅在自己大脑运行，还要通过设计评审在别人大脑运行。如果有多种方案，需要大家进行评测那条最佳。
不可能一次就做好设计，只有反复运行，多处运行，才能最终出错可能性最小。
因此文档是否清晰明了是否简单，非常非常关键。
设计文档我推荐采用幻灯片的形式，因为一个页面说明一个问题。大标题配小节，更简洁。
下面的各个章节，也是这个幻灯片文档的主要内容。
当然你如果问题不大，对自己的大脑内存以及表达能力有信心，也可以不写设计文档。 风险自己承担了，其实设计文档不费时的。
陈述问题
陈述问题，也是陈述需求。
陈述问题，不应该太涉及技术层面的问题。更多是从前用户的角度来陈述。
陈述问题，应该是普通用户都能够看明白是什么东西。
需要将各种场景都说明白。不能漏掉场景，否则对我们之后的设计会存在偏差。
最终设计完成，需要验证这些问题、需求都得到满足了。
这些需求、问题，也需要做一个轻重缓急的判别。因为我们整个设计过程，最终需要做一个开发计划，要求能最快提交一个最小的可工作版本。 这样才能做到敏捷。
陈述问题，有时候不仅需要明确做什么，还要说吗不做什么，这是需要明确系统范围。
如果是多用户系统，需要罗列参与的用户角色，以及每个人的希望的获得功能。
工作原理图
一图抵万言。特别是对于用于沟通的设计文档，文字越少越好。图形能表达最多的内容。
工作原理图是一个方案的陈述方式。可以有一张，或者多张。这个是整个设计的中心。
工作原理图，通常包括系统和外部直接的交互关系图，以及系统内部的组成结构图。
这 2 种图，由方框和连线组成，方框表示模块，连线表示接口。需要标注各个接口和模块的名称，以及接口调用的主要顺序。
画原理图，不仅仅画画，而是真正的设计。里面蕴含大量思辨，需要我们拟清各种概念。
模块和接口命名，是思辨的体现。名不正则言不顺。
围绕这个原理图，需要对个模块和接口进行说明，这个组成了所谓的设计正文。
用户 UI 设计
如果需要用户参与，需要设计用户 UI。当然如果是后端应用，需要明确接口。
用户 UI 往往要比较早明确，因为明确 UI，才能细化需求，这个和概要设计也是相互呼应和印证的。
用户 UI 设计之所以重要，在于，这是更多从用户的角度思考问题，因此更能完整表达系统，明确正确的方向，方便引导思考进入深入。
当然如何设计，也会考虑从前方便实现的角度权衡。二者之间如何拿捏，这个是艺术所在。
开发计划
也就是 todo。
一次设计下来，是需求和想法不断膨胀的过程，往往把简单的事情，弄得很复杂。
开发计划，则是如何干了。这时候主要的思考点，就是理想很伟大，但是我们如何做快速做一个可工作的最小版本。
大胆假设，小心实践也是这个意思。其实我们设计的内容，可能很多都是错的。
设计是永远的，不会终止于一次设计文档，也不会终止于评审，也不会终止于若干次改稿。 设计在开发的过程中，才是真正深入，这时候会不断发现之前设计的问题。
做一个最小可工作版本，这时候再次评估一下设计，发现问题多多。
所以，设计要尽早做，因为每一次回顾，我们基本上都会有新思路。 最早设计，最晚动手，这才是靠谱的方法。留给我们更多时间去消化完善设计。
根据问题，补充内容
初步的设计完成，就会发现各种问题，和疏漏。
准确记录下问题，然后思考解决方法。
其实我们如果能够准确的表达出问题，解决方法往往是呼之欲出的。
更新 Reference 文档
其实设计文档，长期保留的价值并不大，原因是:
- 文档过于简单，而且之后各种产品文档应该会包含设计文档的内容。
- 文档很容易过时，正式开始编码之后，设计仍然在变，这时候通常不会再去更新设计文档
所以设计文档通常都是虎头蛇尾的。
一旦确定设计，设计人员需要优先更新 Reference 文档，而且长期去维护这个 Renference 文档。
Reference 文档是一些参考手册，包括 API 手册、系统维护手册，诸如此类。
这些文档是提供给其他用户，需要永久保留的。
很多人老是觉得没有时间维护这些文档。在设计阶段维护这份文档，其实很重要。
这份文档，其实就是详细设计文档，在编码之前，从用户角度更深入的设计系统，再次发现设计的问题。
如果觉得 APi 很奇怪，或者操作手册很难写，那么可能设计存在问题。
小节一下
分析问题、解决问题，我的套路，基本是这些，其实不麻烦。
但是这些是可以用在生活工作的各个方面的，是属于“道”层面的东西，如果编码是“术”的话。
我们都希望成为一个做事靠谱的人，即便在你不熟悉的领域，也能借助资源做好一件事情，上面的分析方法，可能值得借鉴。
