对于“超级”站点，应该考虑哪些因素？

我公司正在考虑将其所有的第1层（即高端生产）应用程序和站点整合到一个包含所有内容的代码库中。

从理论上讲，它们的权限，设计和整体功能可以同质化并集中管理。

我无休止地担心这种方法，因为支撑每个应用程序的数据结构是非常不同的，业务规则是复杂的，并且对于每个应用程序都是唯一的，并且现有应用程序的整体代码库是极为不同的，并且非常被忽略。

编辑：

当前环境由三个ASP.Net 1.1站点和一个MVC2应用程序组成，这三个站点自首次编写以来就几乎没有任何真正的热爱（主要原因是公司中没有经验丰富的开发人员），而另一个MVC2应用程序在成为ASP.Net 1.1站点之前去年升级。我们只用C＃编写。

该公司规模很小，只有大约50名员工。其中三个是实际的开发人员。管理（甚至是IT管理）除了具有IT项目的项目管理（因此具有一定的术语和业务影响知识）以外，没有任何IT背景或经验。

这些应用程序主要是在线服务，用于支持公司出售的产品。该公司不直接出售任何软件。

因此，用一个合理而具体且可以回答的问题来表述整个情况：在当前条件下（例如，旧代码库，复杂的业务系统和规则），有哪些令人信服的理由支持和反对将所有系统整合到一个总体解决方案中？ ）？

馊主意

此反应基于以下假设：

1. 有很多相当不同的应用程序被同质化
2. 有很多团队致力于不同的应用程序
3. 没有积极地管理应用程序的受人尊敬和权威的软件架构师

如果继续前进会发生什么

最有可能进行一次综合的努力，以单一设计方法将所有内容整合在一起。这将显示出使所有东西都一样工作所需的巨大努力，并且可能被认为是不可行的。

如果按下，则将需要某种包含配置数据的集中式存储库（例如安全访问，日志记录级别等），此时有人会指出明显的内容并说出

“嘿，为什么我们不只是将这种外部化的配置方法改型到旧的应用程序，它会更快呢？”

过了一会儿，其他人会与

“而且，由于无论如何我们都在进行重构，为什么我们不只是对每个应用程序领域应用设计标准-Web处理看起来像这样，业务规则处理像这样，数据库访问就这样。”

直到最后

“哦，这里有很多通用代码，为什么不将一些易于共享的库放在一起。我们可能需要定期（例如每晚）运行某种集成构建。”

这时，每个人都松了一口气，说没有建造一个巨大的整体。

我们在我的公司一直在努力。我认为这是有可能的，并且有明显的好处（您提到过），但是，这可能是一个5至7年的项目，其绝对最低要求，并且基本上需要重写所有内容。如果您可以在类似的东西上签字，那么我会说。如果不是，那就准备一场噩梦般的死亡游行。

Google做到了，所以肯定有可能。

该链接BTW是Google员工关于他们如何管理代码库，持续集成，测试等的有趣演示。

但是，如Google一样，如果没有对工具的同样坚定承诺，您很可能会遭受重创。

这里的关键问题是为什么？为什么高级管理层要这样做？他们希望获得什么节省，杠杆作用或其他优势？

如果您能够解决这些问题中的足够一部分，从而实现他们的目标，那么您可以避免使用与您有关的单一代码库，同时仍能获得相同的有效结果。

我们一直在经历类似的过程。我们的产品已经存在了一段时间。去年，我们推出了另一款产品，该产品与第一款产品具有95％的相同性，其中有5％有时是细微但重要的差异，这些差异由单独的团队开发和维护。

当我们第一次开始开发新产品时，旧团队不断进行更改，对我们造成5％的不利影响，因为他们不了解新产品。因此，我们完全分叉了这5％的代码，这使我们能够按时完成第一个发行版。

然后开始进行更多的维护工作，我们发现我们经常在几乎相同的代码中进行几乎相同的更改。老团队现在对新产品也有了更好的了解，因此我们正在逐步重新整合我们的产品，并找到更有效的架构方法来表达差异。

因此，当您说数据结构不同且整体代码库完全不同时，我要问的问题是它们是否必须那样做，还是由于当前的便利性而如何发展。显然，您必须考虑到不同的业务规则和要求，但是关键是将这些差异隔离到尽可能小的模块中。如果您经常发现自己针对不同的代码库以略有不同的方式为多个客户实现了完全相同的功能，那么合并确实会有所帮助，我怀疑情况就是这样，否则管理层可能不会提出这一建议。

您很可能无法将多个应用程序合并到同一代码库中，因为这将花费很多精力，对于旧的，被忽略的程序，这可能比最初预期的工作要多得多。

就是说，将所有应用程序都放在同一个代码存储库中是没有错的，其中每个应用程序都将其分开。例如，这使您可以在一个一致的视图中为整个代码库生成任何在线文档，这通常是一件好事，因为您希望获得尽可能多的可见性。

那些决定的人应该认真考虑为什么要这么做，并考虑他们要花多少工作才能到达那里。

如果只有一个因素使企业发展如此低效且昂贵，那是一种幻想，即有可能制造出一个可以完成所有任务的系统。如果您只有一个产品所有者，可以了解系统的所有详细信息，并且可以在不需一周会议的情况下做出所有决定，那么它可能会起作用，但我从未见过这种情况。

总的来说，如果您将其更像是为互联网开发而做，那将是更好的选择-只需构建自己的应用程序，并承认在实践中您对自己代码外的任何内容都可以零控制。使用OAuth和用于用户设置的简单API以及一些共享的CSS，您几乎可以获得所有想要的一致性。

这与SOA的初衷非常相似，但是如果您这样称呼，您将最终得到尝试执行所有操作的另一种大型，几乎没有工作的系统。

我的第一个想法是，这将是发布的全部PITA。

如果只是避免所有管理和审批层，那么将功能拆分为可管理的大块将更为明智。

恕我直言，将常见的东西分解成组件/服务并标准化这种方式会容易得多。

您可以使用诸如Deliverance之类的集成技术以类似方式将所有Web应用程序作为主题，以不同的方式进行处理。基本上，每个应用程序仍然是独立的。传递使用XSLT规则将其输出转换为您设计的静态HTML模板。这允许将相对简单的静态HTML / CSS主题以最小的麻烦应用于整套应用程序。