设计先于开发

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

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

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

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

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

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

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

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

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

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

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

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

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

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

推荐阅读更多精彩内容