在这篇文章中，我将阐述在开发、支持应用程序以及在团队开发环境中架构决策的重要性。
.gif)
自助手术餐巾 Lucifer Gorgonzola 教授。鲁布·戈德堡
在我年轻的时候，我曾开发过一个出租车叫车应用程序。在该程序中，您可以选择上车点、下车点，计算行程成本、关税类型，甚至预订出租车。我在预发布的最后阶段收到了该应用程序；在添加了一些修复后，该应用程序已在 AppStore 中发布。到了那个阶段，整个团队就明白它的实现很差，没有使用设计模式，系统的所有组件都是紧密相连的，一般来说，可以把它写成一个大的连续类（上帝对象），一切都不会改变，所以阶级如何混淆了它们的责任界限，并且在它们的总体质量上，彼此重叠，形成死耦合。后来，管理层决定使用正确的架构从头开始编写应用程序，最终产品已实现并应用于数十个 B2B 客户。
但是，我会描述过去建筑中的一个奇怪的事件，我有时会在半夜惊醒一身冷汗，或者在中午突然想起并开始歇斯底里地大笑。问题是我第一次没能击中杆子上的家伙，这导致了大部分应用程序的失败，但首先是最重要的事情。
这是一个普通的工作日，其中一位客户收到了一项任务，需要稍微完善应用程序设计–将接送地址选择屏幕中心的图标向上移动几个像素很简单。好吧，在专业地估计了 10 分钟的任务后，我将图标向上提升了 20 像素，完全没有怀疑，我决定检查出租车订单。
什么？该应用不再显示订单按钮？这是怎么发生的？
我简直不敢相信自己的眼睛；在将图标提高 20 像素后，应用程序停止显示继续订购按钮。回滚更改后，我再次看到了按钮。这里出了点问题。在调试器中花了 20 分钟后，我有点厌倦了对重叠类的调用的意大利面条，但我发现*移动图像确实改变了应用程序的逻辑*
这一切都是关于中心的图标–一个人在一根杆子上，当移动卡片时，他跳起来以动画相机的运动，这个动画之后底部的按钮消失了。显然程序认为移动了20像素的人是在跳跃，所以根据其内部逻辑隐藏了确认按钮。
怎么会发生这种事？屏幕的 *状态 *是否真的取决于状态机的模式，而是在杆上的位置 *表示？
事实证明，每次绘制地图时，应用程序 *目视戳*在屏幕中间，检查那里有什么，如果杆子上有一个人，则说明地图移动动画已经结束，需要显示按钮。如果该人不在那里，则地图会移动，并且该按钮必须被隐藏。
在上面的例子中，一切都很好，首先，它是 Goldberg Machines（深奥的机器）的一个例子，其次，这是一个开发人员不愿意以某种方式与团队中其他开发人员交互的例子（尝试在没有我），第三，您可以根据 SOLID、模式（代码异味）、MVC 违规等列出所有问题。
尽量不要这样做，向各个可能的方向发展，帮助同事的工作。大家新年快乐）
链接
https://ru.wikipedia.org/wiki/Goldberg_Machine
https://ru.wikipedia.org/wiki/SOLID
https://refactoring.guru/ru/refactoring/smells
https://ru.wikipedia.org/wiki/Model -视图控制器
https://refactoring.guru/ru/design-patterns/state
