前一段时间，我观察到软件生产中应用技术的扭曲。 在深入研究细节（使用DDD）之后，我想向读者暗示，在猫头鹰管理的建议下，一个人不能履行工程师的职责。

最近一篇有关该行业赤裸裸的国王的引人注目的文章使我意识到，我仍然想表达我对自己想成为什么样的程序员以及我想看到的周围事物的理解-理解他们的工作背景，他们的角色以及应遵循的方法的工程师。 在削减的基础上，我邀请读者与我一起思考我们在做什么，以及这对开发人员活动的限制。

关于矛盾的原因

我将从远处开始-从十八世纪开始。 生产的发展和社会化，再加上竞争，一次又一次地刺激生产者实现生产现代化和自动化。 蒸汽机，提花织机，输送机，生产线和机器人-所有这些改进都发挥了经济作用 -具有竞争优势，这是使劳动力更加社会化（即生产链统一）的前提。 结果，生产在扩大，他们可以计划其开发和自动化，以获取更大的利润。

当然，任何企业总是有替代盈利方法的。 例如，雇用廉价的劳动力，有效的管理人员，他们将能够降低这些工人的三层皮肤。 但是，如果您像我一样相信人类不应该停滞不前，而要朝着前进的方向前进，那么您将同意我的观点，即这不是适合我们的选择。 是的，所有这些没有卖方的商店都非常害怕，因为无人机越来越多地交付货物，人工智能已经准备好替换驾驶员，等等。 经济学家对成本约为零的行业的出现感到恐惧。 但是，工程师，设计师，发明家，建筑师以及科学家们仍然必须做他们的工作-通过提高产品质量来降低生产成本-这是我们的社会经济任务。

为了不谈论过高的事情，我建议立即进行我们的活动。 对于企业而言，始终可以选择-将10个单位的10个人放在一个简单的工作上，或者25个单位的4个人将这项工作自动化，然后进行服务。 您对业务需求和工程需求的复杂性的清晰理解可以帮助您选择一条密集的发展道路。 对于客户而言，选择这样的路径意味着什么？

我们一天的一部分为自己工作，一天的一部分为雇主或客户工作。 我将用以下价值公式来表达这一点：

在哪里

c是固定资本 ，即 允许其进行活动的组织工具（计算机，软件等）。
v-员工工资。
m是拥有生产者的名义利润。

在软件开发方面，存在细微差别-如果软件是不断发展的业务的服务部分，那么您必须直接做一些与解决业务问题无关的工作。 感觉与众不同-“ 为了将来的工作，花在工作上的钱花在了几个技能水平较低的人身上”。 如果将其转换为公式，则表示我们正在努力支持不变资本c ，我们必须从某人的工资v ，利润m或商品成本W上花钱。 应该更详细地考虑。

因此，例如，如果您打算设计整体的体系结构并将其分解为微服务，但是您的客户对此没有直接需求，那么复杂的工程技术将使他付出什么呢？

• m-客户可能会放弃其利润。 这项投资的名称，即 控制更大利润的风险。 在这种情况下，必须识别风险。 如果您决定学习如何为他人的金钱制造巨大的复合物-这是不可控制的风险。 例如，作为回顾的一部分，另一件事是进行一个小实验，评估结果并进一步前进。

  
  

• W-客户可以提高其产品和服务的价格。 垄断企业很可能负担得起增加成本的费用，而且很可能这样做。 但是最有可能的是，客户总是被市场环境所震撼。

  
  

• v-您可以放弃别人的薪水，这里有多种选择。
  1）你会牺牲你的。 您将处理或制作一个对您有帮助的开源项目。
  2）您可以自动化他人的作品，这将使更少的人使用它。

  
  

  不幸的是，像我这样的天真人选择选项1。 但是，如果您在2中获得成功，那么您正在定性地改变生产链：他不仅需要工作，还需要越来越多的人来创建和正确修改流程。

  
  

团队的问题在于它没有决定要做什么。 但这可能导致争论，而业务将不会受到实质性问题的影响-代码的美感，新框架，时尚技术-这与金钱无关。 技术复杂性和业务需求的投资之间存在联系。 一个应该对应于第二个。

需求对抗

软件是一个复杂的解决方案，它是两个辩证矛盾之间的平衡：业务需求和体系结构。 在评估设计特定系统的复杂性时，错过因其性质而反对的各方的论点可能非常简单。 无论您在项目中的角色是什么： 产品负责人或团队 ，了解上下文，面临的任务很重要。

