应用开发策略选择

日期:2016-4-12作者:Tom Nolle翻译:崔婧雯 来源:TechTarget中国 英文

【TechTarget中国原创】

每个软件架构师,开发经理和开发人员都很可能遇到过软件设计和开发中“自上之下vs.自下而上”的争论。正确的答案其实是,这里并没有单一的最佳方案。

应用是用自上而下和自下而上的两种方案之一来构建,每种方式的支持者和另一方的支持者一直争论不休。但是决定企业应该采取哪一种应用开发战略要求检视需求和资源,并且考虑到应用可能的变化,理解应用设计上这两种不同的方案以及各自减少风险的所需步骤。

模块化编程理念和企业架构都影响着软件开发,使其从上开始,从业务需求和预期收益入手。实际上,这意味着列出业务目标,基于映射到用户行为的功能划分,用通用的软件术语来描述业务目标,然后将这些功能进一步分解,匹配硬件和软件的需求。在过去的十年里,这已经被广泛接受成为应用程序设计的最佳方法。

自上而下和自下而上

自上而下应用设计和开发也更容易和企业以及将使用应用的用户相匹配。大家理解软件做什么以及怎么做,意味着他们从应用的功能驱动视图来理解应用。如果从这样的视角开始,就可以从业务部门收集方案使用性方面的需求,并且能够洞察出业务实践随时间的改动可能会如何影响到软件设计。

这样自上而下方案的问题在于,项目目标还包括使用某种特定技术或者资源集——特别是云——的时候会遇到问题。应用不会为云自动优化;他们必须特别设计来利用云的特定特性,同时避免花费过多。从上开始的话,架构师可能能够构造出一些和一开始的目标平台以及托管选项不是特别匹配的东西。自下而上的方案才能够确保托管以及资源的正确使用。

自下而上的应用开发战略更容易契合通过面向服务架构或者微服务的使用而开发的组件库。如果可以从已有软件组件组装出一个应用程序——或者其中的一大部分——那么就可以减轻开发负担和应用生命周期管理需求。自上而下方案在现有组件模型没有什么用时可以领导设计的方向。

方案之争

经验丰富的开发团队已经适应了自上而下vs自下而上的应用开发战略之争,但是有两种基础方案得到了广泛认可。一种着重考虑资源或者平台目标,认为这些和功能需求一样重要,另一种更像是“在中间会和”的方案。

很容易看出,如果需要为使用现有模块化模型而进行优化,或者为云计算做准备,这样的需要提升成为需求时,那么应用程序设计需要从一开始就考虑到这些需求,并且按需作出设计。但是,不是所有开发团队都能够轻松在设计的最高层混合功能和技术的需求。使用云技术如何和支持某种特定的功能行为相契合呢?如果无法回答这个问题,那么流行的做法是设置某个需求集的优先级高于另一个需求集。这样能够完成拥有有限功能的设计。

当基于资源,平台或者组件重用的目标,业务需求适合某个假定的应用模型时,“提升”模型能够工作得很好。比如,一个基本的Web前端软件模型,管理特定的系统-用户关系,链接到一系列解决企业功能需要的应用流程上,能够足够好地组织开发工作,确保重用需求可见,而不牺牲任何功能性。

“在中间会和”方案假定平台和组件创建一个能够抽象到一系列技术行为的工具包。比如,可用组件能够组装起来更新数据库或者完成报告。这些高层级的行为也能够关联到云特性上,比如水平扩展或者故障发生时的实例置换。虽然它们可能无法直接映射到新应用的功能性需求——或者它们可能对于项目而言并不需要——它们比基础技术需求更加功能化。架构师随后就能够基于这些行为组合出第二或者第三层设计。

基于行为,在中间会和的应用开发战略的问题是,如何向上反应行为感知性,而不会被底层问题占据。最佳方式是从底层开始组装有用的行为,然后将其暴露成工具给架构师,架构师从顶层开始功能性设计。该方案在有显式高层功能性需求时最有用,这些需求可能来自一个良好的EA模型。没有非常强有力的功能性需求,那么设计流程就很容易被自下而上的资源探求和组件战略所占据。

底线

