建议进行大的更改/将其重写为实习生[关闭]

上下文：

• 这是一个内部项目（我认为很多人都不会使用）
• 很老了
• 我们正在更新

问题：

1. 它滥用了mvc框架（不使用模型，视图中的业务逻辑等）
2. 我们被要求做的事情很小，但是由于凝聚力低，我们有两种选择：
   1. 继续捣蛋
   2. 移动大量代码或重写事物

解决方案（我看到）：

1. 继续使用它，忽略最佳实践，而希望尽快完成，并且不通过重构/重写来引入新的错误
2. 重构/重写

我想我的问题确实是：如果我想对该项目进行较大的更改，该如何提出建议而不侮辱任何人？还是对我来说简单地顺应潮流，即使有时意味着（隐喻）导管胶带？

好的，去。

您认为该应用程序的结构不良且编写错误。

客户认为它可以胜任。

您只想改写它就可以改善它的“内在美”。

因此，您是在要求客户花钱让应用程序完全按照现在的方式进行操作-只有用户看不见或不了解的部分才会以某种方式“更好”。

编写不良的结构错误的代码的主要目的是难以理解。

该代码难以理解，并且具有只能在结构不良的应用程序中轻松实现的功能和特性。因此，除非您非常擅长于此，否则新应用程序将无法完全执行当前应用程序的操作，并且由于您不完全了解原始代码在做什么，所以它可能做错了。

因此，您的客户现在已经花了很多钱来获得明显比原始应用程序差的应用程序。你不会受欢迎！

幸运的是，您经验丰富的大学已准备好对您进行幽默处理（可能是因为它们在刚开始时犯了同样的错误，甚至可能不幸遇到了这样不幸的项目而获得管理层批准）。

因此，我的建议是保持旧代码库运行，并保持安静。客户只是想要一个能正常工作的系统，如果您认为代码丑陋，他们并不在乎。

提出您的更改。在每种情况下都应弄清楚业务案例：为什么您提出的更改将对整个系统有所帮助？如果没有，请往后推。为什么要花钱修理不会坏的东西？使系统更具扩展性和关注点分离之类的原因可能是有效的（取决于您正在与谁交谈），但是在99％的时间中，仅说“未正确实施”就无济于事。确保您正在为项目增加价值，而不仅仅是提出制作工作（即使确实清除了代码）。

不幸的是，在专业领域中，仅因某事被错误实施并不意味着它已损坏，因此不需要修复。另外，在修复它时，您可能会引入无法预料的连锁问题，这可能会影响项目的其他领域。

阅读您的问题，我实际上对重写应用程序是否值得表示怀疑。也许您不必费心提出完整的问题。但是，如果它是旧的，很少使用的内部应用程序，那么重写的好处是否值得付出成本呢？重写的成本可能会超过它所拥有的所有更新和补丁之和。

如果您认为这是不正确的，那么您将需要比在这里做更多的事。

至于改进应用程序，您可能会有一些重构的机会，这些重构会在更新过程中自然发生。

你是实习生 想必您是全新的。他们可能会怀疑您是白痴。

因此，当您提出建议时，请轻踩一下。谦虚谦虚。当您允许其他成员讨论他们自己有关代码库的想法以及他们可能承受的压力时，请让您的想法进行对话交流（可能很充分的理由，而我们并未做出任何努力来清理问题）。

您想赢得他们的信任。您可以通过为给定的任务编写良好的代码来做到这一点。编写整洁，使用您希望看到的最佳实践，但仅限于您要做的事情。这些可能很小，团队其他成员可能认为无关紧要。做好那些事。照亮您所处的角落，随着团队开始对您的代码进行有益的审核，您的想法也将日趋成熟。

最终，当您展示自己的能力和知识时，您也许可以提出一两个建议。

我完全会提出这个建议，但仅限于一位开发人员。我不会在管理方面提出这个建议，因为我想像管理层会认为这是某种形式的越界。

向与您一起工作的开发人员提出建议后，他们可能会有一些很好的理由来说明代码库的原因。原因可能从“不，实际上代码很好，您只是不了解MVC（这就是为什么您是实习生）”到“这是个好主意，让我们一起设计新应用程序！”

