技术债务MVP模式

为了解释什么是技术债务(TD),为什么它对产品本身很重要,以及如何在其上应用MVP(设计)模式,让我们首先定义MVP代表什么并详细了解模式。

MVP代表什么?

在这种情况下,MVP并不代表“ 最有价值球员”,尽管可以得出篮球相似之处。 取而代之的是,MVP是“ 最低可行产品的缩写,“ Minimable Viable Product”最低可行产品 )是一种具有适当数量和功能的产品类型,可以使早期客户满意。 换句话说,该产品尚未完全开发,而是依赖于客户反馈来进行进一步开发。

想象拥有一家造船公司。 船或船的基本用途是帮助人们在水体上航行,而不是淹死。

只要您建造能为早期客户提供帮助的船只(出于本示例的真实性起见,假设他们是只想在浅水中捕鱼的渔民),您的产品便是最低限度的。

一方面,渔民可能想以深蓝色钓鱼,这就是为什么他们可能需要将其船升级为某些功能,以使他们感到更安全,航行更快。 他们可能会告诉您有关情况,然后您将进入产品开发的下一个阶段。

如果您做对了所有事情,那么您最好有一天开始建造油轮。

MVP类型

到目前为止,已经认识到几种MVP类型:

  • 解释器视频 —公司有时不制作产品,而是发布解释器视频,以了解有多少人有兴趣购买该产品。 其中最著名的例子是Dropbox解释器视频,其中Dropbox团队研究了其产品的所有功能,但并未真正对其进行完全开发。
  • 着陆页 —公司通常在开始使用产品并邀请潜在客户购买产品之前先制作着陆页,只有在人们如预期的那样感兴趣时才开始开发过程。
  • 绿野仙踪MVP-受机械土耳其人的启发,公司生产看似完美的产品,这些产品看似由AI驱动,可扩展等,但实际上是根据客户手动调整的。
  • 礼宾MVP —公司有时不手工生产解决人们问题的产品,而是手动地帮助人们解决当前的问题,而只是分析辅助过程,扩展规模并制造出提供解决方案的产品。
  • 零碎的MVP-简而言之,这种类型的MVP使用其他产品和工具中的各种零碎零件来创建新产品的基础。
  • 从客户那里筹集资金 -这是最流行的创业方式之一; 公司基本上向公众展示了他们的产品蓝图,并获得了众筹以开始进行设计。
  • 单功能MVP —此方法基于制作一个功能产品并在产品推出后添加其他功能。

如果您想知道哪种方法最适合您,请查看以下图片。

您每次想要实现的目标是,以最低的成本来实现最高的解决方案影响。

在继续讨论模式之前,让我们总结一下MVP是什么。

MVP实际上不是产品,而是一种产品开发技术,涉及寻找最方便的解决方案以尽快启动您的产品。

换句话说, MVP就是使用最基本的解决方案来解决问题

什么是(设计)模式?

软件工程中的设计模式是可重复使用的解决方案,用于解决在特定上下文中经常发生的某些问题。

换句话说,如果您有问题,并且知道可以帮助您解决问题的模式,则不必从头开始,也不必自己提出解决方案。 相反,您可以仅应用设计模式,这会使您的生活更加轻松。

设计模式可以是形式化的描述,也可以是模板,可以帮助程序员解决项目时遇到的问题。

当您查看它时,您周围到处都有模式,我们经常会使用一些模式来解决日常问题并克服反复出现的障碍,而无需考虑太多。

但是,让我们坚持软件工程。 在OOP中,模式可以是创建模式(例如原型),结构模式(例如代理)和行为模式(例如观察者)。 此外,还有并发设计模式可以处理多线程编程范例(例如,区块链)。

但是,模式始终是一件好事吗?

模式与反模式

模式不一定总是一件好事,因为许多IT专业人员会养成不良习惯,这些习惯会变成破坏性模式,有时甚至没有意识到。

