《左耳听风》笔记

每个搞计算机专业的学生应有的知识

What every computer science major should know，每个搞计算机专业的学生应有的知识。

本文作者马修·迈特（Matthew Might）是美国犹他大学计算机学院的副教授，2007 年于佐治亚理工学院取得博士学位。计算机专业的课程繁多，而且随着时代的变化，科目的课程组成也在不断变化。

如果不经过思考，直接套用现有的计算机专业课程列表，则有可能忽略一些将来可能变得重要的知识点。为此，马修力求从四个方面来总结，得出这篇文章的内容。

1. 要获得一份好工作，学生需要知道什么？
2. 为了一辈子都有工作干，学生需要知道什么？
3. 学生需要知道什么，才能进入研究生院？
4. 学生需要知道什么，才能对社会有益？

这篇文章不仅仅对刚毕业的学生有用，对有工作经验的人同样有用，这里我把这篇文章的内容摘要如下。

首先，对于我们每个人来说，作品集（Portfolio）会比简历（Resume）更有参考意义。所以，在自己的简历中应该放上自己的一些项目经历，或是一些开源软件的贡献，或是你完成的软件的网址等。最好有一个自己的个人网址，上面有一些你做的事、自己的技能、经历，以及你的一些文章和思考会比简历更好。

其次，计算机专业工作者也要学会与人交流的技巧，包括如何写演示文稿，以及面对质疑时如何与人辩论的能力。

最后，他就各个方面展开计算机专业人士所需要的硬技能：工程类数学、Unix 哲学和实践、系统管理、程序设计语言、离散数学、数据结构与算法、计算机体系结构、操作系统、网络、安全、密码学、软件测试、用户体验、可视化、并行计算、软件工程、形式化方法、图形学、机器人、人工智能、机器学习、数据库等等。详读本文可以了解计算机专业知识的全貌。

这篇文章的第三部分简直就是一个知识资源向导库，给出了各个技能的方向和关键知识点，你可以跟随着这篇文章里的相关链接学到很多东西。

LinkedIn 高效的代码复查技巧

LinkedIn’s Tips for Highly Effective Code Review，LinkedIn 的高效代码复查技巧。

对于 Code Review，我曾经写过一篇文章 《从 Code Review 谈如何做技术》，讲述了为什么 Code Review 是一件很重要事情。今天推荐的这篇文章是 LinkedIn 的相关实践。

这篇文章介绍了 LinkedIn 内部实践的 Code Review 形式。具体来说，LinkedIn 的代码复查有以下几个特点。

• 从 2011 年开始，强制要求在团队成员之间做代码复查。Code Review 带来的反馈意见让团队成员能够迅速提升自己的技能水平，这解决了 LinkedIn 各个团队近年来因迅速扩张带来的技能不足的问题。

• 通过建立公司范围的 Code Review 工具，这就可以做跨团队的 Code Review。既有利于消除 bug，提升质量，也有利于不同团队之间经验互通。

• Code Review 的经验作为员工晋升的参考因素之一。

• Code Review 的一个难点是，Reviewer 可能不了解某块代码修改的背景和目的。所以 LinkedIn 要求代码签入版本管理系统前，就对其做清晰的说明，以便复查者了解其目的，促进 Review 的进行。

  我认为，这个方法实在太赞了。因为，我看到很多时候，Reviewer 都会说不了解对方代码的背景或是代码量比较大而无法做 Code Review，然而，他们却没有找到相应的方法解决这个问题。

  LinkedIn 对提交代码写说明文档这个思路是一个非常不错的方法，因为代码提交人写文档的过程其实也是重新梳理的过程。我的个人经验是，写文档的时候通常会发现自己把事儿干复杂了，应该把代码再简化一下，于是就会回头去改代码。是的，写文档就是在写代码。

