说服管理层升级到Delphi 2009/2010有什么好的理由?

时间:2009-10-08 20:06:54

标签: delphi arguments upgrade

我们有一个中型到大型的应用程序。一个版本在Delphi 6上运行,另一个在Delphi 2006上运行。

一个论点是支持Unicode。我们需要这样才能满足全球客户的需求。

我读过的其他内容包括:更好的IDE(稳定性,速度),更好的帮助和一些很酷的语言添加(例如:泛型)

第三方组件怎么样?我们使用DevExpress,DBISAM和许多其他人。这些已经移植了吗?

触摸/手势听起来很酷,但在我们的应用程序中我们没有用它。

12 个答案:

答案 0 :(得分:10)

更好的主题支持(例如,TStringGrid / TDBGrid现在支持主题)。

支持Windows Vista和Windows 7,包括支持Win7中的Direct2D Canvas以及您提到的Touch / Gesture支持。

改进了重构,包括支持重构泛型。

内置源代码格式化程序。

IDE Insight允许您在IDE中查找内容。

增强的RTTI。

调试器的改进,包括新的自定义数据可视化工具和创建自己的能力。源包含两个(一个用于TDateTime,一个用于TStringList)。还可以更好地支持调试线程,包括为调试命名线程并在特定线程上设置断点的能力。

能够通过接口向IDE添加版本控制支持。这将允许版本控制开发人员直接在IDE中添加支持。

帮助比以前的版本好很多。它已经完全重新设计,并且更加全面和完整。还有一个基于wiki的在线版本(用于生成帮助本身),您可以添加或编辑它。

后台编译允许您在编译项目时继续工作。

就第三方控制而言,这取决于具体的供应商;你必须检查Delphi 2010版本是否可以单独用于每个版本。 (你可以查看Embarcadero网站,看看他们是否已经有一个列表;我似乎记得听到过一个......啊,是的。Here它是。)

答案 1 :(得分:8)

  • 旧版本的上次升级

使用旧版本的Delphi(Delphi 2005之前),您只能在2010年1月1日之前升级。

您必须购买完整版本。

  • 生产率

http://www.tmssoftware.com/site/blog.asp?post=127

答案 2 :(得分:4)

纯粹作为一种反应措施。让我们说最新版本的尚未发布的操作系统有一个新功能。可以说,此功能会破坏应用程序中的某些功能。如果有一个全局修复它,很可能不会放在旧版本的编译器中,而是“正式”支持新操作系统的新版本。等待时间过长的最大问题是,当需要采取这样的措施时,通常在销售处于危险时的零时。

立即升级,帮助您的应用程序准备好对未来的更改做出更多反应。

答案 3 :(得分:3)

不要说服他进行Delphi 2009/2010升级,为软件保障做这件事。

答案 4 :(得分:2)

  • 重构工具和整体 IDE的速度和稳定性 让开发团队更多 生产性。

  • 使用最新工具可以更轻松地招募顶尖人才。

答案 5 :(得分:2)

IDE绝对是Delphi 6和/或Delphi 2006的一步。

如果Unicode对您的客户很重要,那么Delphi 2009/2010是一个明确的选择。但如果Unicode对而不是你的客户很重要,那么我会小心。

Unicode不是“免费”的。如果您的用户/客户对内存占用和/或性能有疑虑,并且/或者您的应用程序涉及大量字符串处理,那么Unicode确定了客户必须支付的全部的价格,以及客户本身并不关心Unicode的支持,这个价格对他们来说没有任何好处。

同样,如果您的应用程序位于当前未启用Unicode的数据库架构之上。将现有数据库从非Unicode迁移到Unicode是非常重要的,如果您的客户拥有大型生产数据库,那么在他们迁移数据存储时会导致这些客户的停机时间,您应该仔细考虑。

此外,您需要非常了解外部系统的任何接口 - 您的代码将单方面“转为Unicode”,这可能会对的其他系统的外部接口产生负面影响。< / p>

在这种情况下,您最好将过渡到Unicode与其他引人注目的功能改进和优势结合起来,以使转换因其他原因而引人注目。

此外,如果您确实让客户真正需要真正的Unicode,那么转换并不像使用最新/最好的编译器和VCL重新编译那么简单。真正的Unicode支持将使您的应用程序代码中的工作量比您最初所理解的要多得多。

当然,拥有支持Unicode的编译器/ VCL是一个至关重要的组件,但它本身并不是一个答案。

Unicode更改对第三方组件有重大影响。即使您拥有第三方代码的来源,您也可能会发现自己在该代码中面临Unicode问题,除非供应商已采取措施在更新版本中更新该代码。我认为,目前大多数供应商库都是Unicode,所以除非您使用供应商不再支持的库,否则您应该可以获得该分数。

对于那些“酷”语言功能(如泛型),我也会谨慎行事。它们确实看起来很酷,但是它们有一些严重限制的特性,你会在功能演示之外遇到它们,并且由于社区与它们合作的经验有限,可能导致维护和调试困难,所以“最佳实践”还有出现并且工具支持可能尚未赶上实际代码中这些功能的用途。

