思考与积累~

 作为一个工程师，工作就是创造出优秀的产品来。在平时的工作学习中要以产品为指导，而不能是以学习为主导，并且不可以过多地追求记忆细节，因为很多细节都是产品形成过程中人为规定的，并不都是必然的，在需要的时候查找技术手册，比如说man、info，在创造的过程中通过查找手册最终得到完整的产品说明和完美的解决方案，就是胜利！

2. 关于阅读代码。首先要明白代码是人类意志的体现，首先要清楚想做什么。具体看代码的时候如果碰到不懂得地方，要敢于大胆猜想并作出修改，直到发现错误，然后再看看到底出了什么问题；要么就是正确的。这个阶段最容易陷进去的一点就是，不敢修改，反复看原来的代码，本身有bug，也不容易看出什么问题。

3. 阅读设计模式是为了在阅读别人的代码的时候，可以更加快速地清楚设计是哪一类型。加快代码的阅读。

4. 学习UML是为了能够用图形的方式帮助自己思考和设计。

5. API设计过于混乱，绝对影响使用者的熟悉，还有代码的规范。

6. UML这样的工具只是思路的一种描述，本质上只是一个工具，在使用它的过程中核心的东西还是你到底是什么样的思路。千万不能把工具当做是一种思路的替代品。

7. 技术为产品而生，产品为需求而生。所以不要以为技术就是一切。

8. 一个好的学习环境，其中必要的一环就是有足够充裕的时间来供自己学习新的知识。

9. 关于逻辑部分的代码，分析最关键。并且，先做好分析，再下手写代码，这是比较好的实践。

10. 读源码是一种习惯，一旦有了这种习惯，你就不再那么容易被别人愚弄或误导。

11. 人常说C++ Primer和TCPL是C++语言中的屠龙刀和倚天剑，但是在我看来，这实在是给C++ Primer贴了不少金。学习C++真正的阅读顺序应该是：C++ Primer --->  TCPL  ---> 6E（[More]Effective/Essantial C++，Effective STL，Exceptional C++ Style）；对应的级别是入门级、精通级、专家级。

12. 发现自己有很多错误的潜意识。比如认为别人是不确定的，实际上是自己不确定。

13. 自己接手别人的东西，结果不清楚全貌，所以有什么智慧页发挥不出来。缺少背景知识、架构应该是大量年轻有为的程序员不能发挥力量的万恶之源。

14. 节约是昂贵的，比如你想节约运行时间和运行空间。

15. 学习一门技术，最好的方法时阅读它的wiki文档；其次才是去读相关的书籍；再次就没底儿了……

16. 当你逃避、无故咒骂某个技术点的时候，要告诉自己其实我的问题就在这里，你除了搞懂这个问题，就是彻底避开这个问题，包括与之相关的问题！其实后面这个代价更大！没有其他的办法。

17. 应该谨慎使用ASSERT（）宏，因为这个宏只出现在debug模式下，而我们一般无法保证release和debug两者都使用的是相同的数据，并且宏的使用有可能造成隐晦的错误。但并不是说不能使用。

18. 光是阅读技术原理的东西，而不在实践中使用，还是不能确定是否真的掌握了这门技术。

19. 在学习完《C++ Primer》，《6E》之后，如果还想提高对C++的掌握程度，那就可以开始研究模板编程，就只能研究《TCppPL》和C++标准文档了。

20. 研究boost的源码，绝对是提高C++功力的好办法。不过最好先读过《C++ Template》（《C++设计新思维》、《STL源码剖析》）。

21. 牛逼的全能工程师应该是写的了汇编，精通面向对象，搞的定C++，玩得转template，弄得懂socket，linux各种微操，数据库各种优化，操作系统深刻理解。拿过一门新语言来三天内搞定，说一个新技术新理论半天就能搞清楚用什么库，如何用代码实现。数学功底超好，学术论文随便翻阅。

22. 其实做技术和做人都一样，我们即使一辈子准备，准备学习新技术，准备巩固旧技术，但是永远都不会完成这个准备。

23. 应该把每学到的新技术，都尽可能地用代码来表达，做成工具，供以后使用。避免到后面使用的时候你会发现，原来懂了的东西，却没有可用的工具，要用却要从头做起。

24. 读一般技术性的书籍，我的经验是，先略读，理解大概，在分层次、分模块，建立大纲地去读，最好再通过记笔记、练习的方式来增强效果。当然，如果是完全初次接触某一类知识，还要讲循序渐进，先打结实基础，前面说的方法可能就失效了。

25. 那些伤害过我们的人，教会我们自己是多么的卑微；那些爱过我们的人，教会我们自己是多么的珍贵。在这卑微与珍贵之间，就是我们自己在他人眼中的价值。

26. 其实做技术时间稍长之后就会发现，只要搞定那些难搞的基础性的东西之后，所谓的技术就是时间的问题了。只要想做，基本都没什么问题。

27. 每一份工作，对你来说就是一次增值的机会，而不是你拿时间来换取金钱的场所。所以，一份合适的工作是能够让你找到更好、更适合你做的工作的工作。所以，未学成之前，不要轻易换工作。

