Programming 不必是自我虐待

簡體傳統

1997.04

我整理了最近几篇读者来函，希望与大家分享。其中有对 SDK、MFC、RAD 的看法与疑惑，有与我的谈心，也有对我个人的赞美。关於後者，我放上来是为了让大家知道，一颗努力执着的心，可以获得怎样巨大的回响，以此安慰并鼓励所有心系理想的资讯人。这些信件经过「依媚儿」的往返，展现出一问一答的形式。

发信人: moli (咸酥鸡beta v1.0)
标题: 有关 RAD
日期: Mon Feb 24 21:25:48 1997
来源站: 成大工科忘情小筑来源地: 140.116.110.151

侯 sir 你好，有个问题一直想问您。现在的 RAD 产品那麽多，编译出来的程式码已经够快，尤其是 Borland C++Builder 出来後。那麽，有什麽理由还要使用 MFC 或 OWL 呢？是不是有些东西还是用 RAD 无法完成的呢？我相信很多人都想知道，毕竟，如果投资了很多心力，人家却能用 RAD 短时间的学习曲线就能做出相同的东西，心情似乎会不太好过。所以想麻烦您解决一下大家心中的疑问。谢谢您！

问得好。

Programming 的过程不应该是一种自我虐待。有更好的工具上来，一定是为了提升生产力。如果用得上手，自然应该舍繁就简。

关键在於何人曰「简」？这要看 RAD 的使用者根基有多少。我用过C++Builder，很棒，我想我因为已有相当的技术基础，所以能够轻松驾驭。如果不是有 property、event、method 的观念、对软体元件有使用基础，不可能很快进入状况；C++ 的基础则就更不消说了（每次讲到这个我就想起以前有人问我不懂 C++ 而学会 MFC 有没有可能）。MFC 和 OWL 的使用经验，也为我在学习的路上带来帮助，当别人在 RAD 上运鼠如飞，我也运脑如飞地思想 MFC 的可能作法。这一思考，我对 RAD 说不定就有更深刻的看法，或起码，学习印象也要强化十几个百分点吧。

所以，如果你上得了手，工作目标又可以 RAD 达成，当然要尽量使用 RAD。Programming 的过程可不是一种自我虐待。基础不够，跌下马来，那就回头把根基扎好。开花结果通常在深耕的泥土上。

『是不是有些东西还是用 RAD 无法完成的呢？』噢，那当然。我从没看过 Matt Pietrek（Windows 95 System Programming SECRETS 一书作者）用过 RAD，连 MFC 或 OWL 他都没用过。他写的东西不需要繁复的 UI 画面，他需要长驱直入系统核心的 APIs：SetThreadContext、CreateRemoteThread、ReadProcessMemory...，很少听过这些 API 吧！与其花脑筋想这些 API 该安插在MFC（OWL）或 RAD 为我们产生的码的什麽地方，直接采用 SDK 程式风格才最快最乾净。Matt 的工作性质，需要一把利剑，但不需要一把象牙柄带雕花的利剑。写驱动程式的朋友们，则恐怕连 SDK 都不碰，他们碰的是 DDK。RAD 之於他们正是「不知有汉，无论魏晋」。

前两天我动手写一个简易的 backup 软体给自己日常使用。根本就没想过要写 Windows 版，命令列形式反而方便好用。後来我发现以前习惯使用的C runtime 函式库的 findfirst 和 findnext 两函式已经不存在於 32 位元工具中，只好改弦易辙写 Win32 console 程式，还好这和写 DOS 程式一样简单。我用任何一种编译器和联结器，下一个最简单的命令，就把程式制造出来了。

做什麽事情，用什麽工具！「用对工具」比「把工具用对」更先决、更前提。

那麽，您觉得现在 MFC 或 OWL 的存在，
除了为老程式员留後路，或用来开发低阶的 device driver 之外，
是否还有存在的必要？微软的 VC++ 5.0 就要出来了，
不知道微软会不会以 MFC 做底子，开发一套像 C++Builder 的东西。
依您所说，只要懂 Windows 程式的运作原理就好了呀！
只要懂得 event driven 的原理，就可以去驾驭 C++Builder，
那麽，去学习 MFC 或 OWL 是否真的没有必要了。
我突然有点疑惑，因为买了很多书（您的几乎都买了），也包括
您介绍的原文书。
在下学习 MFC 已有一年多了，可是发现一些只有 SDK 基础的人，
利用几个礼拜的时间就可学会用 C++Builder 做出比我还要好很多
倍的程式（我确定他们的资质不见得比我好）。
所以，突然为自己以前的投资觉得有些失落...

心情不太好而且有些失落的人：

１.修正你的观念：MFC 或 OWL 并不能拿来开发装置驱动程式。

２.我没说「懂得 event driven 的原理，就可以去驾驭 C++Builder」。

３.我刚学会开车时，第一次在台北上路。旁边坐着我的哥哥。那是星期天上午的敦北大道。车少人稀，顺畅无比，我不禁得意地说『在台北开车也没什麽难嘛！』我的哥哥对我说：『在美国盐湖城开车更容易，哼！重要的是出现状况时你的应变能力。』

