有什么好的论据可以说服管理层升级到 Delphi 2009 / 2010？
我们有一个中型到大型的应用程序。一个版本在 Delphi 6 上运行，另一个版本在 Delphi 2006 上运行。
一个争论是对 Unicode 的支持。我们需要它来满足世界各地的客户的需求。
我读过的其他内容包括：更好的 IDE（稳定性、速度）、更好的帮助以及一些很酷的语言补充（例如：泛型）
第三方组件呢？我们使用 DevExpress、DBISAM 等。这些已经移植了吗？
触摸/手势听起来很酷，但我们在我们的应用程序中没有使用它。
We have a medium-to-large size application. One version runs on Delphi 6 and another one on Delphi 2006.
One argument would be support for Unicode. We need that to cater to Customers around the world.
Other things I have read about are: better IDE (stability, speed), better Help and some cool additions to the language (e.g.: generics)
What about third-party components? We use DevExpress, DBISAM and many others. Are these already ported?
Touch/Gestures sound cool, but we have no use for that in our application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
不要说服他升级 Delphi 2009/2010，而是为了软件保障而这样做。
Don't convince him for a Delphi 2009/2010 upgrade, Do it for a Software Assurance.
重构工具和整体
IDE 的速度和稳定性
让开发团队更加
富有成效。
使用最新的工具可以更轻松地招聘顶尖人才。
The refactoring tools and overall
speed and stability of the IDE will
make the development team more
productive.
Working with the latest tools will make it easier to recruit top talent.
该 IDE 绝对是 Delphi 6 和/或 Delphi 2006 的一个进步。
如果 Unicode 对您的客户很重要，那么 Delphi 2009/2010 是一个明确的选择。但如果 Unicode 对您而不是您的客户来说很重要，那么我会小心。
Unicode 不是“免费”的。如果您的用户/客户担心内存占用和/或性能，和/或您的应用程序涉及大量字符串处理，那么 Unicode 会确定您的所有客户都必须支付的价格，并且对于以下客户他们自己并不关心 Unicode 支持，这个价格（对他们来说）带来的好处为零。
同样，如果您的应用程序位于当前未启用 Unicode 的数据库架构之上。将现有数据库从非 Unicode 迁移到 Unicode 并非易事，如果您的客户拥有大型生产数据库，那么您应该仔细考虑这些客户在迁移数据存储时造成的停机时间。
此外，您还需要非常清楚与外部系统的任何接口 - 您的代码将单方面“采用 Unicode”，这可能会对其他系统的外部接口产生不利影响，而其他系统不是。
在这种情况下，您最好将向 Unicode 的过渡与其他引人注目的功能改进和优势结合起来，以使过渡因其他原因而引人注目。
另外，如果您确实有真正需要真正 Unicode 的客户，那么转换并不像使用最新/最好的编译器和 VCL 重新编译那么简单。真正的 Unicode 支持将在您的应用程序代码中涉及比您最初想象的更多的工作。
当然，拥有支持 Unicode 的编译器/VCL 是一个重要组成部分，但它本身并不是答案。
Unicode 更改对第 3 方组件有重大影响。即使您拥有第 3 方代码的源代码，您也可能会发现自己在该代码中面临 Unicode 问题，除非供应商已采取措施将该代码更新为最新版本。不过我认为，目前大多数供应商库都是 Unicode，因此除非您使用供应商不再支持的库，否则您在这一点上应该没问题。
当涉及到那些“酷”的语言功能（例如泛型）时，我也会谨慎行事。它们确实看起来很酷，但它们有一些严重限制的特性，您将在功能演示之外遇到这些特性，并且可能会导致维护和调试困难，因为社区使用它们的经验有限，因此“最佳实践”还没有出现后，工具支持可能还没有跟上这些功能在实际代码中的使用。
话虽如此......由于您实际上无法选择除 Delphi 2010 之外的任何版本进行升级，那么如果您要升级，那么您必须咬紧牙关，并且会发现你会看到许多诱人的语言特征来摆弄你并分散你的注意力。 ;)
现在 Embarcadero 对符合资格的升级产品实施了更加严厉的政策，如果您希望获得 Delphi 20*11* 及以上版本的升级定价资格，您将必须退出 Delphi 2006，无论是您决定 2010 是否适合您，否则当升级到 Delphi 2011 时，您会发现自己被视为新客户，如果您认为升级价格过高，请查看新用户许可证费用！
The IDE is definitely a step up from Delphi 6 and/or Delphi 2006.
If Unicode is important to your customers then Delphi 2009/2010 is a clear option. But if Unicode is important to you, rather than your customers, then I'd be careful.
Unicode is not "free". If your users/customers have concerns w.r.t memory footprint and/or performance, and/or your application involves extensive string handling, then Unicode exacts a price that all your customers will have to pay, and for customers who are not themselves concerned with Unicode support, that price comes with zero benefit (to them).
Similarly if your application sits on top of a currently non-Unicode enabled database schema. Migrating existing databases from non-Unicode to Unicode is non-trivial, and if you have customers with large production databases, incurring downtime for those customers whilst they migrate their data stores is something you should consider carefully.
Also you will need to be very aware of any interfaces to external systems - your code will unilaterally "go Unicode", and that may adversely impact on external interfaces to other systems that are not.
In such cases you would do well to tie the transition to Unicode with other compelling feature improvements and benefits to make the transition compelling for other reasons.
Also, if you genuinely have customers with a real need for true Unicode, then the transition is not as simple as recompiling with the latest/greatest compiler and VCL. True Unicode support will involve a great deal more work in your application code than you might at first appreciate.
Of course, having a Unicode capable compiler/VCL is a crucial component, but it's not an answer on it's own.
The Unicode change has a significant impact on 3rd party components. Even if you have the source to your 3rd party code you may find yourself facing Unicode issues in that code unless the vendor has taken steps to update that code in a more current version. Most current vendor libraries are Unicode by now though I think, so unless you are using a library that is no longer supported by the vendor, you should be OK on that score.
I would also exercise caution when it comes to those "cool" language features such as generics. They sure do look cool, but they have some seriously limiting characteristics that you will run into outside of feature demonstrations and can result in maintenance and debugging difficulties as the experience of the community in working with them is limited, so "best practice" has yet to emerge and the tool support perhaps hasn't yet caught up with the uses to which those features are being put in actual code.
Having said ALL that.... Since you cannot realistically choose any version other than Delphi 2010 to upgrade to, then if you are going to upgrade at all then you have to bite the Unicode bullet and will find yourself presented with lots of tempting language features to tinker with and distract you. ;)
And now that Embarcadero are imposing a more draconian policy w.r.t qualifying upgrade products, you will have to get off of Delphi 2006 if you wish to qualify for upgrade pricing for Delphi 20*11* onward, whether you decide that 2010 is right for you or not, otherwise when the time comes to upgrade to Delphi 2011 you will find yourself treated as a new customer, and if you thought that upgrade pricing was steep, check out the new user license costs!
D2006 是一个糟糕的Delphi 版本。为了消除所有内存泄漏和随机 IDE 崩溃和故障，值得升级。向老板证明这是生产力损失的大幅下降。这意味着因为您的开发工具无法工作而浪费的钱会更少。仅凭这一点，它就能很快收回成本。
至于 D6 与 D2010，这是一个功能争论。从 Skamradt 的回应开始，它可以帮助您的代码面向未来。强调它与操作系统兼容性。 D2007是第一个支持Vista的版本。 D2010 是第一个了解 Windows 7 的版本。如果您使用任何旧版本进行编译，那么您的应用程序在部署之前就已经过时了，因为无法保证它与现代版本的 Windows 兼容。
然后你就得到了实际的语言特性。 IMO 从 2006 年到 2010 年的主要改进是泛型（它有助于完成各种重复性任务）和扩展的 RTTI。 Robert Love 最近发表了一些精彩的博客文章，介绍扩展 RTTI 如何简化常见的现实问题。 （当然还有 Unicode。）
D2006 was an awful version of Delphi. It's worth upgrading just to be rid of all the memory leaks and random IDE crashes and glitches. Justify it to the boss as a massive decrease in lost productivity. That means less money wasted paying you to not produce code because your dev tools aren't working. It'll pay for itself very quickly on that basis alone.
As for D6 vs. D2010, that's a feature argument. Start with Skamradt's response, that it helps your code be future-proof. Underscore it with OS compatibility. D2007 was the first version that understands Vista. D2010 is the first version to understand Windows 7. If you're compiling with any older version, your app is obsolete before you even deploy it because there's no guarantee it's compatible with modern versions of Windows.
Then you've got actual language features. The main improvements IMO from 2006 to 2010 are Generics, which helps out with all sorts of repetitive tasks, and extended RTTI. Robert Love has been doing some great blog posts lately on how the extended RTTI can simplify common real-world problems. (Plus Unicode, of course.)
玩恶魔主宰，可能有不升级的理由。例如，您可能缺少某些组件的源代码，或者您可能仍然需要支持 Win9X。
我认为您可能会发现升级的最佳理由（抛开所有新的 wizz-bang 功能）是您在新 IDE 中的工作效率将显着提高。如果您不/无法升级，我建议您获取一份 Castalia，它可以让您访问 Delphi 6 中的许多生产力增强功能（例如重构）。
Playing the devils advocate, there may be reasons not to upgrade. For instance you might be missing the source to certain components or you may still need to support Win9X.
I think you'll probably find the best reason to upgrade (leaving all the new wizz-bang features aside) is that you'll be significantly more productive in the new IDE. If you don't / can't upgrade I'd recommend grabbing a copy of Castalia, which can give you access to many productivity enhancements (e.g. refactoring) in Delphi 6.
DBISAM 已更新，上周我刚刚通过电子邮件向他们发送了有关我希望从 Delphi 3 升级到 Delphi 2010 的项目的信息。
我考虑为该项目升级的所有其他软件包（WPTools、Infopower、TMS）都在其网站上声明：它们提供与 2010 的兼容性。
我从未使用过 D2006（我有 2007），所以我无法谈论该特定版本中的任何缺陷（D2007 也不是那么好），但它通常是保持工具良好状态的一个好原则形状。对于锯来说，意味着锋利；对于软件来说，意味着电流。特别是在新操作系统的一年，您可能需要主要开发环境的相应版本。
DBISAM is updated, I just emailed them this past week concerning a project I hope to be upgrading from Delphi 3 to Delphi 2010.
All the other packages I looked into upgrading for that project (WPTools, Infopower, TMS) all state on their websites that they offer compatibility with 2010.
I never had D2006 (I have 2007) so I can't speak to any defects in that particular release (D2007 isn't that great, either) but it's generally a good principal to keep your tools in good shape. For a saw that means sharp, for software that means current. Especially in a new-OS year, you probably want the corresponding version of your primary development environment.
在我看来，开发专业应用程序有两个方面：
你想赚钱：你必须坚持客户的需求，保持你的东西 KISS，可维护等等...你必须高效：不泛型、RTTI、flowpannel、手势等小部件的问题，因为它需要时间学习和更多时间使用。这样，从 D7 到 D2010 的更改就没有必要了。更改为其他 IDE，例如 REAL Basic，允许多平台目标更加准确。
但是作为一名开发人员，你内心有一个孩子和一个诗人，对新技术或/和算法着迷......这是工作的创造性部分。如果你想给人留下深刻的印象并成为创新者，你就必须具有创造力。升级到 Delphi 2010 是必须的，寻找新的类、新的对象是当今编程的一种生活方式。
这就是我的拙见，也是我花钱将 Delphi 从 I 升级到 2010 的原因。
最诚挚的问候，
Didier
It seems to me there are 2 aspects in developing professional applications:
You want to earn money: you have to stick to your customer's demands, keep your stuff KISS, maintainable and so on... You have to be productive: no matter of generics, RTTI, widgets like flowpannel, gesture and so on because it takes time to learn and more time to use. In this way, change from D7 to D2010 is not nessary relevant. Change for another IDE like REAL Basic allowing multiplaform target is more accurate.
BUT as a developer there is a child and a poet in you, fascinated by new technologies or/and algorithms... This is the creative part of the job. You got to be creative if you want to be impressive and innovator. Upgrade to Delphi 2010 is a must have, searching for new classes, new objects is a way of life in today's programming.
That's my humble point of view and the reason that keep me spend my money to upgrade Delphi from I to 2010.
Best regards,
Didier
已支持 Delphi 2010 的兼容组件列表（包括 DevExpress）（文章将定期从我们的技术合作伙伴数据库更新）位于
http://edn.embarcadero.com/article/39864
参数 - 除了组件和 IDE 的开放 API 之外，还有数以万计的工具和组件可满足您可能需要的需求。
Lists of compatible components that already support Delphi 2010 including DevExpress (article will be periodically updated from our technology partner database) is at
http://edn.embarcadero.com/article/39864
Argument - tens of thousands of tools and components available for the things you might need in addition to the open api(s) for components and the IDE.
Joel 测试：改进代码的 12 个步骤的第 9 项是：
也许这个论点在这里是密切相关的。
另一方面，如果您维护遗留代码并且不生成任何依赖于新操作系统或工具功能的内容，那么这是一个很难获胜的论据。然而，我不建议使用旧的工具生成全新的项目。
Windows 至少从 NT 4.0 开始就支持 Unicode，而 Windows 95/98/Me 自 2001 年添加 MSLU 以来就支持 Unicode - 那么 Delphi 2006 肯定支持它！？ [edit]组件库似乎没有完全支持。[/edit]
我认为一个令人信服的论点是为了确保 Vista 和 Windows 7 的兼容性。据我所知，今年 Delphi 计划支持 64 位目标。这可能是另一个论点；但同样，它仅适用于您确实打算针对这样的平台，并且以某种方式比 32 位代码带来切实的好处。 [edit]我强调了计划，因为我不知道它是否已经进入产品，但它可能是你的考虑因素。看来还没有，所以你向管理层提出的论点可能更不那么有力。[/编辑]
管理层不会对“我只是想要很酷的工具来玩”留下深刻的印象，你必须以一种“投资回报率”（ROI）基础。使用此工具您会更快或更便宜地推出您的产品吗？现有工具是否会成为进步的技术障碍？相反，考虑一下花时间将遗留代码移植到新工具（以及相关的验证和测试）是否会浪费您的预算和截止日期而没有商业优势？
Item 9 of the The Joel Test: 12 Steps to Better Code is:
Perhaps this argument is germane here.
On the other hand if you are maintaining legacy code and not generating anything that has dependency on new OS or tool features, it is a hard argument to win. I would not however recommend generating entirely new projects on tools that old.
Unicode has been supported on Windows since at least NT 4.0, and for Windows 95/98/Me since the addition of MSLU in 2001 - so surely Delphi 2006 supports it!? [edit]Not fully supported in the component library it seems.[/edit]
I suggest that the one compelling argument is in order to ensure Vista and Windows 7 compatibility. I understand that 64bit target support was planned for Delphi this year. That may be another argument; but again it only applies if you actually intend to target such a platform, and in a way that will give a tangible benefit over 32bit code. [edit]I emphasised planned because I did no know whether it had made it into the product, but that it might be a consideration for you. It seems it has not, so the argument you put to management might be even less strong.[/edit]
Management are not going to be impressed by the "I just want cool tools to play with", you have to approach it on a "Return on Investment" (ROI) basis. Will you get your product out faster or cheaper using this tool? Are the existing tools a technical barrier to progress? Conversely, consider whether spending time porting your legacy code to new tools (with the associated validation and testing) will kill your budgets and deadlines for no commercial advantage?
更好的主题支持（例如，TStringGrid/TDBGrid 现在支持主题）。
支持Windows Vista和Windows 7，包括Win7中对Direct2D Canvas的支持以及您提到的触摸/手势支持。
改进了重构，包括对重构泛型的支持。
内置源代码格式化程序。
IDE Insight 允许您在 IDE 本身中查找内容。
增强型 RTTI。
调试器的改进，包括新的自定义数据可视化器以及创建自己的数据可视化器的能力。源代码中包含两个（一个用于 TDateTime，另一个用于 TStringList）。还更好地支持调试线程，包括命名用于调试的线程以及在特定线程上设置断点的能力。
能够通过接口向 IDE 添加版本控制支持。这将允许版本控制开发人员直接在 IDE 本身中添加支持。
帮助比以前的版本好得多。它再次被完全重新设计，并且更加全面和完整。还有一个基于 wiki 的在线版本（用于生成帮助本身），您可以添加或编辑。
后台编译允许您在编译项目时继续工作。
至于第三方控制，则取决于特定供应商；您必须检查 Delphi 2010 版本是否适用于它们中的每一个。 （不过，您可以检查 Embarcadero 网站，看看他们是否有可用的列表；我似乎记得听说过一个……啊，是的。就是这里。）
Better theme support (eg., TStringGrid/TDBGrid now support themes).
Support for Windows Vista and Windows 7, including support for the Direct2D Canvas in Win7 and the Touch/Gesture support you mentioned.
Improved refactoring, including support for refactoring generics.
Built-in source code formatter.
IDE Insight allows you to find things in the IDE itself.
Enhanced RTTI.
Improvements in the debugger, including new custom data visualizers and the ability to create your own. There are two included with source (one for TDateTime and one for TStringList). Also better support for debugging threads, including the ability to name threads for debugging and set breakpoints on specific threads.
The ability to add version control support to the IDE via interfaces. This will allow version control developers to add support directly in the IDE itself.
The help is much better than in previous versions. It's been completely redesigned again, and is much more comprehensive and complete. There's also an online wiki-based version (used to generate the help itself) that you can add or edit.
Background compilation allows you to continue working while you're compiling your project.
As far as third party controls, that's up to the specific vendor; you'll have to check to see if Delphi 2010 versions are available for each of them individually. (You might check the Embarcadero web site, though, to see if they have a list already available; I seem to recall hearing of one... Ah, yes. Here it is. )
对于旧版本的 Delphi（Delphi 2005 之前），您只能在 2010 年 1 月 1 日之前进行升级。
之后您将必须购买完整版本。
http://www.tmssoftware.com/site/blog.asp?post =127
With old version of Delphi (before Delphi 2005), you have only before january 1 2010 to upgrade.
After you will have to buy a full version.
http://www.tmssoftware.com/site/blog.asp?post=127
纯粹作为一种反应性措施。假设尚未发布的操作系统的最新版本中有一个新功能。假设此功能破坏了应用程序内的某些功能。如果要对其进行全局修复，那么它很可能不会放置在旧版本的编译器中，而是放置在“正式”支持新操作系统的新版本中。等待时间过长的最大问题是，当需要采取这种措施时，通常是在销售面临风险的零时。
立即升级，帮助您的应用程序做好准备，以便更好地应对未来的变化。
Purely as a reactive measure. Lets say that there is a new feature in the latest version of a yet to be released operating system. Lets say that this feature breaks certain features inside your application. IF there was to be a global fix for it, it would most likely not be placed in older versions of the compiler, but the newer versions which "officially" support the new operating system. The largest problem about waiting too long is that when such a measure is needed its generally at the zero hour when sales are at risk.
Upgrade NOW, and help prepare your application to be more reactive to future changes.