《编程高手箴言》读后 #1

毕业也有几年了，也看了和学了不少东西。有时也想写点什么，但总是觉得头绪很多，一直没有
动笔。最近翻了翻梁先生的《编程高手箴言》，突然想写点什么，权且用读书笔记的形式写点东西。
等号上面的摘字《箴言》，下面则是笔者自己的感想。希望大家指教，但是谩骂就不必了，谢谢。
注：这一部分涉及《箴言》第一章。


在PC这个领域，现在的程序已不等于软件了。
=======================================
现在的程序不等于软件, 那么什么时候的程序等于软件呢? 我想,不管什么时候,都存在有用的
和没有的程序, 而软件, software,在计算机领域里就应该指那些有用的程序，而不论这些程序
有没有商业化。呵呵，应此只要我们在为自己或者为别人写有用的程序，那么我们就可以说我们
是在写软件了。


商业软件的功能和所要达到的目标就不是一个人能“玩”的起来的了。这就是美国新的软件
公司没法产生的原因。比如Netscape网景是在1995~1996产生的新软件公司，但是，两三年
后他就不见了。
================================================================================
所谓商业软件的功能和目标从来都没有过严格的定义，也不会有严格的定义。何谓商业软件？看
发布时的代码量？看可执行程序的尺寸？看有没有复杂神妙的算法？看有没有优良的售后服务？
还是干脆就把大公司发布的东西就叫做商业软件？ 当然，现在在一些通用领域，一些不涉及复杂
算法设计的场合，一些已经有大公司进入的场合，单凭个人的力量想要做出可以和大公司抗衡的
东西确实几乎不太可能。但是，计算机科学是门涵盖很广的学科，很多分支，比如数字图像处理，
视频音频处理，人工智能和机器人，等等，只要有人得到了突破性的发现，我想快速形成商业软件也非
不可能。当然了，很可能这些刚出现的小公司很快就被那些巨无霸吞并了。如果稍微看看现在这些
巨无霸公司的发展轨迹，就会发现它们吞并刚出现的小公司是家常便饭的事。但即便是这样，硅谷
还是有很多小软件公司出现。毕竟，软件业这块平面上单凭巨无霸公司那些大圆还是填不满的，圆
和圆的结合部总会有空隙存在。
至于说到Netscape的消失，原因大家都明白，这其实更多的不是取决于技术。事实上微软进军这个
领域太直接不过了，软件上已经有了Visual Studio和MS Office，因此开发浏览器的技术对他而言
几乎都是现成的。即便这样，Microsoft的IE还是在NCSA Mosaic的基础上完成的。所以Netscape
没有被收购，而是彻底被打败了。

任何一个行业初始阶段时的门槛都很低，但是，只要发展到一定的阶段后，它的门槛就必然抬高。
=====================================================================================
笔者十分赞同这句话，软件业创意太重要了。什么东西都是最先做出来的那几家获益最多，后来者
通常都是分些残羹。前两天在同事那里看一个搞笑的flash，突然冒出一个念头，怎么当初我就没有
想到在浏览器里写个插件来支持动画和音乐呢。呵呵，归根结底还是个人的水平有限啊:-)
大家每天睡觉前不妨花个几分钟想想，说不定就被你想到个点子从此一步登天了呢，呵呵。


现在中国软件行业正在形成，所以现在做一个程序员一定要有耐心。
===========================================================
我想程序员不管什么时候都需要耐心，耐心可以说是软件开发者的必备素质，并且体现在各个方面：
写程序的时候没有耐心那你就等着后面抓不尽的虫吧；给自己充电的时候你没有耐心，那么你永远只能掌握
肤浅的东西；追女朋友的时候没有耐心，那你就......，晕，怎么有番茄扔过来了，我闪 :-)

你一定要把所有的问题搞清楚，然后再去做程序。
===========================================
软件设计是门要靠脑力的活，而软件发展的迅速和需求的不断提高是人所共知的。什么时候我都不敢
奢望把所有的问题都搞清楚了。实际上每个开发者，哦，不，:-)是我本人在开发的过程中总是不断发
现新问题，不断在解决问题，是个螺旋提高的过程。我一向认为在开发中学习是最快最有效的。

