《一个程序员的奋斗史》书摘（一）

前一段时间读了莫雨的《一个程序员的奋斗史》，有一些部分感觉应该摘录下来，常常看看。思来想去，这里貌似比日记本更合适一些。

首先，关于书与封面的一些信息。这本小说是CSDN《那些年啊，那些事》小说全本，该连载超两百万点击，8000人评论。封面上有这样几句话：“无论在怎样的极品公司中，我都要前行，我都要取得进步！在现实与杯具中生存，在逆境与梦想中成长”。这里，记录下博主norains的博客地址：blog.csdn.net/norains。

下面是文章内容的一些简单的摘录，希望即使没有看过这本书的伙伴看到这些摘录也能有一些体会和思考。

（PS:虽然有些部分自己并没有涉及，有些部分自己也不是很懂，不过记录下来，哪天没准就“遇见”了。）

1 不管结果如何，写技术博客这习惯，一定要坚持下去，就像自己坚持走程序员这条路一样。与其不做后悔，不如做了后悔。

2 Datasheet资料文档等

3 果然，做技术的，没那么多模棱两可，浅尝辄止只能有数不尽的麻烦。绝对不向困难低头。

4 迷茫什么呢？有时间迷茫吗？先将自己手头上的工作忙完再说吧。

5 我每一次的亮相，都想让你重新认识我。

6 只不过对段伏枥来说，他记住了老章说的一句话：一个程序员，一定要经常学习，不能落后于时代。作为一个程序员，其实是不幸的，同时也是幸运的：不幸在于，在这个行业中，一定要保持积极不倦的学习态度，不能倦怠，否则就会不适应技术的发展要求；幸运的是，做这行能接触很多新鲜的东西，不会有别的行业一成不变的死气沉沉。更为有意思的是，经验在这行业中绝对不能呢个生搬硬套，比如以前写DOS程序，限于内存的大小，编程的建议是在一个函数中尽可能一个变量复用；而在处理器和内存飞速发展的现在，却变成哪里用到变量才声明，并且最好给予不同用途的变量于不同的名称，这是因为一两个变量的大小相对于如今的内存容量已经是微乎其微，现在更看重的是代码的可读性。但如果以为现在就都应该按照这准则来进行，那却又是另一番错误，虽然桌面微机发展得很快，但同时还要看到，如今还有不少单片机存在，并且还在各行业发挥无可代替的作用，而这些相比于DOS时代的微机，资源其实也多不到哪去，这便需要用到以前的法则。只不过此时的段伏枥并不知道这些，他只想着一定要努力，才能跟上时代的步伐。

7 嵌入式设备不同于桌面设备，桌面设备是摆在客户面前的，硬件功能一般是不会有什么大的问题的，出现无法录音的情况大多数是应用代码的问题或是驱动安装不正确；可对于嵌入式设备来说呢，却是无法保证硬件的正确性，遇到无法录音的情况，首先要从硬件入手。最简单来说，是首先用万用表之类的仪器来检测音频芯片的电压是否正确，然后再用示波器去检测音频的输入管脚是否有波形，当硬件确定没有任何问题的时候，才会去考虑软件方面。可以说，软硬结合是嵌入式和桌面开发最大的区别。

8 段伏枥顿时语塞，这不就像老柳让自己用查表方式去计算除法一样吗，照搬以前的经验去瞎指挥，而不去考虑实际的运用。段伏枥也只是在网上看了人家的评论，自己没有亲自去实践，自然也不会知道这效率差多少。其实程序员这一职业，没有那么多似是而非的方面，是就是，不是就不是，容不得半点含糊。

9 很显然，群里面的人对于这个问题也没谱，因为没有人真正去实际测试过。

10 Windows CE是嵌入式设备所用，和桌面PC的应用环境大为不同。做桌面应用的，其实真的很少去接触驱动级别的；但对于Windows CE来说，却是截然不同：如果你不懂C++，那么你将如何去看底层的BSP包代码？什么是BSP包代码呢，它是板级支持包（Board Support Package）的缩小，是嵌入式行业中的一个术语，代表在一个特殊硬件平台上快速构建一个嵌入式操作系统所需要的原始资料或者二进制软件包。BSP的作用是支持操作系统，使之能够更好地运行于硬件平台。BSP是相对于操作系统而言的，不同的操作系统对应于不同形式的BSP，包括Windows CE、Linux、VxWorks等。厂商会向其芯片用户提供一个基本的BSP包，以支持主板厂商或整机制造厂商在此基础上定制和开发各种商用终端产品。

