47

从开发到设计(6.30)

 5 years ago
source link: http://blog.sina.com.cn/s/blog_493a84550102xj3x.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

在日常团队沟通中,经常会和开发人员谈到设计思维,如何从开发能力转变到具备基本的设计能力,今天基于这点做一些展开的说明。

在开发过程中应该有的几个关键意识

复用意识: 在软件设计中有一个重点就是复用,因此在你日常的编码过程中就需要有复用意识,你可以自己考虑下你平时编码过程中是否经常存在大量的粘贴拷贝动作,如果是的话那就是复用意识很差。即使一个最简单的字符转换,我们也要有复用的意识,从最简单的公共方法和函数,到可复用的组件和类。尽量去减少你程序里面的大量重复代码。

抽象意识: 抽象意识是你平时在代码编码中另外一个关键意识,即能否从不同的东西中找到共性的内容,抽象出共性的基础类或接口,抽象意识一方面是增加了你代码的可扩展性,这也是最基本的设计模式中谈到的意识。你做好了抽象,你会发现你代码更加容易扩展,你程序里面大量难懂的if ese语句就越少。同时抽象意识是复用的进一步深化,很多东西经过抽象你会发现共性出来了,可以做复用出来了。

流程化意识: 举个例子来说你准备明天去海边度假,那么你的第一思路是做好计划,出行准备,前往目的地,海边度假,返回。而不是第一先去想到去加油,再想到海边要游泳。我们做任何事情最先想的就是分几个阶段,分几个步骤来做,而不是先想到具体的一个操作。写代码也是一样,想清楚究竟分几个关键步骤来实现,而不是一开始就去想某个细节操作,一个功能实现,你是一下就体现出1000行代码?还是5个操作方法步骤段,每段200行代码容易读?你有流程化意识,反倒设计里面去就是用例实现,活动图或序列图,你没有这个意识,那么你简单的序列图也画不好。

当你拿到一个复杂功能的时候,你在想什么?

设计,和你建造房子画的设计图一个道理,房子还没有建好,但是应该如何建,张什么样子就清楚了。再回来说我们生产一个东西,我们就先画好产品的设计图或结构图,但是这个不足以我们把产品生产如来,我们出来设计产品结构和组成外,我们还得先讲清楚产品如何生产,而这个对应到生产过程中的工艺流程。

所以回到软件开发里面,任何一个设计就是包括两个方面的内容,第一个就是最终交付的功能的结构,底层的对象和模型是如何的?其次就是基于底层对象模型如何最终形成完成的产品功能?第1个对应到我们的逻辑模型,数据库设计等;而第2个对应到我们的用例分析和实现,或者类似活动图,状态图,序列图等动态实现等。

那么,当我们拿到一个复杂的业务功能的时候,我们基本的思路究竟应该是如何的?

首先通过完整的业务需求分析,找到具体的业务用例(业务功能点),把业务功能点本身的业务,流程描述清楚。在这个描述和定义过程中,先找到核心的业务对象,从业务对象,从业务对象识别出具体的数据对象,从数据对象抽象具体的对象类,或者定义具体的数据库表对象。简单来说就是,你要先通过业务的分析把关键的对象识别出来,这些对象最终再转成你底层的数据库设计,逻辑层的核心对象或实体类。

其次你就需要考虑底层的对象或模型如何协同和交互,最终实现你需要的业务功能,对于一个最简单的表单增删改查,你会发现这个过程很简单,就是录入数据存储到数据库,或者从从数据库查询出数据展现到界面表格里面,再复杂点的可能涉及到主从或多层表结构而已。

那么这理解究竟是哪里复杂了?或者说复杂的业务功能究竟是哪里复杂了?这里并不是底层数据库表结构和关联关系复杂了多少,而是处理数据入库,查询数据出库的逻辑变复杂了。正是由于这个原因,你在分析任何一个业务功能实现的时候,不仅仅搞清楚简单的表单数据流,更加重要的是识别和抽象出关键的业务规则和逻辑。

这一点如何做?你需要先考虑的就是要有一个分层思维,即界面和前端实现和底层逻辑分层开,不是1对1绑定的,在拆分开后你就会考虑你的逻辑层应该如何规划类,有哪些实体类,有哪些专门的处理业务逻辑的类,有哪些进行业务逻辑组合的类等等问题。

理解了这点,任何一个复杂的前端操作,本质就变成了:N个DAO操作+N个逻辑方法操作的集成。理解到这里,你会发现和我文章里面大量提到的SOA服务组装和编排思路完全一样,只是这个组装和编排不是通过服务设计器完成的,而是通过你的类似组合类或Facade类来完成的而已。

高级开发和设计,从技术流到问题域驱动

在日常接触中,我们经常会遇到一些开发人员,一说到主流的redis, spring cloud, rabbitmq等等都用过,都玩过,也感觉用的比较熟,但是在我们定义里面仍然是高级开发。是否具备设计重点仍然是前面讲的真正面对业务需求和功能时候的抽象能力,同时将问题域转换为最合适的对象和模型的能力。而对于上面各种主流开源技术仅仅是我们解决问题的工具。

我们开发一个系统,比如我们选择了spring cloud来做微服务架构,拿首先要回答的就是面对当前业务域和问题,为什么要采用spring cloud架构,还是你认为当前大家都用这个架构所以我们也要用。其次,前面一篇文章我也讲到过,你懂了spring cloud和各个组件的用法仅仅是熟悉了一种工具和技术平台,你要真正能将业务需求拆分为合适的微服务模块,识别和定义关键接口服务,抽象出共性组件,包括针对不同的非功能性需求,选择最合适的缓存,消息中间件等各种组件来解决问题,才是最关键的设计能力。

软件领域,一个好的设计一定是最合适+兼具扩展的设计,而不是采用最先进技术的设计。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK