4种过程模式
在本文中我们对这 4种过程模式做
个小结并讨论4者间关系以及体现在模式中敏捷思路方法论特色
通过这章描述大家能够对前面内容有更进步了解4种模式
着重点 我把源自需求、团队(Team)设计、简单设计、迭代设计这4种过程模式归类为架构设计
第层次这4种模式能够确定架构设计过程框架这里需要对框架含义进行澄清:架构设计框架并不是说你要严格按照文中介绍内容来进行架构设计在文章开始我们就指出模式能够激发研究因此这框架是需要结合实际进行改造实际我们在这个部分中介绍比较偏向于原则我们花了很大时间来讨论原则来龙去脉而原则度则要大家自己去把握为什么我们不讨论原则度呢？这里有两个原因个是软件Software开发团队(Team)各有特色很难定义出个通用度第 2个原因是我水平不够实战经验也不够丰富前面提到
4种模式其实是从 4个侧面讨论了架构设计中思路方法问题源自需求提供了架构设计基础在软件Software过程中架构设计是承接于需求分析如果没有良好需求分析活动支持再好架构设计也没有用因此我们把这模式放在首位做为架构设计目标有了确定
目标还需有组织保证这也就是第 2种模式――团队(Team)设计由来敏捷思路方法提倡优秀沟通因此团队(Team)设计是必要且有效而团队(Team)设计另个意图是保证架构设计下游活动得以顺利进行例如详细设计、编码、测试等由于开发团队(Team)中人大都加入了架构设计因此最大程度减小了区别活动间信息损耗和沟通效率低下问题如果说源自需求模式是起承上作用那么团队(Team)设计模式则是扮演了启下角色在软件Software设计
过程中沟通往往扮演着非常重要角色从团队(Team)设计开始几种模式所要解决都是沟通问题团队(Team)设计对沟通贡献在于它能够把设计意图以最小代价传播到开发团队(Team)每个角落这样设计和下游活动间由于沟通不畅产生问题就能够得到缓解般而言设计到编码会经历个信息损失过程编码人员无法正确理解设计人员意图设计人员却往往无法考虑到些编码细节虽然我们可以通过共通设计符号来提高沟通质量例如UML但是实战证明只要能够保证畅通沟通即便没有优秀开发思路方法项目成功概率依然很高因此对于单个项目来说最关键问题还是在于沟通只要组织得当团队(Team)设计是个值得应用模式当然配合以UML为代表建模语言更能够提高沟通效果在设计中
我们发现当设计信息转换为编码信息需要定时间这个时间包括设计组织时间设计被理解时间如果设计比较复杂或者说设计文档比较复杂编码人员花在理解上时间就会大大增加因此权衡后结果是相对于详细设计介绍说明书而言简单设计介绍说明书再配合定程度面对面沟通能够起到更好效果"简单要比复杂有效"这就是简单设计模式基本思路同样
简单思路还会用在软件Software开发各个方面例如文档、设计、流程坚持简单原则并不断加以改进是降低软件Software开发成本种很有效做法在有了以上
思路的后我们还需要面对两个现实问题需求变化将会导致设计不稳定而需求复杂性又会导致简单架构设计困难为了解决这个问题我们引入了迭代思路方法将问题分割为多个子问题(把个复杂问题分解为多个较简单子问题是计算机领域最常见处理思路方法)这样问题范围和难度都大大降低了而更关键是由于对用户需求理解不充分或用户表达需求有错导致设计风险被降到最低点迭代和前面几个模式都有关系需求和迭代
源自需求模式是架构设计中
起手式没有这模式支持架构设计只能是空中楼阁其实源自需求模式严格意义上并不能算是敏捷思路方法论特色而应该算是软件Software开发天然特性不幸是就是这么个基本原则却没能够引起开发者足够重视敏捷思路方法论中把需求摆在
个非常重要位置我们把源自需求模式作为架构设计第个模式主要目是承接架构设计上游工作――需求需求决定架构因此我们在经典瀑布模型中可以看到需求到设计严格分界线但是在实际开发中按照瀑布模型理论往往会遇到很多问题所以我们尝试着把需求和(架构)设计的间界限打破形成个重叠地带从而提高软件Software开发速度因此我们在源自需求模型中指出架构设计是紧随着需求开始需求对软件Software开发最具影响就是需求
不稳定性我们都非常清楚软件Software开发曲线越到软件Software开发后期修改软件Software成本越高因此在软件Software开发上游需求变动将会对软件Software开发下游产生天翻地覆影响为了协调这矛盾软工理论提出了螺旋开发模型这就是我们在迭代开发模式中讨论理论基础把软件Software开发过程分为多个迭代周期每次迭代周期最后都将生成个可交付软件Software用户在每次迭代结束后可以试用软件Software提出下步需求或是改变原先需求通过这样方式把客户、开发商风险降到个可以接受水平上 组合使用模式(2)
请注意迭代
前提:需求易变性因此对于那些需求容易发生变化项目我们就可以使用迭代式开发过程虽然我们会付出些额外成本(刚开始这个成本会比较大但可以用较长迭代周期来降低这种成本)但是风险减小了而对于需求比较固定项目是不是有必要使用迭代思路方法就要看具体环境了因此我们是根据实际情况选用开发思路方法而不是
先进或是流行原因实际上
由于现代社会特性大部分项目都是可以采用迭代思路方法因此我们选择就变成了了迭代周期应该要多长迭代周期在理论上应该是越短越好但是并没有个绝对数值时间跨度般从几周到几个月般来说迭代周期会受到几个原因影响:各模块
关联程度在软件Software开发中我们有时候很难把些模块分离开来要开发模块A就需要模块B而模块B又需要模块C各模块关联程度越高迭代周期越长当然也相应解决思路方法我们可以在各模块功能中选取出些关键点作为里程碑以里程碑作为迭代完成点人员技能、经验
平均程度团队(Team)中成员开发能力、开发经验良莠不齐这也是造成迭代周期延长个原因能力低、经验少开发人员会拖后每次迭代时间针对这种情况做好统筹规划就显得非常重要可以通过两次迭代找出队伍中瓶颈人员安排相应对策工具
缺乏迭代周期越短就意味着build、发布次数越多客户也就有更多机会来修改需求这要求有相关工具来帮助开发人员控制软件Software最重要工具是回归测试工具每次迭代都需要增加新功能或是对原先功能进行改动这就有可能引入新bug如果没有回归测试开发人员就需要花费时间重新测试原先功能计划、控制
能力迭代周期越短所需要计划、控制能力就越强短时间内计划制定和实施需要高度细分这就要求开发团队(Team)管理者对开发能力、工作量、任务分配有很强认识才能做好这项工作不过迭代周期越短同样开发时间迭代次数就越多而团队(Team)调整、改进计划控制机会就越多因此后期迭代般都能够做到比较精确控制而这样做法要比问题堆积到软件Software交付日才爆发出来要好多没有突然落后软件Software只有每天都在落后软件Software简单和迭代
简单和迭代关系是双向
在现实设计我们很难界定出简单设计
程度怎样架构设计才算是简单？按照我们在简单设计模式中讨论刚好满足目前需求架构设计就算是简单设计但是从另外个方面考虑需求易变性限制我们做出简单设计我们不能够肯定目前需求将来会发生什么样变化因此为了克服对未知恐惧我们花了很大力气设计些灵活、能够适应变化架构这是源自需求模式对简单设计模式影响源自需求和迭代设计
关系讨论建议我们把需求分为多个迭代周期来实现那么相应架构设计也被分在多个迭代周期中这样思路方法可以降低架构设计复杂程度设计人员不需要考虑软件Software全部需求而只需要考虑当前迭代周期需求复杂性降低将会有助于架构设计简单化从而达到简单设计系列好处(参见简单设计)我们从迭代设计中
最后个例子可以清楚看到迭代设计是如何把复杂需求给简单化把握迭代设计有助于我们避免过分设计毛病这是个技术人员经常犯毛病我所在团队(Team)很多时候也无法避免例如在很多项目中我们都会花费大量时间来设计数据库到业务实体映射诸如此类技术问题对开发人员吸引程度是不言而喻但是必须看到这种设计会导致开发成本大幅度上升更为糟糕是除非有丰富经验这种类型设计给开发工作带来价值往往无法超过其成本因此
我们需要学会权衡利弊是否有必要投入大量资源来开发其实并没有那么有用功能因此迭代设计和简单设计结合有助于我们摆脱过度设计困扰把精力集中在真正重要功能的上此外
简单设计并不等同于较少付出简单设计往往需要对现实世界抽象回忆我们在简单设计中讨论测量模式例子它看似简单但实现起来却需要大量业务知识、很强设计能力因此做到简单是
员不断追寻目标的在很多
思路方法论中般并不过分注意代码重复问题要么是不关注要么认为适当代码重复是允许而XP却把代码重复视为良好代码大敌"只要存在重复代码就介绍说明代码仍有Refactoring可能"这种观点看起来非常绝对这可能也正是其名字中Extreme来历(英文中Extreme属于语气非常重个单词)从实战角度上来看追求不重复代码虽然很难做到但是其过程却可以有效提高开发团队(Team)代码写作质量它逼迫着你在每次迭代重对代码进行改进不能有丝毫怠惰而这种迭代特性促进了简单实现团队(Team)和简单
我们在简单设计中提过简单设计需要全面
设计师除此的外它还需要团队(Team)配合简单意味着区别活动间交付工件简单化也就是说类似于需求介绍说明书、设计文档的类东西都将会比较简单正如此我们很难想象个地理上分布在区别地点开发团队(Team)或个超过50人大团队(Team)能够利用这种简单文档完成开发任务因此
简单设计是需要团队(Team)组织结构来保证简单设计要求团队(Team)相互沟通能够快速进行架构设计完成后架构设计思路传达给所有编码人员速度要块同样编码中发现问题回馈给设计者设计者经过改进的后再传达给收到影响编码人员速度也要快象这样高效率传播我们可以称的为"Hot Channel"为了保证"Hot Channel"
高沟通效率最好组织单位是开发人员在3到6人的间并处于同间工作室中这样结构可以保证讯息交互速度达到最高不需要付出额外沟通成本也不需要过于复杂版本控制工具或权限分配根据我经验个共享式小型版本控制工具、网络共享、再加上个简单网络数据库就能够解决大部分问题了在理论上
我们说只要分配得当大型团队(Team)同样可以组织为金字塔式子团队(Team)以提高大型团队(Team)工作效率但是实际中随着团队(Team)人数增加任务正确分配难度也随的加大沟通信息上传下达效率开始下降子团队(Team)间隔阂开始出现各种原因累加导致敏捷思路方法并不定适合于大型团队(Team)因此我们讨论敏捷思路方法都将受到团队(Team)特性限制模式
源头 如果你对XP有
定了解话那么你可能会感觉到我们讨论模式中应用了XP实战确实如此XP中有很多优秀实战如果组织得当话这些微小实战将会组合成为套了不起开发思路方法不过目前软件Software开发混乱现状阻止了先进软件Software思路方法应用对个身体虚弱病人施以补药只会适得其反因此在前面讨论模式中我们应用了些容易应用、效果明显实战思路方法在实战中适当应用这些思路方法并不需要额外投入却能够有很好效果同时还会为你团队(Team)打下个良好基础架构愿景(1)
从这
篇开始我们将会进入另个区别主题和前面所讨论模式专注于组织、过程、思路方法区别以后介绍模式更偏重于设计但是过程、思路方法影子依然在我们讨论中隐约可见架构愿景是
个很简单模式在软件Software开发中所占时间也很短但是这并不意味着架构愿景不重要相反它会是设计过程不可或缺环Context
在单次
迭代开始阶段我们已经收集好了单次迭代需求Problem
架构和分析设计是密不可分
有时候很难说得清楚架构定义但架构应该能够描述软件Software整体架构包括了软件Software各个方面但是每个设计细节总是需要单独考虑这时候就会出现设计细节的间、以及设计细节和架构的间不致架构设计
各个部分的间设计冲突是很容易发生发生概率及频率和团队(Team)规模成正比、和沟通频度及效果成反比在很多次项目开发过程中我们发现了多处相同功能代码原因是代码作者并不知道别人已经实现了这个功能了这可能只是浪费了点精力可如果区别模块间设计冲突导致了软件Software无法正常运行时候我们就需要坐下来好好审视究竟发生了什么Solution
我们需要建立
个架构愿景架构愿景应该能够提供软件Software全局视图包括所有重要部分定义了各个部分责任和的间关系而且还定义了软件Software设计需要满足原则而这个架构愿景设计应该是满足源自需求模式也就是说部分划分和部分设计都是根据需求而进行同时架构愿景应该要能够满足架构其它各种特点例如简单、可扩展性、抽象性简单来说我们把架构愿景当作是个mini架构设计由于我们是在单次
迭代中讨论架构愿景因此从整体上考虑架构愿景是也是在不断变化这是很自然架构愿景代表了架构设计架构愿景演进代表了架构设计演进架构
愿景是相对于个范围来说在个特定软件Software功能范围的内谈架构愿景才有实际意义例如针对软件Software全局或某个子模块在这个特定范围中订立了架构愿景的后这个范围内所有设计原则将不能违背架构愿景这是非常重要是架构愿景最大用处有了这样保证我们就可以保证设计致性和有效性任何项设计加入都能够融入到原先架构中使得软件Software更加完善而不是更加危险当然
要做到这点并不是件容易事情特别需要指出是架构愿景模式仅仅是实现该目条道路并不是个充分条件如果在设计中愿景不能够贯彻其意志或是愿景制定本身就存在问题那么要想达到上述效果几乎是不可能事情此外该模式仅仅只是达到该目第步我们在接下去模式中会发现还需要很多方面配合架构愿景
层次 我们根据架构适用范围
区别把架构愿景分为几个类别讨论:软件Software全局
软件Software全局
架构是我们所最关心因此也会花费最多笔墨软件Software全局中
架构愿景般很难具体化到代码级别其实你会发现就算是具体化到了代码级别也会实际中存在问题导致代码没有太多价值因此为软件Software全局设置架构愿景可以以原则、或是模式名方式体现并用自然语言或伪代码描述例如可以为个系统规定 3层架构作为其愿景并指出 3层分类原则注意我们需要指出分类原则否则规定 3层架构并没有太大意义 3层架构随着实现平台区别、开发人员区别而有很大差异如果不能够规定个可操作规范标准那么愿景是没有意义在Java环境下我们可以这样说:"客户端采用前端浏览器界面
业务逻辑采用servlet配合JSP编写浏览器到服务器数据采用集中处理具体思路方法是在业务逻辑和前端浏览器的间采用Front Control模式接受前端浏览器传送过来数据并指派给相应业务逻辑处理数据合法性检验分为两个部分:和业务逻辑无关基本合法性验证在前端使用Java Script处理和业务逻辑相关合法性验证在业务逻辑层处理可以使用个集中servlet专门处理
情况"而在Windows环境下
我们知道 3层结构分界和Java中并不相同(有关这点下篇文章中将会有详细描述)我们可以在业务逻辑层或显示层直接操纵数据非常方便因此在Windows中架构愿景描述又不样另外在非面向对象环境中在分布式环境中在Lotus Notes环境中其架构描述都不样注意到
架构愿景制定是根据区别应用环境而变化这点我们在文章开始就强调过这里又出现了相同问题我们可以通过个简单例子来加深对这个问题理解在Java环境下特别是J2EE环境下面经典设计思路是把数据库张表视作个类表中每行都是这个类个具体例子表每个字段对应了类个变量类般支持Find思路方法来获取数据区别例子这是种很自然设计思路而且可以通过CMP等技术来简化设计繁琐步骤可是在Windows环境下相信没有多少人会这么做常用处理思路方法是使用记录集(RecordSet)方式也就是说针对组记录来进行操作而不是单个记录这些记录可以是跨表(使用SQL连接)也可以是单表由于Windows环境下大多数编程语言都能够支持记录集方式因此编写基于记录集方式是相当简单当然我们也可以采用J2EE平台编程方式但是会导致编程量激增同时也难以达到预计效果这种平台差别导致了架构愿景差别此外
我们注意到我们对架构描述其实还是不够仔细这是非常正常随着开发深入我们会不断完善架构描述例如我们可以写出Front Controll类框架写出主要几个Servlet以及他们的间关系这个时候使用UML类图会是个不错选择实际上我非常推崇在架构设计中大量使用类图不过在实际运作中每个软件Software团队(Team)大多数都有自己熟悉架构设计思路使用何种工具并不是主要问题 架构愿景(2)
我们从源自需求模式中
学习到架构设计是来自于需求而应用于软件Software全局架构则来自于最重要需求还记得我们在那个模式中提到网上宠物店例子吗？系统采用了MVC模式sun官方文档开始介绍说明了为什么采用MVC模式MVC模式解决了什么问题然后开始分析MVC模式几个组成部分:Model、View、和Controll其实MVC中每个部分在真正代码中大都代表了个子系统但是在目前我们就非常清楚系统大致上会是个什么样子虽然这时候它还十分朦胧不要视图在全局
架构愿景中就制定出非常细致规划更不要视图生成大量实际代码你架构愿景还没有稳定(我们在其后稳定化模式中将会讨论稳定问题)还没有获得大家同意也没有经过证明因此从整个开发周期来看全局架构愿景是随着迭代周期进行不断发展、修改、完善我们如何确定全局架构愿景工作
完成？般来说你架构设计团队(Team)取得了致意见就可以结束了如果问题域是团队(Team)所熟悉两个小时就能够解决问题接下来设计团队(Team)把架构愿景传播到整个开发团队(Team)大家形成致认识区别意见将会被反馈会来并在本次迭代周期(如果时间比较紧迫)或下次迭代周期中(如果时间比较宽松)考虑
最新评论