通过 AOP 或其他自动化方式重构令人讨厌的遗留系统？
我最近在玩 PostSharp，它让我想起了几年前遇到的一个问题：客户的开发人员制作了一个 Web 应用程序，但他们没有充分考虑如何管理状态信息 - 存储它（不要问我为什么）静态在 IIS 中的应用程序实例上。不用说，该系统无法扩展，并且存在严重缺陷且不稳定。但它是一个庞大且非常复杂的系统，因此重新开发它的成本令人望而却步。我当时的任务是尝试重构代码库，以在组件之间实现适当的解耦。
当时，我尝试使用某种抽象机制来拦截对静态资源的所有调用，并将它们重定向到能够正确管理状态数据的组件。问题是大约有 1000 个复杂的引用需要重定向（我没有太多时间来做这件事）手动编码（即使使用 R#）被证明太耗时 - 我们废弃了代码库并正确地重写它。重写花了一年多的时间。
我现在想知道的是 - 如果我能够访问程序集重写器和/或面向方面的编程系统（例如 PostSharp），我是否可以轻松地自动化查找直接引用并将其转换为可以重定向的接口引用的重构过程自动并由工厂提供。
有没有人使用 PostSharp 或类似的系统来修复病态的遗留系统？这些项目有多成功？事后你发现这些努力都是值得的吗？你会再做一次吗？
更新： 请参阅这篇博客文章更多讨论。
I've recently been playing around with PostSharp, and it brought to mind a problem I faced a few years back: A client's developer had produced a web application, but they had not given a lot of thought to how they managed state information - storing it (don't ask me why) statically on the Application instance in IIS. Needless to say the system didn't scale and was deeply flawed and unstable. But it was a big and very complex system and thus the cost of redeveloping it was prohibitive. My brief at the time was to try to refactor the code-base to impose proper decoupling between the components.
At the time I tried to using some kind of abstraction mechanism to allow me to intercept all calls to the static resource and redirect them to a component that would properly manage the state data. The problem was there was about 1000 complex references to be redirected (and I didn't have a lot of time to do it in) Manual coding (even with R#) proved to be just too time consuming - we scrapped the code base and rewrote it properly. it took over a year to rewrite.
What I wonder now is - had I had access to an assembly rewriter and/or Aspect oriented programming system (such as a PostSharp) could I have easily automated the refactoring process of finding the direct references and converted them to interface references that could be redirected automatically and supplied by factories.
Has anyone out there used PostSharp or similar systems to rehabilitate pathological legacy systems? How successful were the projects? Did you find after the fact that the effort was worth it? Would you do it again?
UPDATE:
See this blog post for more discussion.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你想要的不是AOP，而是一个程序转换系统，它概括了AOP。这些允许人们定义一组对代码库的自动修改，并可靠地执行它们。您不需要手动修改 1000 个复杂的引用；相反，您需要考虑如何定义一个可以处理所有情况的转换，并让该工具为您可靠地应用它。
我不能代表您的网络应用程序，但我有两个成功应用此功能的具体示例。
1) 波音公司需要从根本上重组多达 6,000 个组件，每个组件都编码为一组协作的 C++ 类（通常总计 3-10K SLOC），从传统的分布式架构转变为每个通信元素都成为 CORBA 方面的一个函数的架构。使用我公司的
DMS软件重组工具包，一个能够精确转换C++的程序转换系统，我们实施了一个工具来执行这些更改。该工具平均每三行修改一行，但可以在大约 5 分钟内转换一个组件。最终的转换完成率为 98%，需要进行一些适度的修改，但比预计的 1 个人月手动修改每个组件要有效得多。
最好将其视为工具实现的软件结构的大规模重新架构。
您可以在技术论文中阅读相关内容：
Akers, R.、Baxter, I.、Mehlich, M.、Ellis, B.、Luecke, K.，案例研究：通过自动程序转换重新设计 C++ 组件模型，信息&软件技术 49(3):275-291 2007。可从出版商处获取。
2) 美国空军拥有可以飞行的遗留系统。其中之一是 B-2 轰炸机，它装满了 1975 年世界上最好的微处理器。这些中运行的代码是/曾经是 JOVIAL，这是在 Ada 成为受欢迎的语言之前空军最喜欢的语言（在每个人都被淘汰之前，现在军方只考虑糟糕的语言用于软件工程）。代码运行飞机。 OTOH，他们需要离开 JOVIAL，因为对微处理器的支持（例如，CPU、开发工具、甚至愿意学习 JOVIAL 的人的物理可用性）正在迅速减少。我们使用相同的 DMS 为他们构建了 JOVIAL 到 C 的翻译器，并完成了 100% 的转换，而无法看到原始代码（黑色程序......）
有关其他详细信息，请参阅 B-2 轰炸机改装。 B-2 正在升级
正如我们所说，使用转换后的软件。
现在，这两种情况都需要一些手动时间来配置转换。但与手动完成这项工作的估计成本相比，配置工作量很小。
所以，是的，如果您了解如何使用这些工具，这些工具就可以很好地工作，是的，我们绝对打算再次使用它们。
What you want isn't AOP, but a program transformation system, which generalizes AOP. These allow one to define a set of automated modifications to the code base, and carry them out reliably. You don't hand modify 1000 complex references; instead you figure how to define a transformation that will handle all the cases and let the tool apply it reliably for you.
I can't speak for your web application, but I have two specific examples where I have applied this successfully.
1) Boeing needed to radically restructure up to 6,000 components, each coded as set of cooperating C++ classes (often totaling 3-10K SLOC) from a legacy distributed architecure to one in which each communicating element became a function in a CORBA facet. Using my company's
DMS Software Reengineering Toolkit, a program transformation system capable of accurately transforming C++, we implemented a tool to carry out those changes. The tool modified one line in three on average but could convert a component in about 5 minutes. The resulting conversion was 98% complete and required some modest touch ups, but was much more effective than the estimated 1 man-month to hand modify each component.
This is best thought as tool-implemented massive rearchitecting of the software structure.
You can read about this in a technical paper:
Akers, R., Baxter, I., Mehlich, M. , Ellis, B. , Luecke, K., Case Study: Re-engineering C++ Component Models Via Automatic Program Transformation, Information & Software Technology 49(3):275-291 2007. Available from publisher.
2) The USAF has legacy systems that fly. One of these is the B-2 bomber, which is full of the world's best 1975 microprocessors. The code running in these is/was JOVIAL, the Air Force's favored langauge before Ada became the favored language (before everybody wimped out and now only awful languages are contemplated by the military for software engineering). The code runs the airplane. OTOH, they needed to get out of JOVIAL, because the support for the microprocessors (e.g., physical availability of CPUs, of development tools, and even of people willing to learn JOVIAL) was fast diminishing. We built them a JOVIAL-to-C translator using the same DMS, and accomplished 100% conversion, without ever being able to see the original code (black program...)
See B-2 bomber conversion for some additional details. The B-2s are being upgraded
with the converted software as we speak.
Now, both cases took some manual time to configure the transformations. But the configuration effort was tiny compared to the estimated cost to do the job by hand.
So, yes, such tools work very well if you understand how to use them, and yes we absolutely intend to use them again.