• 业务部门（PO，SH）希望工作，以便在其上花费最少的资源。 不幸的是，提出这个职位非常简单，因为它不仅影响了我们的生活，而且影响了IT民俗-猫头鹰是有效的管理者，这是最引人注目的例子。
• 执行者（团队）需要执行这样的一组工作，以确保解决解决业务问题的体系结构的关键方面，而又不增加技术负担，理想情况下，还需要用于更快解决问题的工具。 业务团队是软件的供应商，而架构是可供其使用的不变资本。

为了找到共同点，我建议在每个新项目之前向客户询问以下问题：

• 我们到底为客户做什么，预期收益是什么？
• 此解决方案的适用频率。
• 更改/扩展要求的可能性。
• 与其他系统/服务/上下文有联系吗？

业务和体系结构方面的需求数量必须成比例，否则提出和解决的任务类别将不成比例，并且如果需求从一侧或另一侧增长，则解决方案可能会延迟或重组。 换句话说，为了使客户能够更好地解决他们的问题，我们还必须拥有适当的手段来解决开发问题。 即 气焊和大锤，没人会为宇航员制造火箭。

因此，如果任务很小 ，并且客户需要用最少的资源来解决它，如果任务不重复且没有与大型系统连接，那么TransactionSript解决方案，智能客户端和所有反模式都是可以接受的。 现实一点-存在此类问题，必须以同样的方式解决这些问题，有时很快就可以解决（但我们不要忘记用技术上的债务来标记）。 但只有在这种情况下，才不会被管道中的贫血模型和其他一半措施所迷惑。

可以在现有系统的基础上解决与现有系统相关的任务 ，对内部流程进行最少的分析，如果不扩展任务或不期望更改需求，则可以使用TableModule，Shared数据库等解决方案。

重大的业务需求可能会对架构产生重大的需求（例如，提高可用性，授权，容错，性能）。 反过来，架构可以提供解决新问题的机会（这主要与过渡到更复杂的架构模板和避免特定情况有关）。

在会议上，开发人员经常问演讲者： 如何说服我们的雇主他们需要花时间在某些事情上（测试，架构，文档等）？ 对于高端任务，可能别无选择。 原因是产品，服务和组织的生命周期。

技术周期决定（同时限制）发展-为了进入下一阶段的发展，有必要超越当前技术过程的限制。 即 扩展您的做法，尝试一些新的东西，建立受控的实验。

逐渐地，随着复杂平台解决方案的数量超过一定数量，它将转变为质的增长。 负有技术债务成本的体系结构可能成为对更复杂任务的投资，从而否认了最初的目的。

敏捷，CI，DDD等 让您突破流程的界限。 这些知识和方法论领域可通过多种方式帮助评估任务的复杂性，从而建立团队合作关系。 正确地将这些东西视为整体 ，是许多人做出很多贡献的机会，以便确切地获得所需的结果！

从需求平衡到工作平衡

在谈论软件生命周期时，时尚的教练和敏捷培训师不会想起著名的I. Adizes图。

里面的所有东西都很漂亮，但是都是单面的。 因此，模型的主观性不能反映内部组织过程。 许多团队同意业务，他们将花多少时间在技术债务和体系结构的各个方面。 我对这个主题- 技术周期 （OTC）的轴向您提供我的想法。

横坐标轴被视为业务功能的复杂性。 纵轴是建筑工作的复杂性。 所谓复杂性，是指老套的故事点。 延迟此图上功能的性能，您可以看到您对所发布的软件对后续更改的适应性。

• 图表相对于OTC的最后一点越靠右，产品越早有用，针对复杂任务开发的难度就越大。
• 图表相对于OTC的最后一点的左侧，您被平台所吸引的更多，并且有在截止日期前不提供有效软件的风险。
• 因此，值得坚持统一发展，即 沿轴运动。

在上图中，我关于实现商机X和架构Y所花费的时间的想法是这样的，其中Z轴反映了产品的实用性。

结论

如果业务任务需要复杂的体系结构，那么它将出现，反之亦然，体系结构可以成为解决复杂问题的驱动力，然而，这些问题必须具有先决条件-流程优化的可能性。 当客户有许多使用当前工具难以解决的复杂任务时，有可能可以借助质变来解决它们。 为了获得质的变化，必须顺序累积某些变化。 例如，为了切换到微服务，通常将整体组件始终划分为有限的上下文和集合，并且始终实现CI。 反之亦然，例如，当您必须向旧版代码中添加功能并为此进行顺序重构时。

复杂的架构工作-您的贡献可以帮助企业提高利润和竞争力。 同时，在设计和实现中避免折衷和妥协的方法变得重要，这有利于快速而短暂的收益。 今天，您将提出一个关键绩效指标，而明天，由于产品问题累积，您将无法按时完成新功能。

我建议在Cyril Skrygan Platform（IDE）wars 的报告中着眼于调优与业务之间的联系 。