４.到底该学习 MFC 或 OWL 或 C++Builder？这不是三言两语能回答的问题。年轻朋友问我先工作再深造好，还是先完成学业再工作，这也不是三言两语能回答的。如果使用的工具关系到工作的性质，我还想说『盍各言尔志』呢。

５.MFC 或 OWL 或 Visual Component Library（VCL）架构到底谁好，现在我还没有能力置评。有的是技术层次高，物件导向性质佳；有的是层次简化，容易学习。这些统统都应该考虑在「好」的范围内。曲高和寡而未能占有市场，那麽这个产品和「无」是一样的。不过，学习 C++Builder 不需要 MFC 或 OWL 基础，殆无疑问。也许你会感到失望，因为表面上你失去了某种「登高台观浮生如蚁」的优势。

６.但是你既不能怨艾自己比别人早生几年，所以你也不要怨艾「我做了好些苦工，别人却一步登顶」。否则只好现在什麽都不要动，等三年後一个不知是什麽但肯定比现在更好的东西出现。

７.何况世界上没有一步登顶的事儿。凡走过的，必留下足迹。电脑界很多东西都可以触类旁通。

送件者: William King
收件者: jjhou@ccca.nctu.edu.tw
主旨: SDK
日期: 1997年2月25日 AM 10:53

侯先生您好，因为工作的关系，我现在是用 SDK 开发程式，不过诚如
您所说的：『如果采用 SDK programming，则对作业系统需要相
当深度的涉猎，否则一知半解，恐怕临渊履薄，状况频出。』
有时候执行上有问题，还真不知道错误出在哪里。不知可否给点建议，
如何能对作业系统有相当深度的了解？

这我该怎麽说呢？找一位好老师，找几本好书，只能这样了。作业系统不如 programming 那麽容易可以自修而成，许多细部观念的养成，需要细细琢磨或经人点拨（我想起「分离位址空间」这题目）。如果你只能自修，那就只好努力多看书多思考了。对，多思考很重要，把书上的东西转化为你自己的思想体系，一辈子跑不掉。

是有人指导，不过我也想自己看些书。市面上这类书并不多，我不求速成
但是也不想浪费时间在无法了解的书上，能否请您介绍几本值得阅读
的书呢？

RunPC 1997.03 的【无责任书评/Windows 系统深耕】，介绍了三本好书。

送件者: Lung Feng
收件者: jjhou@ccca.nctu.edu.tw
主旨: Thank you for publishing your Dissecting MFC.
日期: 1997年2月25日 PM 10:58

侯先生您好：

我是您的忠实读友，从您1992年出版的「Windows程式设计」到现在的
「深入浅出 MFC」，我已花不少银子买下数本您的大作。说真的
您的作品比其他国内出版的作品价格稍为高了一点，但我觉得很值
得，因为我可以感受出您真得非常用心在撰写，初阅读您的作品时，有时
不知其然，但只要用心品尝，总是入味七分。有些书教人一边看书
一边上机实作，会是一个比较好的学习曲线，但我是一个从基隆到台北
通车的上班族，花很多的时间在车上，在车上拜读您的大作真是让人
愉快的事情（我回到家已晚，也只有在车上能有时间充实自已）。
这段时间内，我无法上机，却能从中受益。而且一次再一次去阅读，
常会有新的收获，真如古人所说温故而能知新。当然若找时间上机心得会更多。

以前大家苦哈哈的时候，都是用人脑 run 电脑，不到最後关头不轻言上机，上得机来就要给它个百发百中。这种习惯在今天「写码、编译、除错」的轮回中已经提升为「美德」的层次了！

你的读书形式，虽然辛苦，恐也不无额外收获。苦乐之间，存乎一心。捧着一本砖头般的巨书，随着火车摇摇晃晃的车厢，头儿也不时摇摇晃晃，口中时而念念有词，手上时而握拳时而振笔，初淅沥以潇飒，忽奔腾而砰湃。啊，这样的画面会让你手中那本书的作者感动得掉泪。

在此有几个问题想请教您: 1.您是否有开课？课程为何？如何报名？

我固定每周四晚在元智工学院开３学分的课，分别教过 SDK 程式设计、MFC 程式设计、Windows 作业系统。时有外校学生和校外人士旁听，一律欢迎。其他的公开研讨会，视「奇蒙子」而定。但今年没有这方面的计划。

2.如何得知您的新作何时会出版？

逛书店看到，或，写 mail 来问我。

3.最後请教您，侯捷到底是不是您本人？

您这麽问，会不会让侯捷先生伤心？ :-)

送件者: TomJPSun@acer.com.tw
收件者: jjhou@ccca.nctu.edu.tw
主旨: About Training Course
日期: 1997年2月4日 AM 06:42

Dear JJ：

哈罗，我是 Acer Netxus Inc. 的 Tom。我上次叁加了你的 MFC 训练课程，获益良多，谢谢你。我希望知道你是否还有其他课程，我想叁加。因为我喜欢你的上课风格（以及内容）。如果你最近有任何课程，请让我知道。谢谢。

