这是一个简单的问题。拥有 2 个版本的代码还是一个版本更好？一个是未经V&V测试的工程版本，具有许多功能，另一个是经过高度监管和高度测试的精简客户版本。
我有一个简单的问题，随着需要新的工程功能，我的代码库正在膨胀。但是，核心客户代码非常简单。工程部分有时会导致客户代码中出现意外错误。此外，每个工程错误都必须像客户一样进行调试和处理，这为发布提供了更长的交付周期。
我认为分裂是好事，也是坏事。首先，它允许快速制作和发布工程功能，而无需对软件进行V&V测试。第二个优势是面向客户的软件版本更少，质量更高。但是，这意味着要维护 2(较小的(代码库。
这个问题的常见解决方案是什么？您决定分成两个版本是否有限制？还是我应该学习更深入的组织技巧？我已经尽力遵循该软件的最佳组织提示并遵循 OOP 最佳实践。
截至目前，我会说我的代码库大约是50%的客户软件和50%的工程功能。但是，我刚刚有一个新的(大型(工程/制造项目要添加到软件中。
任何经验将不胜感激。
TL;大卫：拆分它。
您可以使用您提到的任一模型。这是关于你如何看待它在未来的发展以及它目前的设置方式。
如果您决定采用一个大型代码库路线，我建议您使用MVC体系结构，因为它可以有效地将一个大型代码库分类为更小更易于管理的部分。这为工程师提供了一个抽象层，他们可以轻松地将问题缩小到自己的团队。这使得一个团队不必担心另一个团队如何实现功能;是：图形团队无需担心数据如何存储在您的服务器上。
如果您决定使用多个代码库，则会增加一层额外的"难度"。您现在必须维护"两次"尽可能多的代码。您还需要确保这两个来源相互配合良好。这样做的好处是可以将工程版本与生产版本完全隔离。
在您的情况下，由于您提到 50 个版本之间的拆分目前为 50/50，因此我建议您拆分客户和工程版本。这会将未测试的工程代码与经过正确测试的客户代码隔离开来。这确实为您提供了"更多"代码来控制，但这个问题可以通过拥有 2 个团队来轻松缓解，每个团队负责自己的版本。