《那些年啊，那些事——一个程序员的奋斗史》——摘抄

    其实对于刚入门的初学者来说，不应该一上手就去用MFC，或是C#之类的语言。虽然说这些高级的东西能够大大减轻工作压力，加快工作效率，但对于程序员个体来说，又得到了什么，又学到了什么？这些高级玩意，不是给初学者用的，而是为高手准备的。因为对于高手而言，他们已经知道了很多东西，已经没有任何必要从一个框架一门语言中去学到什么，而只需要拿着这个工具去解决问题即可。而反观菜鸟，如果要提升技术，那么背后的那些东西肯定是需要知道的，可偏偏类似于C#的这种高级语言把这些都完美封装了，所以很多一开始就上手C#的程序员，很多年过去了，也做了不少东西，也解决了不少难题，但对于背后的为什么可以这么做，却还是不知其所以然。因此经常可以看到一个用C++做了五六年，然后转到C#做个一两年，在某些新技术方面会比一开始就用C#，并且用了八九年的工程师的领悟性还强。
    只可惜现实是残酷的。虽然对于程序员来说最好的途径确实是从最基础的东西开始，但往往不具备这样的条件，因为对于公司来说，个人能学到什么东西并不是那么重要，最重要的是什么时候能够完成这个任务。如果公司需要做一个C/S的玩意，负责人肯定不会对程序员说：你先将操作系统的原理搞熟悉，然后再把这网络协议给弄明白，当然这虚拟机的原理也搞清楚，最后再给我把这任务完成。估计要真把这些东西给弄明白，少说也要几年时间，公司可以等吗？客户可以等吗？所以这样的情形之下，负责人肯定会这么说：我们做的这个C/S玩意，你们看看需求，看看是用JAVA还是C#快，我这周就要出个样本程序！
    要不要先将这基础学好，再去找工作？这个更不现实了。人所要解决的，首要是温饱问题，如果还饿着肚子，谈何来的理想？那么是不是初学者注定就这么昏昏碌碌下去？其实并不尽然。因为在工作之前，其实有一段时间，刚好可以将这基础打好，那就是——大学四年！大学的英文是University，谐音为“由你玩四年”，想必这是中国大学最真实的写照。除了那为数不多的几所名校以外，大部分的大学都是放羊式，不管你平时干什么，不管你是不是真的学到了东西，只要考试及格就给你发毕业证。更为糟糕的是，大学老师水平也是良莠不一，比如第一节课，老师会大言不惭地说：这门课其实我也没学过，这学期我们就来一起学习！然后上课时，就把课本照着念一遍，匆匆了事。类似的事件，其实不在少数。但这些，并不能作为自己懒惰的理由。其实从另一个角度来说，老师的放任不管未必不是件坏事，至少学业上不会有太多的压力，自己能够凭着喜好去学习其它的知识。
只不过段伏枥明白这道理的时候，已经晚了。自从找了第一份工作之后，每天都要强迫自己去看技术书籍。每每这时侯，段伏枥总会想：这些东西大学就应该知道的，为什么大学虚度了如此多的光阴？不过自古没有后悔药，与其懊悔过去，不如抓紧现在。所以即使在没有什么任务的这段时间里，段伏枥也不敢像别的同事那样每天上上网聊聊QQ，而是抓紧时间，一本一本技术书籍进行专研。
    不过这些技术书籍段伏枥能看懂吗？其实段伏枥大部分没有看懂，但他知道，看了还有希望，不看就只剩下绝望。很多初学者开始看技术书籍的态度是不正确的，拿起一本书，翻几下，发现不懂，便放下了，心理想着等以后能看懂了再看。其实这是一个伪命题，如果都懂了，那还看这书干什么？其实陶潜所说的“好读书，不求甚解”，其实是非常有道理的。对于一个初学者来说，当让开始一个从来没接触过的东西，他绝对是一片茫然，无从下手，甚至于借助搜索引擎也不知道用什么关键字；而如果以前有看过相关的书籍资料，虽然自己根本就没记住任何内容，但至少知道在哪里看过，这时候只要按照印象去搜寻，绝对比盲目搜索更为有效率。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