事实上，美国的商业编译器也不是一个人能”玩“的，现在你可能觉得很简单的，甚至Linux还带了一个
GCC，且源程序还在。你可以把它改一改，做个VC试一试，看它会有人用吗？
即使你再做个界面，它也还是GCC，绝对不会成为Visual C++那样能商业化的软件。
===========================================================================================
我依稀记得曾经看过一篇章，说Borland当初的Turbo Pascal主要就是一个牛牛用汇编写出来的。呵呵，如果
有人给GCC写个类似VC的界面我举双手双脚赞成，免费帮他测试:-) 有时我在想，Borland当初开发Delphi的时候
不用Pascal而用C++的话，现在开发工具的市场份额会是个什么格局?(本人绝对没有瞧不起Pascal的意思，事实上
我的第一门语言就是Pascal，只是因为图书馆里Pascal的书被人借光了才自学了C)
如果我给Gcc写了个界面，当然还是GCC。用过GCC的人从来不会说GCC比不上Visual C++，两者实在没有办法比，不
在一个数量级上。GCC是个强大的编译器，支持N种硬件平台和官方的软件标准，同时也引入了很多软件开发者急需
的好特性。大多数优良的库，罕有不能在GCC上编译通过的。嘻嘻，有为GCC做广告之嫌？
至于GCC的商业化，我就看到过一些卖硬件产品的公司，它们附带的编译器就是GCC或者其变种。再说了，大量大型
的软件都可以用GCC编译出来的，从稳定上讲我想不会比Visual C++差吧。事实上，我用Visual C++的时候就遇到过
所谓的Internal Error，而我用GCC，就从来没遇到过这种莫名其妙的内部错误的抱怨。我想，GCC绝对有商业软件的
潜质，呵呵，就是在可视化方面比不上Visual C++，虽说也有一些GCC的图形前端。


机遇是从耐心中产生的，越有耐心，就越有机遇。
===========================================
名言啊名言，我有耐心啊，机遇快来吧，呵呵。
大家还是埋头苦干吧，别真的机遇来了你还没有准备好，呵呵～～

如果你是从MFC入手的，或者是从VC入手的，那么要做出一个真正的能应用个人领域的通用软件，就会走
非常多的弯路。
===========================================================================================
怪了去了，怎么从MFC或者VB入手就会走非常多的弯路呢？从MFC或者VB里调用Win32 API很直接，尤其在
Visual C++ MFC里。《箴言》很看重底层，Win32 API难道还不够底层吗？难道非要在汇编一级才可以写出真正
的通用软件吗？那我干脆去给CPU写微码去了，呵呵～～～。VB我用的很少，就不说了。至于MFC，如果你
真正弄懂了MFC那么你对于Windows的各个方面几乎就全部精通了(当然，我是指Windows内核外用户空间的
东东)。
计算机这个东西不管是硬件还是软件，层次很重要。开发很重要的一个方面就是要弄明白你自己需要在什么
层次上做东西。一个用java写中间件的开发人员，有多大必要去精通系统底层的东西呢？我想如果你不立足
于自己的层次做东西，而胡乱搞跨层的东西，结果可能就是出力而不讨好了。自己研究研究还行，如果在
工作中还是这样层次不清楚的话，呵呵，就很危险了。
当然，我没有让大家不去钻研，但我想最好还是找个前辈请教，根据自己的兴趣制定自己的学习计划。人的
精力毕竟有限，我们要把有限的精力投入为人民服务之中去嘛，可不要浪费了哟，呵呵。

只想混口饭吃，找个工作，可能教你成为MFC的高手之类的书对你就足够了。
==================================================================
现在的同志好幸福啊，国内在不停的引进国外的名书。想当年在95年左右的时候，外国参考书实在是不多。我建议大家
在计算机领域里面看书最好是找老外的。不是我崇洋媚外，老外出书基本上还是蛮负责的，而国内引进的大多还不错。
但是即使你在修炼国外大牛们关于MFC的书，如果你不认真实践，那么光靠书你是不可能成为MFC高手的。MFC这个类库
的设计已经有很多人在抨击了，我们不多谈，但是如果你真的深入到MFC的源代码里面去，其他我不知道，但是你肯定
可以对Windows的运作有个很深入的理解。

