如何处理推动旧系统的管理？

我目前正在带薪实习中，并且负责维护由过去五年来由多个开发人员（在不同时间）开发的过时系统。管理层同意“该系统具有生命支持”，并且我从当前使用该系统的最终用户那里收到定期报告的错误报告。

管理层现在希望将该项目再延长一年，在此过程中，用户群几乎增加了两倍。

作为一名实习生（或任何入门级职位），我该如何“退缩”？我已经写了一份报告，陈述了我的担忧，尽管它是开放式文档。是否有用于建议更改的协议或文档类型？我是否可以提出建议，还是应该继续支持旧系统？

• 要澄清的是，软件开发不是我公司的主要业务。因此，不存在内部协议。此外，该项目根本没有正式文档，也没有需求文档。发展是非常特别的。

我目前正在带薪实习中，并且负责维护由过去五年来由多个开发人员（在不同时间）开发的过时系统。管理层同意“该系统具有生命支持”，并且我从当前使用该系统的最终用户那里收到定期报告的错误报告。

如果人们仍在使用该系统并且该系统支持业务活动，则该系统并不会过时。由于仍在使用它，因此业务不能只是丢弃它-需要支持它，直到不再需要该系统为止。这可能是业务目标的变化，或者已经开发，测试了新系统并将其成功部署到最终用户。

真的，五年不那么长。我使用的是10年前的代码。如果仍然可以满足用户的需求，为什么要丢弃它呢？这浪费了开发的大量资金。直到由于成本增加而无法进行维护或需求发生巨大变化之前，没有商业理由将其丢弃。

管理层现在希望将该项目再延长一年，在此过程中，用户群几乎增加了两倍。

如果管理层说该系统是“终身支持”的，那么为什么他们要进一步部署它呢？通常，维护活动会在旧系统上继续进行，直到被替换为止，但是，如果系统处于使用寿命终止，则通常不会将其部署给更多的人。扩展维护是一回事，但是添加依赖系统的用户却是另一回事。

在我看来，这实际上并不是寿命的尽头，而是处于维护阶段，并且将继续存在直到系统不再满足用户需求为止。

作为一名实习生（或任何入门级职位），我该如何“退缩”？我已经写了一份报告，陈述了我的担忧，尽管它是开放式文档。是否有用于建议更改的协议或文档类型？我是否可以提出建议，还是应该继续支持旧系统？

您需要继续支持旧系统。后来，您提到软件不是您公司的主要业务。在这样的环境中，软件团队的工作是支持公司的主要业务。但是，软件团队还需要牢记业务目标。

同时，以一种不容忍的方式捕获您的建议。指出在创建新系统时/可以与系统集成或使用的其他技术或方法及其优点/缺点。如何执行此操作取决于公司，但是考虑到以后的观点，也许建立Wiki或其他协作站点会很有用。

在非软件业务中，软件是一项成本，因此软件团队（尤其是软件项目/程序经理）应努力在满足最终用户需求的同时，尽可能降低构建和维护软件系统的成本。 。抛弃满足用户需求的软件（据我所知，无论如何，从您的帖子中可以看出）与软件团队的最大利益背道而驰。

*澄清一下，软件开发不是我公司的主要业务。因此，不存在内部协议。此外，该项目根本没有正式文档，也没有需求文档。发展是非常特别的。

对我来说，这就是问题所在。不产生文档，不按照规范进行开发以及缺乏一致性会增加开发软件的成本。修复此问题将是我的最高优先事项，而我将通过诸如编码标准，版本控制，生成自文档代码和设计文档，缺陷跟踪以及需求规范之类的工作来做到这一点。

我已经写了一份报告，陈述我的担忧

好。那是关于您可以做实习生的程度。为了将来编写此类报告时的参考，我强调以公正，专业的方式陈述真实的事实，而不会引起情感上的偏见。您不知道是谁阅读了该报告，可能是某个人造成了您正在描述的某些问题，或者做出了导致这些问题的决定。诸如冒犯事实或冒犯他人之类的不诚实事实，可能会导致他们不喜欢您，甚至可能不认真对待。

管理层现在希望将该项目再延长一年，在此过程中，用户群几乎增加了两倍

请记住，之所以做出这样的业务决策，是因为它们试图利用他们可用的资源做出应有的努力。我敢肯定，管理层可能已经意识到旧版软件的问题，并且已经意识到用户的抱怨，但是他们是否拥有可用于重构或重写的软件开发资源？

在大多数情况下，它们不会这样做，尤其是如果软件不是公司的生死攸关者，并且软件的质量和用户满意度不会直接影响利润。做出这样的决定有时就是为什么成为经理很糟糕，因为无论您做什么，您经常处于双输的情况。

维护过去五年来由多个开发人员（在不同时间）开发的过时系统

在整个项目中都犯了错误，导致了这一点。缺乏可靠的用户输入或需求，缺乏适当的产品管理和变更控制来管理不断变化的需求和需求，以及缺乏足够的技术资源来实施这些问题，这些都是当今存在的问题。我不知道过时是否是正确的词。基础技术是建立在不受支持的框架和技术之上，还是仅仅是尖端技术或理想技术？

作为一名实习生（或任何入门级职位），我该如何“退缩”？