28. 学习一门新技术，最好还是按照这样的方式来：先找一本比较薄的入门的书来看看，或者找一本厚的，大而全的书来浏览一下，在有了整体印象之后再去找一手的资料来读。因为一开始就去读一手的文档、手册，很有可能因为这些不是为新手准备的而难以读下去。对于新手最好的方式就是找一本条理清晰，结构清晰的书来有个整体的把握。

29. 其实一般来说，我们所处的环境就是我们的心境；我们只是不像用眼睛看到外在那样看清心境。其实这个和本篇没啥关系，如果硬要联系，那么如果你写的代码很烂，那就说明代码在你心中就长那副烂样！

30. 没有去了解一切的好奇心，不明真相，只能让我们不断地去盲从盲听。了解真相的又会因为人性的弱点，卖弄所知，去忽悠盲听者。

31. 为什么程序员应该学习C/C++这类语言，即使你不准备成为C/C++程序员！因为真正掌握这门语言之后你就几乎可以轻松学习任何其他语言。

32. 学完C++之后，再去学习其他语言，我在内心会有一种内疚感和不安全感：“这门容易就实现了！我一定忘记做什么了！咦，好像没有啊！哎……真的没有啊！”。这应该是斯德哥尔摩之症吧！

33. 程序处理流程，是要记录成文档的；画个流程图也可以，最好有文字描述；还要及时更新，过时的文档，就像隔夜的茶水，有毒！不然，当过上几个月之后，当你渐渐地淡忘了什么的时候，这种“暗物质”就藏在了代码里，跟你玩捉迷藏！然后等着你一个不小心，踩中某个坑。然后你就发现，自己载在了自己无意挖的坑里了。

34. 很多程序员，在开发接口的时候，总感觉没啥好说的，就那样用嘛！但是具体使用的人，总会踩到某些接口的各种坑。为什么呢？还是开发文档没写明白，假定了使用者本来不太能清楚的许多“小知识”；当然，如果使用者有开发接口的人那么清楚情况，当然就不会出现这样的坑了；除非他像33那样坑自己。

35. 以前觉得：程序员和木匠一样，就是个技工，玩的是手艺活儿；现在觉得：程序员和作家一样，因他的作品而伟大！

36. 调试程序有一个很牛逼的招儿，把写的代码成段儿注释掉，看看什么反应！

37. 做程序，最抽象的那一端是最整齐的，最接近现实世界的那一端是最杂乱的。

38. C里面的宏，一般是用来对付那些写起来很罗嗦的代码的，但是用了宏之后，这些啰嗦的代码却很容易变成让人读起来很头疼的代码。

39. 我们在通过一本书来自学一个新的知识的过程中，往往会在第一次阅读的时候被一些细节绊住，深入进去，进而忘记应该从整体上看问题的关键；然后在遇到不懂的部分，或者实在看不下去了，返回来看的时候，当初看不懂的东西突然变得明朗起来，过程也清晰了，难度陡然下降。对于这一点我很难给出合理的解释，但是这是一个不错的学习方法。就是第一次学习的时候，要略读，不要精读，因为这样很难真的读懂，而且也是很浪费时间的；但是同时也要抓住概要，最起码要对关键点留下印象，以便以后返回头来重新看的时候引起回忆。或许整个过程可以用“埋雷”，而后回头“点燃引线”，最终完成认识上“爆破”的方式来理解。

40. 我们一般在设计OO代码的过程中，总是会设想为了达到某一个目的而写一个怎样的类；而在学习COM的时候你会发现，它通篇在讲的是写一个类然后暴露一个怎样的接口。这就是境界的差别。前者以一个类作为结束，后者以一个接口作为结束。

41. 一个高级程序员，最后肯定需要了解他的客户，市场；不然就是一个庸碌的程序员。

42. 阅读别人的代码发现，有两个层次的阅读：一个是代码层次的，这个要读懂是需要程序员的技术功底；另一个就是业务层次了，这个需要看这个程序的处理事务和使用场景。这二者缺一个就不能算读懂程序。

43. 这几日看一个C的工程，阅读其代码的过程中有两个感受。一是C的代码在组织上感觉要比C++差一些，对于什么是外部调用的接口，什么是内部调用的函数阅读起来经常有疑惑，不像C++那么分明；二是一个好的代码习惯，或者代码风格能让人省好多力气阅读，比如对于这个C的代码中凡是外部调用的接口都声明在头文件中，凡是内部调用的就写在对应的C文件顶部，试想如果一个不守规矩的程序员，把一个内部调用的函数声明写在了源文件的任意部位，那么阅读的人应该是多么操心其他地方是不是还有这样的函数啊！

44. 有的开发者喜欢对技术细无巨细的了解，属于研究型；有的开发者是只要能解决问题就行，属于工程型。这两种人推荐的书籍和喜欢的书籍就是不同的，在听到别人推荐书籍的时候要注意这个区分。

转载~