因为产品已经要接近批量产，基本上软件方面也不会有很大的变动，只要之前的程序不出现致命的BUG，那么就可以宣告完成。只不过这种没有经过严格测试的程序，仅仅是程序员自己觉得没问题的流程，完全没有BUG的可能性又是几何呢？只不过作为程序员，除非是专业测试的，估计没有几个人会整天对着自己写好的程序在进行测试吧？段伏枥自然也是如此。段伏枥曾经问过黄华中接下来还要做什么，可得到的答复是，暂时没什么了，你先看看一些资料吧。只不过这么一来，上班时间就完全空闲了。
很多职场新人遇到这种情况，都是乐得屁颠屁颠的，上班就会在浏览网页，聊聊QQ，昏昏碌碌过一天。所幸的是，段伏枥并没有这样做，因为之前很久找不到工作的经历实在给他留下了难以磨灭的伤痛。他无时无刻不在担心，万一这家公司炒了他，那么自己再找工作的时候，是不是也是这么艰难？或是说，经过这几个月，自己有了多少长进，能不能作为找工作的资本？回头一想，发现自己还是很多东西不懂，也就不敢太放纵自己。既然工作上暂时已经没有安排，那么为何不自己给自己充电？
这时候，有一本书深深影响了段伏枥往后的代码风格。这本书就是北京大学出版社出版的《Windows CE程序设计》。在此之前，段伏枥所看的关于Windows CE的书籍，全部都是出自于国人之后，无一例外都是采用MFC架构。众所周知，MFC封装了Windows API很多东西，感觉上似乎是方便了很多，但实际上对于初学者弄明白程序的架构却是大大不利。就如同段伏枥写的计算器一样，虽然有很多按钮，但他也仅仅知道双击按钮的时候会转到源文件的某个函数，在这个函数里写的代码是响应点击事件的，仅此而已。至于这个双击函数是如何被调用的，则是一无所知。于是便给段伏枥造成了这么一个假象：编写Windows窗口程序和在学校里学的C++不同，它可以不按执行流程运行并且能够很神奇地跳跃执行某些函数。总而言之，学校学的东西似乎和工作上所运用的完全搭不上边。
可看了《Windows CE程序设计》一书之后，段伏枥的认识完全被颠覆了。原来Windows桌面程序也和学校里所学的C++一样也有入口函数的啊？所不同的是，C++入口函数是main，而Windows程序是WinMain！原来程序没有像学校所学的C++那样马上退出，是因为主线程有个消息提取的循环函数啊！原来按下按钮时系统会发送一个WM_LBUTTONDOWN消息，放起来时又有一个WM_LBUTTONUP，而相应的处理函数就是在这时候被调用的，而不是之前所想象的那样神奇的跳跃执行啊！原来Windows程序也可以写得那么干净，可以没有那么多莫名其妙又不知所云的宏定义啊！
可为什么那么多人会用MFC呢？这个疑惑不久之后段伏枥也明白了。MFC封装了很多东西，在某些方面确实会比较简单。比如说，创建一个最简单的窗口程序，MFC只要在新建工程的时候选择相应的选项，最后点击完成即可；可如果直接使用Win32 API呢，那么就必须自己先手动注册窗口类，然后创建一个窗口，接着自己去处理消息循环，最后根据消息来做相应的动作。如果是从无到有，那么这一套流程下来，至少也要花上一两个小时，相对于MFC的随手点击，效率确实差了不少。但这样的好处是，自己能够明白程序究竟做了什么，而不像用MFC那样糊里糊涂。至少可以让程序员感觉到，这一切都是可控的。
其实对于刚入门的初学者来说，不应该一上手就去用MFC，或是C#之类的语言。虽然说这些高级的东西能够大大减轻工作压力，加快工作效率，但对于程序员个体来说，又得到了什么，又学到了什么？这些高级玩意，不是给初学者用的，而是为高手准备的。因为对于高手而言，他们已经知道了很多东西，已经没有任何必要从一个框架一门语言中去学到什么，而只需要拿着这个工具去解决问题即可。而反观菜鸟，如果要提升技术，那么背后的那些东西肯定是需要知道的，可偏偏类似于C#的这种高级语言把这些都完美封装了，所以很多一开始就上手C#的程序员，很多年过去了，也做了不少东西，也解决了不少难题，但对于背后的为什么可以这么做，却还是不知其所以然。因此经常可以看到一个用C++做了五六年，然后转到C#做个一两年，在某些新技术方面会比一开始就用C#，并且用了八九年的工程师的领悟性还强。
只可惜现实是残酷的。虽然对于程序员来说最好的途径确实是从最基础的东西开始，但往往不具备这样的条件，因为对于公司来说，个人能学到什么东西并不是那么重要，最重要的是什么时候能够完成这个任务。如果公司需要做一个C/S的玩意，负责人肯定不会对程序员说：你先将操作系统的原理搞熟悉，然后再把这网络协议给弄明白，当然这虚拟机的原理也搞清楚，最后再给我把这任务完成。估计要真把这些东西给弄明白，少说也要几年时间，公司可以等吗？客户可以等吗？所以这样的情形之下，负责人肯定会这么说：我们做的这个C/S玩意，你们看看需求，看看是用JAVA还是C#快，我这周就要出个样本程序！
要不要先将这基础学好，再去找工作？这个更不现实了。人所要解决的，首要是温饱问题，如果还饿着肚子，谈何来的理想？那么是不是初学者注定就这么昏昏碌碌下去？其实并不尽然。因为在工作之前，其实有一段时间，刚好可以将这基础打好，那就是——大学四年！大学的英文是University，谐音为“由你玩四年”，想必这是中国大学最真实的写照。除了那为数不多的几所名校以外，大部分的大学都是放羊式，不管你平时干什么，不管你是不是真的学到了东西，只要考试及格就给你发毕业证。更为糟糕的是，大学老师水平也是良莠不一，比如第一节课，老师会大言不惭地说：这门课其实我也没学过，这学期我们就来一起学习！然后上课时，就把课本照着念一遍，匆匆了事。类似的事件，其实不在少数。但这些，并不能作为自己懒惰的理由。其实从另一个角度来说，老师的放任不管未必不是件坏事，至少学业上不会有太多的压力，自己能够凭着喜好去学习其它的知识。
只不过段伏枥明白这道理的时候，已经晚了。自从找了第一份工作之后，每天都要强迫自己去看技术书籍。每每这时侯，段伏枥总会想：这些东西大学就应该知道的，为什么大学虚度了如此多的光阴？不过自古没有后悔药，与其懊悔过去，不如抓紧现在。所以即使在没有什么任务的这段时间里，段伏枥也不敢像别的同事那样每天上上网聊聊QQ，而是抓紧时间，一本一本技术书籍进行专研。
不过这些技术书籍段伏枥能看懂吗？其实段伏枥大部分没有看懂，但他知道，看了还有希望，不看就只剩下绝望。很多初学者开始看技术书籍的态度是不正确的，拿起一本书，翻几下，发现不懂，便放下了，心理想着等以后能看懂了再看。其实这是一个伪命题，如果都懂了，那还看这书干什么？其实陶潜所说的“好读书，不求甚解”，其实是非常有道理的。对于一个初学者来说，当让开始一个从来没接触过的东西，他绝对是一片茫然，无从下手，甚至于借助搜索引擎也不知道用什么关键字；而如果以前有看过相关的书籍资料，虽然自己根本就没记住任何内容，但至少知道在哪里看过，这时候只要按照印象去搜寻，绝对比盲目搜索更为有效率。
这段时间里，段伏枥居然做到了，凡是市面上带有“Windows CE”字样的书籍，只要能搞到的，都无一例外地全部看了一遍。只不过这期间，段伏枥也发现了一些问题。如果作者是外国的，那么书中基本上都是直接用Win32 API；但如果是国内的作者，毫无例外使用MFC，更为让人惊异的是，某些书甚至还是大篇幅大篇幅抄袭另外一本的。这难道不算抄袭？结果将两本书的作者一比较，发现其中其中一本书的编者之一就是另一本书的作者。这也行？坑人吧？至此之后，只要是购买国内作者的书籍，段伏枥就不会那么随意了，都会在网上先看看相关评价，然后才谨慎入手。
很多职场新人遇到这种情况，都是乐得屁颠屁颠的，上班就会在浏览网页，聊聊QQ，昏昏碌碌过一天。所幸的是，段伏枥并没有这样做，因为之前很久找不到工作的经历实在给他留下了难以磨灭的伤痛。他无时无刻不在担心，万一这家公司炒了他，那么自己再找工作的时候，是不是也是这么艰难？或是说，经过这几个月，自己有了多少长进，能不能作为找工作的资本？回头一想，发现自己还是很多东西不懂，也就不敢太放纵自己。既然工作上暂时已经没有安排，那么为何不自己给自己充电？
这时候，有一本书深深影响了段伏枥往后的代码风格。这本书就是北京大学出版社出版的《Windows CE程序设计》。在此之前，段伏枥所看的关于Windows CE的书籍，全部都是出自于国人之后，无一例外都是采用MFC架构。众所周知，MFC封装了Windows API很多东西，感觉上似乎是方便了很多，但实际上对于初学者弄明白程序的架构却是大大不利。就如同段伏枥写的计算器一样，虽然有很多按钮，但他也仅仅知道双击按钮的时候会转到源文件的某个函数，在这个函数里写的代码是响应点击事件的，仅此而已。至于这个双击函数是如何被调用的，则是一无所知。于是便给段伏枥造成了这么一个假象：编写Windows窗口程序和在学校里学的C++不同，它可以不按执行流程运行并且能够很神奇地跳跃执行某些函数。总而言之，学校学的东西似乎和工作上所运用的完全搭不上边。
可看了《Windows CE程序设计》一书之后，段伏枥的认识完全被颠覆了。原来Windows桌面程序也和学校里所学的C++一样也有入口函数的啊？所不同的是，C++入口函数是main，而Windows程序是WinMain！原来程序没有像学校所学的C++那样马上退出，是因为主线程有个消息提取的循环函数啊！原来按下按钮时系统会发送一个WM_LBUTTONDOWN消息，放起来时又有一个WM_LBUTTONUP，而相应的处理函数就是在这时候被调用的，而不是之前所想象的那样神奇的跳跃执行啊！原来Windows程序也可以写得那么干净，可以没有那么多莫名其妙又不知所云的宏定义啊！
可为什么那么多人会用MFC呢？这个疑惑不久之后段伏枥也明白了。MFC封装了很多东西，在某些方面确实会比较简单。比如说，创建一个最简单的窗口程序，MFC只要在新建工程的时候选择相应的选项，最后点击完成即可；可如果直接使用Win32 API呢，那么就必须自己先手动注册窗口类，然后创建一个窗口，接着自己去处理消息循环，最后根据消息来做相应的动作。如果是从无到有，那么这一套流程下来，至少也要花上一两个小时，相对于MFC的随手点击，效率确实差了不少。但这样的好处是，自己能够明白程序究竟做了什么，而不像用MFC那样糊里糊涂。至少可以让程序员感觉到，这一切都是可控的。
其实对于刚入门的初学者来说，不应该一上手就去用MFC，或是C#之类的语言。虽然说这些高级的东西能够大大减轻工作压力，加快工作效率，但对于程序员个体来说，又得到了什么，又学到了什么？这些高级玩意，不是给初学者用的，而是为高手准备的。因为对于高手而言，他们已经知道了很多东西，已经没有任何必要从一个框架一门语言中去学到什么，而只需要拿着这个工具去解决问题即可。而反观菜鸟，如果要提升技术，那么背后的那些东西肯定是需要知道的，可偏偏类似于C#的这种高级语言把这些都完美封装了，所以很多一开始就上手C#的程序员，很多年过去了，也做了不少东西，也解决了不少难题，但对于背后的为什么可以这么做，却还是不知其所以然。因此经常可以看到一个用C++做了五六年，然后转到C#做个一两年，在某些新技术方面会比一开始就用C#，并且用了八九年的工程师的领悟性还强。
只可惜现实是残酷的。虽然对于程序员来说最好的途径确实是从最基础的东西开始，但往往不具备这样的条件，因为对于公司来说，个人能学到什么东西并不是那么重要，最重要的是什么时候能够完成这个任务。如果公司需要做一个C/S的玩意，负责人肯定不会对程序员说：你先将操作系统的原理搞熟悉，然后再把这网络协议给弄明白，当然这虚拟机的原理也搞清楚，最后再给我把这任务完成。估计要真把这些东西给弄明白，少说也要几年时间，公司可以等吗？客户可以等吗？所以这样的情形之下，负责人肯定会这么说：我们做的这个C/S玩意，你们看看需求，看看是用JAVA还是C#快，我这周就要出个样本程序！
要不要先将这基础学好，再去找工作？这个更不现实了。人所要解决的，首要是温饱问题，如果还饿着肚子，谈何来的理想？那么是不是初学者注定就这么昏昏碌碌下去？其实并不尽然。因为在工作之前，其实有一段时间，刚好可以将这基础打好，那就是——大学四年！大学的英文是University，谐音为“由你玩四年”，想必这是中国大学最真实的写照。除了那为数不多的几所名校以外，大部分的大学都是放羊式，不管你平时干什么，不管你是不是真的学到了东西，只要考试及格就给你发毕业证。更为糟糕的是，大学老师水平也是良莠不一，比如第一节课，老师会大言不惭地说：这门课其实我也没学过，这学期我们就来一起学习！然后上课时，就把课本照着念一遍，匆匆了事。类似的事件，其实不在少数。但这些，并不能作为自己懒惰的理由。其实从另一个角度来说，老师的放任不管未必不是件坏事，至少学业上不会有太多的压力，自己能够凭着喜好去学习其它的知识。
只不过段伏枥明白这道理的时候，已经晚了。自从找了第一份工作之后，每天都要强迫自己去看技术书籍。每每这时侯，段伏枥总会想：这些东西大学就应该知道的，为什么大学虚度了如此多的光阴？不过自古没有后悔药，与其懊悔过去，不如抓紧现在。所以即使在没有什么任务的这段时间里，段伏枥也不敢像别的同事那样每天上上网聊聊QQ，而是抓紧时间，一本一本技术书籍进行专研。
不过这些技术书籍段伏枥能看懂吗？其实段伏枥大部分没有看懂，但他知道，看了还有希望，不看就只剩下绝望。很多初学者开始看技术书籍的态度是不正确的，拿起一本书，翻几下，发现不懂，便放下了，心理想着等以后能看懂了再看。其实这是一个伪命题，如果都懂了，那还看这书干什么？其实陶潜所说的“好读书，不求甚解”，其实是非常有道理的。对于一个初学者来说，当让开始一个从来没接触过的东西，他绝对是一片茫然，无从下手，甚至于借助搜索引擎也不知道用什么关键字；而如果以前有看过相关的书籍资料，虽然自己根本就没记住任何内容，但至少知道在哪里看过，这时候只要按照印象去搜寻，绝对比盲目搜索更为有效率。
这段时间里，段伏枥居然做到了，凡是市面上带有“Windows CE”字样的书籍，只要能搞到的，都无一例外地全部看了一遍。只不过这期间，段伏枥也发现了一些问题。如果作者是外国的，那么书中基本上都是直接用Win32 API；但如果是国内的作者，毫无例外使用MFC，更为让人惊异的是，某些书甚至还是大篇幅大篇幅抄袭另外一本的。这难道不算抄袭？结果将两本书的作者一比较，发现其中其中一本书的编者之一就是另一本书的作者。这也行？坑人吧？至此之后，只要是购买国内作者的书籍，段伏枥就不会那么随意了，都会在网上先看看相关评价，然后才谨慎入手。
再分享一下我老师大神的人工智能教程吧。零基础！通俗易懂！风趣幽默！还带黄段子！希望你也加入到我们人工智能的队伍中来！https://www.cnblogs.com/captainbed