认真授课能获得回响，真是最好的回报。唯今年我没有安排公开课程的计划，只有宏、睿昱半导体、华邦电子等公司内训是安排好了的。

Dear JJ：开春第一喜，就是收到侯大哥的回信。
看到 Run!PC 中时而出现的大补丹（很有营养的文章是也），就可以略窥几位前辈的研究方向。现在 Jave 与 ActiveX 的世纪大战方兴未艾，大
概不善押宝的 programmer 两边都要去学，果真是「学海无涯」了！

我有一个千古之谜侯捷是谁？
也许侯大哥刀笔风格回异，小弟也曾比对 Dissecting MFC 与【无责任书评２】的笔锋，却有似同实异之感觉！没人告诉我答案。
追查这事又似乎是与 programming 无关，这千古谜团就搁在我心里。

侯捷是谁？唔，一个好人吧我想。:-)

送件者: Jaguar
收件者: jjhou@ccca.nctu.edu.tw
主旨: 曲高和寡
日期: 1996年12月20日 PM 05:27

俊杰兄您好 :

有个问题想问您，为何在台湾要做基础的事（R & D）总是很难如愿。
为何只有做近利的事才能被认可为成功之道。也许是无知的人寄

社会是如此功利，政府又没有远见，故此。

也不见得近利才能成功。我自己做的事并不图谋近利，从其回响观之，成果丰硕，令我感动。

Hi, 杰兄您好 :

Sorry，又来打扰您了。在此要先说句谢谢您的解答。
也要说句我真的很羡慕您，因为您是在学术界工作。

进入学术界是无心插柳。原先在工研院，则只能说是带点学术味的半研究单位。目前我只是在学校开３学分课程，算半个学术人。不打算专任，这样最好，自由。

我是属於为了生存而不得不为五斗米而折腰的人。如何才能将所谓的工作和自己真正想做的事找出一个平衡点，使其能两全其美？

我们都难免可能为五斗米折腰，人生终归这麽回事。不要折损了尊严就好。只要有理想与毅力，不会永远壮志难伸。

希望您能多出版一些像「深入浅出MFC」的书, 让我们这些想要真正好书的人能大快朵颐一番。谢谢。带着一颗期待心的人（原也许是无知的人）寄於苦牢

听到这样的鼓舞，我不能无动於衷。今晚我会多熬两个小时 -- 情不自禁地。苦牢让人联想到囹圄，难道我在纵贯线上和看守所内都有读者？玩笑话请原谅，愿你早日脱离苦牢。

送件者: Shieh
收件者: 侯俊杰
主旨: 拜读大作「深入浅出MFC」
日期: 1997年2月10日 AM 03:15

侯先生:您好，我是您忠实的读者，您所写的书一向是我在学习新的东西时很大的帮助。除此之外，我也十分喜欢看你为新书所写的序，那种带有些哲学家的感觉！最近我想学 MFC，在市面上找到你的书。拜读後甚为兴奋，也十分谢谢您写书的用心。

我所追求的，不仅是知识的传达，还有阅读的乐趣。一位医师朋友说他最喜欢看我写的书序（其他的部份都看不懂）。因为有你这麽可爱的回应，所以有我这麽努力的付出。

送件者: xxxxxxxx@csie.ntu.edu.tw （姑隐其名）
收件者: jjhou@ccca.nctu.edu.tw
主旨: 「EQ价更高」读後感
日期: 1997年2月10日 AM 10:34

侯先生，好久没和你通信了，不知你是否还记得我？那不重要，我只想跟你分享自己今天看过「IQ 诚可贵，EQ 价更高」这篇文章的感觉。

当初刚进资讯系时,听了一番您的演说，就已经明白资讯这领域竞争之激烈，环境之险恶。但是我仍然对自己充满信心，深信能够依靠後天的努力，开创自己的一片天。但是一学期下来，却充斥着无力感，觉得在资讯的茫茫大海中，找不到一丝着力点...。

我时常勉励自己：在程式写作之外，我还有许多别人比不上的能力，诸如人际关系，企划能力等等，这并不是短期间就能够见到成效的。也因此我显得有些迷惑，也不知道今後能否在资讯的领域里创建自己的天地？
说实在的，我跟系上某些「电脑保送生」相处不来，他们就像侯先生所说的一样，相当神气，过度自负。

不知道面对这些「电脑高手」是跟他们学习好呢？还是保持距离好呢？
能合作固然是件好事，但是必定不能长期相处。说句真话，不是酸葡萄
心理，他们只是比一般人早接触到电脑，对写程式有兴趣，但是其他的方面确实表现的不怎麽样。这段差距应该不会永久，而且太过自负也无法在团队里头生存下去。

写了这麽多，不知确切想表达什麽，只是今天看过文章，心中
有话不吐不快。希望不会耽搁您太多的时间。过了新年，
又是新的开始，我该再重新思考将来的方向吧！