软件架构乱弹——问题域及其解决方法 - 第八基地

软件开发的家园,编程爱好者的天地.

现在是:北京时间 2016/4/14 上午11:50:51 星期四

设为首页  |  加入收藏  |  网站地图

软件架构乱弹——问题域及其解决方法
发布于:第八基地 来源:互联网 作者:天堂路上 时间:2011-10-12 点击:221
一、什么是架构

1.和架构相关的几个问题域

架构需要解决的非业务问题域包括如下:

A系统目标:系统性能,稳定性.

B.项目目标:开发成本,质量

C.项目过程:需求的不确定性和开发过程的团队协作性

不同的问题域,解决之道也不相同!而同一问题域的不同层次的要求,解决之道也不尽相同。

2.什么是架构

   架构到底是啥,愚以为下面的这段英文描述的很清楚。

That'slikeasking,whatisculture?Cultureisthewayyoudothingsinagroupofpeople.Architectureisthewayyoudothingsinasoftwareproduct.Youcouldarguebyanalogy,then,thatarchitectureistoasoftwareproductascultureistoateam.Itishowthatteamhasestablishedandchosenitsconventions,

Whichleadsusinevitablytothequestionof“goodness”?Howdoyouknowifanarchitectureisgood?Consideranarchitecturethatisn'tbuiltusingastrongdomainmodel,andinsteadreliesheavilyonstoredprocedures.ThatmightbeOK,oritmightnotbeOK.Youcouldhavedecidedthatpartofyourarchitectureistouseareallystrongdomainmodelandnotusestoredprocedures,right?Soanarchitectureissomereasonableregularityaboutthestructureofthesystem,thewaytheteamgoesaboutbuildingitssoftware,andhowthesoftwarerespondsandadaptstoitsownenvironment.Howwellthearchitecturerespondsandadapts,andhowwellitgoesthroughthatconstructionprocess,isameasureofwhetherthatarchitectureisanygood.

Thesystemarchitecturedetermineshowhardoreasyitistoimplementagivenfeature.Goodarchitecturesarethoseinwhichitisconsideredeasytocreatethefeaturesdesired.Inthatthewaytojudgewhetheranarchitectureisgoodiswhetherthearchitectureisgoodforthepurposestowhichitisapplied.

Thedefinitionofgoodnesshastoberelatedtofitnessforpurpose.Isthisglovegood?Idon'tknow.Whatareyoudoingwiththeglove?Areyouthrowingsnowballs,cookingbarbeques,orplayinggolf?There'sasetofchangesthataregoingtooccurtoasoftwaresystemovertime.Probablytheutilitarianormostusefuldefinitionofgoodnessistheanswertothisquestion:arethechangesthatwillkeepthissystemsuccessfulinthisdomaininthisproductlinerelativelyeasy?Iftheyare,thenit'sprobablyagoodarchitecture.

3.架构的背后

为了实现架构的目标涉及到以下三个方面:技术,组织和过程。这里举例说明。

1)      技术对开发效率和运行性能,以及组织和过程的影响。

案例A.映射的问题。公司产品的一个重要需求是根据客户输入,映射到PDF文件上。技术上整体实现需要四个步骤:在PDF文件上画好所有的数据域,通过读入一个XML映射文件,获得运行数据并生成FDF,合并FDF和PDF生成目标文件。后两步工作都由代码自动化了,因而实现的主要工作在于前两步。

在第一个实现版本里,XML映射文件的DTD太简单,致使一个xml文件至少在4000行左右,同时xml文件太verbose了。这样的结果直接导致运行系统在峰值时,由于XML消耗了大量内存,1G的内存根本吃不消;同时对XML解析执行使用了CPU的大量时间;导致开发人员需要做大量的工作,开发效率降低了,通常需要尽一周才能完成一个xml文件,员工都不愿意做;也导致开发过程的漫长,开发部门对于BA部门和ST部门的要求反应变的缓慢。

在第二个版本的实现中,重新实现了DTD,加入了大量的关键字同时也消除了verbose,大量的缩小了XML大小,从4000多行减低到900多行。不仅减低了内存使用,提高执行效率;也提高了开发效率,基本只要一天就可以完成一个映射文件。同时对BA部门和ST部门的反应也快了。

案例B:脚本的问题。产品在web层提供了脚本支持,出于方便开发的目的。但是没有对脚本的环境限制,脚本可以做系统程序的大部分工作。导致开发人员偷懒,在web层混入了大量业务逻辑代码。最终造成业务逻辑分散而不可控制。

2)      组织结构对技术,开发效率和应变能力的影响。

案例A.部门的分工问题。开发部门根据不同的职责,分成A,B和C等数个小组。大部分开发中互不相干。但也有时候,需要跨组的支持,比如B要实现某个需求,需要A在一定条件在记录一个或多个信息。因为每个开发人员各自负责一部分工作,导致跨组沟通的困难。同时由于整个开发部采取任务绩效,有时间压力,加上只是一个小的要求。于是在A人员的同意下,B人员直接在A代码中写入业务逻辑。每次都是这样的小改动,不断的发展后,代码开发变凌乱。

案例B.开发的历史问题,当某个开发人员写下的代码,有是问题的,接手开发人员由于文档不全以及没有测试用例,不愿意承担变化的代价,选择小修小补,这个小修小补有可能和有问题的代码混杂,导致更大的代码。

3)      过程对开发效率和应变能力,以及组织的影响

案例A.过程的问题。开发部门的上下游部门BA部门和ST部门的合作关系。ST部门的绩效考核,考核基于发现错误的数量,导致ST为了完成任务,提出一些非正常性要求。PM部门出于部门的方便通常提出一些实现难度比较大要求。开发部门本身又存在时间压力,导致一些需求的实现本应在低一层的代码中实现的,却在高层用蹩足的方式实现。

对我有帮助
(0)
0%
对我没帮助
(0)
0%
返回顶部
在线反馈
在线反馈