框架模块设计经验总结-阿里云开发者社区

开发者社区> 云计算> 正文
登录阅读全文

框架模块设计经验总结

简介:

  三个月没写日志了,比较懒散……下半年准备做OEA 的 B/S 版本,比较复杂,需要从架构设计开始认真入手。正好今天到了部门反思的时间,今天先把原来的一些设计经验总结一下,以方便将来回顾。

    直入主题,这篇日志主要用于总结一些框架级别的模块设计经验。

 

总述


 

    一个大型的框架,必然由多个较独立的子系统/子模块构成。这些子模块如何交互,之间的接口如何定义,这是框架的架构设计的问题。而今天我主要要总结一下,针对其中的某一个子模块,应该如何进行设计。(例如,在 OEA 中有这些相对独立的模块:分布式框架、实体框架、界面生成框架、命令框架、产品线框架、分布式缓存框架、报表模块……)

    我在对一个模块进行设计时,大致经过以下流程:预设计阶段、逻辑设计阶段、设计评审、设计调整阶段、设计实现阶段、模块整合阶段。在一次单独的设计中,并不是必须要经过以上每一个阶段。例如,当模块比较简单时,就不需要设计评审、设计调整等阶段了。以下我逐一描述。

 

 

预设计阶段


 

    设计开始之前,我们需要为设计做很多工作。其主要的目标是收集并整理模块的需求,力求结构化地描述需求。这些需求主要包括:场景需求、质量属性要求、环境约束。这个过程对于之后的设计过程相当重要,原因也很明显,不再赘述。

    场景需求包括:框架用户对模块的功能性需求、70%场景、20%场景、10%场景、API 需求。

    质量属性:参考ISO 9126。这里要分析出关键质量属性。

    环境约束:技术约束、系统环境等。比较常见的是对原有系统的兼容性。

    根据模块的复杂度不同,这个阶段的时间长短可能会有很大区别。例如,界面生成框架在 OEA 框架中是核心模块,在它的 2.0 版本的设计之前,我们平时会不断地收集前一版本的缺点及不足,做整理并使这些杂乱的需求结构化,这个工作“非正式”地做了一年,这些时间都可以算是在预设计阶段中。

    最后的交付物自然是:《模块需求规格说明书》。当然,文档这东西,主要用于沟通、传授。可以看情况而定,不一定有这个必要。但是,如果后面有正式的评审会议,这个文档最好还是准备一个正式的。

 

 

逻辑设计阶段


    关键点:场景驱动设计、质量属性验证设计、环境约束验证设计。前者做加法,后两者做减法。

    设计师的经验越丰富,在这个阶段成功的机会也就越大。要满足一套关键质量属性,如果你之前没有遇到过类似问题的话,可能你觉得你的设计能实现,但是最后的事实往往不一定正确。而且设计不象数学那么严格,更象是艺术,艺术靠什么,灵感!所以这个阶段中,不同的设计师很可能会有不同的设计稿。(当然,如果这个模块比较简单的话,很可能设计就不会有什么区别了,毕竟,现有的软件设计的模式是很多的。)

    逻辑设计的方法主要还是画图。其中主要还是依据一些通用设计的原则进行设计。

    画什么?主要是 UML 中的两类图:静态结构图(包图、类图);动态结构图(序列图)。

    顺带说一句,很多设计人员可能会坐在电脑旁边直接拿 EA 等工具画图。但是我个人比较喜欢的方式是:

  1. 先用纸笔来画一些手稿。
    这个方式主要是比较方便,任何地点都可以画,例如开一些不重要的会议的时候,就可以随手画画。而且最后看着许多有用的手稿,感觉还是很有成就感的,跟画家似的~哈哈。
  2. 随时想、随时画:
    我觉得,一些复杂的设计不是简简单单就能想出来的,特别是我觉得自己的智商只是处于常人智商的范围中,要想出一些卓越的设计,不可能只是坐在办公室的那一点点时间。(我记得我曾在梦中想出了一些醒着的时候想不出来的东西……)
  3. 汇总成正式设计稿。

    交付物:UML 图!这是必须的!

    这个阶段中,主要考虑质量属性及关键需求。

    要提升该阶段的能力,个人再次推荐几本著名的书籍:《Pattern of Enterprise Application Architecture》,《Microsoft Application Architecture Guide》,《Enterprise Solution Patterns Using Microsoft .NET》。

 

 