而且,模式会随着时间而变化,特别是在IT行业中。 换句话说,解决当今问题的模式将来可能会成为反模式。

反模式示例

尽管术语“反模式”主要适用于代码,但我们始终可以将其与一些非技术示例联系起来。

我来自哪里,祭司过去常常去村庄参观,以便执行与村庄庆祝的宗教节日有关的神圣仪式(每个村庄庆祝一个不同的假日)。 祭司通常会在节日前在每个村庄住一两个晚上,人们对此已经习以为常。

但是,教堂设法获得了汽车,牧师立即开始拜访所有村庄,而无需停留几天。 突然,由于这种新型的运输方式,他以前的模式变得无效,这使得他在较短的时间内访问所有村庄变得更加方便。

换句话说,他本来可以保留以前的行为,但是这种技术无效,因为这项技术要求他采取一种更适合所有人的不同方法。

那么,什么是MVP(设计)模式?

现在我们知道了MVP代表什么以及设计模式是如何工作的,我们可以将两者组合成MVP设计模式。 为了清楚起见,让我们再次看一下设计模式的定义。

软件工程中的设计模式是可重复使用的解决方案,用于解决在特定上下文中经常发生的某些问题。

上面句子中的最后一个单词是context,在这种情况下,上下文是MVP开发。 简而言之,MVP设计模式将产品管理和软件工程相结合,以创建可尽快启动最低可行产品的模式。

扼杀模式

MVP设计模式的示例之一称为“扼杀器”模式。 下面的图片很好地总结了它。

本质上,我们得到了一个过时的代码,可以通过LoadBalancer与浏览器进行通信。 我们的任务是重构代码,而用户不会注意到我们正在处理的应用程序/站点中的任何异常情况。

通常,可以通过在一段时间内进行较小的更新,然后逐步引入完全更新的产品,而用户不会意识到情况已经改变的事实来完成此操作。

Facebook使用这种类型的模式,其中一个示例是Facebook Messenger,它曾经是该平台的一部分,直到它成为独立的应用程序为止,而您无需成为Facebook社区成员就可以使用。

什么是技术债务?

当人们听到债务一词时,他们通常对此没有积极的感觉。 实际上,在任何可能的情况下, 债务一词都会让人皱眉,除非有人偿还了他们欠您的债务。

但是,技术债务可能具有某些积极方面,这将在后面讨论。 首先,让我们尝试定义实际的技术债务。

技术债是一个概念,程序员使用它来表示当使用易于实现的代码而不是应用最佳解决方案时出现的额外工作。

用简单的英语来说,每当开发人员编写短视且最容易编写的代码,而不是编写包含将来可能出现的所有问题的代码时,他们就会产生技术负担。 这种债务是他们(或其他人)将来需要做的额外工作,以便重构代码并使之更适合任何可能的情况。

为什么会发生?

由于编码员无知或不可靠,可能造成技术债务,这是一种无意债务。

但是,由于编码人员没有足够的时间或资源来寻找最佳解决方案,因此有时会故意制作TD。 在某些情况下,人们意识到自己的未来产品注定要失败,所以他们故意编写错误的代码并故意创建TD。

Wikipedia提出了TD发生原因的开放式列表-随时添加建议:

  • 业务压力
  • 缺乏过程或理解
  • 缺乏文件
  • 并行开发
  • 缺乏与标准的一致性
  • 最后一刻规格变更
  • 技术领导能力差
  • 缺乏所有权
  • 延迟重构
  • 缺少知识

除了刻意或疏忽外,态度也可能是鲁ck或审慎的。 让我们在下面看一下马丁·福勒的TD象限。

对于MVP,如果目标是尽快发布,则TD可能是一件好事。 这也是制造TD并随后“还清”的有意方式之一。

“技术债务应保留给人们,如果人们已经做出了深思熟虑的决定,那就是采用长期而言不可持续的设计策略,但会产生短期收益,例如发布产品。”
—马丁·福勒

如何处理技术债务?