• 有些 Code Review 工具所允许给出的反馈只是代码怎样修改以变得更好，但长此以往会让人觉得复查提出的意见都表示原先的代码不够好。为了提高员工积极性，LinkedIn 的代码复查工具允许提出“这段代码很棒”之类的话语，以便让好代码的作者得到鼓励。我认为，这个方法也很赞，正面鼓励的价值也不可小看。

• 为 Code Review 的结果写出有目的性的注释。比如“消除重复代码”，“增加了测试覆盖率”，等等。长此以往也让团队的价值观得以明确。

• Code Review 中，不但要 Review 提交者的代码，还要 Reivew 提交者做过的测试。除了一些单元测试，还有一些可能是手动的测试。提交者最好列出所有测试过的案例。这样可以让 Reviewer 可以做出更多的测试建议，从而提高质量。

• 对 Code Review 有明确的期望，不过分关注细枝末节，也不要炫技，而是对要 Review 的代码有一个明确的目标。

为什么你能够写出这么多东西？

我还是先说一下，我对写东西这个事的热情是怎么来的。从 2002 年开始写东西到今天，我基本上经历了几个阶段。

第一个阶段，是学习的阶段。因为在我刚入行的时候，软件公司对文档的要求还是比较高的，干什么事都要写个文档，所以，我就有了写文档的习惯。不过，这个阶段，对于我个人来说，我会把学习到的东西都以笔记的方式记录下来，方便我以后可以翻出来看看。所以，这个阶段主要还是学习的阶段。

第二个阶段，是有利益驱动的阶段。正如《程序员如何用技术变现》一文中提到的，因为我写的一篇技术文章，让我接到了一个培训的私活，两天时间就挣了我一个月的工资。说实话，这件事给了我很大的鼓励，让我有了更多的热情来写文章。

第三个阶段，是记录自己观点打自己脸的阶段。这个时候，我遇到了博客火爆的时代，我看到很多人写博客来记录自己的观点和想法，我也跟着写博客，记录一些自己的想法和观点。时间一长，我发现有个有趣的事——我看自己好几年前写的东西，发现要么是我以前记录的观点打了现在的脸，要么就是现在打了自己过去的脸。

这种有点科幻色彩的跨时空打自己脸的方式，让我觉得很好，因为这里面，我能够看到自己成长的过程，并且可以及时修正，这真是太好了。

第四个阶段，是与他人交互的阶段。这个阶段，我开始写一些观点鲜明，甚至看上去比较极端或是理想的文章了。而且我的文章开始有很多人转载和评论，还时不时地引发争论。我发现在这个过程中，我的收获也很大，因为一旦一件事被真正地讨论起来（而不是点赞和转发），就会有很多知识命中了我的认知盲区。虽然这会被别人批评或是指责，但是，我能从中收获到更多，因为我会从不同的观点，以及别人的批评中，让自己变得更加完善和成熟。

而且，我从写作中还能训练自己的表达能力，这让我能够更好更漂亮地与别人交流和沟通。这一点对于我们整天面对电脑的技术人员来说，太重要了。

因为我能从写作中得到这么多的好处，所以我当然就能坚持下来了。虽然，我近几年的文章更新频率比较低，但是，我还是在坚持，因为我能从中收获很多对我个人有帮助、有提升、有价值的东西。

我相信，只要你坚持下来，你一定也会有和我一样的感受。

除了技术领导力之外的一个 Leader 需要的素质。

• 赢得他人的信任。信任是人类一切活动的基础，人与人之间的关系是否好，完全都是基于信任的。对于信任来说，并不完全是别人相信你能做到某个事，还有别人愿意向你打开心扉，和你说他心里面最柔软的东西。而后者才是真正的信任。这还需要你的人格魅力，你的真诚，你的可信，你的价值观和你的情怀等一些诸多因素，才会让别人愿意找你分享心中的想法和情绪。

