曾经做过重写C++中的一个大型C++应用程序吗?[关闭]

您是否考虑过不要从头开始重新编写,而是应该开始分离GUI和后端层(如果还没有,那么您可以开始用C编写其中的一些部分)。

25万行不是一夜之间写出来的,它们包含了数十万人多年的努力,所以没有人明智地建议立即从头开始重写。

如果你们打算这样做,最好的方法就是一个接一个的。否则,在现有产品中没有实现新功能(基本上在竞争面前停滞不前)的情况下,向您的管理层请求几年的开发工作。

它以前已经尝试过,不仅是C++ +gt;c,而且vb6= & gt;VB.NET,c++=& gt;Java和任何其他旧的= & t;新的,你可以想到的。它从来没有真正起作用。我认为,因为PPL并没有考虑到真正意义上的转换(完全重写),他们倾向于轻视它。

从C++=和G..NET中迁移的故事应该是通过CLI,仔细地决定什么是托管的和什么仍然是非托管的,以及S-L O-W-L Y“一块一块”地固定。

我的公司确实做到了。我们有一个粗略的C++代码库,每个人(程序员、管理层、客户)或多或少都同意它不是最好的软件。我们希望在旧的代码库中实现一些非常困难的特性,所以我们决定(经过多次讨论和测试项目)在.NET中重写它。我们重用了使用C++/CLI模块化的代码(大约有20%的代码——无论如何都是用C++编写的性能关键的数字压缩的东西),但是其余的是从头开始重新编写的。这花了大约2个人年的时间,但是这个数字在很大程度上取决于应用程序的类型、团队的规模以及程序员。我认为这一切都是成功的:我们能够重新构建整个系统,以启用新的特性,而旧的代码库几乎不可能实现这些特性。我们还可以通过围绕旧软件重新设计来避免我们经常遇到的问题。此外,新系统在我们了解到需要灵活性的地方更加灵活和模块化。(事实上,我有时会惊讶于新特性可以多么容易地融入到新系统中,即使我们在设计时从未考虑过它们。)

所以简而言之:对于中型项目(100K-500kloc),重写是一种选择,但你必须清楚价格和风险。只有当旧的代码库质量很低并且抵制重构时,我才会这样做。

还有两个你不应该犯的错误:

1. 雇佣一个新的.NET程序员,让他/她进行重写——一个新的人可以帮助你,但是大部分的工作,尤其是设计工作都必须由对旧代码有足够经验的开发人员来完成,因此他们对需求有一个很好的理解。否则,你只需用不同的语言重复你以前的错误(加上一些新的错误)。
2. 让C++程序员把重写作为他们的第一个C项目。这是一个灾难的处方,原因很明显。当你处理一个如此规模的项目时,你必须对你正在使用的框架有一个扎实的理解。

(我认为这两个错误可能导致如此多的重写失败。)

ExpressionBlend最初是一个MFC应用程序。当前版本使用WPF作为UI,但引擎仍然是本机的。我看到了首席建筑师亨利·索伊兹拉尔一年前的一次伟大演讲,他描述了移民的过程。使引擎用户界面不可知,您将能够支持任何最新的用户界面技术。表情小组一度拥有他所说的九头蛇版本。两个前端UI与一个底层引擎同时运行-这样,他们就可以看到行为在无意中偏离了以前的版本。由于UI订阅了事件和通知,所以在WPF工具窗口中所做的更改反映在旧的MFC工具窗口中。

编辑 :看起来有些PowerPoint是 available here 或作为 html here .

我曾经经历过一个项目,它使用大致相同大小的代码库来完成您所描述的工作。最初,我完全加入了重写。最后花了3年多的时间,几乎变成了死亡行军。一般来说,我现在更赞同递增主义者。

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

首先,你必须确保每个人都完全理解你最初所做的是“重写”(或“重拍”),而不是升级或“重新想象”。1998年的《心理医生》是1960年原版的一次镜头重拍。2003年的《太空堡垒卡拉狄加》是对1978年的原作的重新想象。看到区别了吗?

在我们的例子中,最初的计划是在.NET中重新创建现有的产品。从技术上讲,这不会让人望而生畏,因为我们很好地理解了原版。然而,在实践中,仅仅增加、修正和改进一些东西的冲动被证明是不可抗拒的,并最终增加了2-3年的时间线。

第二,你必须确保从执行官到销售人员到最终用户的每个人都对你当前的产品在重新制作的开发过程中保持不变是满意的。如果你的市场在波动,你将无法在这段时间内维持你的业务,那么不要这样做。

因此,我们面临的主要障碍是社会性的,而不是技术性的。由于缺乏明显的进展,用户和商业利益变得非常沮丧。每个人都觉得有必要推动自己的宠物改进和特点,所以我们的最终产品只是表面上的相似性,原来。这绝对是一个重新想象而不是翻拍。

最后,我们的结果似乎不错,但这是一个真正的磨难,而不是我们会选择再次做的事情。我们消耗了大量的善意和耐心(包括内部和外部),这在很大程度上可以通过增量方法避免。

C++不会自动转换成C语言(无论如何,你不想保持它),而你在谈论使用不同的框架。

