网站开发课题开发背景,wordpress二级分类列表,那几家是做失物招领的网站,旅游做的视频网站前言
MVP 和 MVA 的概念不仅适用于新应用程序#xff1b;它们提供了一种新颖的方式来审视对遗留系统的范围变更#xff0c;以防止过快地承担过多的变化 - 参见图1。MVA 可以帮助组织评估和更新其技术标准#xff0c;通过展示新技术如何真正对支持 MVP 至关重要。创建 MVA 可…
前言
MVP 和 MVA 的概念不仅适用于新应用程序它们提供了一种新颖的方式来审视对遗留系统的范围变更以防止过快地承担过多的变化 - 参见图1。MVA 可以帮助组织评估和更新其技术标准通过展示新技术如何真正对支持 MVP 至关重要。创建 MVA 可以帮助团队评估哪些遗留系统的部分现在需要现代化哪些部分可以等待。遗留应用程序由于其经常是使命关键的需要特别关注可持续性。最后有必要记住今天的遗留应用程序在很多情况下曾经是闪亮而新颖的。将 MVA 视为每个新发布的一部分有助于保持应用程序的新鲜度。
遗留应用程序通常陷入慢车道老化和脆弱理解不足且几乎得不到支持基于老化技术它们往往是最后一个受益于诸如持续交付之类现代概念的应用程序。然而由于它们潜在的不稳定性实际上它们是最能从诸如最小可行产品MVP及其相关的最小可行架构MVA等概念中受益的应用程序。这是怎么可能的呢大多数遗留应用程序相对来说是巨石的很难逐步发布。一旦你意识到每个发布都是价值实验其中发布要么提高了客户体验的价值要么没有你就会意识到每个发布即使是遗留应用程序的发布也可以从MVP的角度来考虑。每个发布实际上都是一个与您希望提供的附加价值相关的MVP。因此每个发布也都有一个MVA。MVP和MVA等概念为团队提供了对他们所测试的有关客户真正价值变化的假设的绝对必要性的极致关注。由于MVP概念最常与新产品相关联因此将现有应用程序的每个新版本视为最小可行增量可能更好即团队认为将产生客户体验价值改进的最小变化集。但由于“MVP”一词已经被广泛使用我们将继续使用它。正如我们在之前的文章中最小可行产品需要最小可行架构所指出的MVA是确保MVP满足其质量属性需求QARs所需的最小架构量。由于对我们而言架构主要是关于技术决策因此遗留应用程序发布的MVA代表了团队需要进行的最小应用程序更改集以确保发布支持其QARs。发布准备的MVP标准通常集中在发布是否能让团队测试其对客户期望结果的理解上MVP并不是“技术概念验证”。同样通过评估对遗留应用程序进行的更改是否能确保发布能够满足应用程序的QARs并且通过这样做能够可持续地满足客户需求可以确定MVA的发布准备情况。图1:MVP和MVA提供了一个以新的方式看待遗留系统的“视角”流程挑战任何发布的标准之一尤其是组织所依赖的应用程序是该应用程序已通过一组测试最好是自动化的验证发布候选版本是否满足其质量属性要求QARs。进行手动测试以评估QARs太繁琐且容易出错不足以保证可靠性。缺乏自动化测试来确定发布是否符合其功能要求和QARs是阻止组织以小批量交付价值的因素之一。 其他因素有时会阻止组织以小批量方式发布导致它们以相对较大、复杂的增量发布变更。这些因素包括
缺乏有效的构建、测试和发布自动化。当交付流程的重要部分是手动的时候手动步骤引入的延迟和错误会阻碍组织迅速行动。即使部分自动化团队之间的交接引入的延迟也会减慢速度。虽然这些问题的解决方案层出不穷但它们要求组织改变工作方式有时还要改变组织的结构。应用程序之间的紧密耦合。当应用程序共享数据或组件时对其中一个应用程序的更改可能需要重新发布另一个应用程序。具有紧密耦合的遗留应用程序的组织可能很难进行小的更改因为他们无法承担重新发布可能需要重新发布的所有应用程序的时间或精力。繁琐的发布批准流程。由于许多遗留应用程序在某种程度上已成为业务关键因此需要从可能并不真正了解与变更相关的技术问题的高级业务主管那里获得更改批准。当他们需要对更改的范围和风险感到满意时将更改转化为通用术语所需的时间和精力可能是相当可观的。监管限制。受监管行业的组织可能需要获得监管批准以发布新产品或者对现有产品进行重大改变。他们还需要向监管机构报告客户对这些产品的使用情况。他们很难利用MVP概念因为监管机构通常希望了解新产品或更改产品的各个方面。使用MVP的整个目的是通过真实的客户体验数据回答关键问题因此组织陷入了一种进退两难的境地他们无法发布产品来测试MVP但他们又无法完全定义新产品或更改的产品而没有经验。这些公司似乎注定要受到监管限制的困扰因为他们可能会过度投资于客户不需要的产品因为他们无法及早和逐步地测试想法。专业知识短缺或丧失。在某些情况下组织可能不再真正了解遗留应用程序的业务逻辑或应用程序所基于的技术。解决此问题的一种方法是逐步用更有效的现代解决方案替换仍然相关的遗留应用程序部分逐个解决客户结果。这样做组织可能会发现许多遗留应用程序不再相关或不再需要但要弄清楚这一点需要时间在短期内组织将面临一个更加碎片化的解决方案存在永远无法完全解决的风险因为其他挑战总是会出现。
除了监管限制外这些问题都可以解决但需要时间和共同努力。
偿还技术债务的困境
在有机会偿还债务时听起来好像是件好事对吧 有时组织会受到诱惑要做额外的技术工作现代化或减少他们的技术债务因为正如他们可能合理化的解释的那样我们无论如何都会在应用程序的那部分上工作所以我们应该趁着在那里的时候把事情处理好。虽然出于善意但这几乎总是一个不好的决定会导致不必要的成本和延迟因为一旦开始很难决定停下来。 这就是MVA概念发挥作用的地方它给了每个人一个决定哪些变化必须进行哪些变化不应该进行至少还不应该进行的方式。如果一个变化对于实现发布的所需客户结果是必要的那么它就是MVA的一部分否则就被排除在外。 有时一个团队可能会审视应用程序所需的变化并决定考虑到代码的状态进行完全重写是必要的。应用于遗留应用程序的MVA概念有助于通过质疑这一点来缓和即这些变化是否真的必要以产生所期望的客户结果的逐步改进。 应用程序可能确实已经过时无法扩展了但根据我们的经验“全面重写”几乎从未成功过我们从未见过甚至没有听说过这些项目中的一个真正交付了任何东西。如果你真的要重新设计不要重新编写现有系统相反从客户期望的结果出发寻找不同的交付方式。
可行性和发布范围
MVA对MVP有影响特别是对于遗留应用程序而言。MVA和MVP都包含一个重要的词可行性。如果在评估团队需要对应用程序进行的更改以实现MVP时他们确定以可持续的方式实现MVP成本太高那么就需要重新考虑并可能更改MVP。
利用MVA方法:使用QARs
最小可行架构MVA方法参见文章【最小可行产品需要最小可行架构】提供了一种决定现代化程度“足够好”的方式以便交付MVP。将MVA作为MVP交付工作的一部分来创建有助于评估技术可行性并为产品提供一个稳定的基础可以随着产品的发展而进行调整。透明地进行MVA架构决策有助于组织更好地理解为何会做出某些选择的原因从而帮助他们更好地决定如何将产品适应不断变化的市场条件和不断发展的客户需求。 QARs驱的决策需要做出的最重要的MVA架构决策可能是选择最少量的架构组件使MVP能够处理与产品/系统特性相关的QARs例如
并发性——与产品必须响应的同时用户数量、传感器和其他创建事件的设备数量有关。吞吐量——与产品必须在定义的时间段内处理的交易或数据量有关。延迟和响应性——与产品必须对事件作出响应的速度有关。可扩展性——与系统通过增加系统成本来处理增加的工作量的能力有关通常是近线性关系。持久性——与产品必须存储和检索的数据的吞吐量和结构或缺乏结构有关。通常包括有关不同种类数据存储技术的决策例如SQL数据库管理系统、NoSQL数据库管理系统等。安全性——与产品如何保护自己免受未经授权的使用或访问产品数据的影响有关实现机密性、完整性和可用性。监控——与产品如何被仪表化以便支持产品的人员可以了解产品何时开始无法满足QARs并防止关键系统问题有关。平台——与产品如何满足与系统资源约束相关的QARs例如内存、存储、事件信号等有关。例如实时和嵌入式产品如数字手表或自动制动系统与基于云的信息系统具有完全不同的约束条件。用户界面——与产品如何与用户进行通信的决策有关例如虚拟现实界面与二维图形用户界面具有完全不同的QARs而命令行界面则与二者具有完全不同的QARs。这些决策可能会影响上述其他QARs。图形用户界面、虚拟现实、命令行或其他类型的界面。
例如假设您计划构建一个移动应用程序以支持在新市场推出产品使用开源或商业框架来帮助您快速交付MVP同时为传统系统数据创建一个新界面。在这样做的过程中传统应用程序将不可避免地面临其设计未能处理的工作负载。这些增加的工作负载会导致传统系统失败吗额外的工作负载会威胁传统系统满足现有用户的QARs的能力吗移动应用程序会改变传统系统的QARs吗 不可避免地访问传统系统数据的新应用程序将通过改变工作负载、吞吐量、响应性和安全相关需求等方式改变传统系统的QARs。传统系统并非建立在满足新应用程序用户需求的基础上而在决定如何以及在何处修改传统系统时必须考虑到这些需求。在某些情况下无论付出多少工作传统系统都无法满足新的QARs在这种情况下传统系统将不得不被替换以便支持新的应用程序。 经验主义是评估这些问题的强大工具新移动应用程序的每个发布至少都将为评估传统系统架构是否能够满足对其提出的新需求提供机会。开发团队很可能需要修改传统应用程序以满足新的QARs。将传统应用程序的变化视为移动应用程序MVP发布的一部分将有助于团队决定要承担多少变化以实现移动应用程序MVP发布的目标。 QARs是诊断传统系统潜在改进领域的非常有用的工具。专注于QARs可以帮助您将变化范围限制在目前仅需最小限度的内容以支持MVP。这有助于防止滑入到“全面重写”的泥潭这是昂贵的、耗时的、容易失败的而且通常对于MVP来说是不必要的。 限制新功能的范围抵制超出MVP范围的诱惑将此努力变成一个更大的项目包括MVP所不必要的“不错的”功能。领域驱动设计DDD是一种极其强大的软件开发方法对于确定需要实现的新功能范围以支持MVP并将其限制在确切所需的内容方面非常有效。 尝试解耦和简化系统组件。在与传统系统一起工作的挑战之一是它们缺乏模块化许多系统在编写时并没有鼓励模块化代码大多数代码重用都是通过“复制和粘贴”完成的。尽管重构所有这些冗余代码很诱人但要保持在支持MVP所需的范围内。当您确实需要重构或替换代码时确保新代码是模块化且可重用的。在某些情况下微服务和无服务器函数也很有效。在需要更改的应用程序中用对共享组件或服务的调用替换代码同时为可能有类似机会的其他应用程序做笔记。这样当其他团队必须修改其应用程序以使用类似服务时他们将有一些优势。 开始将新工作远离传统系统。除非在传统系统中实现新功能显着简单且更可持续否则应使用现代技术如基于云的服务开发与MVP相关的新业务功能。如果新功能必须从旧程序启动那么为新工作编写一个新的组件或服务然后只需从旧代码中调用它。随着时间的推移上述解耦工作以及将新代码移至现代技术将减少您需要担心的传统代码量。使用诸如“植绳者模式”或“分支抽象”模式等模式以及在适用时实现网关来路由请求到新的MVA组件可能对此迁移有所帮助。请记住所有方法和工具都有局限性。例如使用“植绳者模式”适用于从单个应用程序迁移明确定义的功能块但如果您需要替换影响数十个应用程序的破损基础设施则可能不是正确的方法。 开始识别“死代码”并找机会消除它。使用静态和动态代码分析工具找出传统系统中不再使用的部分范围包括MVA。将死代码作为消除目标但不要立即着手 - 要注意范围蔓延。这可以延伸到报告 - 旧系统产生大量报告其中一些或许多可能对任何人都不再有用业务可能已经发生了变化而系统没有变化。识别不再有用的代码可以帮助团队更轻松地看到该代码是否会影响MVA。部署的代码越少其余代码越可靠关键系统资源的使用越轻。即使团队决定不消除代码他们也应该识别死代码的潜在消除机会以帮助其他团队做出未来的决策。 组织技术标准延续了传统系统。组织技术标准对于防止不可支持的配置和基础设施技术组合的增加非常有用但如果保留时间过长它们可能会让组织根深蒂固于过去无法适应未来。使用MVA概念可以帮助组织了解新技术是否真正需要以使团队能够交付特定的MVP。有了MVA提供的证明组织可以决定MVP是否真正战略并因此需要改变技术标准。 组织技术标准延续了传统系统。组织技术标准对于防止不可支持的配置和基础设施技术组合的增加非常有用但如果保留时间过长它们可能会让组织根深蒂固于过去无法适应未来。使用MVA概念可以帮助组织了解新技术是否真正需要以使团队能够交付特定的MVP。有了MVA提供的证明组织可以决定MVP是否真正战略并因此需要改变技术标准。 你应该将MVA数据存储在哪里。关键的MVA决策之一是选择一个数据存储库来存储与MVP相关的数据。这些数据很可能已经存在于传统的数据存储库中而且在大多数情况下还需要捕获和存储额外的数据。这些数据可以整合到传统的数据存储库中或者可以实现一个新的、更现代化的数据库管理系统DBMS来存储新数据。第一种方法简化了数据聚合和报告但会扩展可能被淘汰的技术的使用范围——例如IMS/DB。如果只需要添加少量现有的MVA传统数据来支持MVP则可能是合适的选择。第二种方法限制了传统数据存储库的使用但复杂化了数据聚合如果需要添加大量现有的MVA传统数据则应考虑该方法。第二种方法的一个变体是将现有的MVA传统数据迁移到新的DBMS中。然而迁移数据比迁移功能更加困难因为这些数据可能被MVA范围之外的多个传统应用程序使用。尝试这样做可能会导致超出MVA范围的工作。
总结
传统系统有点像一个古老的城市仍然是一个繁荣的大都市它们的新旧混合使得很难跟上所需的修复工作更别提对其进行大规模的翻新以适应快速变化的需求了。但是找到一种持续适应传统系统的方式对于将企业发展到一个不断变化的世界中至关重要。 MVP和MVA的概念不仅适用于新应用程序它们提供了一种新颖的方法来审视对传统系统的变更范围以防止过快地进行过多的变更。事实上每一个新应用程序在其第一个重大发布之后都会成为一种“传统应用程序”因此在应用程序不断发展的过程中限制变更范围的方式很重要。 MVA方法可以帮助组织通过展示新技术如何真正支持MVP来评估和修改其技术标准。它使您能够通过真实数据来挑战技术标准而不仅仅是凭借偏好和观点。 创建MVA的过程可以帮助团队评估现在需要现代化的传统系统的哪些部分以及哪些部分可以等待。许多组织已经在失败的“全面重写”现代化项目上花费了巨额资金而事实上这些项目事后证明是不必要的。识别现在必须现代化的部分以及哪些部分可以等待是有用的因为这使得组织更好地了解了他们的技术债务同时为他们提供了一个非常需要的过滤器以防止不必要的工作。 由于传统应用程序通常是至关重要的因此它们需要特别关注可持续性。事实上害怕使传统应用程序变得不稳定阻止了许多组织对它们进行重要和必要的渐进性改进使它们变得更加脆弱和充满风险。专注于可持续性QAR包括培养团队发展应用程序所需的技能有助于使应用程序随着时间的推移变得更加强大。 最后值得记住的是今天的“传统”应用程序在很多情况下在不久前还是全新的。这些不仅仅是40年前编写的应用程序它们也是仅仅10年前甚至更近期编写的应用程序。一旦一个应用程序不再持续更新它就开始腐化。将MVA作为每个新版本的一部分考虑有助于保持应用程序的新鲜度。
