设计先于开发

上一篇，我们聊了如何搞懂业务需求，吃透了需求就可以进入开发了吗？也不是，我们还要进行架构的设计，下面，我们就来聊一下这个话题。

为什么要先进行设计呢？从业务需求到代码实现之间其实还是有很大跨度的，如果不进行设计就进行开发，往往就很难考虑详细和周全，一旦出现欠考虑或者考虑错误的地方，后期再来改就会浪费更多的成本，整体效率和质量反而更低。

很多人会认为，互联网的思维就是小步快走，快速迭代，这是不是跟设计在先矛盾呢？其实是不矛盾的，而且是相辅相成的。设计就是要考虑未来的变化，提前在架构上做好准备，让系统在快速变化的过程中，不至于每次都推倒重来，保持架构的相对稳定，让整体迭代的效率和质量最高。

而且，开发的工作是需要多个工种协同进行的，就像是盖大楼，如果没有设计图纸，大家就很难高效的协同工作。设计的过程就是画图纸的过程，就是让大家思路和目标保持一致的过程。尤其是中大型的项目，一定要经过这样的过程，才能让大家信息一致。

那么，设计的过程需要考虑哪些关键点呢？首先，针对业务需求来说，从梳理需求到设计，是一脉相承的关系，不要脱离上一篇我们梳理出来的业务图。上一篇中，我们已经将业务拆分到单个场景的粒度，接下来就是要把场景拆分到功能页面上，同时，每个功能页面，要拆分出需要几个接口才能实现。要对照着场景拆分图来进一步拆分接口，就是要站在当前角色下，看这个场景到底需要几个接口才能实现。只有这么来做，才能让接口的设计真正适合业务的需求。

其次，除了业务需求之外，我们更应该关注的是非功能性需求。什么是非功能性需求呢？就是系统的可用性、性能和可扩展性。这三点是系统的隐性需求，不容易被人察觉，但是对系统来说却是至关重要的。具体这三点应该怎么来做，我们后续章节还会继续来聊。下面，我先说其中最关键的一点。

无论是业务需求也好，还是非功能性需求也好，我们要想做好设计，最关键的是找到明确的设计目标，以及不断迭代的抓手。业务是在不断变化的，系统就要跟着不断迭代。所以，无论是业务需求还是非功能性需求，都是不断迭代的。如果没有目标，我就不知道这么设计到底是对还是错，如果没有一个抓手，就不知道每次迭代是否精进了。

对于业务需求来说，满足业务目标就是设计的目标，抓手就是业务需求的拆解图，拆解就要从业务背景和目标开始，拆解到具体的场景和功能，然后再把功能拆解到具体的页面和接口。逐一的拆解保证了从设计到开发的连贯，也就保证了最终的系统能够满足业务的需求。

对于非功能性需求来说，系统的高可用、高性能和高可扩展性就是设计的目标。那么，这里的“高”的指标到底是多少就是我们的抓手。我们要对当下的非功能性指标做一个测试，只有量化的指标才能让大家清晰的知道目前系统的准确情况。然后，我们再把需要达到的目标做量化，量化之后才能看到差距，逐步去分拆这个差距，才能知道怎么去逐步迭代。

我们以高可用性指标为例，我们可以以一个月为单位，计算每个系统模块的可用性指标，比如2个9就是99%，3个9就是99.9%，只有有了明确的指标数值，我们才能清晰的知道当前每个系统模块的真实情况。一定要花时间去统计和定义这些指标，有了这个指标，我们就能发现待改进的项目，比如有哪些可用性差的模块，以及可用性差的接口，具体再去分拆，就能找到其中的关键问题，就可以逐步去优化。优化完毕以后，再来进行统计，看看指标有没有改善，通过复盘再来进行改进。这里的指标就会成为我们的抓手，可以不断督促着我们不断进行精进，指标统计得越真实、越实时，迭代的效率就越高。

再以性能指标为例，我们可以周期性对当前系统进行真实的压力测试，得到当前系统每个接口真实的响应时间和并发数，就可以看到哪些接口存在性能问题，通过这个抓手，就可以让我们不断进行优化。

同时，我们需要注意一点，非功能性需求的指标不是越高越好，指标每提升一点，都是需要投入大量人力和资源的，都是需要成本投入的。就以性能为例，高的性能对系统架构、数据结构、算法、存储和网络等都有很高的要求，这都是成本。所以，指标要有明确的目标，这个目标要跟业务未来的发展匹配，既不要过度设计，造成资源浪费，也不要没有提前量，阻碍了业务的发展。具体这个度到底多少合适，就需要根据业务不同的发展阶段和目标来综合考虑。

最后，一个顶尖的工程师都不会敝帚自珍，心态都是开放的，三人行必有我师，只有不断吸取别人的经验，才能成就自己。所以，设计环节一定要进行一定范围的评审，评审就是让不同角色的人共同来看你的设计方案，从不同的维度给你提意见。甚至可以请业务需求方一起提意见，因为只有他们才知道业务未来可能变化的方向以及目标，知道了这些就可以提前做一些准备，让系统的设计更有灵活性。

总结一下，设计先于开发，设计既要满足业务需求，也要满足非功能性需求，既要有目标也得有抓手，要不断进行迭代和优化，才能不断精进。