框架模块设计经验总结

    三个月没写日志了,比较懒散……下半年准备做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。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据的力量

干货|互联网运营数据分析必须掌握的十个经典方法

3928
来自专栏PPV课数据科学社区

大数据可视化、实时性分析的工具——Datawatch

编者注:互联网后时代,我们谈的最多的不是电脑,而是基于互联网产生的伟大的互联网公司,比如谷歌、微软、百度、阿里巴巴等;移动互联网后时代,我们谈的更多的不是手机,...

56410
来自专栏灯塔大数据

干货|互联网运营数据分析的十大经典方法,朴实却能解决问题

导读 眼花缭乱的东西很多,真正派上用场的,却不见得是那些看起来炫酷的。很多方法朴实无华,却解决大量的问题。 下面十个方法都是我这么多年做互联网运营分析时一定会...

2825
来自专栏Java学习网

程序员获取新编程技能的5个技巧学习

程序员获取新编程技能的5个技巧学习 “你是怎么学会所有这些框架和语言的?”,最近在黑客马拉松上一个朋友问我。 “其实,很简单,只要用你想学的东西去创建一个合...

25210
来自专栏FreeBuf

聊聊身份欺诈和窃取那些事

很多人都认为“个人隐私”不过是一纸空谈而已,引用老炮儿中六爷的一句被删台词:“我活那么大,我TM都不知道自己还有隐私?” ? 目前社交媒体如此发达,而社交平台上...

2139
来自专栏IT大咖说

天天写业务代码,如何成为技术大牛!

不管是开发、测试、运维,每个技术人员心理多多少少都有一个成为技术大牛的梦,毕竟“梦想总是要有的,万一实现了呢”!正是对技术梦的追求,促使我们不断地努力和提升自己...

1333
来自专栏CSDN技术头条

如何在三年内快速成长为一名技术专家

作者 | 清英 文章来源GitChat,CSDN独家合作发布,查看交流实录:http://gitbook.cn/books/59b69dc608f7233e6...

1866
来自专栏大数据文摘

聊聊身份欺诈和窃取那些事

1362
来自专栏达摩兵的技术空间

所谓“前端能力不足”

随着前端越来越多的被提上日程,用户对产品的体验度要求越来越高,产品除了实用的特性还必须满足方便用,美观,交互好,人性化等一系列的操作,谁的产品先做到这些,就能获...

954
来自专栏熊二哥

项目管理深入理解04--时间管理

进入比较重要的时间管理一章,重点是对WBS,工作单元,活动,资源,时间这一条线索的理解,熬夜加班到4点,继续俺的学习了,正好等等联调数据的状态,加油,熊二。 ...

2346

扫码关注云+社区

领取腾讯云代金券