遗留代码、遗留工具——该怎么办？
我有一个有点旧的项目，我称之为遗留项目。
它的一些特点是：
- 它是一个工作产品（大约 3 年）并且正在持续开发中。
- 代码库相当大，包括（CS、SQL、ASPX、Jayrock、JS/HTML/CSS 等）
- 平台是 .NET 1.1。
- IDE 是 Borland C# Builder 2006（多棒啊……）。
- 其他工具是 Enterprise Core Objects 3（适用于 .NET 1.1）（模型驱动架构 - 来自 UML 的 O/RM）。
- 另外还使用了 Telerik RadControls。
- 主要是一名活跃的开发人员。
- 对业务对象进行了大量测试，但 UI (WebForms) 根本不是可测试的 ATM（没有应用 MVP/MVC 等）。
- 我必须承认代码质量不是“最好的”，并且仍然处于“足够好”的标记（所以这不是 从头开始重写)
该项目的问题是：
- .NET 1.1 - 该平台不再“活跃”。
- IDE——一直在挣扎。 只是上班很痛苦。 工具支持不好，任何重构基本上都是手工完成的。
- ECO3 框架 - 为迁移到 ECO5（以及 .NET 3.5）付出了很多努力。
- 从 ECO3 迁移到 NHibernate（首选）将花费更多时间（因为所有逻辑/测试都应该重写）。
- ECO3 严重依赖 IDE，因此几乎不可能仅更改 IDE。
- 一般来说，迁移到 .NET 3.5 将花费大量时间（特别是对于 1 名开发人员而言）。
我想听听有关如何处理该项目的任何建议/提示。
我应该继续在那种环境中工作吗？
如果不是，那么在几天内迁移整个项目的最佳方法是什么（几周的延迟太长了 ATM）。 是的，我知道稍后会有回报，但我现在不能这样做。
一般来说，任何建议都是受欢迎的。
干杯，
德米特里。
I have a bit old project that I would call legacy.
Some characteristics of it are:
- It is a working product (for about 3 years) and is under continuous development.
- Code-base is pretty large and includes (CS, SQL, ASPX, Jayrock, JS/HTML/CSS etc)
- Platform is .NET 1.1.
- IDE is Borland C# Builder 2006 (what a ...).
- Other tool is Enterprise Core Objects 3 (for .NET 1.1) (Model Driven Architecture - O/R-M from UML).
- Additionally Telerik RadControls are used.
- Mostly one active developer.
- Lots of tests for Business Objects, but the UI (WebForms) is not testable ATM at all (no MVP/MVC applied etc).
- I have to accept that code quality is not "the best" and remains on the mark "Good enough" (so this is NOT the main reason to rewrite all from scratch)
The problems with this project are:
- .NET 1.1 - the platform is not "active" anymore.
- IDE - struggling with it all the time. Just pain to work. Bad tooling support, any refactoring is basically made by hands.
- ECO3 framework - a LOT of effort to move to ECO5 (and thus .NET 3.5).
- Migrating from ECO3 to NHibernate (preferable) will take even more time (as all the logic/tests should be rewritten).
- The ECO3 heavily relies on IDE, so it is nearly impossible to change IDE ONLY.
- Generally migration to .NET 3.5 will take a lot of time (especially for 1 dev only).
I would like to hear any recommendations/tips on how to deal with this project.
Should I continue working in that environment?
If NOT, what is the best way to migrate the whole project BUT within days (delay in weeks is too long ATM). Yes, I understand it will pay off later, BUT I can't do that NOW.
Generally any suggestions are welcome.
Cheers,
Dmitriy.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，考虑到您的可用时间跨度，我建议您保留代码并使用它。 但无论您要进行更改或进行新的更改，请确保以最佳方式编写代码。
通常，当你这样做时，项目会随着时间的推移而变得更好，因为偶尔你可能会更改一些“脏”部分，嘿，这是代码中一个不那么“脏”的部分:)。 从长远来看，您应该拥有更清晰、编写更好的代码。
至于IDE的改变，我倾向于同意Martin的观点。 迁移到另一个应该不会那么困难。 但我建议在你提到的第一个小时间跨度之后这样做（除非你是一个冒险的人）。
Well, given your available time span, I'd suggest you keep the code and use it. But whatever you're changing or making new, make sure you write the code in the best manner you can.
Usually, when you do this, the project gets better as time goes by, 'cause once in a while you'll probably be changing some "dirty" part, and hey, that's one less "dirty" part in your code :). In the long term, you should have a cleaner and better written code.
As for IDE changing, I tend to agree with Martin. it shouldn't be THAT hard to migrate to another one. But I'd suggest doing it after this first small time span you mentioned (unless you're a risky guy).
如果代码只有三年历史，那么它还不是遗留代码。 在我看来，每三年（甚至每五年）以不同的方式重做事情是浪费的。
OTOH，应该可以轻松地将 IDE 替换为其他 IDE。
If the code is only three years old, it's not legacy yet. It's IMO wasteful to redo things in a different way every three years (or even every five years).
OTOH, it should be possible to replace the IDE with a different one with comparably little effort.
我会慢慢地、小步地迁移和重构。 我的建议按顺序是：
除了更改 IDE 之外，其他所有事情都可以通过标准重构实践在代码库的一小部分上以非常小的步骤完成。 没有必要全部重写。
I'd migrate and refactor slowly, in small steps. My suggestions, in order, would be:
Other than changing the IDE, everything else can be done in very small steps, on small portions of the codebase, via standard refactoring practices. No all out rewriting should be necessary.