将昨天的技术债务归咎于今天的弊病

我目前不最初编写的应用程序上出现了数量惊人的质量，可伸缩性和负载问题。值得庆幸的是，我有一些从头开始做的新项目，以保持我的理智。

最初的团队由20名开发人员（其中大多数人具有过时的技能）组成，没有业务需求文档或质量保证测试人员，并且从一开始就以瀑布式的方式管理不善。生产的早期是一个令人尴尬的噩梦，涉及用更脆弱的修补程序修补脆弱的过程式代码。后来又添加了一些功能，这些功能被大刀阔斧地打入了一个从来都不打算支持它们的数据模型中，看到相同的代码重复十次并且看到资源没有被安全关闭，并且ORM查询只获取了成千上万个实体，这并不少见。扔掉几乎所有的东西。

只是我现在，每当出现一个新问题时，我都会改写模块以达到更好的标准，并使模块更加稳定，但是管理层需要对所有这些原因的发生做出适当的解释。

他们对这种应用程序质量差且技术债务沉迷的想法感到震惊和困惑。幸运的是，他们理解技术债务的概念并在我寻求消除技术债务的过程中为我提供了支持，他们对我非常支持和赞赏，但我觉得我似乎一直在指责原始团队（他们全都在另一个项目中毁了另一个项目）师）。

最重要的是，我不想成为“那个家伙”，他总是抱怨在他之前的项目开发人员。我以前在我的职业人士中已经看到过这种态度，我个人认为他们是无知的，没有考虑到鼓励事物成为现状的环境和设计影响。

通常，我会以这种态度将以前的团队归咎于理想化的初级开发人员的设计和实施不力，这些理想的初级开发人员没有更多高级成员所拥有并受益的生活经验。

您是否觉得有一种更好的方法，也许更柔和的方法可以向管理人员报告这类问题，而又不会在您之前提高人员/团队的声誉？

技术债务就像金融债务一样。您可以有计划地在程序开发过程中进行策略性的使用，以期将来能得到回报。有时人们做出较差的技术债务决策（例如运行信用卡），但有时一定数量的技术债务只是正常现象。决定不花时间在今天以“正确的”方式来做某事，并假设将来需要更改它是完全正常的，应该可以预见。当然有一条分界线，但是认为您第一次使用正确的方法会引起一系列问题（分析瘫痪）。

最重要的是，任何持续时间超过两年的重要项目都需要投入一些新的开发时间来偿还技术债务。事实是，即使您以正确的方式编写应用程序，也是如此。如果您不这样做，那么您就是将债务堆积在债务上，并且如果您这样提出，管理层当然可以理解。

向管理层解释这一点，而不是一直都在指责先前的团队，您可以将其表示为“一切照旧”。

IMO，您已经大都以正确的方式进行此操作：您不是在建议进行地面重写，因为“旧代码很烂”，而是一次修复了一件事情。

为避免感觉到您在责怪旧团队，请想象他们可能不得不在巨大的时间压力下生成此代码。当时的管理人员可能并不真正理解，仅仅因为代码“或多或少地起作用”并不意味着无需进行大量的痛苦和返工就可以进行任何维护。

感谢旧团队设法制造出确实具有一定商业价值的产品-如果没有，它将不再使用。即使项目编写精美，您也常常会对项目无法交付业务价值的频率感到惊讶。

当被要求评论问题产品的当前状态时，我总是回过头说“它就是它”，然后开始谈论改进它的计划。

您不知道导致此问题的决定所涉及的所有因素-也许在当时它们甚至是合理的。您所能做的就是继续前进，让明天变得更好。听起来您做得不错-您对这种情况有正确的态度。

在被问到时只关注报告事实。您不必添加叙述或评论；只需说“在X情况下系统发生故障”或“在Y情况下报告不正确”。然后快速添加您打算如何改善当前状况。