|
1回顶部 毕业也有几年了，也看了和学了不少东西。有时也想写点什么，但总是觉得头绪很多，一直没有动笔。最近翻了翻梁先生的《编程高手箴言》，突然想写点什么，权且用读书笔记的形式写点东西。 等号上面的摘字《箴言》，下面则是笔者自己的感想。希望大家指教，但是谩骂就不必了，谢谢。注：这一部分涉及《箴言》第一章。
2回顶部 你一定要把所有的问题搞清楚，然后再去做程序。 ======================================= 软件设计是门要靠脑力的活，而软件发展的迅速和需求的不断提高是人所共知的。什么时候我都不敢奢望把所有的问题都搞清楚了。实际上每个开发者，哦，不，:-)是我本人在开发的过程中总是不断发现新问题，不断在解决问题，是个螺旋提高的过程。我一向认为在开发中学习是最快最有效的。 事实上，美国的商业编译器也不是一个人能”玩“的，现在你可能觉得很简单的，甚至Linux还带了一个GCC，且源程序还在。你可以把它改一改，做个VC试一试，看它会有人用吗？即使你再做个界面，它也还是GCC，绝对不会成为Visual C++那样能商业化的软件。 3回顶部 只想混口饭吃，找个工作，可能教你成为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，也许有什么好的库我不知道，希望知道的朋友不吝赐教:-) 4回顶部 初级程序员他会觉得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位的威力就在可以同时跑跑多操作系统，不会吧？ 5回顶部 微软的技术非常雄厚，世界计算机的最新技术绝对集中在这几个人(指微软设计内核的人)手里。 ======================================= 晕啊，计算机是门涉及面很广的学科，操作系统就是计算机全部吗？我看不见得吧。我们如果看看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网卡驱动里分配的内存，就可能被很多其他的高层协议处理程序释放(当然，对于一块特定的内存，只会被释放一次)，这时你怎么才能做到成对编码呢？ 6回顶部 集成环境的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和硬件系统的深入了解而写下的程序确实能够使后来人获益了。更别说一些特殊的场合，那些大牛们在没有办法的情况下写下”脏“的代码都会给出说明，看着那些充满幽默的注释，往往你会会心一笑，从心底佩服那些人的水平和率真。 7回顶部 所有程序都是调试出来的，不是写出来的。 ======================================= 呵呵，不先写出来你怎么调？再说了，也不是什么系统你都可以慢慢去调的。现在的很多大型软件代码量十分庞大，哪里有可能让你在汇编状态下慢慢琢磨，我想只有在那些很少的关键的部位才有可能吧。所以好的软件它们那些对效率十分敏感的部位才是在汇编状态下慢慢调慢慢改出来的。 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写的程序永远不可能稳定。 8回顶部 任何一个软件一定都是跟一个平台相关联的，脱离平台之上的软件几乎都是不能用的。 ======================================= 不知道《箴言》所谓的平台只什么，开放源码领域里很多程序都是跨操作系统和硬件平台的。为什么我能这么说？很简单，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干扰宿主程序运行的典型吗？当然这种干扰有良性和恶性的区别罢了。 9回顶部 通用软件是一行一行编出来的，而且每一行的结果要到达一种可预测性。 ======================================= 从《箴言》的上下文理解，好像是不推荐利用一些现成的库而崇尚什么都自己写。别忘了，很多有工业强度的库，比如STL是饱经考验的，而开发工具生成的代码都是那些很死板的东西，我倒是认为人工去写不仅效率低，而且反而在不经意间容易出错。如果这么不信任开发工具，干脆自己写机器码算了，但是这可能吗？ 也就是从症状就能判断出哪些代码产生了问题。 ======================================= 如果能够从软件的症状就可以知道哪些代码出了问题，我想微软也就不会要在它的错误代码报告里包含一大堆系统映象数据了。尤其是软件的复杂性提高后，问题产生的原因往往是复杂的，交织在一起的。高手相对于普通人的一个显著标志就是对出现的问题能够直接或者借助调试器的情况下准确定位。当然了，如果程序规模不大，还是可以根据症状而定位出问题的代码的。 所有的代码必须是经过测试的，必须是一步一步调试过的。代码在汇编一级是怎么执行的，你都得非常清楚。 ======================================= 所有的代码都经过测试，这是理所当然的，然而对于经过测试的代码是不是要一步一步调试。我想是不必要的，都没有问题了，还调什么啊？再说，现在软件规模这么大也不太有时间让你一步一步调试，一些不提供源码的第三方库你不会都在汇编一级慢慢调试吧，呵呵。 |
正在阅读：《编程高手箴言》读后感(1)《编程高手箴言》读后感(1)
2004-04-05 10:08
出处：CSDN
责任编辑：sdq