• 开放的心态 + 倾向性的价值观。这两个好像太矛盾了，其实并不是。我想说的是，对于新生事物要有开放的心态，对于每个人的观点都有开放的心态，但并不是要认同所有的观点和事情，成为一个油腔滑调的人。

  也就是说，我可以听进各种不同观点，并在讨论中根据自己的价值观对不同的观点做出相应的判断，而并不是不加判断全部采用。因为如果你要做一个 Leader，你需要有明确的方向和观点，而不是说一些放之四海皆准的完全正确的废话。我的经验告诉我，对于各种各样的技术都要持一种比较开放的态度，可以讨论优缺点，但不会争个是非对错，尤其对于新技术来说，更要开放。

  然而，就价值观来说，还是需要有倾向性的，比如，我就倾向于不加班的文化，倾向于全栈，倾向于按职责分工而不是按技能分工，倾向于做一个 Leader 而不是 Boss，倾向于技术是第一生产力，倾向于 OKR 而不是 KPI……

  我的这些倾向性可以让别人更清楚地知道我是一个什么样的人，而不会对我琢磨不透，一会东一会西只会让人觉得你太油了，反而会产生距离感和厌恶感。我认为，倾向性的价值观是别人是否可以跟随你的一个基础。

• Lead by Example。用自己的示例来 Lead，用自己的行为来向大家展示你的 Leadership。这就是说，你需要给大家做示范。很多时候，道理人人都知道，但未必人人都会做，知易行难，以身示范，一个示例会比讲一万遍道理都管用。

  所以我认为，对于软件开发来说，不写代码的架构师是根本不靠谱的。要做一个有人愿意跟随的技术 Leader，你需要终身写代码，也就是所谓的 ABC – Always Be Coding。这样，你会得到更多的实际经验，能够非常明白一个技术方案的优缺点，实现复杂度，知道什么是 Best Practice，你的方案才会更具执行力和实践性。当有了执行力，你就会获得更多的成就，而这些成就反过来会让更多的人来跟随你。

• 保持热情和冲劲。在这个世界上，有太多太多的东西会让人产生沮丧、不满、彷徨、迷茫、疲惫等这些负面情绪，但是几乎所有的人都不会喜欢在这样的情绪中生活，我们每个人都会去追求更为积极更为正面的生活方式。

  所以，作为一个 Leader 无论在什么情况下，你都需要保持热情和冲劲，只有这样，你才会让别人有跟随的想法和冲动。

  但是，所谓的保持热情和冲劲，并不是自欺欺人，也不是文过饰非，因为掩耳盗铃、掩盖问题、强颜欢笑的方式根本不是热情。真正的热情和冲劲是，正视问题，正视不足，正视错误，从中进行反思和总结得到更好的解决方案，不怕困难，迎难而上。

  正如鲁迅先生在《记念刘和珍君》中所说的那句话——“真的猛士，敢于直面惨淡的人生，敢于正视淋漓的鲜血”。

• 能够抓住重点，看透事物的本质。这个世界太复杂，有太多的因素和杂音影响着我们的判断和决定。绝大多数人都会在多重因素中迷失或是纠结。作为一个 Leader，能够抓住主要矛盾，看清事物的本质，给出清楚的观点或方向，简化复杂的事情，传道解惑、开启民智，让人豁然开朗、醍醐灌顶，才会让人追随之。

• 描绘令人激动的方向，提供令人向住的环境。我相信，我们每个人心中都有激动和理想，就算是被现实摧残得最凶残的人，他们已经忘却了心中那些曾经的激动和理想，但我相信也只是暂时的。一个好的 Leader 一定会把每个人心中最真善美的东西呼唤出来，并且还能让人相信这是有机会有可能做到的。

• 甘当铺路石，为他人创造机会。别人愿意跟随你，愿意和你共事，有一部分原因是你能够给别人带来更多的可能性和机会，别人觉得和你在一起能够成长，能够进步，你能够带着大家到达更远的地方。帮助别人其实就是帮助自己，成就他人其实也是在成就自己，这就像一个好的足球队一样，球队中的人都互相给队友创造机会，整个团队成功了，球队的每个人也就成功了。作为一个好的 Leader，你一定要在团队中创造好这样的文化和风气。