从最低层做起，从最基本坐起。
===========================
笔者的看法是从中间层做起。就以Win32上的Java为例，一开始我绝对不会从Java虚拟机规范，java和本机系统的交互，
Java垃圾回收算法的实现等等很底层的东西着手。也不会一开始就涉及那些什么设计模式，Frameword框架之类的高层
抽象。我会就从Java语言本身着手，熟悉它的语法，熟悉它的基本库，试着不断用Java描述问题。在这个过程中，你自然
会遇到一些或高层或底层的问题，这个时候你在去钻研它们绝对不迟，并且只可能是事半而功倍。

高手成长的六个阶段
==================
《箴言》一书把程序员的成长分成了六个阶段。笔者却认为只有第一阶段，即熟练的使用某种语言是每个程序员必备的。
其他的一些能力对于不同的开发方向应该是不同的。比如《箴言》认为第二阶段是精通某种平台的接口(比如Win32 API)。
然而，很多做高层开发的同志，往往不太接触这些底层的API，因为在他下面，操作系统上面已经叠加了很多的层次了。
比如，如果你用Java在Win32上面编程，几乎不需要和系统API打交道。这其实也体现了软件分层的思想：每一层只负责自己
的职能，只和自己相邻的层通讯。
《箴言》认为能够进行VxD编程，或者进行操作系统内核的修改就算进入了高层次了。且不说VxD已经被Microsoft抛弃了，
新的Win32驱动模型WDM，Linux/Freebsd kernel的小修改笔者都参经碰过，但是我从来不认为我到了很高的层次，尤其和
那些做高层开发的朋友比。因为实在是没有办法比，比较是要在同一个层面上进行的，不同层面的东西你怎么比？就算你
设计了操作系统，如果让你去规划一个ERP系统，你也未必成功。再说了，我写过WDM，觉得WDM也不那么神秘。但反观如果
让我设计一个ERP Framework，我倒是觉得很多东西需要学习，我想反之也是一样。至于说到底层开发，难度大概应该实在
比较少的资料和例子程序(尤其在Win32下面)，不太友好的调试工具，以及较少的系统支撑。不妨举个例子，在做应用程序开发
的时候，开发环境往往有完善的调试工具，也不太容易把整个操作系统搞死。然而做Kernel开发就不一样了，一不小心操
作系统就崩溃了。记得笔者在做WDM开发时，就挂了第二个硬盘，随时准备Ghost，呵呵。


这时Win32或Linux在你眼里已经没有什么差别了。
===========================================
从操作系统的角度看，Win32和Linux就都是操作系统，没什么差别。但是涉及到具体的开发，你就不得不清楚的认识到
两者的不同，用户态程序还好一点，大致把几个重要的发面，比如线程，消息机制，GUI等方面抽象一下，就像QT，GTK
做的那样，就可以实现Win32和Linux的跨平台。然而，在内核里面，两者差别是很大的，我从来没有看到过有什么Driver
开发库能够做到很好的在Win32和Linux下面跨平台。我所看到的最接近的可能是Driver Works带的那个C++库。
BTW，也许有什么好的库我不知道，希望知道的朋友不吝赐教:-)


初级程序员他会觉得VB也能做出应用来，到中级程序员他可能就不会选择VB了，可能会用MFC。到高级程序员时，他绝对
不是首先选择以上工具，考虑的绝对是什么才是具有最快效率，最稳定性能的解决问题的办法。
======================================================================================
不知道《箴言》怎么把VB和初级程序员绑到一起去了，不管你用什么开发工具，你水平不到家你就是初级程序员，并不是说
你选择了看似高档的开发工具你水平就高了。再说VB和MFC两者是不同的概念，没的比！至于说到高级程序员，我觉得《箴言》
的看法还是对的，我有个老师就曾经把一个大项目分成了多块，每块都选择了适当的开发工具，最后项目成功了。每每看到
论坛上有人在讨论开发工具的优劣，我就想只要讨论就落入下乘了。没有一个工具是十全十美的，聪明的人应该根据自己项目
的情况做正确的评估。你想想，如果真的出来个十全十美的东东，那别的人还怎么生存？


