如何进行软件设计——不断迭代

辛苦堆砌，转载请注明出处，谢谢！

最近工作，开始了新的软件设计，所不同的是，这次从需求对接开始的。之前的设计往往是已有的系统重新设计架构；有时是需求已经确定，已经进入正常的设计阶段；更有甚者，不进行需求分析，也不进行设计，直接开始开发，所谓的边开发边设计。可能我还能处理这种情况，但是具备设计能力的开发人员不多，寄希望于边开发边设计，真的是很有风险的。敏捷开发不建议重量级的设计，但不否认要对系统的关键点进行必要的设计。

那么，我们如何进行软件设计呢？

经过这一次的软件设计实践，我认为最好的软件设计都是一次次迭代的结果。软件开发讲求迭代，设计也讲求迭代，需求转化为设计，也需要迭代，一切都是迭代产生的。之所以这样说，个人的理解，主要是以下几个因素导致的。

需求提出者本身对需求也不是很清楚

我没有开玩笑，的确这样，需求提出者只有很笼统的需求，比如，我希望做一款电商使用的APP。他往往会忽略操作，忽略流程，忽略所有其他的，对他来说，他就要一款电商APP，但是这个APP包含什么功能？去问他，他会说，和其他电商APP一样就好了。这样的回答实际上没有给出任何有用的答案。

所以，需求的探究需要迭代，我们需要问他，你要什么，他会给你一些描述，你拿着这些描述，回去琢磨一下，会发现有一些会影响你的设计的因素，他并没有给出答案，然后我们需要再和他问一遍，你想做什么？然后加上我们的问题，他可能会发现，原来他当初没有考虑到这一点。一次次迭代，需求就会逐渐清晰。

有需求的人可能不懂开发

很多人有奇思妙想，但是他们并不具备开发能力。这些人可能会认为做这样一个软件很有前景，然后想找懂开发的人去做。这时候，我们在帮助他理清需求之后（一般理解到80%时），需要做的是出简单的原型，让他能够清楚这个东西我们可以做，但是我们需要他告诉我们做成什么样。

不过我的原型可能更简单，我不会构建整个系统，我会在技术难点和用户最期望的功能上下些功夫，做出一系列Demo，每一个Demo可以满足用户的一个功能需求。这些Demo我不会丢弃，他们之后会作为功能模块添加到我的产品中，但是我抛弃了界面的优雅，而重在功能的组织和架构。利用这些Demo我告诉需求方，我能做这些，同时我会配合一些简单的界面示意图，我说这个功能可以这样展示，让他提出意见，一同讨论，看看如何处理会更好。需求方必然会提出改进意见，但是你会发现，这个时候的改进意见往往是界面上的，但是这同时会引发他对功能需求的进一步思考，很有可能会引出非功能需求。

比如这段时间的软件，要求可以扫条码，我自以为需求方会有扫描二维码的可能，我就擅自添加了扫描二维码，但是使用时，无意中将二维码也扫上了，需求方就会说，我不希望扫条码被干扰，我会问确定永远不会扫二维码，他很确定地说是，那好，我们在我们的设计清单中把扫二维码功能去掉就好了，庆幸自己还没有开发。

我们的设计不会十全十美

谈完需求方的原因，说说我们自己的原因，人无完人，做软件我们不可能考虑到方方面面，任何我们自以为是的想法，都反而被需求方所忽略，反而我们忽略的东西，需求方可能更看重。就像我上面扫二维码的例子一样，自以为是往往自食苦果。

我们的设计一定要不断交给需求方看，界面的示意图，初始的功能Demo等等，需求方在看到这一系列东西时，一定会提出他自己的看法，我们要及时采纳，修改设计，然后再让需求方过目。

同时，在这个过程中，我们会看到自己设计忽视掉的问题，给了我们更多的弥补过错的机会，何乐而不为。

人的认识能力有限

人的认识能力是有限的，我们不可能想到所有，所以设计过程的不断迭代，就一层层加深了我们对系统以及自己设计的理解，这样，我们才能尽可能的减少开发中的风险，能够更好地评估开发的效率。

以上是我对软件设计的一些理解，可能有一些不太成熟，但是会随着以后的实践进一步提高自己的软件设计能力，到时候再和大家分享。