28 | 推荐阅读：分布式系统架构经典资料

29 | 推荐阅读：分布式数据调度相关论文

编程范式游记

函数式编程——有哪些领域是非函数式编程不可的吗？总感觉在实际的编码过程中（起码在我狭隘的编码过程）很鸡肋（用于代替大批量循环？）。大数据用得很多？scala？

GO中的反射 https://blog.golang.org/laws-of-reflection

什么是“边车模式”？实际应用案例？

hadoop生态集群管理工具，cloudera manager 了解一下？

奇奇怪怪的架构设计（对于现在的我有点抽象）

• 配置中心 Configuration Management
• 边车模式 Sidecar
• 服务网格 Service Mesh
• 网关模式 Gateway

左耳朵耗子谈比特币

最后一个哲学问题

当一个社会出现问题的时候，在民众开始抱怨和发泄不满的时候，需要一个目标。这是一件很自然的事。于是有人就满足大众，告诉大家，你们今天之所以穷，之所以苦，之所以不公，是因为那些中间商玩弄了你们，是因为政府不可信，是因为有坏人……因为这是最好被民众所理解的，因为有明确的目标，简单粗暴。这也是人们容易被煽动的原因。

然而，整个社会的运作其实是一种协同，由多方带着不同的利益或诉求而形成的。也就是说，问题的出现是多方造成的，或是社会协同出了问题造成的，是机制造成的。并不是其中的某个实体造成的。

而且，无论你制定出什么样的机制或是规则，都会有好的一面和不好的一面，这一面有多好另一面就有多不好。所以，如果一件事完全只有好的，而没有不好的，那么，你有绝大可能是在被人在忽悠中。

去中心化就是好吗？我们不需要权威机构了吗？技术可以解决信任问题吗？

我是要继续改善我们现在这个社会，还是直接毁了再建一个？是“破坏性的建设（Disruptive Construction）”，还是“建设性的破坏（Constructive Disruption）”？

我不知道你喜欢哪个，而我喜欢后者。

程序员练级攻略

开篇词

通过这一系列文章，我主要想回答以下几个问题。

• 理论和现实的差距。你是否觉得自己从学校毕业的时候只做过小玩具一样的程序？走入职场后哪怕没有什么经验也可以把文中提到的这些课外练习走一遍。学校课程总是从理论出发，作业项目都看不出有什么实际作用，到了工作上发现自己什么也不会干。

• 技术能力的瓶颈。你又是否觉得，在工作当中需要的技术只不过是不断地堆业务功能，完全没有什么技术含量。而你工作一段时间后，自己都感觉得非常地迷茫和彷徨，感觉到达了提高的瓶颈，完全不知道怎么提升了。

• 技术太多学不过来。你是否又觉得，要学的技术多得都不行了，完全不知道怎么学？感觉完全跟不上。有没有什么速成的方法？

对此，我有如下的一些解释，以端正一下你的态度。