最高境界的时候，想的就是“我就是程序，程序就是我”。
===========================================
”我就是程序，程序就是我“，这是不是走火入魔了？人脑和电脑的差别无疑是巨大的，否则就不至于人工智能领域多年来都
缺乏革命性的进步了。我想最高的境界反而应该是认清人脑和电脑的巨大差别，设法用程序搭桥，让他们能够沟通。实际上，
我们想想数据结构里，操作系统里的很多概念是不是都是直接反映了人类生活的一些经验呢？(比如字符串匹配的快速算法，
各种同步和Cache技术)。我想，让电脑去适应人脑还可以，反之怎么才能进行？


如果你达到高手的状态，你就是操作系统，你就能做任何程序。
===========================================
假设我现在就是操作系统了，我就可以做任何程序了吗？操作系统不是什么特别的东西，它就是在替我们管理硬件资源而已。
什么是程序？程序是给人解决问题的代码的集合。操作系统的功能是受硬件资源约束的，而人类需要解决的问题是误穷尽的。

实际上技术到达最高境界，是没有分别的。
=====================================
对于同一种技术，到了比较高的境界，确实是相通的。为什么呢？其实可以理解，你们都是在解决一个具体的问题，这个问题
本身所具备的特性你怎么也回避不了的。比如你做分布式数据库，那么数据的一致性问题就是分布式数据库的一个没法绕过的
问题，不管你用什么方法，你最终还是要回到这个问题上来。然而，这种所谓的没有差别只是概念上的，你可千万不要奢望说
你明白了Microsoft的DCOM，你就可以不需要花什么力气就能很快上手Sun的分布式技术。我想这也就是我们这些做软件的家伙
命苦的地方吧。如果有个什么标准化组织把软件的方方面面也定义好严格的规范，我们也能省去好多事了啊。


作者说微软的那些“老头”在64位的机器上去做虚拟windows，然后就说“微软的技术能不先进吗？是Linux那几个玩家
能搞定的吗？
======================================================================================
怪了去了，在CPU上跑几个操作系统就很牛了吗？这根本就不是什么新的想法，且不谈Java环境就具备了初步的虚拟
计算机的能力，sourceforge上一度排名很考前的bochs就是个很好的x86模拟器，我就在它上面跑过一个小小的linux。
再说现在的VMWare，性能已经很好了，我同事在PII350的机器上都可以在VMWare里跑Win2000，那里还要什么64位机
啊。再说了，64位的威力就在可以同时跑跑多操作系统，不会吧？

微软的技术非常雄厚，世界计算机的最新技术绝对集中在这几个人(指微软设计内核的人)手里。
======================================================================================
晕啊，计算机是门涉及面很广的学科，操作系统就是计算机全部吗？我看不见得吧。我们如果看看Microsoft的发展
轨迹，就可以看到它的”原创“其实也不是想象中的多。Microsoft本身就不是靠先进的技术起家的。我想让《箴言》
举一些Microsoft的最新的而别人没有的技术，恐怕也不容易吧。(也许还锁在比尔的保险柜里，我还不知道，呵呵)


尤其现在很多的程序员，都被误导从MFC着手，这样很容易形成封闭式的思维模式。
========================================================================
奇怪了，从MFC着手怎么就算被误导了？怎么从MFC入手就容易形成封闭的思维模式了呢？MFC恐怕应该算是
对Win32 API封装最薄的了吧。而对MFC的研究你迟早要深入到源代码一级。你想想，Microsoft一向对源代码
视如珍宝，它还是公开了MFC的源代码，为什么？很明显，微软明白MFC的封装是不完善的，它几乎是鼓励你
自己做扩展了。难道非要我们哪怕打开一个窗口还要做那些手工编写资源文件，注册窗口类，大的CASE语句
处理消息分发，消息循环那些”杂事“？我记得当初我对在Borland C++ 3.1下面不得不做那些蠢事恼火的很，甚至还
写了个小程序用来生成那些千篇一律的代码。
所以我认为用MFC不但不会形成封闭的思维模式，恰恰相反！呵呵，如果MFC的设计者看到《箴言》对他们的评价
不知会做何感想了。


