曾经在C#中完成了对大型C++应用程序的重写吗?

Dan*_*olt 30 c# c++ mfc

我知道乔尔说永远不会这样做,我在大多数情况下同意这一点.我认为有些情况是合理的.

我们有一个大型C++应用程序(大约250,000行代码),它使用MFC前端和Windows服务作为核心组件.我们正在考虑将项目转移到C#.

我们考虑重写的原因是:

  1. 更快的开发时间
  2. 使用WCF和其他.NET内置功能
  3. 各种系统上的操作更加一致
  4. 更容易的64位支持
  5. 许多漂亮的.NET库和组件

有人做过像这样的重写吗?它成功了吗?


编辑:

该项目现在已有近10年的历史了,我们正在努力增加我们想要的新功能,即编写.NET已经内置的重要功能.

App*_*per 49

你有没有考虑过而不是从头开始重写你应该开始分离GUI和后端层(如果还没有),那么你可以开始用C#编写它的部分.

250,000行不是一夜之间写的,它们包含了数十万人的努力,所以没有人会建议一次性从头开始重写它.

如果你们打算这样做,最好的办法就是一件一件.否则要求管理层进行多年的开发工作,而现有产品中没有实现新功能(基本上在竞争前停滞不前)

  • 是的,一步一步地开始,然后通过模块化您当前的应用程序开始,这样您就可以重用C#中的一些C++组件(例如,作为DLL)重写 (10认同)
  • 我同意.虽然不是C++到C#,但我们正处于为期1年的项目的第5年,以重写我们的遗留应用程序.如果没有客户知道,可以在大块中完成.当然,这并不像一个全新的系统那样值得称赞. (8认同)
  • 经理们认为转换是一致的...... (4认同)
  • 我同意.模块化是最好的.您应该从系统中提取可以从C#中获益最多的部分,并将其余部分留待以后使用.SnapConfig是正确的,因为立即重做整个事情是一种资源匮乏,并将在其轨道上追求发展. (3认同)

Nik*_*iki 20

我的公司确实这样做了.我们有一个大致相当大的C++代码库,每个人(程序员,管理人员,客户)或多或少都认为它不是最好的软件.我们想要一些在旧代码库中非常难以实现的功能,因此我们决定(在许多讨论和测试项目之后)在.NET中重写它.我们使用C++/CLI重用了足够模块化的代码(大约20%的代码 - 主要是性能关键的数字运算内容,应该用C++编写),但其余部分是从头开始重写的.它花了大约2个人年,但这个数字在很大程度上取决于应用程序的类型,团队的规模以及程序员的当然.我认为整个过程都是成功的:我们能够重新构建整个系统,以启用旧代码基本几乎不可能实现的新功能.我们还可以通过重新设计它们来避免我们在旧软件中经常遇到的问题.此外,在我们了解到需要灵活性的地方,新系统更加灵活和模块化.(实际上,我有时会惊讶于新功能可以很容易地融入到新系统中,即使我们在设计它时从未使用它们.)

简而言之:对于一个中等规模的项目(100k-500kloc),重写是一种选择,但你一定要注意价格和风险.如果旧的代码库质量很低并且拒绝重构,我只会这样做.

此外,你不应该犯两个错误:

  1. 聘请一位新的.NET程序员并让他/她进行重写 - 有些新人可以提供帮助,但大多数工作,特别是设计必须由对旧代码有足够经验的开发人员完成,因此他们有充分的理解的要求.否则,你只需用不同的语言重复你的旧错误(加上一些新的错误).
  2. 让C++程序员将重写作为他们的第一个C#项目.出于显而易见的原因,这是灾难的秘诀.当您处理该大小的项目时,您必须对您正在使用的框架有充分的了解.

(我认为这两个错误可能是为什么这么多重写失败的原因.)

  • 对于你列出的两个错误中的第一个,我认为你是100%正确的.重写项目是解决很多问题的好机会,但前提是你确切知道第一次迭代出了什么问题.开发第一个人(如果他还在附近)的人将有一个新手到s/w的洞察力还没有. (4认同)

Sha*_*men 19

之前已经尝试过,不仅是C++ => C#,而且VB6 => VB.NET,C++ => Java以及您能想到的任何其他旧=> new.它从来没有真正奏效.我认为,因为人们不认为转换是真正的(完全重写),所以他们倾向于认真对待.

来自C++ => .NET的迁移故事应该通过CLI,仔细决定哪些托管和什么仍然是不受管理的,然后慢慢地"修复"一块一块.


sea*_*n e 12

Expression Blend最初是一个MFC应用程序.当前版本使用WPF作为UI,但引擎仍然是本机的.大约一年前,我看到了首席建筑师Henry Sowizral的一次精彩演讲,他描述了移民的过程.使引擎UI不可知,您将能够支持最新的UI技术.表达团队在某一点上拥有他所说的水头版.两个前端UI与一个底层引擎同时运行 - 这样他们就可以看到行为无意中偏离了以前的版本.由于UI订阅了事件和通知,因此在WPF工具窗口中所做的更改会反映在旧的MFC工具窗口中.

编辑:看起来像这里有一些powerpoint 或html这里.


Rya*_*yan 5

我已经完成了一个项目,它完全按照大小相同的代码库完成了你所描述的内容.最初,我完全被重写了.它结束了3年多,几乎变成了死亡之旅.总的来说,我现在更多地同意渐进主义者.

但是,根据我们的经验,我会说这样的重写(特别是如果你能够在.NET中重用一些C++业务逻辑代码),并不像它看起来那样具有技术危险性. 但是,它可能非常危险!

首先,你必须确保每个人都完全理解你最初所做的是"重写"(或"重拍")而不是升级或"重新构想".1998年的Psycho是1960年原版的重拍.2003年太空堡垒卡拉狄加是1978年原版的重新构想.看到不同?

在我们的例子中,最初的计划是在.NET中重新创建现有产品.这在技术上并不令人生畏,因为我们理解原来的井.然而,在实践中,添加和修复并改进一些事物的冲动被证明是不可抗拒的,并且最终在时间线上增加了2到3年.

其次,你必须确保从高级管理人员到销售人员到最终用户的每个人都可以在重制过程中保持当前产品不变.如果您的市场正在发展,那么您将无法在此期间维持业务,那么就不要这样做.

所以我们的主要障碍是社交,而不是技术.由于缺乏明显的进展,用户和商业利益变得非常沮丧.每个人都觉得有必要推动他们自己的宠物改进和功能,所以我们的最终产品只与原始产品表面上有相似之处.这绝对是一种重新构想而非翻拍.

最后它似乎对我们来说没问题,但这是一个真正的磨难,而不是我们再次选择做的事情.我们通过很多善意和耐心(内部和外部)来焚烧,这可以通过增量方法在很大程度上避免.