“该手册不会让我重构我的旧代码！”常见情况？太烦人了。大多数开发人员迟早都会遇到一个经理，他对改善已经准备好的东西完全不感兴趣。他们要么需要实施一些新的东西，要么立即扑灭大火，或者修复一些错误……通常，他们总会找到理由推迟正在运行的代码库的重构。
而且，即使您试图向他们解释使用简洁代码的好处，他们要么不理解，要么不希望理解。他们只考虑成本和时间，没有人关心质量。事实证明，您绝对无能为力，仍然在不断积累和积累技术债务。程序员为产品而工作，而产品-为不耐烦的用户请求而工作。没有人会为重构支付费用。情况看起来毫无希望。
面对这种情况，许多聪明的开发人员只需打包他们的东西就离开公司。很快，由于部门的人员流动，门不再关闭：有些请假，其他请假...
经理不是程序员
该问题的解决方案是与管理人员进行交流，以了解不良代码质量对业务的影响。最终，公司的活动旨在赚钱。到了 因此，管理层正在寻找削减成本和增加收入的最佳方法。这意味着，为了恢复他们眼中的重构，他们将不得不说自己的语言。
我碰巧同时担任技术主管和顾问，所以我在这项业务上有很多经验。让我们与您分享一些模板。
你可以给出五个论点
1）“重构将有助于减少软件功能每单位边际成本的波动性”，
这是JB Reinsberg在“软件开发的经济性”会议上的精彩演讲的正确引用。等等，别走！您在这里所说的一切，您都非常清楚，它是用抽象的，深刻的精神来表达的。
让我们按顺序进行：
- “重构将有助于减少...”-到目前为止，一切都很好
- “ ...波动...”-换句话说，不可预测
- “ ...边际成本...”-也就是说，生产另一个额外单元需要多少资源
- “…每单位软件功能”是一项具有业务价值的功能。万岁！商业价值正是我们所需要的。
所有五种论点都基于将一种语言翻译成另一种语言的相同总体思路，而在与远离IT领域的人们打交道时，我们经常会忽略这一观点。不要使用语，而要依靠经济学和商业学的概念-这就是全部秘密。这样可以更快地在您和管理层之间建立联系。
2）“在过去的一个月中，有63％的开发资源用于解决产品质量问题”
。在这里替换您的数字。重点是用定量数据备份消息。科技债务不禁会影响您的日常工作流程。你能证明这个吗？当然！
您可以查看以下一些指标：
- . ? ?
- -, , . , ? ?
- , . ? ?
向管理人员确切显示对他们而言不良的代码质量是什么。更好的是，找到一种将这些数字转换为货币价值的方法。
我曾经参加过验尸错误，如果完成了数据类型检查，这是可以避免的。该代码是用JavaScript编写的。当时，公司中存在关于是否切换到TypeScript的争论。
了解发生了什么情况的开发人员并不太懒惰以提出数据，并且能够评估该错误对业务造成的损害。事实证明，在它存在的几个月中，该漏洞从公司那里吸走了100万加元。百万！仅此一项就足以抵消切换到TypeScript的成本。
基于此，决定将在TypeScript中实现新服务，对于最重要的服务，应追溯检查数据类型。
3）“从技术角度来看，我们致力于提高产品质量。现在，我们需要偿还部分债务，以免上市时间增加。”
再次：我们使用对话者的语言。当您需要传达信息时，隐喻可能会非常有效：隐喻将陌生的概念与熟悉的概念联系起来，以供听众使用，从而有助于理解它们。 “信用”的概念是任何经理人都熟知的。 “技术债务”本身也是一个广为流传的隐喻。
或者说，假设一家公司是一家餐馆，而代码库则是其厨房区域。随着脏盘子的堆积，为越来越多的游客提供服务变得越来越困难。员工在烹饪之间需要有时间洗碗。
4）“如果您将10％的时间投入代码质量，则营业额将大大下降。”
到目前为止，我们已经讨论了代码质量差带来的明显后果。但是有一个容易被忽视的阴险之处：营业额。
如今的公司很难让开发人员，尤其是有才华的人才留在他们身上。如果这样的人不再享受工作，他将不难再获得一份新的报价，随便他们去哪里，远离永恒的混乱。为什么，也许您自己已经在寻找更好的东西了……
现在让我们问自己一个问题：公司要替换一位辞职的开发人员要花多少钱？需要找到新的专家，逐步完成招聘流程，并不断更新。这需要投资，需要时间，并且会使整个团队变慢。管理层绝对不希望每年都进行这种改组。因此，减少流动性可能是一个严肃的论点。制定消除技术债务的计划的事实将立即使整个团队的动力提高100。
5）“如果将20％的资源投入到重构中，FRT将减少一半，投资回报率将对开发人员的生产力产生积极影响”
FRT是响应时间，这是用户支持的重要指标。业务致力于确保客户对一切感到满意。
在这里，我们执行以下操作：
- 选择在技术支持中占重要地位的指标；
- 我们发现了一些经常出现的问题，需要开发人员进行干预。
- 我们提供了一项计划，通过消除根本原因来减少致电技术支持的次数。
- 如果解决了这类问题，开发人员将不太可能参与用户支持任务。也就是说，他们将比在重构上花费更多的时间，这意味着投资将得到回报-非常正的ROI。
最终，他们决定
没有人可以反对。我提供了五种论据来说服人们消除技术债务的重要性，但是现在我认为，在开始担任经理之前，还需要提供另外一条建议。
随身重构
重构不应被视为功能性工作的一个单独阶段。毕竟，您仍然无法预先预测将来将要实现的功能。这意味着您需要针对新的现实情况调整代码库。这也是创造非常重要的价值所需的工作的一部分-任何专业的开发人员都会证实这一点。
该规则甚至适用于具有旧版代码的数据库。好吧，好的，您绝对不会在明天之前将她带入神圣的状态。尝试在两者之间进行大规模重构也是一个死问题。但是使用这种方法，至少情况不会恶化。而且，在使用通用代码时，您不必将重点放在“好”上，而应放在“更好”上。
您要修复错误吗？花额外的时间编写自动测试。您准备好推出新功能了吗？花额外的时间清理代码。尝试日复一日使变化变得无痛。几个月后，您会注意到这种习惯对您的生产率产生了巨大影响。你知道为什么吗？因为重构有助于减少每单位软件功能的边际成本的波动性。