在你能够成为高级程序员的时候，对MFC这些是不屑一顾的。
====================================================
从对C++威力利用的角度或者从纯面相对象的角度看，MFC的封装确实不算最高明，但是如果你去看看它的源代码，
闪光点还是随处既是的 。不知道《箴言》是不是想到过用C语法的宏来构造消息处理系统呢？我想不是对系统和语言
都有深入了解的人，恐怕是不会想得到吧。微软作为一个大公司，里面有很多牛人很正常。在
research.microsoft.com上有一个正则表达式库就是微软一个牛人用C++实现的，现在正则表达式库不希奇，但是
微软那个牛人是用C++模板来构造自动机的，确实不失巧妙，据说性能还不错。
所以，MFC能够在微软的产品里存在这么多年，不是没有原因的吧。呵呵，我也希望我有能够对MFC不屑一顾的那
一天啊:-)


正确的程序设计思路是成对编码，先写上面的大括号，然后马上写下面的。
当你要用到一个内存的时候，写一个分配函数分配一块内存，马上接着写释放这块内存的代码。
======================================================================================
呵呵，对于大括号的问题，不同的编码规范有不同的定义，我想没有必要强行规定吧，至于《箴言》所说的便于查找，
我看这个理由也站不住脚。稍微好一点的编辑器，比如GNU Emacs就支持括号的自动匹配，哪里用的着自己去找，不累
啊。
至于说到内存的分配和释放，这是C/C++永恒的话题了，如果就如《箴言》所说的这么容易解决，也就不会被讨论这么多
年了。你想想，很多时候都是在这个地方分配了内存而在别的地方释放，而这个别的地方有可能是在别的人的程序里。
比如在Linux网卡驱动里分配的内存，就可能被很多其他的高层协议处理程序释放(当然，对于一块特定的内存，只会
被释放一次)，这时你怎么才能做到成对编码呢？

集成环境的TAB首先要设成8， 因为TAB的基本定义就是8，而现在的VC把它设成4，这样你编出的程序
放到一个标准的环境里看的时候就是乱的。
======================================================================================
应为我习惯了TAB是4的风格，但我还是做了试验，在TAB是4的VC环境里，写的代码在UltraEdit打开一点
问题都没有。不知道《箴言》是用的什么标准环境，呵呵～～～


如果写出来的代码大家都看不懂，那绝对是垃圾。
======================================================================================
我觉得这话可以和这句话类比，如果写出来的论文大家都看不懂，那绝对是垃圾。 呵呵，怎么可以这么
武断哟。什么代码是垃圾？我想对于一个大家都知道的思想而你用别人看不懂的代码表达，那才是垃圾。工作
中这种代码是十分有害的，不利于维护还会隐藏很多bug在里面。这里可以举个例子，有个网站收集很多以难懂
著称的C源程序，有些还是在一个什么难懂程序比赛里得奖的东西。然而我下回来后，很多都在现在主流的编译
器里不能成功编译了。


比如你从Linux中或者网上下载了一个”烂“程序后。
============================================
看来《箴言》是把Linux中的程序和那些”烂“程序相提并论了，我就不懂它的这种结论是从哪里来的。怎么
它就看不到Linux里大量优秀的源程序呢，呵呵，我都不愿意多说了，大家都有自己的眼睛。

(Linux里)那些程序还在不断的升级，那程序还会有新版，如果你把他拿来看一下，对你来说其实没有
什么价值。
======================================================================================
没有价值？！别人我不知道，但我自己的事我明白，我可以坦率的对大家说我从Linux/BSD的代码里获益
良多。各个方面，算法，系统架构，硬件等等方面，都可以从这些优秀的代码里获益，希望大家不要听信
《箴言》里的说法，有空根据自己的兴趣去多读读源代码，保证获益不浅。就以超级解霸擅长的东西而言，
Linux社区里一些播放器，性能就十分出色。而且免费，源代码全都有，只要你水平高，想怎么改就怎么改，
多好啊。不知道《箴言》里说上面那些话的用意是什么。

