2.4.2　需求分析和系统设计

1. 几种常见的错误现象

相对于编码工作，需求分析和系统设计是两个经常被忽视的环节。在现实工作中，我们经常会看到以下这些现象。

（1）很多人错误地认为，写代码才是最重要的事情。不少软件工程师如果一天没有写出几行代码，就会认为工作没有进展；很多管理者也会以代码的产出量作为衡量工作结果的主要标准，催促软件工程师尽早开始写代码。

（2）有太多的从业者，在没有搞清楚项目目标之前就已经开始编码了。在很多时候，项目目标都是通过并不准确的口头沟通来确定的。例如：

“需要做什么？”

“就按照×××网站的做一个吧。”

（3）有太多的从业者，在代码编写基本完成后，才发现设计思路是有问题的。他们在很多项目上花费很少（甚至没有花费）时间进行系统设计，对于在设计中所隐藏的问题并没有仔细思考和求证。基于这样的设计投入和设计质量，项目出现设计失误也是很难避免的。而面对一个已经完成了基本编码的项目，如果要“动大手术”来修改它，相信每个有过类似经历的人都一定深知那种感受——越改越乱，越改越着急。

以上这几种情况，很多读者是不是都有过类似经历？

2. 研发前期多投入，收益更大

关于软件研发，首先我们需要建立一个非常重要的观念。

在研发前期（需求分析和系统设计）多投入资源，相对于把资源都投入在研发后期（编码、测试等），其收益更大。

这是为什么呢？

要回答这个问题，需要从软件研发全生命周期的角度来考量软件研发的成本。除编码外，软件测试、上线、调试等都需要很高成本。如果我们把需求搞错了，那么与错误需求有关的设计、编码、测试、上线等成本就都浪费了；如果我们把设计搞错了，那么与错误设计相关的编码、测试、上线的成本也就浪费了。

如果仔细考量那些低效的项目，会发现有非常多的类似于上面提到的“浪费”的地方。软件工程师似乎都很忙，但是在错误方向上所做的所有努力并不会产生任何价值，而大部分的加班实际上是在做错误的事情，或者是为了补救错误而努力。在这种情况下，将更多的资源和注意力向研发前期倾斜会立刻收到良好的效果。

3. 修改代码和修改文档，哪个成本更高

很多软件工程师不愿意做需求分析和系统设计，是因为对“写文档”有着根深蒂固的偏见。这里问大家一个问题，如果大家对这个问题能给出正确的回答，那么在“写文档”的意识方面，一定会有很大的转变。

任何人都不是神仙，无法一次就把所有事情做对。对于一段程序来说，它一定要经过一定周期的修改和迭代。这时有两种选择：

选择一：修改文档。在设计文档时完成迭代调整，待没有大问题后再开始编码。

选择二：修改代码。只有粗略的设计文档，或者没有设计文档，直接开始编码，所有的迭代调整都在代码上完成。

请大家判断，修改代码和修改文档，哪个成本更高？

在之前的一些分享交流会上，对于这个问题，有人会说，修改文档的成本更高。因为在修改文档后还要修改代码，多了一道手续。而直接修改代码，只需要做一次，这样更直接。

这个回答说明了回答者没有充分理解“先写文档，后写代码”的设计方法。如果没有充分重视设计文档的工作，在输出的设计文档质量不高的情况下就开始编码，确实会出现以上提到的问题。但是，如果在设计文档阶段就已经做了充分考虑，会减少对代码的迭代和反复。

对于同样的设计修改，“修改代码”的成本远高于“修改文档”。这是因为，在设计文档中只会涉及主要的逻辑，那些细小的、显而易见的逻辑不会在设计文档中出现。在修改设计文档时，也只会影响到这些主要逻辑。而如果在代码中做修改，不仅会涉及这些主要逻辑，而且会涉及那些在文档中不会出现的细小逻辑。对于一段程序来说，任何一个逻辑出现问题，程序都是无法正常运行的。

4. 需求分析和系统设计之间的差别

很多读者无法清楚地区分“需求分析”和“系统设计”之间的差别，于是会发现，在写出的文档中，有些需求分析文档里出现了系统设计的内容，而有些系统设计文档里又混杂了需求分析的内容。

我们用几句话可以非常明确地给出二者的差异。

（1）需求分析：定义系统/软件的黑盒的行为，它是从外部（External）看到的，在说明“是什么”（What）。

（2）系统设计：设计系统/软件的白盒的机制，它是从内部（Internal）看到的，要说明“怎么做”（How）和“为什么”（Why）。

比如，对一辆汽车来说，首先使用者从外部可以看到车厢、车轮，坐在车里可以看到方向盘、刹车踏板、油门踏板等；操作方向盘可以改变汽车的行驶方向，脚踩刹车踏板、油门踏板可用于减速和加速。以上这些是对汽车的“需求分析”。

然后，我们想象汽车外壳和内部变成了透明的，可以看到汽车内部的发动机、变速箱、传动杆、与刹车相关的内部装置等。而这些对驾驶者来说是不可见的，它们是对汽车的“系统设计”。