organization - 拥有一个软件的 2 个简单版本还是 1 个复杂版本更好？

Question

这是一个简单的问题。有两个版本的代码还是一个更好？一种是未经 V&V 测试的工程版本，具有很多功能，另一种是经过严格监管和高度测试的精简客户版本。

我有一个简单的问题，我的代码库正在膨胀，因为需要新的工程特性。但是，核心客户代码非常简单。工程部分有时会导致客户代码中出现意外错误。此外，每个工程错误都必须像客户错误一样进行调试和处理，这会延长发布时间。

我认为分裂有好有坏。首先，它将允许快速制作和发布工程功能，而无需对软件进行 V&V 测试。第二个优势是面向客户的软件版本更少，质量更高。但是，这意味着要维护 2 个（较小的）代码库。

这个问题的常见解决方案是什么？你决定是时候分成两个版本有没有限制？还是我应该学习更深入的组织技术？我已经尽力遵循软件的最佳组织技巧并遵循 OOP 最佳实践。

到目前为止，我想说我的代码库大约是 50% 的客户软件和 50% 的工程功能。但是，我刚刚获得了一个新的（大型）工程/制造项目来添加到软件中。

任何经验将不胜感激。

标签： organizationcode-organizationproject-organization

Answer 1

TL;DR：拆分它。

---

您可以使用您提到的任何一种模型。这是关于你如何看待它在未来的发展以及它目前是如何建立的。

如果您决定采用一个大型代码库路线，我建议您使用MVC架构，因为它可以有效地将一个大型代码库分类为更小的更易于管理的部分。这为工程师提供了一个抽象层，他们可以轻松地将问题缩小到自己的团队。这使得一个团队不必担心另一个团队是如何实现一个功能的；是：Graphic 团队无需担心数据如何存储在您的服务器上。

如果您决定使用多个代码库，则添加了额外的“难度”层。您现在必须维护“两倍”的代码。您还需要确保这两个来源相互配合。这样做的好处是您将工程版本与生产版本完全隔离开来。

在您的情况下，由于您提到当前两个版本之间的拆分为 50/50，因此我建议您拆分客户版本和工程版本。这将未测试的工程代码与经过适当测试的客户代码隔离开来。这确实为您提供了“更多”的代码来控制，但这个问题可以很容易地通过拥有 2 个团队来缓解，每个团队负责自己的版本。