VC自动给你生成一堆堆的垃圾框架，相对于网上Linux程序来说，它可能更”臭“一些。
======================================================================================
呵呵，又是赤裸裸对VC的打击，老实说我确实很少听人说VC生成的是垃圾代码，更很少听人说这些代码
很臭。难道非要用纯C去给Win32编程才香吗？


Linux是个操作系统，很厉害呀！其实那些程序你拿回来，耐心的去读它，会发现，它里面乱的很。
======================================================================================
难道操作系统能够和普通的应用程序相提并论吗？我就读过Linux里面网络部分和文件系统部分的源代码，我怎么
没感到”乱的很“啊。操作系统程序直接架构在硬件上面，当然和普通的程序不同，你硬要用普通应用程序的写作
眼光来看操作系统的编码，我想这只能说明你的方法没有对头。实际的情况是，Linux里面核心的代码已经经过了
多次提炼，有很多好的东西在里面。而一些牛人对于C和硬件系统的深入了解而写下的程序确实能够使后来人获益了。
更别说一些特殊的场合，那些大牛们在没有办法的情况下写下”脏“的代码都会给出说明，看着那些充满幽默的注释，
往往你会会心一笑，从心底佩服那些人的水平和率真。

所有程序都是调试出来的，不是写出来的。
=====================================
呵呵，不先写出来你怎么调？再说了，也不是什么系统你都可以慢慢去调的。现在的很多大型软件代码量十分庞大，
哪里有可能让你在汇编状态下慢慢琢磨，我想只有在那些很少的关键的部位才有可能吧。所以好的软件它们那些对
效率十分敏感的部位才是在汇编状态下慢慢调慢慢改出来的。


int i;
extern int In[], Out[];
for(i=0;i<100;i++)
 {
 Out[i] *= In[i];
 }
========================
呵呵，当心Out[x]溢出变负数从而于你的预期不符哦。


如果说哪个系统是编出来的，那它肯定会有很多性能方面的问题，包括可能有不可预测的各种各样的问题。
======================================================================================
现在硬件告诉发展，很多时候性能的考虑已经放到第二的位置上去了。我们更多的是关注代码的可理解性。
至于可能有不可预测的问题，我想什么东西都自己动手而不去用一些饱经考验的库，可能更遭。以我为例，
我在用了STL后，对于常用数据机构的使用就不再出现指针问题了。

有可能完全是编译器的错误，也有可能因你程序里面增加了什么，而对程序产生干扰。
======================================================================================
记得在刚开始编程的时候，经常抱怨编译器有问题，可是越到后来这种抱怨就越少了，几乎都没有了。就
比如现在吧，如果你给Visual C++打了最新的补丁后想要找个bug出来，保证不容易。至于在程序里添加了
新东西而导致新的问题，这点很正常，所以才需要一些源码控制软件来跟踪软件的修改。

MFC里很常见的一种设计思维，就是任何一个东西，只管创建，不管释放和销毁。这种思路是现在很多程序员
做的程序没用几下就会死机的原因。MFC让你这么做，就是让你永远成为不了高手，你写的程序永远不可能
稳定。
======================================================================================
我在MFC里编程也有几年了，怎么就是第一次听说任何东西都是只管创建，不管释放和撤销呢？还有《箴言》怎么
知道MFC就是让人不能成为”高手“了呢？呵呵，我好同情那帮设计MFC的人啊，居然有人说用MFC写的程序永远不可
能稳定。

任何一个软件一定都是跟一个平台相关联的，脱离平台之上的软件几乎都是不能用的。
===========================================================================
不知道《箴言》所谓的平台只什么，开放源码领域里很多程序都是跨操作系统和硬件平台的。为什么我能这么
说？很简单，C可以跨硬件平台和软件平台，很多库在设计的时候就考虑到了不同的软件平台，所以在这样的
基础上写出跨平台的软件再直接不过了。再比如，Borland就声称Win32上的Delphi程序几乎不用修改就可以
跑在Kylix/Linux上。

