RAD与non-RAD

RAD与non-RAD
         申 旻 2002年7月于珠海
   似乎说到Delphi，就会谈到这个话题。不错，Delphi是RAD（Rapid Application Development，快速应用开发工具）。
   VB的出现掀起了一场编程方式的革命，它带来了可视化编程，一种无数程序员所梦想的编程方式。但从此，也给人留下了这样的印象--RAD就是“搭积木”。这也让一些“高手”对RAD不屑一顾。很多初学者感觉VB好用，立刻就可以写出一个能看得上眼的程序，但在学习、使用一段时间后，便感觉无从更进一步了。于是，又责怪RAD太过于简单。甚至许多熟练的Delphi程序员都会有着类似的担心，RAD是不是难登大雅之堂？
或许，用VB进行开发，的确可以算是“搭积木”。但是，请不要认为这就是RAD的全部。而且，Delphi绝对不等同于VB！
首先，RAD是提高生产效率的工具。工具是被人们用来解决实际问题的，而不是用来炫耀或作为理论来学习的。好的工具应该可以帮助使用者快速、有效地达成目的，那么，RAD正是扮演了这样一个角色。它让你能够专注于问题的重点，用别人写好的、经过大量使用测试的现成控件按照项目的业务逻辑，组装成符合客户需要的软件产品，既保证了开发速度，又提高了质量（可以近似认为现成的控件是零bug的）。从这个意义上来说，“搭积木”的开发方式是有存在的价值的，这也是全世界程序员所梦想的“模块化”的一种形式。“搭积木”本身并没有错，RAD并没有错。
其次，RAD是工业的开发工具，不是学习工具。众所周知，RAD简单易用，初学者一接触到RAD，就仿佛找到了学习的捷径。但是，最终可能会让这些人丧气，因为简单易用的背后，是需要扎实的基础作为依托的。RAD出现的初衷就是让开发者不必考虑太多的恼人的细节，但并非不需要相关的基础理论的支持。例如，当用Delphi开发基于TCP协议的网络应用时，你不必知道TCP包的格式，但是，如果连IP地址都不知道是何物，纵使有RAD也无补于事，而且，知道得越多，在出问题时就越容易解决。RAD的简单易用只是降低了开发人员在尝试使用RAD时的学习曲线。又如，假设精通Windows环境下的SDK编程，能脱口而出所需要的Win32 API，于是，当你使用Delphi时，就不会有什么困难，至多熟悉一下VCL是如何封装这些API就可以了。如果Delphi是非常难学难懂的开发工具，你会耗费精力去用它吗？不如直接用SDK开发了。如果将掌握RAD本身作为学习目标的话，那么你注定至多只是个业余的编程爱好者而已（没有贬低爱好者的意思，只是相对于专业程序员而言）。在此，笔者有一些题外话，这就是经常可以听到有人说现在大学计算机专业学习的内容与实际需要脱节之类的话。其实如何才算不脱节呢？真的要学校教VB、VC、Delphi才算不脱节？如果真是这样的话，VB、VC、Delphi都淘汰了怎么办？那才是真正的悲哀呢。言归正传，所以，RAD不是学习的捷径，RAD是实现的利器。
最后，RAD和non-RAD是互补的。RAD和non-RAD有着不同的适合领域，拥有各自的存在原因和拥护群体，它们的存在并没有冲突，也不必人为地将它们对立起来。常可见non-RAD的使用者嘲笑RAD的使用者“低阶”，其实这些所谓“高手”只是眼高而已。使用VC的一定比使用VB的人“高阶”？项目中使用什么编程语言、开发工具，时常并不是你个人所能左右的，会受很多因素制约。例如，客户的硬件环境、操作系统环境，开发环境，开发工具的成本、许可证等，所以使用什么工具说明不了问题。况且，专业程序员不应该是忠于开发工具，而是应该忠于自己的编程理念。一个人只会说“最喜爱XX开发工具”，“最熟悉XX开发工具”，绝不会说“我是使用XX开发工具的”。所以，RAD并不等于低阶，non-RAD并不意味着高人一等。RAD和non-RAD的存在，并不冲突。个人水准的高低，也不是通过所使用的工具来表现的。
很多刚入门的编程爱好者，摆弄了几天VB或Delphi或C++Builder，拖拉几个控件弄出个EXE之后，便宣称自己已经学会了编程，这就有些盲目了。这也是为什么RAD会被人误会的原因之一。不可否认，RAD的出现，使得编程的门槛变低了。但是，入了门槛并不等于都掌握了，程序设计本身是一门博大精深的学问，做学问最重要的就是严谨、踏实。
   另外，虽然Borland一直宣称Delphi是RAD，但其实完全可以把Delphi 当作non-RAD的开发工具来用（即纯Object Pascal编译器），这也是其提供的自由度的一个表现吧！