🧖🏻 👹 ✌🏾 我们将架构重构出售给客户或开发人员的问题是什么 😻 📐 😭

架构或设计重构始终是项目中的一个痛苦问题。重构的好处对我们的技术专家来说是显而易见的，但是客户通常很难出售和证实这种想法。主要原因是我们的技术专家不知道如何与企业交流。

主要问题是技术人员与赚钱的人之间的沟通。尽管他们尝试解决相同的问题，但他们会说不同的语言。

本文是英文原版的翻译：体系结构重构和设计重构如何出售客户端。如果您有不说俄语的同事，他们可以在我的仓库里阅读原文。

重构的好处对所有技术专业人员来说都是显而易见的，但是通常我们无法将这种想法传达给企业。为什么会这样？我们跳过了一些次要但非常重要的业务步骤。

我们将整个过程分为6个简单但必要的步骤：

确定问题的原因。
确定需要进行哪些更改。
决定的理由
制定重构计划
创建路线图
提出你的决定

找到问题的原因

作为技术专家，我们对这一步骤非常熟悉。用真实的例子考虑它。

几乎每次提交后，构建都会崩溃。

发生这种情况的原因有几个：

应用程序组件紧密相关并且相互依赖
应用程序组件没有适当的隔离
缺乏单元测试
缺乏SDLC流程和CI / CD

再举一个例子。应用程序部署需要很长时间，并且还会观察到性能问题。

主要原因可能是：

整体应用程序增长很快，对于一个应用程序来说已经变得太大了
该应用程序很大，并且消耗大量RAM和处理器功能。
该应用程序很复杂，编写得不好

确定需要进行哪些更改。

下一步要复杂一些，但对于高级+开发人员来说仍然很熟悉且不复杂。我们都是优秀的技术专家，并且始终知道需要改进的地方。而此时，我们犯了一个错误，并用“让我们去做”这句话来吸引客户。

但是我们是聪明的建筑师，我们将逐步遵循6步的计划。

基于带有整体应用程序的先前示例，解决方案显而易见。将大型，复杂的应用程序分解为较小的独立模块。这些是面向服务或微服务体系结构的第一步。

决定的理由

我们将这一步骤分为两个阶段：技术和业务证明。

技术原理在我们看来是合乎逻辑的。将整体拆分为较小的服务，结果是：

更多不同的组件
构建问题不会那么频繁
小型服务消耗更少的RAM和处理器功率，因此-更好的性能
单独的服务可以更快地部署并且彼此独立

从业务角度来看，证明合理性是技术专家经常忘记的非常重要的一步。您必须记住什么对业务很重要。没错- 是钱。

简而言之：如果重构对业务没有好处-这样做是没有意义的。

根据我们的示例，您可以为客户提供以下好处：

新功能将更快开发
由于较低的错误修复成本和满意的应用程序用户，应用程序的质量将更好，这也将对业务产生积极影响
降低开发和部署成本
更容易找到愿意与该项目合作的有上进心和有经验的专业人员。

重构计划

该计划应清晰详细。每次迭代都应清楚描述，所有架构和设计变更都应记录在案。

创建计划时，您必须回答以下问题：

此迭代的目的是什么？
此迭代的技术和商业价值是什么？
如何缩短迭代时间？

路线图

非常重要的一步。如果您真的想向企业销售重构，请花一些时间来做。

每个经理和商人都想知道两个问题的答案：

多少钱？
这需要多长时间？

尝试将重构分解为小的迭代。每次迭代都应带来技术和业务价值。在没有任何中间结果的情况下，要出售多年的重构并花费数百万美元是非常困难的。

每次迭代都应包含有关所需时间和专家数量的信息。这些信息将帮助经理回答两个基本问题。

在每次迭代之前和之后重构项目指标。这将帮助您显示此迭代带来的技术和业务价值。

我提出我的决定

在做出决定之前，请与您的直属经理联系。侧视图始终是好的，特别是如果是商业侧视图。也许您的经理有更多的背景信息，并且可以帮助您根据业务的期望更改计划。

您需要知道如何回答经典问题。

通常，当您提出架构重构时，企业可能会提出要求。为什么我们需要重构？去年我们在建筑上花了足够的钱，现在又遇到了问题。

这个经典问题有一个经典答案。这种架构解决方案一年前就不错，但是业务在不断发展和变化，架构也必须随之变化。

提示号码2。不要让客户感到恐慌。提供紧急信息，而不是灾难信息。假设您有六个月的重构时间，但今天就需要启动它。

终于。在提出您的决定时，请尝试教育人们，而不要怪罪。请记住，当责备他人时，您会遇到他们的抵抗。您应该寻找解决问题的方法，而不是罪魁祸首。

最后

重构是昂贵的并且很难卖给企业
架构重构不仅是技术问题，还是需要卖给企业
记住重构对您的业务的好处。
出售小型重构总是比较容易，但是通常比大型重构要容易得多

您可以在原始资源上找到有关体系结构和体系结构软技能的更多文章。

很好的重构给大家！

我们将架构重构出售给客户或开发人员的问题是什么

找到问题的原因

确定需要进行哪些更改。

决定的理由

重构计划

路线图

我提出我的决定

最后

More articles: