Joe*_*Fan 9 architecture migration legacy
我参与了几个项目,主要涉及用"新"系统替换"旧"系统.不变的是,模式一直是建立"新"系统的团队中几乎没有人对"旧"系统有任何真正的了解.每当我对此提出质疑时,我都被告知这是有目的的......通过不了解"旧"系统,团队能够以不同的方式思考,而不受那里事情的限制.因此,团队中通常只有1或2个人对"旧"系统有所了解,每当有关"旧"系统如何做某事的问题时,他们都会被咨询.
但似乎总会发生的事情是,在"新"系统交付之后,用户总是会对新系统中的"我们如何做X(在旧系统中很容易)"这一形式提出疑问？对于开发人员来说,这通常是他们第一次听说X.所以他们必须去研究X是什么,他们回馈给用户的答案往往是"你不能"或"你可以,但它是真的很尴尬".
这对我来说似乎不对......在我看来,通过让"新"系统的每个开发人员真正了解"旧"系统可以获得很多,而这并不一定会扼杀他们的创造力,如果他们拥有不错的设计和开发技能.
对哪种方法最好的想法？
您需要更好的业务分析师.他们应该审查旧系统,并准确(完全)定义新系统需要做什么.他们应该为您提供完整的要求清单,以便考虑所有需要发生的事情.
无论谁在撰写要求,都需要更加彻底.如果那是不可能的,那么您可能需要参与并学习"旧系统".
然而,总有一些事情会被遗漏 - 这只是人性.显然,您应该尝试使"新系统"尽可能灵活,以便在用户意识到忘记时添加需要的功能.
我明白你的痛苦.
用新系统替换旧系统通常意味着同功能（即至少能够执行旧系统能够执行的操作）
因此，虽然不需要深入了解旧系统，但了解接口并构建一组功能测试套件对于有效开发新系统很有用。
该套件将用于验证新开发的结果，请记住结果绝不能是 100%（否则，您将成功重现第一个系统的错误！）
另外，对于一个非常大的系统，您的新程序至少需要三个实现：
如果我们谈论的是很长一段时间，这还涉及架构师能够管理旧系统的演变（旧系统不能停滞不前，在新系统取代它之前等待几个月或几年），使这些演变保持不变比你的新实施的方向。