我们可以通过以下几种方式处理TD:

  • 亨里克·尼伯格的方式
  • 牺牲建筑
  • 技术债务模式

让我们检查每个。

Henrik Kniberg的解决方案

在Henrik Kniberg的文章“技术债务的优缺点(以及TDD如何提供帮助)”中,他研究了如何使用TD来改进您的代码,从而对TD的优缺点进行了明显区分。

TL; DR — Kniberg认为TD应该一直存在到一定程度,因为编写完美的代码几乎是不可能的。 我们应该养成将代码的等级从1到5评分的习惯。数字5表示我们有足够的空间来加快处理速度并创建一些TD。 但是,如果我们的代码率低于三,我们应该考虑偿还债务并改进我们的代码。

牺牲建筑

福勒对他的“几年时间”持乐观态度,因为我们生活在世界上,有些代码甚至都无法庆祝他们的第一个生日。

“……您现在可以编写的最好的代码通常是您将在几年后丢弃的代码。”

—马丁·福勒

因此,他建议我们在编写代码时应牢记这一想法,即我们将有一天要把它扔掉,或者,如果您愿意,则要牺牲掉它,因此得名。

Google之所以使用牺牲性架构,是因为它们设计的系统的需求是当前需求的10倍。 一旦需求超过系统的规模,Google的开发人员就会丢弃代码并开始从头开始编写所有内容。

我们可以利用技术债务制作(MVP)(设计)模式吗?

到目前为止,我们已经涵盖了以下四个主题:

  1. 什么是技术债务?
  2. 关于TD的想法和解决方案
  3. MVP基本原则
  4. MVP模式

现在,我们已经达到了知识范围的最后一个领域,让我们跨步进入未知领域,并结合从以上主题中收集的知识。

*击鼓*

技术债务MVP设计模式

工程师,抑制您的热情。 首先,非技术读者应该理解在解释技术债务MVP设计模式的过程中将要使用的几个术语。

传出和耦合

有时我们的代码段(函数,类,模块等)被依赖于它的其他代码段所使用,这种关系类型称为传入耦合(Ca)。

另一方面,我们的代码还依赖于其他一些代码,这种关系称为传出耦合(Ce)。

圈复杂度

本质上,您应该知道上面的函数可以根据输入以几种不同的方式执行。 但是,某些功能可以比其他功能执行更多的方式,因此具有更大的循环复杂性。

这样做的目的是使事情尽可能简单,并最大程度地减少代码中的循环复杂性。

技术债务设计模式

现在我们知道什么是循环复杂性,我们需要在代码中的每个函数中运行它,并确定每个类和模块中的复杂性级别。

这是了解首先需要重构哪些代码的一种方法。 但是,具有大量传入耦合(Ca)的类和模块需要首先使用,因为其他代码段依赖于它们。

在上图中(尼尔·福特(Neil Ford)和马克·理查兹(Mark Richards)获得了非常好的演讲/课程的功劳),我们可以看到列表中的第一个具有最高的Ca数。

但是,与其使用循环复杂性,不如使用Kniberg的评分系统以1到5的等级对类和函数进行评分? 我们可以使用一个插件(仅假设存在),该插件将覆盖所有类和费率模块,并确定依赖于该模块的其他模块的数量。

换句话说,最复杂且依赖它的模块数量最多的模块是我们必须偿还的技术债务的第一部分。

本质上,TD模式是Henrik Kniberg方法与传出耦合的结合。

由于最好通过模板来描述模式,因此以下是有关如何成功使用TD模式的简短分步模板。

  1. 问团队中的人们“我们对代码质量有何看法?”。 选择任何规模。 那就是您的技术债务(TD)。
  2. 您可以使用1-5,其中5是“技术债务零的美丽,很棒的代码”,而1是“堆满债务的废话”。
  3. 测量出射(Ce)和出射(Ca)耦合。
  4. 图TD和Ca彼此相邻。
  5. 从3.您最大和最相关的债务得出结论。
  6. 还清!