这意味着你要重写25万行代码。这实际上与一个新的250K生产线项目是一样的,只是你已经有了很好的需求规范。好吧,不是“很好”;毫无疑问,这里有一些代码很难理解,一些可能是因为重要的问题使得优雅变得困难,整体结构也会有些模糊。

那是一个非常大的项目。最后,您将得到的是执行相同操作的代码,可能有更多的bug,可能结构相当差(尽管您可以随着时间的推移进行重构),对未来的开发具有更大的潜力。它不会有任何人们在项目期间一直要求的新功能(除非你喜欢危险的生活)。

我不是说不做。我是说,你应该知道你在提议什么,成本是多少,收益是多少。在大多数情况下,这意味着“不要这样做!”

我也做了类似的事情。我的工作包括开发和支持一些称为ContractEdge的软件。它最初是由印度的一个团队在Visual C++ 6中开发的。在2004年基本完成后,我接管了开发角色。后来,当WindowsVista作为测试版发布时,我发现ContractEdge会在Vista中崩溃。同样的事情也发生在候选版本中。

所以我面临着一个决定。要么用数万行几乎不熟悉的代码来寻找这个问题,要么利用这个机会在.NET中重写它。嗯,我在2个月内用vb.net 2.0重写了它。我把它看作是一个完全重写,基本上放弃了所有东西,我只专注于用不同的语言复制功能。事实证明,我只需要写原始代码行数的十分之一。然后我们进行了一个为期一个月的测试程序来消除所有剩余的bug。紧接着,我们推出了它,这是一个巨大的成功,此后,比它取代的C++版本更少的问题。

在我们的特定场景中,我认为重写效果很好。这个决定变得更容易了,因为我们团队中没有人和C.NET一样熟悉C++。所以从这个角度来看,可维护性现在要容易得多。现在我认为C++对于大多数商业软件来说是太低的语言。你真的可以用更少的代码在.NET中完成更多的工作。我写了关于我的 blog .

为了重写而重写?我不推荐它。

除了其他的回答,我不会想当然地认为“更快的开发时间”。当然,对于大多数以数据为中心的“业务”应用程序来说,情况可能是这样的,但是有许多领域.NET不会带来显著的生产力提高,而且您需要考虑学习曲线。

当我们移动到.NET时,我们做了一个大的C++ & gt;c迁移。这是一个相当困难的项目。管理层几乎不愿意为它花钱,所以你必须妥协。最好的方法是在C++中保留最内层(或最低层),用C++来覆盖上面的部分,用更好的API设计更好的概念,如可读性和API可用性,用单元测试和高级工具(如FxCop)安全地保护。这显然是一场伟大的胜利。

它还可以帮助您更好地分层组件,因为它强制某些切割。最终产品不好,因为最终可能会在C++中复制大量代码,因为多年的编码包含许多bug修复和许多未文档化和难以理解的优化。在C中添加所有的指针技巧(我们的代码随着时间的推移从C演变成C++)。当你稳定的时候,你发现自己越来越多地阅读C++代码并把它移到C语言中,而不是一开始就想到的“更清洁的设计”目标。

然后你会发现互操作性能很糟糕。这可能需要第二次重写——也许现在就使用不安全的C代码。GRRR!

如果所有的团队成员都来自C++,新代码看起来也像是C++设计。尝试在团队中混合C语言和C++开发人员,这样你就可以在最后得到一个.NET一样的API。

过了一段时间,项目可能会失去兴趣,MGMT可能不会资助整个重写,因此最终得到一个Cy-糖包的C++代码,并且您可能仍然没有解决Unicode/64位问题。这真的需要一个非常仔细的计划。

我参与了一个非常类似规模的项目。由于新的硬件和新的需求,有必要重写GUI前端。我们决定用C++/CLI把这个移植到.NET。我们能够重新使用超过一半的代码,并且移植它非常好。

我们能够充分利用.NET最有意义的地方。这使得代码的主要部分更加清晰。我们发现这本书“Pro Visual C++/CLI和.NET 2平台”由史蒂芬R.G.弗雷泽非常有帮助。

您考虑过端口到C++.NET吗?可能会减轻疼痛。

我目前正在重写一个相当大的Web应用程序。

有一点需要记住的是,当从一种语言转换到另一种语言时,尤其是像C++到.NET之类的东西,可能是由于语言的进步或框架代码而导致的代码更少,也可能更干净。

这对于将来的可维护性来说是一个优势,即使有机会重新构建旧应用程序不那么健壮的方面。

一些附加评论。

根据您的应用程序的寿命,您可能会被迫以现代语言重写它,因为我怀疑C++开发人员会越来越难找到。

仅仅将应用程序转移到一种新的语言并不能获得那么大的回报。你可能还想重新设计应用程序!不要低估为此所需的努力。我想重新设计+重写的工作可能是原始实现工作的50%。(当然,50%是完全不科学的猜测)。

这是一种很容易让你自欺欺人的方式,“好吧,C和WPF的效率更高,重写这一团糟的东西简直是小菜一碟!”

有趣的是,大多数这样做的人的答案似乎是积极的。IMO最重要的是要有良好的单元测试,这样你才能确保你的重写完成你想要它做的(这可能与旧代码做的不完全相同)。