一个很普通的程序员，如果他能够考虑到将程序分成好几个动态库，那么他的思维就已经有点开放性了，就
已经不是MFC那些思维方式了。
===========================================================================
软件用DLL实现就叫做有开放性思维了，原来这么简单啊，呵呵。 MFC好像重来也没有限制过你在程序里用DLL吧，
连动态连接的MFC程序里都要求目标系统里有MFC动态连接库啊。VC向导里好像也有生成DLL的Wizard吧。


你看MFC的思路，那就是一层套一层的，要把所有的类都实现了，然后继承。他从CWnd以后，把所有的东西
都包含进去了，然后组成一个巨型的类。这个巨型的类连界面到实现系统都包括在里面。这时你怎么拆？根本
没有拆的方法，这就是封闭式思维。
======================================================================================
继承，当然就是一层套一层了！MFC作为一个Framework，实现很多的类有什么希奇的？我们看看MFC的类图，好像
在CWnd下面还有很多继承关系吧？ CWnd作为对Win32里window的抽象，其复杂性是天生的，因为win32的概念里
窗口本来就是个复杂的概念，里面设计各种各样的资源的管理，自绘，消息处理等等。至于说道拆分，我看很
容易啊，我实现个新的窗口类我就从CWnd派生，不是窗口类而要支持什么Serialize之类的，那么我就从CObject派生。
要么我就干脆自己实现自己的类层次体系。像BCGSoft的基于MFC的界面库就是大量的用自己的类去替代MFC，也没
听他们抱怨说MFC没法扩充啊。

每个小函数出错的几率就会很小，那么组合起来整个程序出错的几率就很小。
===================================================================
软件设计的一个讨厌的地方就是有时它不是简单的1+1=2，我们常常会说联合调试，如果真的小部件OK，大系统就
OK，我们干吗还需要联调啊。对于函数拆分的原则，可能没有个普适的并且能付诸实践定义。但是在设计的时候
心中尽量想着软件工程里面的那些原则，比如什么松耦合之类的总是没错的。


动态库，包括它的代码和数据都是独立的，绝对不会跟其他的动态库串在一起。但是如果你把所有功能放到一个EXE
工程里，他的数据和代码都是放到一起的，最后产生可执行程序的时候就会互相干扰。
======================================================================================
谁说不会相互干扰的，别忘了，一旦DLL被加载了，它就会映射到你的程序地址空间里面来。一度大家讨论的很多的
DLL注入大法不就是DLL干扰宿主程序运行的典型吗？当然这种干扰有良性和恶性的区别罢了。

通用软件是一行一行编出来的，而且每一行的结果要到达一种可预测性。
======================================================================================
从《箴言》的上下文理解，好像是不推荐利用一些现成的库而崇尚什么都自己写。别忘了，很多有工业强度的库，比如
STL是饱经考验的，而开发工具生成的代码都是那些很死板的东西，我倒是认为人工去写不仅效率低，而且反而在不经意
间容易出错。如果这么不信任开发工具，干脆自己写机器码算了，但是这可能吗？

也就是从症状就能判断出哪些代码产生了问题。
=========================================
如果能够从软件的症状就可以知道哪些代码出了问题，我想微软也就不会要在它的错误代码报告里包含一大堆系统映象数据
了。尤其是软件的复杂性提高后，问题产生的原因往往是复杂的，交织在一起的。高手相对于普通人的一个显著标志就是
对出现的问题能够直接或者借助调试器的情况下准确定位。当然了，如果程序规模不大，还是可以根据症状而定位出问题
的代码的。


所有的代码必须是经过测试的，必须是一步一步调试过的。代码在汇编一级是怎么执行的，你都得非常清楚。
===============================================================================================
所有的代码都经过测试，这是理所当然的，然而对于经过测试的代码是不是要一步一步调试。我想是不必要的，都没有问题
了，还调什么啊？再说，现在软件规模这么大也不太有时间让你一步一步调试，一些不提供源码的第三方库你不会都在汇编
一级慢慢调试吧，呵呵。