Architecture “谁应该学习？”；旧的；系统？

我参与过几个项目，基本上涉及到用“新”系统替换“旧”系统。一成不变的是，在构建“新”系统的团队中，几乎没有人真正了解“旧”系统。每当我质疑这一点，我都会被告知这是有目的的。。。通过不了解“旧”系统，团队能够以不同的方式思考，而不受那里的工作方式的限制。因此，团队中通常只有一两个人知道“旧”系统，每当出现关于“旧”系统如何做的问题时，都会咨询他们

但似乎总是发生的是，在“新”系统交付后，用户总是会向开发人员提出“我们如何在新系统中执行X（在旧系统中很简单）”的问题，这通常是他们第一次听说X。所以他们不得不去研究X是什么，他们给用户的答案通常是“你不能”或“你可以，但这真的很尴尬”

这对我来说似乎不合适。。。在我看来，让“新”系统的每一位开发人员都非常熟悉“旧”系统会获得很多好处，如果他们有体面的设计和开发技能，这并不一定会扼杀他们的创造力

---

对哪种方法最好有什么想法？

用新系统替换旧系统通常意味着iso功能（即至少能够完成旧系统所能完成的任务）

因此，虽然对旧系统的深入了解不是强制性的，但了解接口和构建一套功能测试套件对于高效开发新系统是有用的。
该套件将用于验证新开发的结果，记住结果永远不能是100%（否则，您将成功复制第一个系统的bug！）

另外，对于一个非常大的系统，您的新程序至少需要三种实现：

• 能够与旧系统对话的人
• 其中一个正在更换旧的部件
• 完全接管旧计划的人

---

如果我们谈论的是一段很长的时间，那么还需要一个架构师能够管理旧系统的演变（它不能停滞不前，在新系统取代它之前等待数月或数年），使这些演变与新实现保持一致。

您需要更好的业务分析师。他们应该审查旧系统，并准确（完整）定义新系统需要做什么。他们应该为您提供一份完整的需求清单，以便考虑到需要发生的一切

无论是谁编写需求，都需要更加彻底。如果这是不可能的，那么你可能需要参与并学习“旧系统”

然而，总会有遗漏的事情——这只是人的本性。显然，你应该尽可能地使“新系统”灵活，这样当用户意识到他们已经被遗忘时，就可以添加需要的功能

---

我理解你的痛苦。

这听起来像是新系统的规范不完整，因为有人（项目经理、项目发起人）没有确保记录和检查旧系统的功能，以查看客户实际使用了什么

如果做到了这一点，那么没有人知道旧系统就不重要了，因为规范是您开发时所反对的东西

---

如果您没有一个规范，除了您将遇到的所有其他问题外，每个人都应该了解旧系统以避免这个问题。

+1'如果您没有一个规范。。。每个人都应该知道旧的制度——在太多的情况下太真实了。在没有BA的情况下出现过，这很痛苦。试图与用户谈论“新”的需求有时也很困难，因为a）他们并不总是想要一个新的系统&b）他们只是想让它做旧系统所做的事情哦，是的。第一项要求总是“与旧系统相同”。“你需要使字体时代成为新的罗马字体，这就是旧系统的风格”。