您的权力最小，只是暂时的。没错，没关系，我不期望实习生会向我“推后腿”。我希望他们学习，讨论他们看到的问题并遵循命令。就是这样 发出命令后，我希望可以尽其所能执行命令，因为此时的讨论时间已经结束。

你是实习生 我非常怀疑您是否对整个日常业务需求甚至是遥遥无期的需求，正如其他人已经注意到的那样，拥有5年历史的代码库真的不是那么古老。

关于更换旧系统的决定并不总是在技术上驱动的。它们是由不断变化的业务需求驱动的。向这些人员输入可能是与维护有关的困难；但总而言之，您需要认识到自己的职位并不一定意味着您拥有所有可用的和必需的知识。我要说的是，实际上您几乎不需要掌握什么知识来就目前的最佳举动作出决定。

我对您的建议是：从经验中学习，并停止假设您的知识胜过那些必须每天经营业务的人。

您的工作是保持系统正常运行，而不是建议使用新的替代产品。

在我看来，很多年轻的程序员并没有意识到维护旧系统是编程工作中比设计闪亮的新系统更大的部分。

不要退缩。您唯一要做的就是以清晰，简洁的方式表达您的疑虑。事实是，您将来要工作的大多数企业都将使用旧系统。这些旧系统需要维护，因为在许多情况下，更换它们的成本太高。

在许多情况下，您甚至有最好的意图将现有系统替换为更好的系统，但是，您可能会引入新的和不同的错误...当您离开系统时，它们会迅速再次变成旧系统，并且公司会和以前一样。在不再满足其目的或与现代系统完全不兼容之前，没有什么过时的了。我公司有20多年的历史，我们现在正在将其转换为ASP.NET。该系统仍然可以运行，但是对旧技术的支持正在减少，并且使其与现代Web浏览器一起工作正变得越来越耗时。

你可以做什么：

保持清洁

当您维护某物时，请使其比开始时更干净。进行修复，但也可以清除所有内容，以便下次有人需要进行修改时更容易理解。

建立文件

如果缺少文档是一个问题，请创建文档。当您处理系统的特定部分时，请进行记录。

减轻痛苦

正如我所说的，您可以表达您的担忧，但最好的选择就是在系统上勤奋工作，并为在您之后的工作做更好的工作。正确修复错误。文献。散布代码气味。做得更好。当您执行这些操作时，请让您的上司知道。告诉他们您做X，Y和Z来改善开发过程。这将建立信誉，从长远来看，这将对您和您的公司提供最大的帮助。

你不要！这是一个巨大的机会！

您是一个学习的实习生！这个项目是一个现实世界。

你很幸运。您不合格的事实与您无关。（如果\当管理层意识到这一点时，您将收获很多）

完成实习后，您将有资格，这是个好消息。

PS：认真进行备份，请确保您所做的任何事情都可以回滚。从“轻松修复”的问题开始，但给用户带来很大的痛苦。采取婴儿的步骤。

我想，从理论上讲，没有所谓的“ 旧系统”。我有一部非常旧的手机（旧版系统），这些天有很多不错的android手机（现代平台），但是我的手机可以工作并且可以满足我的需求。我为什么要扔掉它？

今天，您称为“旧版”的所有系统都是最先进的一天。这只是我们需要的时间。此外，当有大量工作准备就绪时，并不是要在现代平台上重新做全部工作，这意味着它会自动消除错误（或减轻痛苦）。

这是我建议您应该做的：

1. 首先，消除对“旧版系统”的厌恶。这将使您的生产效率非常高。

2. 开始记录您现在所做的事情和您的想法。尽管是逐步进行的。没有比编写意识到需要文档的时间更好的时间了。

3. 与其尝试推迟“旧式系统”的发展，不如为平滑退出定义路径。尝试让您相信管理层可以说，可以隔离的较新开发可以以较新的平台形式逐步进行，而不会破坏与旧系统的互操作性。随着事情的发展，速度变慢（而且这将真的变慢），保持传统系统的需求将消失。这是对任何旧系统说再见的唯一方法。

地盘

真相是没有人给实习生他们想要做的工作。当您是最初级的人时，您得到的最不刺激的工作。您个人处理得如何好，这对于组织是否可以信任您来完成更多激动人心的工作，说明了很多。

因此，这是一个无价的机会，可以证明您可以通过执行错误修复来交付，可以通过使代码的各个部分稍作改动来重构，可以通过开始为该系统创建代码来创建单元测试。并且您可以通过为下一个受困于此系统的可怜灵魂创建文档来进行文档记录。它还给您机会，表明您可以有效地与用户打交道（以获取有关报告的错误的更多详细信息）并满足他们的需求。如果项目现在不在源代码管理中，请将其放在此处，并且如果没有在错误跟踪器中跟踪错误，则启动一个。这些类型的动作将告诉您知道如何专业地工作。

或者，您可以采取相反的方法，只是对项目有多糟糕以及替换它有多酷而苦恼。在这种情况下，几乎可以肯定的是，在您实习之后，您将不会在那家公司找到工作。

您可能没有足够的信息来确定再过一年是否符合成本效益。了解公司以及他们为什么要添加用户会很有趣。似乎可能会继续增长，而他们又无力在财务上或在一定的时间限制下退后一步来构建另一个应用程序。无论如何，构建新应用程序很少是最佳选择。除非他们以旧技术为基础，否则5年就没有那么久了。