现代开发人员，第2部分：设计

设计系统的体系结构被认为是软件开发中最重要的部分之一，因此，通常是由团队中经验最丰富的人员（例如架构师和高级开发人员）来完成的。

架构设计师需要解决几个关键问题：系统将拥有哪些组件，如何拆分它们以及它们之间如何通信？ 将使用哪些存储或Web服务器？ 是否需要更多支持软件，例如缓存或队列？

让我们看一下传统设计的完成方式，存在的问题以及如何解决这些问题以将其发展为最终成为现代设计的事物。

设计过程

在过去的几十年中，该过程发生了很大的变化，这主要是因为对软件的需求增加了，最低可接受质量也变得更高，并且软件的运行规模现在已经不同于25年前。

当前，系统可以拥有数千万的活动用户，而几十年前，大多数软件被编写为一次只能由一个用户使用，并且没有在线连接。

请记住，设计应该是符合要求标准的最简单的版本。 当今软件的所有复杂性（例如，具有包含数百个物理机的数据库的分布式软件，所有这些物理机都可以相互通信）都是出于一个简单的原因：市场需要它。

添加不需要的东西来满足验收标准是软件设计中的最大问题。

在小镇上进行简单的鲜花递送服务。 实际上，不可能有数以百万计的活跃每周用户—毕竟，我们只能在一个只有几千人的小镇上运营。 设计具有分布式数据库的花店或添加缓存层可能很诱人，但是这样做过于刻板，并且可能超出预算。

现在，让我们在州/国家/地区拥有150家实体店的鲜花递送业务。 那是150个城市，其中有些很小，有些很大。 该公司可能具有集中式系统（只要城镇的管辖权相同）。

观众可能包括几百万个潜在客户。 对于这样一个可能的用户群，在负载平衡器后面添加一些DDos保护，缓存层和一些服务器是有意义的。

还有其他因素将决定设计，例如预期的服务时间。 每个因素的共同点是，将产生影响的因素与业务直接相关。

那么为什么人们有时会在架构设计中引入不必要的复杂性呢？ 一方面，每个开发人员都喜欢使用最新的流行语言，工具或库。 另一件事是，软件可以像MongoDB一样出售而不是出售。 最后，我们是人类，我们会犯错误。 无论您有多少经验，在设计系统时，您的首要任务都是以最低的复杂度满足所有要求。

传统设计

过去，设计相当简单，部分原因是大多数软件的用户群较小，部分原因是缺少许多选择。 但是，这并没有使这项工作变得微不足道。

平均而言，更新要比今天困难得多，因此过去的错误代价更高。 此外，由于当时工作方式的本质，大多数错误是在开发的后期才发现的， 而不是设计， 而是开发。

瀑布方法是当时的国王。 至关重要的是，一个阶段（如计划，分析，设计，开发，质量保证等）必须在下一个阶段开始之前100％完成。

但是，这种逻辑自从被证明存在缺陷。 瀑布方法的主要问题是反馈速度过慢。 如果在设计中引入了缺陷，通常只有在剩余分配时间的10％到15％时才发现它。 更糟糕的是，它已经被实施了，因此架构师和开发人员的时间将被浪费。

由于设计过程非常正式，因此通常会以统一建模语言图的形式生成许多工件，以解释系统中的所有实体，子系统和接口。

随着时间的流逝，人们开始注意到减少反馈所需的时间可以减少总的开发时间，从而减少了构建软件的成本。 因此，除了瀑布方法中涉及的其他主要问题之外，更喜欢采用短反馈循环的方法。

现代设计

如今，首选敏捷方法和流程框架（例如Scrum）。 尽管事实证明这不是灵丹妙药 ，但由于有很多问题要处理，这是对瀑布模型的改进。 游戏对软件设计有何不同？

