读书

为什么程序员要写功能设计书

续上篇，还是阅读了《软件随想录》之后，希望把以前的思考再总结一下。

1.什么是功能设计书

功能设计书
  从用户的角度，完整描述了程序的行为。它只介绍了程序的功能、交互方式，并不涉及具体的实现方式。   

技术设计书
  指引程序员，如何实现功能设计书所描述的功能。它涉及数据结构、数据库、程序语言、算法等等内部的实现细节。

从头开始设计一个程序时，最重要的，是完成对用户交互的设计：用户需要哪些功能；这些功能具体需要哪些页面来实现；页面如何操作。
功能设计书的写作者需要将整个软件的所有可能的使用场景、流程，在自己的脑海中想象出来，并展现在功能设计书当中。

2.为什么要写功能设计书

有好多同事觉得写设计书没有必要，浪费开发的时间，而且对个人能力没有提升。
我无法想象他们是如何得到这些结论的。可能我在学生时代也是这么想的，看到一个任务就马上写代码，但我早就不这样做了。

2.1 设计

功能设计书最重要作用，就是对程序所有的功能进行设计。通过写文档描述所有页面交互的细节，你会被迫对程序做真正的设计。
在程序的使用中，有可能遇到什么问题，应该如何处理，你在设计阶段就应该想清楚。在写作中，那些可能出问题的地方，大部分都能暴露出来；而如果不写设计书，当你写了一些代码之后，才发现这些问题，付出的代价会更大。
所以设计能够大幅度缩短整个项目的开发周期。

更重要的，这对你个人的思维能力和表达能力都很有提升。
看上去，设计的成果是一篇文档，但为了写作这篇文档，你在脑海中进行的一系列思维活动，才是你最大的收获。

2.2 沟通

有没有回忆起，用户／开发人员／测试人员一次次的跟你确认功能设计的情景？他们东一句西一句地跑过来问你各种愚蠢的问题，你的工作时间被消磨殆尽。
通过功能设计书，你只需要跟别人沟通一次；其他人员只要去阅读功能设计书，就能知道你能给他们的所有信息。
如果没有功能设计书，你只能一遍一遍地讲给他们听。
更可怕的是，如果没有功能设计书，测试人员会根据程序的输入输出来测试程序，或者根据开发人员的实现细节来测试程序，而不是基于设计来设计程序。

2.3 计划

如果没有功能设计书把所有的功能点／页面罗列出来，如何安排计划呢。

2.谁来读功能设计书

客户
  这里的客户，是那些付钱给你开发程序的人。
  友情提醒你一下，要把他们想象成一毛不拔的铁公鸡，妄图只花5块钱买一架航空母舰。
  写作功能设计书的时候，需要一遍又一遍的跟他们确认，跟他们的想象和需求是否一致。这里的功能设计书，就是必须的“立字据”。基本完成之后，再修改是要加钱的哦。
用户
  这里的用户，是那些使用程序的人。
  友情提醒你一下，要把他们想象成又笨又懒的人，他们什么都不会，什么都不想做。
  但你的功能设计书，必须要把他们教会使用这个程序。
技术设计书的作者
  技术设计书的作者，需要根据功能设计书，考虑如何实现程序。
开发人员
  开发人员，主要按照技术设计书来实现程序，但是也会参考功能设计书，确认功能是否都实现了，页面流程是否一致。
测试人员
  测试人员，需要按照功能设计书来写测试案例，并最终实施测试任务。

3.谁来写功能设计书

不同的公司，会有不同的职位和称呼，而且写作功能设计书的人，又不是专职写作功能设计书的。
所以这里，我并不会将什么人来写，而是简单说下，写作功能设计书的人，需要哪些素质。

3.1 技术能力

虽然功能设计书本身并不涉及具体的实现方式，但是，作者必须明白，功能点都是在成本范围内能够实现。这就要求作者必须要有技术功底。
这也是为什么，本文的标题是“为什么程序员要写功能设计书”，有过开发背景的人，才会具备技术功底。其他人员，很可惜，我觉得不具备写作功能设计书的能力。

3.2 思维能力

将脑海中的设计，通过确切的图片和简要的语言，展现在文档中。我认为这不是写作能力，而是思维能力。

3.3 沟通能力

功能设计书不是独自写完就可以的。而是要跟其他所有读者沟通达成一致后，才能最终定稿。

4.如何写功能设计书

4.1 应当包含哪些要素

概述
  该程序的主要功能。
使用场景
  在什么情况下，可以使用该程序。
流程图
  程序各个页面的关系，也是整个服务的全貌。
每个页面的功能说明
  所有页面的详细功能。
细节！细节！细节！
  重要的事情说三遍。页面上所有可能出现的细节都要考虑到，所有可能影响页面的因素都要考虑到。在这些情况下，程序如何反应，写下来。
待解决的问题
  文档不可能在第一版就达到完善的状态，这是你要把还不清楚的地方写下来。
多角度的注解
  主要是从开发人员或者测试人员的角度，需要注意的细节。
修改履历
  所有的读者，都会根据修改履历，大概了解每次修改的功能点和位置。

4.2 写作原则

简单
  能用图片的，尽量用图片而不是语言。能少说的，就不多说。
用户角度
  从用户的角度思考问题，想想用户需要知道什么信息。
评审
  自己阅读，甚至大声朗读几遍。拿给所有必需的读者看。再修改。