请记住，重构此应用程序的答案很可能不是。我永远都不想让实习生接管内部应用程序的重写（当实习结束并且重写只完成了一半时会发生什么情况？）此外，与在内部应用程序中四处寻找相比，您可能还需要处理更重要的事情。

但是问你的同伴也没有什么坏处，如果你这样做，你会学到一些东西。而这就是7983879342，这就是实习的全部内容。

无论发生什么情况，我希望您都将以下消息带走。正如上面的一些答复所指出的那样，出于商业和成本方面的原因，出于技术上的最佳原因，有时有时无法重写代码。技术解决方案中生活着太多的程序员，他们拒绝考虑他们个人对技术优雅/可读性/最佳实践的追求应该与企业完成工作的需求相平衡。以我个人的经验，不平衡（从任何方向）的人通常被视为团队中的责任。

但是，即使您受到一些打击，也不要停止质疑事情，这是我们学习和成长的方式。

关于您所处情况的政治因素，其他答案也很多，我倾向于同意。除非您能提出令人信服的业务案例，否则可能不会进行重写。

但是，这并不意味着您应该忘记童子军规则：

始终将营地的清洁剂留在您发现不到的地方。

如果在此代码库上实现某些东西时，可以找到一种方法来清理设计或实现的某些方面，那么您应该考虑这一点。您可能不需要重新编写整个应用程序以更好地利用MVC模型，并且如果您要为特定视图实现一些新的业务逻辑，则可以考虑将逻辑从旧视图移到模型中并在其中添加新的逻辑。

正如其他人所述，请另一位开发人员（熟悉此应用程序的人员）进行快速演练，以便您可以了解实施的方式/原因。向您解释，虽然您可以理解技术方面，但是您希望能够将点连接到业务需求（业务需求胜过一切）。

获得这些信息后，您就可以进行评估了。如果您个人认为应该重新编写它，但又不认为其他人会认为它是对时间的充分利用，那么可以将其作为个人项目。即使这里/那里有一个小时的停机时间，也要“正确”执行实施。完成后，将其呈现给其他开发人员，以“嘿，我觉得这可能需要一些清理，所以我在停机期间做了一些辅助工作。您怎么看？” 不要对他们进行更改，而只是向他们提供“嘿，你们喜欢这样吗？” 然后从那里去。

通常，大多数更改都是增量发生的。

需要记住的几件事；

• 申请的历史是什么？
• 今天为什么丑陋？
• 架构更改的好处是什么？

一个好的策略是处理一些小问题，并提出很多有关事物的问题（您不能从Google或源头学到的问题，不要浪费人们的时间）。在对代码库和开发人员感到满意之后，您应该对为什么这样的代码有一个很好的了解。有时只是，“是的，我们不得不一起砍东西，然后将其推到门外”。如果您可以建议在正常工作中对系统的小部分进行轻微的更改，那么与彻底的重写相比，这将获得更大的吸引力。

如果您提出很好的要求并提出合理的理由（建议不只是预感或更好的做法），建议重写是没有害处的。重写低使用率应用程序的可能性很高，很可能是最初编写该系统的人仍然存在（并且在层次结构中比您高），并且可能不会友善地接受批评。

因此，请不要说“我们需要改写这个违反基本MVC原则的可怕设计的系统”，而是将其作为对适当的上层人士（就在您上方的人们）的开放式问题。诸如“我想知道从长远来看是否可以用MVC模型重写系统，这会节省很多时间。您如何看待？我敢打赌，如果进行大规模重写（例如2周），我们可以将维护时间减少一半。合并了MVC模型，TDD等，并且经过两个月的例行维护，我们将达到收支平衡。” 答案可能是，不，我们不认为这是必须的-我不同意您的时间估算，也不同意新系统将成为合适替代品的可能性。还是可以这样回答，但是请记住，如果您的新系统没有 在您提议人们会责怪您的时间范围内，它比新系统工作得更好/更好。即使该系统很少使用；在重写期间停止使用较小的修补程序进行更新可能是不可接受的。