ALL ....由于你无法现实地选择除Delphi 2010以外的任何版本升级,那么如果要进行升级那么你必须咬掉Unicode子弹并会发现自己有很多诱人的语言功能来修补和分散你的注意力。 ;)

现在Embarcadero正在制定一项更严格的政策以及符合条件的升级产品,如果您希望获得Delphi 20 * 11 *的升级价格,您将 离开Delphi 2006,您是否认为2010款适合您,否则当您升级到Delphi 2011时,您会发现自己被视为新客户,如果您认为升级价格很高,请检查超出新的用户许可证费用!

答案 6 :(得分:1)

D2006是Delphi的糟糕的版本。升级只是为了摆脱所有内存泄漏和随机IDE崩溃和故障。向老板证明这是对生产力损失的大幅减少。这意味着为了不生成代码而浪费的钱更少,因为你的开发工具不起作用。仅在此基础上它就会很快收回成本。

至于D6与D2010,这是一个特色论点。从Skamradt的回复开始,它可以帮助您的代码面向未来。通过操作系统兼容性来强调它。 D2007是第一个了解Vista的版本。 D2010是第一个了解Windows 7的版本。如果您使用任何旧版本进行编译,则在部署之前您的应用程序已经过时,因为无法保证它与现代版本的Windows兼容。

然后你就有了实际的语言功能。从2006年到2010年,IMO的主要改进是Generics,它可以帮助解决各种重复性任务,并扩展RTTI。 Robert Love最近一直在做一些关于扩展RTTI如何简化常见现实问题的博客文章。 (当然还有Unicode。)

答案 7 :(得分:1)

扮演恶魔的倡导者,可能有理由不升级。例如,您可能缺少某些组件的源代码,或者您可能仍需要支持Win9X。

我认为您可能会发现升级的最佳理由(将所有新的wizz-bang功能放在一边)是您在新IDE中的效率会大大提高。如果你没有/不能升级我建议你抓一个Castalia的副本,它可以让你在Delphi 6中获得许多生产力增强(例如重构)。

答案 8 :(得分:1)

DBISAM已更新,我上周刚刚通过电子邮件向他们发送了关于我希望从Delphi 3升级到Delphi 2010的项目的电子邮件。

我为该项目升级的所有其他软件包(WPTools,Infopower,TMS)都在其网站上声明它们与2010年兼容。

我从来没有过D2006(我有2007年)所以我不能说出那个特定版本中的任何缺陷(D2007也不是那么好),但它通常是保持你的工具良好状态的好主要。对于意味着尖锐的锯,对于意味着当前的软件。特别是在新的OS年中,您可能需要相应版本的主要开发环境。

答案 9 :(得分:1)

在我看来,开发专业应用程序有两个方面:

  1. 你想赚钱:你必须坚持客户的要求,保持你的东西亲吻,可维护等等......你必须高效:无论是泛型,RTTI,像flowpannel这样的小工具,手势等因为学习需要时间和使用时间更长。这样,从D7到D2010的变化不是必要的。更换另一个像REAL Basic这样允许多平面目标的IDE更准确。

  2. 但作为开发者,你身上有一个孩子和一个诗人,对新技术或/和算法着迷......这是这项工作的创造性部分。如果你想成为一个令人印象深刻和创新的人,你必须具有创造力。升级到Delphi 2010是必须的,搜索新类,新对象是当今编程中的一种生活方式。

  3. 这是我谦虚的观点以及让我花费我的钱将Delphi从I升级到2010年的原因。

    致以最诚挚的问候,

    迪迪埃

答案 10 :(得分:0)

The Joel Test: 12 Steps to Better Code的第9项是:

  

你使用钱可以买的最好的工具吗?

也许这个论点与此密切相关。

另一方面,如果您要维护遗留代码并且不生成任何依赖于新操作系统或工具功能的东西,那么获胜就是一个难题。但是,我不建议在旧的工具上生成全新的项目。

自从2001年加入MSLU以来,Windows至少支持NT 4.0以及Windows 95/98 / Me支持Unicode,所以Delphi 2006肯定支持它! [edit]它似乎不完全支持组件库。[/ edit]

我建议一个令人信服的论点是为了确保Vista和Windows 7的兼容性。据我所知,今年计划为德尔福提供64位目标支持。这可能是另一个论点;但同样它只适用于你真正打算以这样一个平台为目标,并且以一种比32位代码更有利的方式。 [edit]我强调计划因为我不知道它是否已经成为产品,但它可能是你的考虑因素。它似乎没有,所以你向管理层提出的论点可能更不强烈。[/ edit]

“我只想要很酷的工具”,管理层不会留下深刻的印象,你必须以“投资回报率”(ROI)为基础。您是否会使用此工具更快或更便宜地购买产品?现有工具是进步的技术障碍吗?相反,考虑花时间将遗留代码移植到新工具(使用相关的验证和测试)是否会导致您的预算和截止日期无效,从而无法获得商业优势?

答案 11 :(得分:0)

已经支持Delphi 2010的兼容组件列表(包括DevExpress(文章将定期从我们的技术合作伙伴数据库更新)位于

http://edn.embarcadero.com/article/39864

参数 - 除了组件和IDE的开放API之外,还有成千上万的工具和组件可用于您可能需要的东西。