在你编码之前

很多开发者，将自己限定为程序员，觉得自己就是一个专业写代码的，和代码稍微远一点东西，就不感兴趣。

在前一篇文章 《软件开发之未来》 中， 我已经阐述了技术的时效性以及快速更新。

如果我们紧紧把目光局限在代码，而不是分析、解决问题的综合能力，我们将迟早陷入中年危机， 被奔腾的技术潮流淘汰。

这篇文章我想讲讲分析问题、解决问题的基本套路，这是我多年总结下来的习惯，希望对大家有帮助。

绝对不是立刻写代码

有些同学钟情代码，收到一个任务，马上就想到代码实现。

问题都还没弄清楚，工作原理还没分析透，就开始整出几个类，然后思考如何用这些类。

找人讨论，直接看代码。

这是准备死1000次的节奏。

动笔头: 设计文档

有些新人，很有责任心，碰到问题也会找我沟通讨论。 但是怎么也不能深入下去，执行效果千疮百孔，各种返工改进，考虑不周，不能产品化，弯路不少。

问题在于，不善于动笔头。动笔头的目的:

1. 沉淀思考结果：

   每次思考，每次讨论，达成一步认识，就固定下来。上一步台阶，步步为营才能达到目标。

   如果不记录，就会焦虑，就会低水平原地重复思考。

   大多数人的大脑内存有限，必须借助文档这种外存进行交换才能顺畅运行的。

2. 文档是alpha版本的程序

   大脑就是运行文档的计算机。

   看一遍文档，让整个系统在运行之前，在大脑里面运行一遍。

   每次运行一遍，才能发现是否会抛出异常。对这些异常，在文档修正。然后再次运行，再次寻找处理异常。

   不仅仅在自己大脑运行，还要通过设计评审在别人大脑运行。如果有多种方案，需要大家进行评测那条最佳。

   不可能一次就做好设计，只有反复运行，多处运行，才能最终出错可能性最小。

   因此文档是否清晰明了是否简单，非常非常关键。

设计文档我推荐采用幻灯片的形式，因为一个页面说明一个问题。大标题配小节，更简洁。

下面的各个章节，也是这个幻灯片文档的主要内容。

当然你如果问题不大，对自己的大脑内存以及表达能力有信心，也可以不写设计文档。 风险自己承担了，其实设计文档不费时的。

陈述问题

陈述问题，也是陈述需求。

陈述问题，不应该太涉及技术层面的问题。更多是从前用户的角度来陈述。

陈述问题，应该是普通用户都能够看明白是什么东西。

需要将各种场景都说明白。不能漏掉场景，否则对我们之后的设计会存在偏差。

最终设计完成，需要验证这些问题、需求都得到满足了。

这些需求、问题，也需要做一个轻重缓急的判别。因为我们整个设计过程，最终需要做一个开发计划，要求能最快提交一个最小的可工作版本。 这样才能做到敏捷。

陈述问题，有时候不仅需要明确做什么，还要说吗不做什么，这是需要明确系统范围。

如果是多用户系统，需要罗列参与的用户角色，以及每个人的希望的获得功能。

工作原理图

一图抵万言。特别是对于用于沟通的设计文档，文字越少越好。图形能表达最多的内容。

工作原理图是一个方案的陈述方式。可以有一张，或者多张。这个是整个设计的中心。

工作原理图，通常包括系统和外部直接的交互关系图，以及系统内部的组成结构图。

这2种图，由方框和连线组成，方框表示模块，连线表示接口。需要标注各个接口和模块的名称，以及接口调用的主要顺序。

画原理图，不仅仅画画，而是真正的设计。里面蕴含大量思辨，需要我们拟清各种概念。

模块和接口命名，是思辨的体现。名不正则言不顺。

围绕这个原理图，需要对个模块和接口进行说明，这个组成了所谓的设计正文。

用户UI设计

如果需要用户参与，需要设计用户UI。当然如果是后端应用，需要明确接口。

用户UI往往要比较早明确，因为明确UI，才能细化需求，这个和概要设计也是相互呼应和印证的。

用户UI设计之所以重要，在于，这是更多从用户的角度思考问题，因此更能完整表达系统，明确正确的方向，方便引导思考进入深入。

当然如何设计，也会考虑从前方便实现的角度权衡。二者之间如何拿捏，这个是艺术所在。

开发计划

也就是todo。

一次设计下来，是需求和想法不断膨胀的过程，往往把简单的事情，弄得很复杂。

开发计划，则是如何干了。这时候主要的思考点，就是理想很伟大，但是我们如何做快速做一个可工作的最小版本。

大胆假设，小心实践也是这个意思。其实我们设计的内容，可能很多都是错的。

设计是永远的，不会终止于一次设计文档，也不会终止于评审，也不会终止于若干次改稿。 设计在开发的过程中，才是真正深入，这时候会不断发现之前设计的问题。

做一个最小可工作版本，这时候再次评估一下设计，发现问题多多。

所以，设计要尽早做，因为每一次回顾，我们基本上都会有新思路。 最早设计，最晚动手，这才是靠谱的方法。留给我们更多时间去消化完善设计。

根据问题，补充内容

初步的设计完成，就会发现各种问题，和疏漏。

准确记录下问题，然后思考解决方法。

其实我们如果能够准确的表达出问题，解决方法往往是呼之欲出的。

更新Reference文档

其实设计文档，长期保留的价值并不大，原因是:

• 文档过于简单，而且之后各种产品文档应该会包含设计文档的内容。
• 文档很容易过时，正式开始编码之后，设计仍然在变，这时候通常不会再去更新设计文档

所以设计文档通常都是虎头蛇尾的。

一旦确定设计，设计人员需要优先更新Reference文档，而且长期去维护这个Renference文档。

Reference文档是一些参考手册，包括API手册、系统维护手册，诸如此类。

这些文档是提供给其他用户，需要永久保留的。

很多人老是觉得没有时间维护这些文档。在设计阶段维护这份文档，其实很重要。

这份文档，其实就是详细设计文档，在编码之前，从用户角度更深入的设计系统，再次发现设计的问题。

如果觉得APi很奇怪，或者操作手册很难写，那么可能设计存在问题。

小节一下

分析问题、解决问题，我的套路，基本是这些，其实不麻烦。

但是这些是可以用在生活工作的各个方面的，是属于“道”层面的东西，如果编码是“术”的话。

我们都希望成为一个做事靠谱的人，即便在你不熟悉的领域，也能借助资源做好一件事情，上面的分析方法，可能值得借鉴。

转自：http://developer.everydo.com/blog/idea/soft-world-future.rst