11 相对于桌面以应用为重，嵌入式接触更多的是底层驱动级别。

12 任何事情，即使对方说的言之凿凿，也要自己亲自测试一番，眼见才能为实，绝对不能人云亦云。（QQ群中的言论）

13 其实对于程序员来说，绝对不能拘泥于形式。最重要的是明确自己的目标，需要达到什么样的目的，至于使用什么样的手段，则不是所关心的。如果段伏枥一直不转变自己的观念，总是从代码的角度入手，虽然最终也可能解决问题，但所耗费的时间，绝对比直接更改程序文件要多。

14 仅仅解决了问题是不够的，要有百折不挠、寻根问底的特性。

15 如果直接使用Win32 API呢，那么就必须自己先手动注册窗口类，然后创建一个窗口， 接着自己去处理消息循环，最后根据消息来做相应的动作。如果是从无到有，那么这么一套流程下来， 至少也要花上一两个小时，相对于MFC的随手点击，效率确实差了不少。但这样的好处是，自己能够明白程序究竟做了什么，而不像用MFC那样糊里糊涂。

其实对于刚入门的初学者来说，不应该一上手就去用MFC，或是C#之类的语言。虽然说这些高级的东西能够大大减轻工作压力，加快工作效率，但对于程序员个体来说，又得到了什么，又学到了什么？这些高级玩意，不是给初学者用的，而是为高手准备的。因为对于高手而言，他们已经知道了很多东西，没有任何必要从一个框架一门语言中去学到什么，而只需要拿着这个工具去解决问题即可。而反观菜鸟，如果要提升技术，那么背后的那些东西肯定是需要知道的，可偏偏类似于C#的这种高级语言把这些都完美封装了，所以很多一开始就上手C#的程序员，很多年过去了，也做了不少东西，也解决了不少难题，但对于背后的为什么可以这样做，却还是不知其所以然。因此常常可以看到一个用C++做了五六年，然后转到C#做个一两年的程序员，在某些新技术方面会比会比一开始就用C#并且用了八九年的工程师的领悟性还强。

16 只可惜现实是残酷的。虽然对于程序员来说最好的途径确实是从最基础的东西开始，但实际中往往不具备这样的条件，因为对于公司来说，个人能学到什么东西并不是那么重要，最重要的是什么时候能够完成这个任务。因为，公司可以等吗？客户可以等吗？

17 要不要先将这基础全部学好，再去找工作？这个更不现实了。人所要解决的，首先是温饱问题，如果还饿着肚子，谈何来的理想？那么是不是初学者注定就这么昏昏碌碌下去？其实并不尽然。

18 其实从另一个角度来说，老师的放任不管未必是件坏事，至少学业山不会有太多的压力，自己能够凭着喜好去学习其他的知识。

19 不过这些技术书籍段伏枥能看懂吗？其实大部分没有看懂，但他知道，看了还有希望，不看就只剩下绝望。很多初学者开始看技术书籍的态度是不正确的，拿起一本书，翻几下，发现不懂，便放下了，心里想着等以后能看懂了再看。其实这是一个伪命题，如果都懂了，那还看这书干什么？其实陶潜所说的“好读书，不求甚解”是非常有道理的。对于一个初学者来说，当让开始一个从来没接触过的东西时，他绝对是一片茫然，无从下手，甚至于借助搜索引擎也不知道该用什么关键字；而如果以前有看过相关的书籍资料，虽然自己根本就没记住任何内容，但至少知道在哪里看过，这时候只要按着印象去搜寻，绝对比盲目搜索更有效。

20 至此之后，只要是购买国内作者的书籍，段伏枥就不会那么随意了，都会在网上先看看相关评论，然后才谨慎入手。

（号外：国内的技术书籍的确存在一些问题，还是要好好甄别下。）

21 代码备份的重要性

22 对于一个小公司来说，找准产品的方向是非常重要的；当进入的领域是大众所关注的，并且还没有寡头而是刚开始的时候，虽然产品的质量非常不理想，但只要做出来了，第一桶金的赚钱是最容易不过的。

23 一旦遇上感冒，鼻炎就如火借风势，一发而不可收拾。其实呢，用点生理盐水，用棉签蘸点，洗洗鼻子就好了。生理盐水，可以去药店或者医院去买。

24 人如果懂得知足，那么生活便没有那么多烦心事；但如果仅仅满足于知足，却容易变得懈怠，止步不前。在这满足和不满足的交替中，也许便是人前进的动力之一。

