请不要误会，我的名字不叫 "No MFC" 。
写这 "自白" 缘于昨日一网友 chinaeagle 问我，写 No MFC 系列的目的何在？ 我竟一时间答不上来，我后来想了很多。
起初写作的时候，因为我所举的源程序在开头都会预先定义 #define WIN32_LEAN_AND_MEAN 。使不包含和 MFC 有关的预编译，所以取名 No MFC 编程系列 。 可是，我潜意识里并不光是为了这个简单的原因。
No MFC 的最大好处在于不封装！ 我有足够理由相信这样有利于学习。 你可以完全了解你的程序运行的基本原理，这是你在学习 MFC 的过程中无法具备的。 ( 我不想只是 见猫画猫，想做创新需要建立在对 "客观世界" 有足够了解和认识的基础上的 )
起 No MFC 这个标题并不代表我对 MFC 有成见。事实上，我从来不反对使用高效率的开发工具。 记得我刚刚开始学习 Windows 编程的时候，手头上仅有的全部书都是关于 MFC 的，我就靠那些书籍来入门。结果呢？ 我只能说完全不明其所而然，只懂得照抄一段又一段莫名其妙的代码，更别说编程序按照自己的意思表达出来了。 这样的状况一直没有好转，直到我知道世界上还有 SDK 编程，还有 API 可用，并且尝试了解 Windows 的运行机制为止。
值得幸运的是迷茫的过程只持续了不很长的一段时间！
在我的价值观中，何谓懂编程呢？ 我认为现阶段的学习目的应该是 — Windows 运行基本原理。 是懂得 Why 而不仅仅是 How ！
对我而言，学习一门语言，懂得语法，懂得方法 (继承，模板) 不是最终目的！
我应该掌握并运用所学的语言去描述计算机抽象的 "虚拟世界" 。那代表我要对该世界有足够的理解。
这里我要再提到抽象层面的概念。( 以下例子可能有些极端，但那不是讨论的重点 )
比方说一个绝对的底层方面的高手，他对保护方式的运行机制完全了解，知道如何初始化 LDT，GDT，任务门等等，直到如何访问它们，甚至可以编写从硬盘引导系统的程序。 但是，这样的高手到了 Windows 的虚拟世界，他就完全陌生了，因为他之前没有接触过 Windows ，在这方面，他就成为初入门的菜鸟了，他可能要花半年的时间去了解 Widows 运作方式，才可以应用到实际中去，最终又重新成为高手。
原因何在？ (我不想讨论这个例子的可能性) 因为从操作系统的角度看，计算机已经被抽象，分离开来，成为独立的抽象层面 (另一个虚拟世界)，虽然它看起来和先前的有很多类似的地方，但是，在它之上编写程序将是完全不同的，先前用汇编 (甚至机器码)来写程序，而现在就只剩下 API 可用了！
Java 其实是另一个虚拟世界，它有自己的虚拟机，实际上是另一个抽象层面。不然你说，有多少 API 被搬到 Java 里了？(应该是一个都没有吧？)
MFC 也是！ 要是谁能看穿 继承、父类、对象背后真正在工作的 API 的工作原理，那么称呼他一声高手应该不冤枉了吧！( 侯俊杰就是这样的一个高手，他是我尊敬的前辈！)
(其实我的自白到这里本也差不多了，下面是补充内容)
一个不得不提的内容是关于优化的。
对规律了解的更多有助于你做好程序的代码优化。 (代码优化不同于算法优化，这里假定程序在算法上已经最优化。)
你听说过紧凑编码吗？(在中国，应该只有少数人会这样做) 一般情况下，像这样优化代码的编程方法不会用来开发大型程序，不过在大项目的关键部分开发中不可或缺，就连开发一个游戏，也会被频繁的使用 ...
任何事物都有 "好的" 和 "不好的" 一面，软件工程也不例外。 它是为了开发大型项目而产生的，实际证明了这套理论很有效！ 而紧凑编码在某些方面上跟软件工程的思想是背道而驰的！ 因为软件工程并不保证代码最优化！这不是它的目的。
对于紧凑编码，它使用全局变量来加快访问速度，软件工程不提倡，因为会增加耦合度； 它合并模块使代码更加紧凑，软件工程不支持，因为破坏了模块独立性； 它更多的使用 goto 来避免远转移，软件工程中不允许，因为这样会使得程序可读性变差！
( 它连模块都要合并，更不会扯上 类，继承和对象了，代替的只有数据结构，数组 ... 但有的时候， "简单的" 不等于 "不好的"。 )
的确，这样极端的开发方式很少用到，因为太累人！ 开发成本极高 (开发人员的工资太高)，调试成本和时间很长 ( 要求开发人员极其严谨，考虑问题非常的全面，这就是为何这类程序员更有价值的原因 ) 。
虽然很少用到，你会自己做做紧凑编码的练习吗？
紧凑编码能使代码最优化的道理其实很简单，相信学过汇编的人都知道。 执行跳转是分为 近转移 、远转移 和 call 方式的。这三种跳转方式的效率是不同的。 根据我老掉牙的 486 资料，分别对应上面的， 3个周期， 17个周期 和 35个周期 (最大去到 77 + 4X ，对应的是在不同特权间且有 X 个参数的情况)。 你要知道，模块间调用实际上是 call 方式转移啊， 紧凑编码好在哪里就不言而喻了。
最后指出，紧凑编码只是少部分人的努力方向！ ( 此时我脑海中冒出了一句话 " Genius 往往是被世人称为 "傻瓜"的东西，爱恩斯坦就是例子！" 出处已忘记了。)
另一个不得不提的内容是关于软件工程应用的。
在计算机速度以几何级数发展的今天，软件工程的作用越来越重要。
记得曾看到类似的言论 " 印度的软件从整体效果上看是最棒的； 而印度人写的模块内码却是最烂的。"
其实这和印度人的思考方式有关，印度人编软件不会考虑用在最低配置上，他会认为买软件的人会用在最快的机器上。
微软巨人不也写出庞然大物了吗？
也许有人会问，计算机速度发展有慢下来的一天吗？ ( 这恐怕不是我能回答的。 )
不管怎样，现时来说软件工程的应用，其地位是举足轻重的。学好用好这个法宝是决定成败的关键。
从另一个角度看，就算自己暂时没法写出更优秀的代码，起码要让自己的程序在整体效果上最好。要学习他人 (印度人) 成功的经验！
( 这就是我转贴 "远去的代码" 想要说明的 )
如果情况有变，记得告知我！
如果你对该 XX "自白" 有什么看法，也请告知我。
我只想做个普通的好程序员。 `海风 2002年10月18日 am 11:39
——————————————————————————
附 自我简介：
特 征：未到而立，刚到米七，语音略带磁性，性格开朗，有点小聪明，准完美主义者 …
最 大 嗜 好 : 玩电子游戏、 编程 和 运动
爱用的编译器: VC + DX_SDK + api ( 戏称VC++ )
目前在听的歌: 那英 - 梦醒了
