在旧版应用程序中启动一致的体系结构

我负责基于Asp.Net的大型网站。目前，它是一个网站（不是Web应用程序），一些Windows服务和许多类库。

数据层使用LLBLGEN 和Linq To LLBGen 的混合物，以及许多尚未重构的传统内联SQL实例。

有一些管理器类型的实现，但是在许多情况下，该应用程序都具有Smart UI反模式（即，类背后的代码中的业务逻辑过多）

该站点的流量相当大，性能还不错，但是我们正在将开发能力提高到大约10个团队，并且越来越明显的是，我们需要在现有中间件之上进行总体分层设计。

我的问题是从哪里开始？我们有10年的代码（其中有些实际上仍然只是在迁移ASP Classic东西），许多不同的方法和样式。

重构整个代码库是不现实的，并且可能是不希望的

我知道这不是一个新情况，关于如何解决这个问题是否有有用的想法或概念？

我也在类似的情况下工作，我可以给您以下建议。

1. 您需要减少技术债务。现在。为什么？因为技术债务就像金融债务。您将为此支付利息。
2. 由于重构整个代码库是不可行的，请问自己：是什么阻止了它？仅仅是太多的工作吗？为什么？
3. 制定计划以减少技术债务。例如，通过将规则设置为“ 团队所接触的每一位代码都必须固定/重构为新标准 ”。通常：必须编写单元测试，必须在正确的层中移动代码，等等。这使您可以修复很多代码，而不必求助于昂贵且低价值的“重构”项目。
4. 包装废话。去耦是重构和良好架构的关键。如果可以以某种方式对代码库进行分区，则可以重构较小的位。
5. 不要进一步增加技术债务。不要进一步增加技术债务。不要进一步增加技术债务。不要...

您是对的，重构整个代码库是不正确的。重构是您在进行新开发之前要做的事情，以使开发更加顺利。如果您不打算修改代码库中的所有代码，则重构将证明效率低下。

除了Sklivvz所说的一些建议：

1. 将代码分为频繁和不频繁修改的部分。仅需要将经常修改的部分完全纳入新架构。只需很少的更改即可将不经常修改的代码与新体系结构集成在一起（如果可以避免的话，请不要进行任何更改）。抵制完全重写的诱惑，它的成本将超过您从中获得的收益。即使现有的代码很丑陋，也要意识到它可以正常工作。

2. 找出您的重构目标是什么。您是否想使内容更容易进入网站？您是否有很多错误，并且想要提高用户感知的质量？您是否想减少功能开发时间？还是您主要想要更好的UX？您的体系结构应该使重构代码轻松实现您设定的目标。永远不要忘记，重构的主要受益者应该是您的用户/客户/业务。干净的代码本身并不是目标，它是达到目的的一种方法，而最终涉及用户。

3. 尝试找到尽可能多的参考体系结构，不要害怕复制它们。不要重新发明轮子。如果其他人拥有适合您这样的网站的架构，请向他们学习。

4. 考虑一下人员管理方面的事情。在我自己的迁移项目中，最困难的部分是使人们学习新方法并坚持下去。您将需要参考实现，以及向团队中的每个人（新老）教授体系结构的方法。为了减少对变更的抵制，请在决策前征求团队中每个人的意见。确保新设计从开发人员的个人角度真正改善了事情，并且步伐不会太大，以至于他们感觉不到他们的深度。

在尝试处理旧代码库时，我看到的最重要的事情是不要一直更改您要拍摄的内容。也就是说，弄清楚您想要的架构，然后坚持该计划！我上一个职位的主要问题之一是，随着时间的推移，代码库对它的外观有几种不同的想法。每次尝试一个新的主意时，某些代码都会被转换，有些则不会，然后其他人会有一个“更好”的主意。随着时间的流逝，它变得越来越不连贯，最终被废弃了。

关于重新设计旧版软件，有一本非常不错的免费书籍/ pdf：http : //scg.unibe.ch/download/oorp/

标题中标明OO，但是大多数想法适用于任何软件。它讨论了从何处开始，如何在重组过程中处理系统的不同部分以及更多这些主题。

如果没有一致的体系结构，那是因为管理层不了解/不在乎问题。只需编码即可。在编写新代码时，您应该引入新的良好架构。

只有当事情开始有严重的错误，需要扩展它并且根本不能扩展或者根本不符合要求时，才应该重新构建事物。

我的意思基本上是只关心您的经理真正关心的问题，而不是他们是否了解您的知识。

如果您可以将重新架构出售给管理层，请从测试开始。如果他们不想投资于测试，那么您的努力只会给您带来麻烦。