自上而下的设计很好地将应用和业务目标契合在一起,并且优化用户体验的质量,但是他们可能创建出不是最优的组件化,并且限制了应用程序采纳新技术,比如云计算的能力。自下而上的设计优化资源和组件化能力,但是可能会偏离用户的体验质量。最后,最好选择契合你的最重要目标的方案,然后一步步确保能够兼顾到另一端。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

评论
查看更多评论

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

作者>更多

Tom Nolle
Tom Nolle

关于作者:Tom Nolle是CIMI公司的总裁,这家公司成立于1982年,是致力于电信和数据通信的战略顾问公司。Tom Nolle是IEEE、ACM、Telemanagement Forum和IPsphere Forum的一员,著作有关于Netwatcher方面的书籍。

SOA开发>更多

  • 故障注入注定要成为软件专业人士的必备技能

    尽管云改善了企业迅速发布高质量、高能力应用的能力,但专家警告说要小心这些应用会变得太复杂,难以进行人工测试。

  • 容器与微服务要“联姻” 你对它们够了解吗?

    在虚拟化和云计算领域,容器大概是发展最快、最广为令人兴奋的技术了,微服务则紧随其后。如果把这两大技术结合起来会碰撞出怎样的火花呢?

  • 事件驱动框架和SOA在空军的应用

    空军正在利用SOA来改善数据共享,并实时跟踪战机,美国空军机动司令部的Michael Marek解释了企业可从中学习的经验。

  • HTML5促进企业移动化服务走向极致

    在企业困扰于传统移动化方式过于复杂时, HTML5凭借其天然的跨平台特性,乘势而起并逐渐得到企业的关注。可是,由于HMTL5标准建立时间不长,展示性能及稳定性更是需要和浏览器有一个良好的兼容,除此之外企业更是缺乏实际应用经验,所以基于HTML5技术的企业级服务市场还处于一片初创状态。

相关推荐

  • 学习下一代软件和App编码的经验

    面对关键软件开发者人才短缺的情况时,新兴的一代软件开发者那里似乎还有一线希望。这些年轻的开发者对待应用代码的方式对于老一代软件专业人士来说也许能提供有价值的经验教训。

  • 细说软件架构师应该具备的十大特点

    如果有人问你,作为一个软件架构师需要哪些特质的话,你会怎么回答?从技术层面上讲,架构师的技术要求是首位的。除此之外在做人处事方面,更有魅力的架构师则更受欢迎。

  • 跟遗留代码打交道:干掉顽固漏洞的简单方式

    跟遗留代码打交道会是比较困难的,尤其是如果代码是由某位不知道名字的程序员用一种不熟悉的语言编写的话。

  • 应用开发的美学之道

    很多人说「会操作 Photoshop」等于「会美术设计」,但如何为应用开发做出好的美术设计,除了摸熟 Photoshop 以外,还需了解一下一下四个步骤。

技术手册>更多

  • 2010年SOA现状调查报告

    在2008-2009面临全球性的信贷危机时,SOA的应用依然屹立不倒。即便时下流行语已经被“云计算”所替代的情况下,SOA的运用也没有下降。TechTarget/Forrester Research所做的2010SOA现状调查表明……

  • SOA指导大数据分析管理手册

    近一年来,大数据的热潮席卷全球,我们无时无刻不在听着关于大数据的事情。大数据时代带来更理性、更可靠的决策,但究竟是什么魔力让大数据这一概念得到全球各国的普遍关注?如此巨大量的数据如何进行管理,分析,找到价值所在?SOA又能帮助大数据做一些什么?

  • 复杂事件处理CEP手册

    在金融服务和其他行业中,如何使那些重要且具有战略意义的业务信息以高速数据流的方式到达企业变得尤其重要,而复杂事件处理(CEP)就是这一过程的代名词。在复杂事件处理中,数据是不断变化的,而“操作”是“静态”的。复杂事件处理具备了分析高速数据流并鉴别重要事件的能力,虽然对这些事件的鉴别过程是复杂的,但结果却是无价的。复杂事件处理能够帮助企业及时全面地洞察市场变化,降低风险和提高决策效率。下面我们就来介绍一下复杂事件处理。

  • API开发与管理大作战

    2014将会是API管理方法新旧PK的一年,据Delyn Simons说,她领导了Mashery开发者的外展团队。应用编程接口(API)的主流化和私有化在新的一年也将掀起波澜,她在波士顿“Future Insights Ultimate Developer Event 2013”大会上预测说。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算