• 并不是理论和现实的差距大，而是你还没有找到相关的场景，来感受到那些学院派知识的强大威力。算法与数据结构、操作系统原理、编译原理、数据库原理、计算机原理……这些原理上的东西，是你想要成为一个专家必须要学的东西。这就是“工人”和“工程师”的差别，是“建筑工人”和“建筑架构师”的差别。如果你觉得这些理论上的东西无用，那么只能说明，你只不过在从事工人的工作，而不是工程师的工作。
• 技术能力的瓶颈，以及技术太多学不过来，只不过是你为自己的能力不足或是懒惰找的借口罢了。技术的东西都是死的，这些死的知识只要努力就是可以学会的。只不过聪明的人花得时间少，笨点的人花得时间多点罢了。这其中的时间差距主要是由学习方法的不同，基础知识储备的不同决定的。只要你方法得当，多花点时间在基础知识上，会让你未来学习应用知识的时间大大缩短。以绝大多数人努力的程度，和为自己不努力找借口的程度为参考，只要你坚持正常的学习就可以超过大多数人了。
• 这里没有学习技术的速成的方法，真正的牛人不是能够培训出来的，一切都是要靠你自己去努力和持续地付出。如果你觉得自己不是一个能坚持的人，也不是一个想努力的人，而是一个想找捷径的人，那么，这篇文章并不适合你。这篇文章中的成长路径是需要思考、精力和相关的经验的，这都需要时间，而且是不短的时间。你先问问自己有没有花十年磨一剑的决心，如果没有，那这篇文章对你没有任何作用。

这里有一篇传世之文《Teach Yourself Programming in Ten Years》（中英对照版）。还有在我 Cooslhell 上的这篇《程序员的荒谬之言还是至理名言？》。

我希望你在学习编程之前先读一读这两篇文章。如果你觉得可以坚持的话，那么，我这一系列文章会对你很有帮助。否则，我相信你只要大致浏览一下目录及其中的某些章节，就会选择放弃走这条路的。是的，这个系列的文内容也会让一些想入行但又不愿意付出努力的同学早点放弃。

高手成长篇（不必过分push自己，毕竟是作者花了20年学习到的东西）

• Linux 系统、内存和网络（系统底层知识）
• 异步 I/O 模型和 Lock-Free 编程（系统底层知识）
• Java 底层知识
• 数据库
• 分布式架构入门（分布式架构）
• 分布式架构经典图书和论文（分布式架构）
• 分布式架构工程设计 (分布式架构)
• 微服务
• 容器化和自动化运维
• 机器学习和人工智能
• 前端基础和底层原理（前端方向）
• 前端性能优化和框架（前端方向）
• UI/UX 设计（前端方向）
• 技术资源集散地

与他人沟通

三本书

此外，我还想强调一点，无论干什么，你一定要有一个非常犀利的观点，也就是金句。如何得到这些金句呢？一定要多看书。你到那些公众号或者知乎里面看一些抖机灵的内容是没有用的。抖机灵的金句没有用。一定要是有思想深度的金句，才有力量。推荐你看三本书《清醒思考的艺术》、《简单逻辑学》和《重来》。

我是先被《重来》洗脑了，这本书帮我开拓了眼界，打破了我既有的思维模式，让我反思过去习以为常的每一件事。同时书中给出了实用、可操作的建议，让我头一次从心底感受到，原来世界还可以如此不同。

然后，我看了《清醒思考的艺术》，这本书作者以显微镜般的观察发现人们常犯的 52 个思维错误，并一一列出。帮人们认识到错误的思维是如何发生，从而避免掉入思维陷阱中。看这本书的过程中，我能明显感觉到自己的思维方式在被重新构造。

随后是《简单逻辑学》。逻辑学是很枯燥的，但这本书的作者以其简练而又充满趣味的笔触，将逻辑学活化为一种艺术，从它的基本原理，到论证，到非逻辑思维的根源，再到 28 种就发生在人们身边的非逻辑思维形式，带领我们进入这个精彩无比的逻辑世界，体会妙趣横生的思维交锋，跨过无处不在的逻辑陷阱，让人沉醉其中，欲罢不能。

这三本书对我影响很大，也建议你好好读读，能改善你的思维，炼就你的火眼金睛。你会发现自己跟和别人不在一个频道上，你能看到事物更多的侧面，在阐述观点时，会比别人更加深刻、犀利和有见地。一些金句也会在你跟人互动交流时，随机地冒出来。你自己都能明显感觉到自己的气场要比其他人足。

加餐—Go语言模式编程

https://time.geekbang.org/column/article/332600