用户登录
转载自《电脑爱好者》
这篇文章虽然有点旧，不过今天看来仍相当有现实意义。尤其是最后一句实在是对完美的最佳表述。
在动笔写这篇文章前，我心中一直是非常犹豫的：我明白自己距离一个优秀程序员还差得很远，但是又的确想把自己的想法和各位程序爱好者交流，矛盾中就有了这些文字，其中若有不妥之处还希望各位多多指点。我并不准备谈如何达到编写完美程序的境界，相反，我只想和那些愿意切切实实完成日常编程任务的人们谈谈。说实在的，在这个Windows时代，我心中惟一的目标就是那个最终的可以使用的软件成品，而我并不会费心去考虑是否每个细节都做到灵气四射，我只想在精疲力尽之前好好完成代码的编写工作，仅此而已。
我想Immanuel Kant的话最能代表我的观点了：“没有弯弯曲曲的原木便没有笔直的木板”，我把它理解为不要期望你的程序完美无比，更不用浪费时间费尽心机把它变得完美。相反，你应该试着把目标定得低一些，并不十分完美，只是“这个程序已经接近bug－free了”，或者至少“嘿，它正确工作了”，而把自己的注意力放在整体全局，更快、更方便、更安全地完成目标那才是最好的结果。
一、离开Windows API的日子
同样完成一个Windows下的软件开发工作，你可以通过两种方式：自己可以动手编写Windows API代码，或者你也可以使用可视化RAD（Rapid Application Development，快速程序开发）工具拖拽控件然后响应消息。Windows API代码绝对代表了晦涩与高效的完美统一，真好比DOS时代之汇编，而可视化控件则代表了高效与高速的开发过程。一个恰当的控件几乎可以免去一个程序员几周的工作时间。虽然RAD的初衷相当不错，在大多数情况下也的确可以避免代码的重复编写，可是，以前的Visual Basic和Power Builder似乎给了人们一个“RAD烙印”，RAD仅仅是“快速开发”而已，离“快速程序”还远得很。但随着Visual Basic的不断进步，Delphi和Borland C++ Builder（对不起，我还是不习惯称它Inprise）的完善，这个看法就需要更新了，新一代的RAD距离真正的RAD又近了一大步。下面我们就拿C++ Builder的VCL（Visual Component Library）和Windows API来做个比较。BCB的控件都是基于VCL库的，而VCL和BCB的关系就好比Visual C++之MFC及Borand C++之OWL一样密不可分。请注意下面代码中用来初始化Picture属性的LoadFromFile方法：
if (OpenDialog1 -> Execute())
{Image1 -> Picture -> LoadFromFile(OpenDialog1 -> File Name);
Image1->Stretch=True;
}
TImage控件的LoadFromFile方法完全遮盖了把BITMAP图像读取至内存、分配一个句柄然后把它传送给TImage控件以把图像显示在用户面前的复杂过程，这种能够把用户直接和Windows API打交道的复杂过程全部打包正是VCL的一大特色。但是如果你还是把控件看作是“黑箱操作”那就大错特错了，VCL中的控件与OWL、MFC或者其他OOP函数库都不同，VCL的所有源程序都随着C++ Builder的发布而发布，当然，你同样也可以从Borland得到。这也意味着你得到VCL源代码的同时你还可以用BCB创建自己的控件，如果你更愿意成为一个亲近Windows API的系统黑客的话，你随时随地都可以在BCB中使用Windows API。不容置疑，作为优秀的VCL程序员，他应该尽可能地使用控件，因为这些控件十分健壮且相当程度的高效。当然，我相信TImage控件中一定还包含了你没有使用到的代码部分，为了减缩最终程序的体积并提高运行速度你当然可以重写一个，但是那样的做法将会耗去非常多的工作时间。放弃5％的运行效率而缩短80％的开发时间，虽然离开Windows API不是那么的完美，但是我们已经相当接近了，不是么？
二、知人善任你的控件
曾经有这样一个幽默来形容不同程序员对待控件的态度，虽不十分确切但也颇有几分哲理：几个程序员同时面对着一个渡过一条波涛汹涌的大河的问题，可是河上竟然没有一座现成的桥可用。VisualC/C++程序员二话不说立即开始培土、种树、伐木、设计、制造，埋头苦干六个月后终于建成了一座双臂悬索式带回旋引桥且富丽坚固的大桥，VC程序员们高高兴兴地过了河；相比之下Visual Basic程序员倒是悠然自得，慢慢打开手提式电脑上网查找“桥梁”，可结果非常令人失望，在附近只找到一些锈迹斑斑的铁索。可河还是要过的呀，他们只得咬咬牙，腾空悬在铁索下摇摇摆摆、提心吊胆地慢慢向对岸挪。不幸中的万幸，铁索控件没有崩溃，他们艰难地过了桥，前后只用了三天。Delphi程序员上网查找“桥梁”后也只发现了铁索，不过他们在修补锈损铁索的同时向VisualC/C++程序员要了些木板。不出一个星期，一座虽不豪华但美观牢固的铁索桥落成了，Delphi程序员们兴高采烈地过了河，当然忘不了向正在忙碌的VC程序员们挥手致谢。
没错，虽然 Visual C/C++、Visual Basic、Delphi和C++ Builder都提供了丰富的可视化控件，搭积木似的开发中它们已经足够应付日常的需要。但是捉襟见肘的一天总会到来。假如你需要开发一个JPG转GIF格式的任务而身边没有一个现成控件可以帮助你，那么你有两条路可以选择：一个是像传统VC程序员一样找本关于文件格式的图书并着手写从JPG转向GIF的代码，另一个就是同VB和Delphi程序员一样在网络、书店或者像“程序员天堂”(www.pparadise.com)之类的代码资源便利店寻找或者购买自己需要的控件、函数库等。现在你必须做出抉择：成为一个底层控件编制者还是普通程序设计师？大多数的程序员兼而有之，但迫使你做出抉择的那一天总会来到你的面前！你或许会认为你可以同时生活在两个世界之中，但实际并非如此，习惯是很不容易更改的。嗨，还是暂时别想这个JPG-to-GIF工具了，这里有一些你必须考虑到的事实：
1．你不能忽略JPG和GIF格式有许多版本，不同版本之间的细微差别能否轻易忽略？
2．你不能只处理16位色的文件，你至少需要考虑到8位、16位和24位的！别忘了新的格式可能不断涌现哟，注意及时更新！
3．你的代码应该易于维护，不能仅仅为了完成任务而完成任务，否则，如果你想为你的工程增添一种格式怎么办？如果你必须把程序移植到：32位色的系统上去怎么办？如果你又想支持OLE自动化怎么办？这些你也要考虑考虑。
4．想想那些go on and on的Bugs。你的代码纯洁吗？如果读取了坏JPG文件怎么办？用户对能够处理文件的大小要求苛刻又怎么办？
仔细想想吧，乐观估计一个星期能够完成吗？也许你非常出色，按时完成了任务，但是大多数程序员两星期时还只拿得出BETA测试版而已，接着的两周只能用作测试与捉虫子了。那么到“程序员天堂”等网站寻找一个控件会要多少时间呢？大概一个小时就可以了吧，而且它还可能是免费的或是提供源代码的！当然，不排除运气坏的情况，但这毕竟是少数。所以我的观点是，和以往深入底层代码的HACKER时代不同，在如今的编程中应该尽量减少低级代码的编写，如果能找到现成的，拿来主义+修正主义就是了，实在不行的话再着手开发也为时不晚。此外，这里还有一个不同控件之间的搭配技巧问题，有时候几个控件的组合效果或许正是你想要的。事实上，Borland C++ Builder的开发小组分为两部分：一部分是系统专家，他们的任务是设计对象类和写控件，而另一部分的程序员是这些控件的“消费者”，他们研究如何灵活调配不同控件以达到RAD这个最终目的，两个小组地位同等并没有贵贱之分。所以，除了特殊的系统底层应用程序，优秀的程序员应该学会尽量使用现成的成熟控件，学会搭积木，而且搭好积木。控件虽千变万化，但存乎一心知人善任者，这才是最终的完美。
三、技术的抉择
Object Pascal or C++？
Visual Basic or Delphi？
MFC or VCL？
C or C++？
……
这些问题就像To be or not to be困扰着哈姆雷特一样困扰着许多程序员。真难以分辨，更难以自拔。优秀程序员都有一种偏执倾向，谁都想掌握最完美的东西，谁都不愿意看到自己所擅长的完美技术被别人轻视。某些惧外主义者认为，外国人演讲的不尽人意之处很大程度要归咎于他所继承的文化背景有缺陷。但对于能同时掌握C++和Object Pascal两种语言的人而言，这种说法则会不攻自破，因为他们能够深刻体会到C++的博大多变令Object Pascal相形见绌。正如Object Pascal的朴素高雅颇令C++显得文过饰非。同样的，Visual Basic虽然不如Delphi先天那么强大，但是的的确确的快速开发以及仗着Bill Gates多年以来的钟爱有加，Visual Basic不久便会彻底支持面向对象，前途不能不说光明。本是同胞兄弟的C与C++也颇让人费思量。人人知道C++面向对象的好处，是它构筑了现代计算机程序的大部分基石。但是要确切地抽象事物本质并组织好却不是易事，否则MFC大可独行天下，决不会再有什么VCL出现的必要了。况且，C语言的鼻祖Dennis W. Ritchie在北大演讲时明确指出C和C++完全是两种思维方式的不同，并不存在孰优孰劣的问题。所以，只有一样东西是不需要争论完美的，那就是个人爱好问题，就像法语非常优美，相形之下西班牙语就显得略微平淡，但这并不意味着法语优于西班牙语，在餐桌上你大可用西班牙语丰富的用餐词汇来充分表达你的褒美之词！
没有一种技术是完美的，但无论你给我一个多么小的ε，我肯定能够找到一个技术的某个部分，使得这个部分离开完美的距离小于ε，无限趋近但永不相交，这才是完美的真谛！
