07 | 推荐阅读：每个程序员都该知道的知识
每个程序员都应该要读的书
- 《代码大全》
- 《程序员修练之道》
- 《计算机的构造和解释》
- 《算法导论》
- 《设计模式》
- 《重构》
- 《人月神话》
- 《代码整洁之道》
- 《Effective C++》/《More Effective C++》
- 《Unix 编程艺术》、《Unix 高级环境编程》
每个搞计算机专业的学生应有的知识
http://matt.might.net/articles/what-cs-majors-should-know/
- 要获得一份好工作，学生需要知道什么？
- 为了一辈子都有工作干，学生需要知道什么？
- 学生需要知道什么，才能进入研究生院？
- 学生需要知道什么，才能对社会有益？
首先，作品集（Portfolio）会比简历（Resume）更有参考意义。简历中应该放上自己的一些项目经历，或是一些开源软件的贡献，或是你完成的软件的网址等。个人网址写自己的技能、经历、文章。
其次，计算机专业工作者也要学会与人交流的技巧，包括如何写演示文稿，以及面对质疑时如何与人辩论的能力。
最后，硬技能方面工程类数学、Unix 哲学和实践、系统管理、程序设计语言、离散数学、数据结构与算法、计算机体系结构、操作系统、网络、安全、密码学、软件测试、用户体验、可视化、并行计算、软件工程、形式化方法、图形学、机器人、人工智能、机器学习、数据库等等。
LinkedIn 高效的代码复查技巧
LinkedIn 的高效代码复查技巧
LinkedIn’s Tips for Highly Effective Code Review
LinkedIn 内部实践的 Code Review 形式复查有以下几个特点。
- 强制要求在团队成员之间做代码复查。Code Review 带来的反馈意见让团队成员能够迅速提升自己的技能水平，这解决了 LinkedIn 各个团队近年来因迅速扩张带来的技能不足的问题。
- 通过建立公司范围的 Code Review 工具，这就可以做跨团队的 Code Review。既有利于消除 bug，提升质量，也有利于不同团队之间经验互通。
- Code Review 的经验作为员工晋升的参考因素之一。
- Code Review 的一个难点是，Reviewer 可能不了解某块代码修改的背景和目的。所以 LinkedIn 要求代码签入版本管理系统前，就对其做清晰的说明，以便复查者了解其目的，促进 Review 的进行。
LinkedIn 对提交代码写说明文档这个思路是一个非常不错的方法，因为代码提交人写文档的过程其实也是重新梳理的过程。写文档的时候通常会发现自己把事儿干复杂了，应该把代码再简化一下，于是就会回头去改代码。
- 有些 Code Review 工具所允许给出的反馈只是代码怎样修改以变得更好，但长此以往会让人觉得复查提出的意见都表示原先的代码不够好。为了提高员工积极性，LinkedIn 的代码复查工具允许提出“这段代码很棒”之类的话语，以便让好代码的作者得到鼓励。
- 为 Code Review 的结果写出有目的性的注释。比如“消除重复代码”，“增加了测试覆盖率”，等等。
- Code Review 中，不但要 Review 提交者的代码，还要 Reivew 提交者做过的测试。除了一些单元测试，还有一些可能是手动的测试。提交者最好列出所有测试过的案例。这样可以让 Reviewer 可以做出更多的测试建议，从而提高质量。
- 对 Code Review 有明确的期望，不过分关注细枝末节，也不要炫技，而是对要 Review 的代码有一个明确的目标。
编程语言和代码质量的研究报告
编程语言和代码质量的研究报告
A Large-Scale Study of Programming Languages and Code Quality in GitHub
结论1： 从查看 bug fix 的 commits 的次数情况来看，C、C++、Objective-C、PHP 和 Python 中有很多很多的 commits 都是和 bug fix 相关的，而 Clojure、Haskell、Ruby、Scala 在 bug fix 的 commits 的数上明显要少很多。
结论2：函数式编程语言的 bug 明显比大多数其它语言要好很多。有隐式类型转换的语言明显产生的 bug 数要比强类型的语言要少很多。函数式的静态类型的语言要比函数式的动态类型语言的程序出 bug 的可能性要小很多。
结论3：研究者想搞清是否 bug 数会和软件的领域相关。比如，业务型、中间件型、框架、lib，或是数据库。研究表明，并没有什么相关性。
结论4：研究人员想搞清楚 bug 的类型是否会和语言有关系。的确如此，bug 的类型和语言是强相关性的。
这份报告可以在评估编程语言时有一定的借鉴作用。
电子书：《C++ 软件性能优化》
Optimizing Software in C++ - Agner Fog
这本书是所有 C++ 程序员都应该要读的一本书，它从事无巨细地从语言层面、编译器层面、内存访问层面、多线程层面、CPU 层面讲述了如何对软件性能调优。实在是一本经典的电子书。
Agner Fog 还写了其它几本和性能调优相关的书，可以到这个网址http://www.agner.org/optimize/下载
- Optimizing subroutines in assembly language: An optimization guide for x86 platforms
- The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers
- Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel, AMD and VIA CPUs
- Calling conventions for different C++ compilers and operating systems08 | Go语言，Docker和新技术
一个技术能不能发展起来，关注三点：
- 有没有一个好的社区（商业机构参与的社区）
- 有没有一个工业化的标准（企业级标准）
- 有没有一个或多个杀手级应用（解决方案）
影响因素：
- 学习难度是否低，上手是否快
- 有没有一个不错的提高开发效率的开发框架
- 是否有一个或多个巨型的技术公司作为后盾
- 有没有解决软件开发中的痛点
衡量Go：
- Go 语言容易上手；
- Go 语言解决了并发编程和底层应用开发效率的痛点；
- Go 语言有 Google 这个世界一流的技术公司在后面；
- Go 语言的杀手级应用是 Docker 容器，而容器的生态圈这几年可谓是发展繁荣，也是热点领域；
也就是说，Go 语言不会吞食底层到 C 和 C++ 那个级别的，也不会吞食到上层如 Java 业务层的项目。Go 语言能吞食的一定是 PaaS 上的项目，比如一些消息缓存中间件、服务发现、服务代理、控制系统、Agent、日志收集等等，他们没有复杂的业务场景，也到不了特别底层（如操作系统）的软件项目或工具。而 C 和 C++ 会被打到更底层，Java 会被打到更上层的业务层。
衡量一下 Go语言的杀手级应用 Docker：
- Docker 容易上手。
- Docker 解决了运维中的环境问题以及服务调度的痛点。
- Docker 的生态圈中有大公司在后面助力，比如 Google。
- Docker 产出了工业界标准 OCI。
- Docker 的社区和生态圈已经出现像 Java 和 Linux 那样的态势。
Docker解决了PaaS层的问题，PaaS层能解决以下问题：
- 软件生产线的问题
- 分布式服务化的问题
- 提高服务的可用性 SLA
- 软件能力的复用
新技术的入场，而不是等待技术成熟了再进入：
- 技术的发展过程非常重要
- 关键新技术，可以让你提前抢占技术的先机
09 | 答疑解惑：渴望、热情和选择
加班太严重完全没有时间学习，怎么办？
时间一定是能找得到的，就看你对你要干的事有多大的渴望程度和多大的热情。 只要你真的想做，你就一定能想出各种各样的招儿来为自己挤出时间。
为什么你能够写出这么多东西？
- 第一个阶段，是学习的阶段：把学习到的东西都以笔记的方式记录下来，方便可以翻出来看看。所以这个阶段主要还是学习的阶段。
- 第二个阶段，是有利益驱动的阶段：证明自己能做，不但要做出来，写出来，还要说出来。
- 第三个阶段，是记录自己观点打自己脸的阶段：写博客，记录一些自己的想法和观点。
- 第四个阶段，是与他人交互的阶段：写一些观点鲜明，甚至看上去比较极端或是理想的文章了。一旦一件事被真正地讨论起来（而不是点赞和转发），就会有很多知识命中认知盲区。虽然会被别人批评或是指责，但是，能从中收获到更多，因为会从不同的观点，以及别人的批评中，让自己变得更加完善和成熟。
从写作中还能训练自己的表达能力，这让我能够更好更漂亮地与别人交流和沟通。这一点对于我们整天面对电脑的技术人员来说，太重要了。
怎样选择自己的人生和职业发展？
- 20-30 岁，这是打基础的阶段：开阔眼界，把基础打扎实，努力学习和成长。
- 30-40 岁，这是人生发展的阶段：明确自己奋斗的方向，需要做有挑战的事儿，需要提升自己的技术领导力
耗子叔给的一些建议：
- 客观地审视自己：如果你超过了身边的大多数人，你不妨选择得激进一些冒险一些，否则，还是按部就班地来吧
- 确定自己想要什么：所谓“极端”，就是自己不会受到其它东西或其他人的影响，不会因为这条路上有人退出你会开始怀疑或者迷茫，也不会因为别的路上有人成功了，你就会羡慕。
- 注重长期的可能性，而不是短期的功利：多去选择能让自己成长的事，尤其是能让自己开阔眼界的事情。人最害怕的不是自己什么都不会，而是自己不知道自己不会。
- 尽量关注自己会得到的东西，而不是自己会失去的东西：无论怎么选，都会有得有失。
- 不要和大众的思维方式一样：如果你和大众不一样，那么只有两种情况，一个是你比大多数人聪明，一个是你比大多数人愚蠢。
10 | 如何成为一个大家愿意追随的Leader？
Leader 和 Boss 的不同
两者得不同点如下：
- Boss 是驱动员工，Leader 是指导员工
- Boss 制造畏惧，Leader 制造热情
- Boss 面对错误喜欢使用人事惩罚的手段，而 Leader 面对错误喜欢寻找解决问题的技术或管理方法
- Boss 只是知道怎么做，而 Leader 则是展示怎么做
- Boss 是用人，而 Leader 是发展人
- Boss 从团队收割成绩，而 Leader 则是给予团队成绩
- Boss 喜欢命令和控制（ Command + Control ），而 Leader 喜欢沟通和协作（ Communication + Cooperation ）
- Boss 喜欢说“给我上”，而 Leader 喜欢说“跟我上”
从上面这些比较，可以看到 Boss 和 Leader 的不同。了解和认识到什么才是一个真正的 Leader，什么才是一个 Leader 应有的素质和行为。
如何成为众人愿意追随的 Leader
- 帮人解决问题：总是能站出来告诉大家该怎么办。
- 被人依赖
- 这个世界很大，一个公司或是一个 Leader 很难做到把人一辈子留下来，因为人总是需要有不同经历的，优秀的人更是如此。既然做不到把人留一辈子，那么不妨把这件事做得漂亮一些，这样会让要离开的员工觉得这个 Leader 或是这个公司的胸怀不一般，可能是他再也碰不到的公司或 Leader，反而会想留下来，或是离开后又想回来。
- 既然做不到不让员工吐槽公司，那么不妨让这件事做得更漂亮一些——可以公开透明地说，而不是在背后说，因为在背后说对公司或是团队的伤害更大。赢得他人的信任：对于信任来说，并不完全是别人相信你能做到某个事，还有别人愿意向你打开心扉，和你说他心里面最柔软的东西。而后者才是真正的信任。
开放的心态 + 倾向性的价值观：
- 对于各种各样的技术都要持一种比较开放的态度，可以讨论优缺点，但不会争个是非对错，尤其对于新技术来说，更要开放。
- 倾向性可以让别人更清楚地知道我是一个什么样的人，而不会对我琢磨不透，一会东一会西只会让人觉得你太油了，反而会产生距离感和厌恶感。我认为，倾向性的价值观是别人是否可以跟随你的一个基础。- Lead by Example：要做一个有人愿意跟随的技术 Leader，你需要终身写代码，也就是所谓的 ABC – Always Be Coding。这样，你会得到更多的实际经验，能够非常明白一个技术方案的优缺点，实现复杂度，知道什么是 Best Practice，你的方案才会更具执行力和实践性。当有了执行力，你就会获得更多的成就，而这些成就反过来会让更多的人来跟随你。
- 保持热情和冲劲：所谓的保持热情和冲劲，并不是自欺欺人，也不是文过饰非，因为掩耳盗铃、掩盖问题、强颜欢笑的方式根本不是热情。真正的热情和冲劲是，正视问题，正视不足，正视错误，从中进行反思和总结得到更好的解决方案，不怕困难，迎难而上。
- 能够抓住重点，看透事物的本质：能够抓住主要矛盾，看清事物的本质，给出清楚的观点或方向，简化复杂的事情，传道解惑、开启民智，让人豁然开朗、醍醐灌顶，才会让人追随之。
描绘令人激动的方向，提供令人向住的环境：能够抓住主要矛盾，看清事物的本质，给出清楚的观点或方向，简化复杂的事情，传道解惑、开启民智，让人豁然开朗、醍醐灌顶，才会让人追随之。
甘当铺路石，为他人创造机会：帮助别人其实就是帮助自己，成就他人其实也是在成就自己，这就像一个好的足球队一样，球队中的人都互相给队友创造机会，整个团队成功了，球队的每个人也就成功了。
也许，你不必做一个 Leader，但是如果你有想跟随的人，你应该去跟随这样的 Leader！