设计评审


    召开设计评审会议的原因:

  1. 人无完人,个人的想法很可能有问题。
  2. 听取更有经验的人的指点。
  3. 团队协作、团队沟通。
  4. 听取模块使用者的建议。

    所以,如果不是十万火急,都建议召开评审会议!

    我主持过的评审会议,曾经出现了许多的问题,大家可以看看我当时的反思:《反思 - 组内设计评审会议》,不要出现和我一样的错误。

 

 

设计调整阶段


    没啥,看评审会议的结论。要么做些小的调整,要么大改动,甚至重新设计。如果改动较大,别忘了最后再召开一次评审会议。

 

 

设计实现阶段


    这个阶段包含了设计的代码验证阶段。

    可能由于公司的组织结构不同,这个阶段并不一定由设计师自己去完成。但是我建议不要完全由他人完成,设计就象是自己的孩子一样,辛苦辛苦把他生下来,你让别人来把它抚养大,不觉得奇怪吗?如果你觉得你要设计的东西太多,没时间完成,我觉得你还是少做一些,做好一些会更好。

    建议实战能力弱甚至没有实战能力的设计人员不要再做设计了,先好好在底层磨炼磨炼吧。设计师从程序员成长而来,架构师从设计师成长而来,这才是务实的做法!

    这个阶段考验的是设计人员的代码实现能力,团队协作能力。代码的实现能力往往真正能看出一个人的设计能力。软件设计原则大家都会说,但是,要真正把这些原则应用到代码实现中,却需要时间的不断磨炼。如果开发组里能有几个为技术痴迷的人,那是最好不过的了。

    实现相对于设计稿,可以有一些更多的灵活性,并不一定要100%符合设计稿,这是因为代码实现本身就是一种微观的设计。但是必须要求80%以上是要符合设计稿的。如果实现过程中,不得已有过多的部分不符合当初的设计稿。请:召开讨论会议!重新画图描述当前设计!总结反思!

    值得一说的是,实现阶段需要着重对使用场景进行 721 分析,设计良好的 API 以应对这些场景,并配以相应的单元检测。关于框架设计中的场景驱动设计,大家可以看这篇文章推荐的书籍:《Framework Design Guidelines 2nd Edition》

 

 

模块整合阶段


    其实这个阶段中的工作在上一阶段中需要准备好,也就是说,在进行编码时,需要不断考虑所设计的代码能否在大的环境中运行。所设计的接口是否能和当前系统正确的衔接上。如果之前的代码没有考虑足够,在这一整合阶段中,可能会发生一些集成的问题。不过这种情况我遇到的比较少,这里就不展开了。

    这阶段完成后,最好能配上集成测试。(不过我目前都没有做过。)

 

 

演进模块的考虑点 


    在整个框架的架构设计完成之后,其中所涉及到的模块分两类:一类是在架构设计时已经考虑到并明确定义的模块;另一类是架构初始设计时并没有考虑到,但是随着系统逐渐演进,发现必须被添加进来的模块,我简称其为“演进模块”。两种模块的设计有许多相同之处,相对而言,设计演进模块时,相对要需要考虑更多的东西。

    针对演进模块,在预设计阶段,约束中需要重点写明历史系统对当前模块的兼容性约束。在设计阶段,需要分析当前系统,从中找到突破口。

    兼容性是很麻烦的一种约束,为了满足这种约束,常常会使简单的设计变得复杂。最后的代码也很可能写得不符合规范。在以后的新版本中,如果做出不再兼容这些历史代码的决定时,这些兼容性设计需要被删除。

 

 

设计失败的常见原因 


 

  1. 预设计阶段工作做得不充足。
    未收集场景、早早地进入了逻辑设计阶段、甚至直接开始编码,导致最终设计了不需要的部分,或者根本满足不了需求。
  2. 过份自信,未召开评审会议。
  3. 设计经验不足。(逻辑设计要求经验、灵感)
    提升方案:多把现有系统画出来。架构模式、设计模式都熟了吗?平时有没有花非工作的时间多设计些东西?书看太少了?
  4. 编码能力不强。(代码实现要求实战家。)
    提升方案:天天写些无聊的代码?非工作时间有多少花在代码上?书看太多了?
  5. 逻辑设计、代码实现分两波人做。

 

总结


 

    这篇文章是基于目前我的设计经验总结而成,将来可能会不断更新……

    同时,希望和园友们交流设计经验。更加希望平台开发人员能和我一起交流平台级别的开发。

    可以短信我,交换QQ和EMail。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

其他文章