25 所以段伏枥现在使用类，其实只是披上了一件外衣，没有真正用到C++的精髓。这也无可厚非，试问哪个高手一开始就懂得在实际使用中如何很好地运用继承啊，虚函数之类的？这些都是在慢慢的代码书写当中，一点一点领悟的。但如果一开始就惧怕，甚至于拒绝使用这些高级特性，那么也就意味着从来没有踏进这个门槛，谈何来的进步。甚至有些程序员还会想，这些东西我还不会用，等我技术水平高了，回头再来使用；可问题是，隔行如隔山，如果你一直不用，那么面前永远就有一座山，只有开始使用了，才能翻越这座大山，看到胜利的彼岸。

26 一般的车载产品，常见的流程是从原厂获得开发板，配套的资源自然又BSP代码和原理图。然后驱动工程师根据CPU的资料，以及原厂的原理图，和硬件工程师相配合，得出和需求相符合的原理图，这个时间一般在五天左右。之后便是将原理图交给画板工程师进行布局画板，一般也需要两三天。当然，如果器件比较多，那么所花的时间更久。接着便是找对应的工厂打板，这也有一些研究。如果工厂管控不佳，也不做相应的分针测试，那么这板子很可能短路。板子回来后，便是贴片。如果是大批量，这倒不是什么问题，直接用盘料上贴片机。但对于只有十片左右的样板，这是不切实际的，所以往往采用手贴的方式。正是因为这种需求，深圳有不少手贴的公司，不仅生存没问题，甚至还活得很滋润。

27 大公司分工很明确，可谓一个萝卜一个坑，这个坑究竟是浇粪还是施化肥，都有明确的规定；而小公司呢，就没那么多的讲究了，管你有多少个萝卜，只要有坑了，你就必须给我种进去。所以，在这另种环境之下成长的程序员，有截然不同的品质：大公司的，知识面比较窄，但钻研的程度却比较深；小公司的，知识面非常广，但钻研的程度却相对来的浅。这两种品质，无法说哪种更为优越，也无法说哪种更容易提升自我价值。

28 程序员究竟要不要研究算法？其实这在业界也一直争论不休。正方的意见是，不懂得算法，就不能更好地理解计算机，写出的软件效率就会非常低，因为程序就是数据结构+算法的结合；而反方的意见呢，无非是说现在又很多算法库，可以直接拿来就用，根本就不必要去深究，再花费心思去重新发明轮子。

对于程序员要不要学算法，的确要分两个方面来看，不能一概而论。比如说，如果要到谷歌或者百度这样的公司，因为他们是以算法优势起家的，如果你不研究算法，对算法一窍不通，那么进去只能打打酱油，说不定哪天主管心情不好了，还会请你吃鱿鱼。但如果是到一些主要做产品的公司，你天天研究算法也不行啊：产品的界面、客户的体验等杂七杂八都需要你去完善，可逆偏偏在研究什么样的算法效率会高一点点，而这些偏偏是客户无法直观感受到的，那么估计炒鱿鱼这道菜同样还是免不了的。

根据对算法的掌握程度，大体上可以将程序员分为三类：第一种是对算法非常精通的，第二种是知道有那么些算法概念，知道相应的算法库该如何使用的，最后一种是对算法一窍不通甚至连算法库都不知道的。这三种人中，第一种是神一样的人物，适合于从事提升产品竞争力的工作；第二种便是大多数程序员所处的范围，适合产品的应用开发；最后一种嘛，便是菜鸟级别的，遇到和算法相关的问题只能撞的头破血流。

29 绝对不向困难低头，是段伏枥一贯坚持的信念，也是他一直能够进步的原因之一。

30 虽然段伏枥在《C++ Primer》里见过multimap的身影，但该书对于应用却惜字如金，并没有很好地诠释其用法。所以段伏枥对此的印象也不是很深，在编写程序的时候自然没有想到使用该容器。如果在此之前段伏枥看过《C++标准程序库》的话，可能情形就截然不同。该书从最基础开始，给读者介绍了STL的使用，特别是其中的一章，更是以字典为例来讲解如何使用multimap，恰好和段伏枥程序要求不谋而合。

这不能不说，多看书，对于程序员而言，是多么地重要。也许看的时候一窍不通，但只要你有了那么点印象，知道有那么一回事，说不定就这么一个灵感，会让以后的工作省掉很多的麻烦。

（未完待续）