不幸的是，对软件的需求从来都不是一成不变的。 他们不断变化。 事实是，在系统开始运行之前，没人知道系统的全部要求。 较短的反馈循环有助于尽早发现更多这些错误，并调整设计和体系结构以更好地解决这些问题。

从某种意义上说，第一个冲刺是示踪剂子弹，这是一个准系统的实现，有望捕获设计中的主要缺陷。 但是，极不可能所有错误都会被发现。

这意味着设计应该足够灵活以允许更改。 灵活性的代价是增加了复杂性，如上所述，设计的目标是以最小的复杂性满足所有要求。

我们正处在十字路口，通常，不清楚走哪条路。 选择灵活性还是简单性取决于经验，没有每次都能遵循的规则。

除了这种方法，实际的设计在过去的几十年中也发生了变化。 过去，所有开发都是在构建时一次完成而没有太多反馈的，因此，该软件通常是大块地构建的。 这种架构称为单片式。

如今，由于敏捷性，所有事情都是按时间顺序进行的，每一步都是按小块完成的，即，您有sprint，这是一到六周的时间，您在其中处理特定的事物，接收反馈，并且在应用反馈时，在下一部分开始。

这自然导致将软件分解为小块，每个小块都执行特定的操作。 这称为面向微服务的方法。

这种方法的“营销”将列出以这种方式开发软件的许多好处。 但是，之所以受欢迎，是因为由于该软件一次开发一个块（从一到六个星期），因此使用由许多相对较小的独立组件组成的体系结构是很自然的。

实际上，与单个应用程序相比，管理和监视许多小型服务往往更麻烦。 这并不是说面向微服务的设计很糟糕，但是它与很多人认为的灵丹妙药相去甚远。

设计趋势

尽管移动平台和网络是两个截然不同的世界，但它们的设计趋势有些相似。 在互联网泡沫破灭之后，perl和PHP被用于构建网站。 没有标准，没有框架，没有工具。 谈论任何一种生态系统为时尚早。 那么，接下来发生了什么？

每个人都开始为所有内容构建自定义框架。 不用说，大多数框架都是废话，其中99％的框架专门由创建它们的人使用。 但是其中一些为下一代框架以及我们今天拥有的最终技术生态系统铺平了道路。

开源和协作蓬勃发展，以至于它成为展示您的参与度的重要内容。 如今，许多公司都期望它。

如今，有无数种不同的体系结构，根据软件的具体情况，任何体系结构都可以使用。 不过，我看到的一种趋势是使用大量服务而不是托管自己的服务。 例如，如今您拥有诸如关系数据库即服务，电子邮件，队列，键值存储，缓存等服务。

使用服务而不是托管您自己的解决方案的优缺点不在本文讨论范围之内，但这可能会成为以后文章的主题。

在今年年初，我为一个教育应用程序提供咨询，该应用程序将用于学龄前儿童的研讨会。 我介绍了几种设计，而选择的一种是使用最多服务的一种。

在这种情况下，该项目的寿命预计为两到三年。 我们选择的服务具有关于数据恢复，备份和正常运行时间的严格服务级别协议。 正如我所提到的，该项目的预期寿命为三年，服务成本为几千美元，而且建造成本更低，速度更快。

从长远来看，如果进行更改，它将花费更多的钱，但是由于我们需要推出1.0版并每天进行命名，因此，这（似乎是）是一个不错的选择。

设计就是要找到平衡

设计的目标是以最小的复杂性满足所有业务需求。 尽管设计过程可能会更改和发展，但其最终目标仍然是相同的。

设计阶段的错误是不可避免的。 因此，反馈循环应尽可能短，以解决设计和体系结构问题，同时又不浪费团队其他成员的时间。

设计中的更改是不可避免的，这不仅是由于建筑师的错误造成的，而且还因为人们不确定自己需要什么。 因此，考虑到这一点，必须在低复杂性和灵活性之间保持平衡。

翻译自: https://www.javacodegeeks.com/2019/09/the-modern-developer-design.html