《编程高手箴言》的读后感
毕业也有几年了，也看了和学了不少东西，《编程高手箴言》读后感。有时也想写点什么，但总是觉得头绪很多，一直没有动笔。最近翻了翻梁先生的《编程高手箴言》，突然想写点什么，权且用读书笔记的形式写点东西。
在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在你眼里已经没有什么差别了。
【《编程高手箴言》的读后感】相关文章：
1.阳谋高手的读后感
2.圣经的箴言
3.圣经箴言
7.圣经精选箴言
8.圣经爱情箴言
本文来源：https://www.010zaixian.com/shiyongwen/2817524.htm