段伏枥想到了类这玩意。他不管三七二十一，每个文件都套上class这个关键字，比如主窗口就叫CMainWnd，设置窗口就是CSettingWnd，然后成员函数无非就是什么CreateWindow之类，也就避免了之前要在函数前加前缀的尴尬。但段伏枥使用这个类，也仅仅是用其形，而不知其神。功能类似的函数，段伏枥的做法是：复制，黏贴，修改，而根本不是什么继承之类。所以段伏枥现在使用类，其实只是批上了一件外衣，没有真正用到C++的精髓。这也无可厚非，试问哪个高手一开始上手就懂得在实际使用中如何很好地使用继承啊，虚函数之类的？这些都是在慢慢的代码书写当中，一点一点领悟的。但如果一开始就惧怕，甚至于拒绝使用这些高级特性，那么也就意味着从来没有踏进这个门槛，谈何来的进步。甚至有些程序员还会想，这些东西我还不会用，等我技术水平高了，回头再来使用；可问题是，隔行如隔山，如果你一直不用，那么面前永远就有一座山，只有开始使用了，才能翻越这座大山，看到胜利的彼岸。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

怎么回事，段伏枥这下可头大了。仔细查看了下代码，也找不出蛛丝马迹。索性将刷新线程给屏蔽掉吧！没想到，这么一来，一切正常！原来问题是出在多线程上！可这线程会有什么问题呢？咋看都不像有病的样子。段伏枥为此而苦恼了好几天。万事总有其原因乃至解决之道，有一天段伏枥不经意间看到一篇帖子，提到多线程可能会有资源占用的问题。不过这文章全是英文的，自己也没有仔仔细细全部看完，但毕竟给予了灵感。而顺着这灵光一闪，段伏枥找到了问题关键所在：在停止播放到开始播放另一个文件的这个间隔中，如果继续获取当前时间，那么程序将会崩溃！因为那时候实例已经释放，直接是使用空指针来提领，能不出错吗？
   
   找到问题的根源所在，似乎解决问题的方法也不难：不就是因为不知道当前的播放状态而导致的吗？自己增添一个变量，分别标示播放完毕以及播放开始，然后在线程中进行判断，这不就好了嘛？不能不说，这是一个非常正确的解决方式，但却并不彻底。崩溃的几率减少了，但却没有完全杜绝，偶尔的偶尔还是会崩溃。这究竟是怎么回事呢？不是已经设置标志了吗？为什么还会这样呢？这问题肯定还是因为多线程，可是根源在哪里？
   
   不得已，段伏枥只好硬着头皮将那篇英文文章看完。噢，原来如此！问题很可能在于，子线程在判断状态之后，然后开始获取当前时间的这个间隔呢，可能主线程已经将当前的实例给释放了！为了避免这情况的发生，只需要加上临界区即可。这么简单的问题，却让自己想了那么多天；而更为让自己汗颜的是，这种可能性在文章中已经明明白白写了出来，仅仅是因为自己的懒惰以及怕麻烦，只是匆匆看一眼，才引发了后续时间的浪费。果然，做技术的，没有那么多模棱两可，浅尝辄止永远只能有数不尽的麻烦。
   
   当将临界区这一利器添加到代码之后，段伏枥长长地舒了一口气：程序再也不见崩溃了。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

话又说回来，程序员要不要学算法，这的确要分开两个方面来看，不能一概而论。比如说，如果要到谷歌或百度这样的公司，因为他们是以算法优势起家的，如果你不研究算法，对算法一窍不通，那么进去最多就是打打酱油，说不定哪天主管心情不好了，还会请吃鱿鱼。但如果是到一些主要是做产品的公司，你天天研究算法也不行啊：产品的界面，客户的体验等等杂七杂八都需要你去完善，可你偏偏在研究什么样的算法效率会高一点点，而这些却偏偏是客户无法直观感受到的，那么估计炒鱿鱼这道菜还是免不了的。
   
    盲目崇拜，或是盲目鄙视算法，这两种态度都是不可取的，关键是看自己用算法来做什么。就像一辆法拉利跑车，估计没有人会说它差，开着它在路上狂奔，估计是一个非常惬意的享受。可是如果任务是要从大陆到日本，需要越过海洋，那么这法拉利的价值估计还不如一艘破船。可是这时候，你能说法拉利一无是处吗？一无是处的是使用者，因为他没有将法拉利用在最恰当的场合。算法也是如此，它是否有用，能发挥多大的作用，关键是看用它的人，看用它的场合。
   
    根据对算法的掌握程度，大体上可以将程序员分为三类：第一种是对算法非常精通的，第二种是知道有哪么些算法概念知道相应的算法库该如何使用的，最后一种是对算法一窍不通甚至连算法库都不知道的。这三种人之中，第一种是神一样的人物，适合于从事提升产品竞争力的工作；第二种便是大多数程序员所处的范围，适合产品的应用开发；最后一种嘛，便是菜鸟级别的，遇到和算法有关的问题只能撞得头破血流。很不幸，段伏枥就属于最后一种。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~