mod

极客时间专栏/程序员进阶攻略/修行：由术入道/15 | 根源：计划的愿景——仰望星空.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="15 | 根源：计划的愿景——仰望星空" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ae/d3/ae5ee58110aebc0f30da63c54b0daad3.mp3"></audio>
+
+在前面第 2 章节 “程序之术” 中，我已把对“设计”“编程”和“Bug”的思考与理解都分享给你了。今天开始进入第 3 章节，是关于成长修行中 “由术入道” 的部分，而“道”的维度众多，我就先从和个人成长最直接相关的 “计划体系” 讲起。它会有助于你一步一步走向你“理想的自己”，所以可别小看它的重要性。
+
+我想你肯定做过计划，我也不例外。一般在开始一件中长期的活动前，我都会做计划，但更重要的是反问为什么要做这个计划，因为计划是抵达愿望的途径。如果不能清晰地看见计划之路前方的愿景，计划半途而废的概率就很大了。
+
+古希腊哲学家苏格拉底有一句名言：“未经检视的人生不值得活。”那么我们为什么要检视自己的人生呢？正是因为我们有成长的愿望，那么愿望的根源又到底是什么呢？
+
+## 需求模型
+
+上世纪四十年代（1943 年）美国心理学家亚伯拉罕·马斯洛在《人类激励理论》中提出了需求层次理论模型，它是行为科学的理论之一。
+
+该理论认为个体成长发展的内在力量是动机，而动机是由多种不同性质的需要所组成，各种需要之间，有先后顺序与高低层次之分，每一层次的需要与满足，将决定个体人格发展的境界或程度。 其层次模型的经典金字塔图示如下：
+
+<img src="https://static001.geekbang.org/resource/image/36/90/363a67db781786a5f0aca5417d6e0090.png" alt="" />
+
+在人生的不同阶段，会产生不同层次的目标需求。
+
+在人生的早期，我们努力学习，考一个好大学，拥有一技之长，找一份好工作，带来更高薪的收入，这很大程度都是为了满足图中最底层的生存需求，让生活变得更舒适美好。
+
+成长拼搏数年，事业小成，工作稳定，有房，有车，有娃后，第二层次，也就是安全的需求开始凸显。有人在这阶段开始给自己、父母、老婆、孩子都买人寿保险，开始考虑理财，投资甚至强身健体。然而处在这个阶段时，我却有一种强烈的不安全感，这也许和长年的程序员职业经历养成的习惯也有关系。
+
+我们做系统应用服务时总是需要考虑各种意外和异常事件发生，一般至少提供主备方案。于人生而言，保持持续学习，与时俱进，追求成长，这其实也是一种主备方案：主，指当前支撑生活的工作；备，是通过持续学习，同步成长，保持核心能力的不断积累与时间的付出来获得一份备份保障，以避免 “主” 出现意外时，“备” 的能力已被时代淘汰。
+
+需求金字塔底部两层属于物质层次的 “经济基础”，而再往上则进入了更高精神层次的 “上层建筑”。就个体而言，高层次需求要比低层次需求具有更大的价值。在 “生存” 和 “安全” 基本满足的保障基础之上，我们才会更从容地向内求，更多地探求内心，进而向外索，对外去探索、发现和建立不同的圈层关系，以满足上层的社交 “归属”、获得 “尊重” 与 “自我实现” 的需求。
+
+马斯洛把底层的四类需求：生存、安全、归属、尊重归类为 “缺失性” 需求，它们的满足需要从外部环境去获得。而最顶层的“自我实现” 则属于 “成长性” 需求。成长就是自我实现的过程，成长的动机也来自于 “自我实现” 的吸引。就像很多植物具有天生的向阳性，而对于人，我感觉也有天生的 “自我实现” 趋向性。
+
+人生最激荡人心的时刻，就在于自我实现的创造性过程中，产生出的一种 “高峰体验” 感。正因为人所固有的需求层次模型，我们才有了愿望，愿望产生目标，目标则引发计划。
+
+## 生涯发展
+
+在攀登需求金字塔的过程中，我们创造了关于人生的 “生涯”。而 “生涯” 一词最早来自庄子语：
+
+> 
+吾生也有涯，而知也无涯。以有涯随无涯，殆已。
+
+
+“涯” 字的原意是水边，隐喻人生道路的尽头，尽头已经没了路，是终点，是边界。正因如此，人生有限，才需要计划。著名生涯规划师古典有一篇文章《你的生命有什么可能？》对生涯提出了四个维度：高度、宽度、深度和温度。这里就借他山之玉，来谈谈我的理解。
+
+- 高度：背后的价值观是影响与权力。代表性关键词有：追逐竞争、改变世界。
+- 深度：背后的价值观是卓越与智慧。代表性关键词有：专业主义、工匠精神。
+- 宽度：背后的价值观是博爱与和谐。代表性关键词有：多种角色、丰富平衡。
+- 温度：背后的价值观是自由与快乐。代表性关键词有：自我认同、精彩程度。
+
+每个人的人生发展路线都会有这四个维度，只是不同人的偏好、愿望和阶段不同导致了在四个维度分布重心的差异。在不同维度的选择，都代表了不一样的 “生涯”，每一种 “生涯” 都需要一定程度的计划与努力。
+
+虽有四种维度，四个方向，但不代表只能选其一。虽然我们不太可能同时去追求这四个维度，但可以在特定的人生不同阶段，在其中一个维度上，给自己一个去尝试和探索的周期。所以，这就有了选择，有了计划。而计划会有开始，也会有结束，我们需要计划在人生的不同阶段，重点开始哪个维度的追求，以及大概需要持续的周期。
+
+人生本是多维的，你会有多努力、多投入来设计并实现自己的生涯规划呢？不计划和努力一下，也许你永远无法知道自己的边界和所能达到的程度。
+
+上世纪七十年代初，一个文学专业成绩很一般的学生毕业了。他虽然喜欢读文学作品却没写出过什么东西，毕业后就结了婚，和老婆开了个酒吧，生意不错，生活无忧。到了七十年代末，他似乎感受到某种 “召唤”，觉得应该写点什么东西了，于是每天酒吧打烊后，他就在餐桌上写两小时的小说，这一写就写了三十多年。熟悉的人想必已经知道他是谁了？对，就是村上春树。
+
+所以，总要开始计划做点啥，你才能知道自己的 “涯” 到底有多远；而计划就是在系统地探索生涯，甚至人生的无限可能性。
+
+## 回首无悔
+
+关于后悔，有研究说：“我们最后悔的是没做什么，而不是做过什么。”回味一下，这个结论也确实符合我们的感觉。
+
+万维钢写过一篇文章《决策理性批判》，里面引用了一个最新（2018）的关于后悔的研究，这个研究从 “理想的自己” 与 “义务的自己” 两个角度来说明：
+
+> 
+“理想的自己” 就是你想要成为什么人。
+“义务的自己” 就是你应该干什么。
+
+
+若放到前面马斯洛需求金字塔中，“理想的自己” 就是站在顶端 “自我实现” 位置的那个自己；而 “义务的自己” 正在金字塔下面四层，挣扎于现实的处境。如果你从来没有去向 “理想的自己” 望上一眼，走上一步，将来终究会后悔的。事实上，研究结论也证明了这点：70% 以上的人都会后悔没有成为 “理想的自己”。
+
+当我把自己进入大学以后的这十八年分作几个阶段来回顾时，有那么一段的好多时间我就是那样浑浑噩噩地混过去了，以至于现在回忆那段日子发现记忆是如此的粘连与模糊。后悔么？当然。
+
+如果我能好好计划一下那段日子，也许会得到一个更 “理想的自己”。而在最近的这一段，我也感谢好些年前 “曾经的我”，幸运兼有意地做了一些计划。虽然一路走来，有些辛苦，但感觉会充实很多，而且如今再去回首，就没有太多后悔没做的事了。
+
+计划，就是做选择，你在为未来的你做出选择，你在选择未来变成 “谁”。如果你还在为今天的自己而后悔，那就该为明天的自己做出计划了。
+
+人生的征程中，先是恐惧驱动，地狱震颤了你，想要逃离黑暗深渊；后来才是愿望驱动，星空吸引了你，想要征服星辰大海。
+
+逃离与征服的路，是一条计划的路，也是一条更困难的路，而 “你内心肯定有着某种火焰，能把你和其他人区别开来” 才让你选择了它。
+
+最后，你想去到哪片星空？你为它点燃了内心的火焰了吗？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/16 | 方式：计划的方法——脚踏实地.md

@@ -0,0 +1,101 @@
+<audio id="audio" title="16 | 方式：计划的方法——脚踏实地" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/28/48/285e0fe9aeee246706f7879d3325eb48.mp3"></audio>
+
+当你内心成长的火焰被点燃，有成长的愿望，也形成了清晰的成长愿景，但却可能苦恼于不知道如何确定目标、制定计划，以达成愿景。
+
+就拿我来说，每年结束我都会做一次全年总结，然后再做好新一年的计划，一开始这个过程确实挺艰难且漫长的，因为毕竟要想清楚一年的计划还是挺难的。但慢慢的，我开始摸索和学习到了一套制定富有成效计划的方法，成为了我成长的捷径。现借此机会我将其总结、分享给你。
+
+## 目标
+
+富有成效的计划的第一步，便是确定目标。
+
+在设定目标这个领域，国外一位研究者马克·墨菲（Mark Murphy）曾提出过一种 HARD 方法。HARD 是 4 个英文词的首字母缩写：
+
+- Heartfelt 衷心的，源自内心的
+- Animated 活生生，有画面感的
+- Required 必须的，需求明确的
+- Difficult 困难的，有难度的
+
+如其解释，这是一种强调内心愿望驱动的方法。按这个标准，一种源自内心的强烈需求在你头脑中形成很具体的画面感，其难度和挑战会让你感到既颤栗又激动，那么这也许就是一个好目标。
+
+应用到个人身上，HARD 目标中的 `H` 体现了你的兴趣、偏好与心灵深处的内核。就拿写作这个事情来说吧，于我而言，兴趣只是驱动它的一种燃料，而另一种燃料是内心深处的表达欲望。写作本身不是目标，通过写作去完成一部作品才是目标，就像通过写代码去实现一个系统，它们都是作品，其驱动内核就是一种 “创造者之心”。
+
+而 `A` 是你对这个目标形成的愿景是否足够清晰，在头脑中是否直接就能视觉化、具象化。就拿我个人来说，我非常喜欢读书，常在夜深人静的时候，默默潜读，掩卷而思，和作者产生一种无声的交流。这样一种画面，慢慢烙在脑海中，渐渐就激发起了想要拥有一部作品的目标。
+
+`R` 则是由上一篇文章中的马斯洛需求模型层次决定的。写作一方面本是自带属于第三层次的社交属性，但另一方面更多是一种成长性的自我实现需求在激发。完成一部作品，需要明确一个主题，持续地写作，一开始我从每月写，到每周写，再到写这个专栏，作品也就渐渐成型。
+
+而最后的 `D` 是其难度，决定了目标的挑战门槛。太容易的目标不值得设定，太难或离你现实太远的目标也不合适。基于现实的边界，选择舒适圈外的一两步，可能就是合适的目标。于我，从写代码到写作，其实也真就只有那么一两步的距离。
+
+以 HARD 目标法为指导，我回顾了我工作以来的成长发展阶段，根据目标的清晰度，大概可以划分为如下三个阶段：
+
+1. 目标缺乏，随波逐流
+1. 目标模糊，走走停停
+1. 目标清晰，步履坚定
+
+第一个阶段，属于工作的前三、四年，虽然每天都很忙，感觉也充实，一直在低头做事。但突然某一天一抬头，就迷茫了，发现不知道自己要去向哪里，原来在过去的几年里，虽然充实，但却没有形成自己明确的目标，一直在随波逐流。
+
+在那时，人生的浪花把我推到了彼时彼地，我停在岸边，花了半年的时间重新开始思考方向。当然这样的思考依然逃不脱现实的引力，它顶多是我当时工作与生活的延伸，我知道我还会继续走在程序这条路上，但我开始问自己想要成为一个怎样的程序员，想要在什么行业，什么公司，写怎样的程序。就这样，渐渐确立了一个模糊的目标。
+
+重新上路，比之前好了不少，虽然当时定的目标不够清晰，但至少有了大致方向，一路也越走越清晰。从模糊到清晰的过程中，难免走走停停，但停下迷茫与徘徊的时间相对以前要少了很多，模糊的目标就像一张绘画的草图，逐渐变得清晰、丰富、立体起来。当目标变得越来越清晰时，步履自然也就变得越发坚定。
+
+回顾目标在我身上形成的经历，我在想即使当时我想一开始就要去定一个目标，想必也不可能和如今的想法完全一致。毕竟当时受限于眼界和视野，思维与认知也颇多局限，所立的目标可能也高明不到哪里去；但有了目标，就有了方向去迭代与进化，让我更快地摆脱了一些人生路上的漩涡。
+
+假如，你觉得现状不好，无法基于现状延伸出目标。那么也许可以试试这样想：假如我不做现在的事情，那么你最想做的是什么？通常你当前最想做的可能并不能解决你的谋生问题，那么在这两者之间的鸿沟，如何去搭建一条桥梁，可能就是一个值得考虑的目标。
+
+我们为什么要立 HARD 目标？有一句话是这么说的：
+
+> 
+Easy choices, hard life. Hard choices, easy life.
+容易的选择，艰难的生活；艰难的选择，轻松的生活。
+
+
+## 方法
+
+目标是愿望层面的，计划是执行层面的，而计划的方式也有不同的认识维度。
+
+从**时间维度**，可以拟定 “短、中、长” 三阶段的计划：
+
+- 短期：拟定一年内的几个主要事项、行动周期和检查标准。
+- 中期：近 2～3 年内的规划，对一年内不足以取得最终成果的事项，可以分成每年的阶段性结果。
+- 长期：我的长期一般也就在 5～7 年周期，属于我的 “一辈子” 的概念范围了，而 “一辈子” 当有一个愿景。
+
+短期一年可以完成几件事或任务，中期两三年可以掌握精熟一门技能，长期的 “一辈子” 达成一个愿景，实现一个成长的里程碑。
+
+从**路径维度**，订计划可以用一种 SMART 方法，该方法是百年老店通用电气创造的。在 20 世纪 40 年代的时候，通用电气就要求每一个员工把自己的年度目标、实现方法及标准写信告诉自己的上级。上级也会根据这个年度目标来考核员工。这种方法进化到了 20 世纪 80 年代，就成了著名的SMART原则。
+
+SMART 也是 5 个英文词的首字母缩写：
+
+- Specific  具体的
+- Measurable 可衡量的
+- Achievable 可实现的
+- Relevant  相关的
+- Time-bound 有时限的
+
+今天 SMART 已经非常流行和常见，我就不解释其具体含义了，而是讲讲我如何通过 SMART 来跟踪个人年度计划执行的。按 SMART 方式定义的计划执行起来都是可以量化跟踪的，我通常用如下格式的一张表来跟踪：
+
+<img src="https://static001.geekbang.org/resource/image/c2/f3/c2a95b61c1b8bcdb982d140683d4cbf3.png" alt="" />
+
+其实，一年值得放进这张表的就那么几件事，每件事又可以分解为具体的几个可量化的任务，再分解到一年 50 周，就可以很明显地看出理想计划和现实路径的曲线对比。如下，是我 2017 年的一张计划与实际执行的对比曲线图：
+
+<img src="https://static001.geekbang.org/resource/image/75/e3/75ab745ec06dc17af708c8a65f1123e3.png" alt="" />
+
+按 SMART 原则方法使用计划跟踪表的优点是：简单、直接、清晰。但缺点也明显：即使百分百完成了所有的计划，也都是预期内的，会缺乏一些惊喜感。而因为制定目标和计划会有意识地选择有一定难度的来挑战，所以实际还很难达成百分百。
+
+说到目标的难度与挑战，使用 SMART 方法最值得注意的点就是关于目标的设定和方法的选择。鉴于人性和现实的因素，制定计划时很可能是这样一种情况：基于现实掌握的方法，考虑计划的可达性。这样制定出来的计划看起来靠谱，但却失去了真正挑战与创新的可能。
+
+通用电气传奇 CEO 杰克·韦尔奇执掌时期，有一个飞机引擎工厂制定了一个减少 25% 产品缺陷的目标。韦尔奇当时就觉得这个 SMART 目标很普通，没什么挑战，但工厂负责人却觉得已经很有难度了。韦尔奇执意坚持，把目标提高到了减少 70% 的缺陷，工厂负责人一开始很焦虑，认为这根本不可能完成。
+
+没办法，标准是韦尔奇定的，改不了。工厂负责人知道按以前的方法根本达不成，只好去寻找新方法。在寻找的过程中，他们发现，要想如此大幅度地减少缺陷，不能只靠质检人员，而是必须让每名员工都有质检意识。
+
+于是，工厂开始大规模进行培训；同时，工厂开始有意识招聘综合素质更高的技术工人。为了吸引并留住这些工人，工厂必须改变以前的管理方式，给他们更多的自主权，因为这些工人普遍受过很好的教育，而且很容易找到工作。最后，一个拔高的目标计划改变了整个工厂的培训、招聘和运行方式。
+
+SMART 计划，正如其名，需要聪明且智慧地设定并使用它。
+
+有时你可能会觉得计划没有变化快，或者计划好的人生，过起来好机械，没劲。其实计划是准备，变化才是永恒，而计划就是为了应对变化。为此，我经常会把计划表按优先级排得满满的，但我永远只做那些计划表顶部最让自己感到 HARD 的事情。
+
+变化来了，就把它装进计划表中，看这样的变化会排在哪个位置，和之前计划表前列的事情相比又如何。如果变化的事总能排在顶上，那么说明你的人生实际就在不断变得更精彩，做的事情也会让你更激动。而如果变化老是那些并不重要却还总是紧急的事情，老打断当下的计划，那么也许你就要重新审视下你当前的环境和自身的问题了。
+
+这样，计划表就成了变化表，人生无法机械执行，只有准备应对。
+
+最后，找到属于你的 HARD 目标，开始有计划且 SMART 的每一天；这样的每一天，走的每一步也许会更重些、累些，但留下的脚印却很深、很长。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/17 | 检视：计划的可行——时间与承诺.md

@@ -0,0 +1,75 @@
+<audio id="audio" title="17 | 检视：计划的可行——时间与承诺" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/67/8b/67df5606309ddb8349a70b0e6de6c08b.mp3"></audio>
+
+有了愿景，也有了具体的计划，但经常还是一年过去，发现实际和计划相比，总是有差距。是的，这是普遍现象，你可能并不孤独和例外：统计数字表明，在年初制定了计划的人中，只有8% 实现了这些计划。
+
+老实说，我回顾了近几年的个人年度计划完成情况，也只完成了约 70% 的样子。但我个人把这70% 的比例算作“完成”，毕竟一年中谁还没个变化呢？于是，我把另外的30%留给变化，毕竟一成不变地按计划来的人生，感觉太过枯燥，有 30% 的变化还可能会碰到 “惊喜”；而如果 70% 都是变化，那可能就是 “惊吓”了。
+
+程序员啊，有一个特点就是偏乐观，所以对于计划的估计总是过于乐观，乐观地期待 “惊喜”，然后又“惊吓”地接受现实。那如何才能让计划更具可行性呢？又可以从哪些方面来检视呢？
+
+## 时间与周期
+
+计划的第一个影响因素是和时间有关。
+
+在过去的人类社会生活中，人们已经习惯了以年为单位来进行时间分界，所以我们都会习惯于做年度计划。在个人的时间感觉中，一年，似乎也算是挺长一段时间了，但在过去这么些年的计划与实践中，我学到的经验是：做计划不能靠模糊的感觉，而是需要精确理性的计算。
+
+先来计算下，一年，我们到底有多少时间？一个正常参与社会工作的人，时间大约会被平均分成三份。
+
+其中的 1/3（约 8 小时）会被睡过去了，这里假设一个正常人的生理睡眠需求大约 8 小时。虽然有一些讲述成功人士关于睡眠的说法，比如：“你见过凌晨四点钟的…”，似乎在暗示他们之所以成功，是因为每天都很努力只睡四个小时。但这个说法并没有提每天几点入睡，只是说四点起床而已。而我写这篇文字也是在周末的早晨五点开始的，但前一晚十点之前便睡了过去，至少我对睡眠时间的要求是没法长期低于 8 小时的。
+
+另一个 1/3 你会贡献到和你的工作有关的各种事项中，虽然国家法律规定了每周只用上 5 天班，每天 8 小时，似乎用不了 1/3 的时间。但如果你的工作不是那种 “混日子” 的清闲工作的话，实际占用的时间基本总会多于法律规定的，至少程序员这份工作肯定是这样了。不过值得庆幸的是程序员的工作是可以随着时间积累起相应的知识、技能和经验，那么这份时间投入就是很有价值的了，随着时间积累，慢慢你就会成为工作领域内的行家。
+
+最后的 1/3 就是我们常说的决定人生的业余 8 小时。可能有人会说我根本就没有业余 8 小时，天天都在加班。实际上工作和业余的 8 小时有时不太那么具有明显的分界线。程序员的工作，是一份知识性工作，很可能工作时间你在学习，也有很多情况是你在业余时间处理工作的事务。对于严格区分工作和业余时间的思维，我碰到过一种人：上厕所都要忍着，到了公司利用工作时间再去，以达成变相在工作时间偷懒的感觉。但，其实时间总是自己的。
+
+一年 52 周，会有一些法定的长假和个人的休假安排，我们先扣除两周用于休假。那么一天业余 8 小时，一年算 350 天，那么一年总共有 2800 小时的业余时间。但实际这 2800 小时里还包括了你全部的周末和一些零星的假期，再预扣除每周 8 小时用于休闲娱乐、处理各种社会关系事务等等，那么你还剩下 2400 小时。
+
+这2400 小时就是你可以比较自由地用来安排的全部业余时间了，这就是理性计算的结果。这样看来，一年实际能用来计划的时间并不多，需要仔细挑选合理的事项，放进计划表，并真正地执行。而实际，一年中你还需要把时间合理地分配在 “短、中、长” 三种不同周期的计划上。
+
+- 短期：完成事项，获取结果，得到即时反馈与成就感（比如：写这个专栏）。
+- 中期：学习技能，实践经验，积累能力（比如：学一门语言）。
+- 长期：建立信念，达成愿景（比如：成长为一名架构师）。
+
+你可以从时间的维度，看看你计划的时间安排是否合理分配在了不同周期的计划事项上。如果计划的事项和周期匹配错了，计划的执行就容易产生挫败感从而导致半途而废，曾经的我就犯过这样的错误。
+
+这个错误就是在学习英语的计划上。两年多以前，工作十年后的我又重启了英语提升计划，希望能通过每天 3 ～ 4 小时的英语学习，一年内使自己的英语听读都能达到接近汉语的水平。但实际情况是，我用了两年（接近 1500 小时吧）才勉强比刚从学校毕业时上了一个台阶，离母语水平，我不知道前面还有多少个台阶。
+
+英语提升计划，我搞错了周期，一度颇受打击。英语技能，实际就是一个 10000 小时技能，虽然我是从初中开始学习，然后至大学毕业拿到六级证，差不多有十年时间。但实际真正有效的学习时间有多少呢？假如每天一节课算 1 小时，一周 6 小时，每年 50 周，十年上课下来也就 3000 小时，再考虑为了考试自己的主动复习时间，再加 2000 小时，那么过去在学校总共投入了 5000 小时。
+
+但从学校毕业后的十年，实际工作环境中，除了技术英语阅读，我几乎很少再接触英语了。而语言基本就是用进废退的技能，所以再重启学习提升计划时，我对此计划的周期完全估算错误，最后得到的效果也远低于我的预期。其实这应该是一个长期的计划，定一个合理的愿景，循序渐进成为一名熟练的英语使用者。
+
+要让计划可行，就是**选择合适的事项，匹配正确的周期，建立合理的预期，得到不断进步的反馈**。
+
+## 兴趣与承诺
+
+既然时间有限，那该如何选择有限的事项，才可能更有效地被执行下去呢？
+
+其中有一个很重要的因素：兴趣。有的人兴趣可能广泛些，有的人兴趣可能少一些，但每个人多多少少都会有些个人的兴趣爱好。对于兴趣广泛的人来说，这就有个选择取舍问题，若不取舍，都由着兴趣来驱动，计划个十几、二十件事，每样都浅尝辄止。实际从理性上来说价值不大，从感性上来说只能算是丰富了个人生活吧。
+
+彼得·蒂尔在《从 0 到 1 》这本书里批判了现在的一个观点：过程胜于实效。他解释说：“当人们缺乏一些具体的计划去执行时，就会用很正式的规则来建立一些可做的事情选项的组合。就像今天美国中学里一样，鼓励学生参与各种各样的课外活动，表现的似乎全面发展。到了大学，再准备好一份看似非常多元化的简历来应对完全不确定的将来。言外之意，不管将来如何变化，都在这个组合内能找到可以应对的准备。但实际情况是，他们在任何一个特定方面都没有准备好。”
+
+因此，在有限的学校生涯中，你就得做出选择。就好像我大学那时，学校开了几十门（记得大概有 45 门）各类专业课，这就是一个组合。但其中真正重要的课程实际只有个位数，重心应该放在少数课程上，其他的只起到一个开阔眼界和凑够学分的作用。
+
+几十门课是学校给的选项，你可以从中做出选择。那应该选择哪些事项放进计划表呢？我建议你可以从兴趣作为出发点，因为这样更容易启动；而对于中期目标，像学习提升一项技能，只靠兴趣是不足以驱动去有效执行的，甚至达不到预期效果。关于此，吴军有一个观点：
+
+> 
+凡事从 0 分做到 50 分，靠的是直觉和经验；从 50 分到 90 分，就要靠技艺了。
+
+
+凭借兴趣驱动的尝试，结合直觉和经验就能达成 50 分的效果，而要到 90 分就需要靠技艺了。而技艺的习得是靠刻意练习的，而刻意练习通常来说都不太有趣。要坚持长期的刻意练习，唯一可靠的办法就是对其做出郑重的承诺。
+
+通过兴趣来启动，但要靠承诺才能有效地执行下去。感兴趣和做承诺的差别在于，只是感兴趣的事，到了执行的时候，总可以给自己找出各种各样的原因、借口或外部因素的影响去延期执行；而承诺就是这件事是每天的最高优先级，除非不可抗力的因素，都应该优先执行。
+
+比如，写作本是我的兴趣，但接下 “极客时间” 的专栏后，这就是承诺了，所以为此我就只能放弃很多可以用于休闲、娱乐的时间。
+
+**兴趣让计划更容易启动，而承诺让计划得以完成。**
+
+而在现实生活中，让计划不可行或半途而废的常见错误有：
+
+- 以为一年之内自己有足够多的自由支配时间；
+- 对计划的事情误判了其开发与成长的周期；
+- 兴趣很多，一直在尝试，却不见有结果。
+
+放进计划表的事项是你精心识别、选择并做出的承诺，而承诺也是一种负担，若承诺太多，负担可能就太重，会让你感觉自己不堪重负，最后就可能放弃了，到头来又是一场空。其实，一年下来，重要的不是开启了多少计划，而是完成了几个计划。
+
+所以，可行的计划应该是：**有限的时间，适合的周期，兴趣的选择，郑重的承诺**。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/18 | 评估：计划的收获——成本与收益.md

@@ -0,0 +1,102 @@
+<audio id="audio" title="18 | 评估：计划的收获——成本与收益" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d5/b9/d524a1f35233e478cf31eb1b8303dcb9.mp3"></audio>
+
+做计划自是为了有收获，实现愿景也好，获得成长也罢，每一份计划背后都有付出与收获的关系。如果计划的收益不能高于执行它付出的成本，那么其实这种的计划就几乎没有执行价值。
+
+执行计划的成本通常是你付出的时间或金钱，但收益则没那么明确，这就需要你去仔细评估和取舍。
+
+而有些计划本身从成本和收益的角度看就不是一个好计划，比如，我见过一些计划是：今年计划读20本书。读书本是好事，但读书的数量并不是关键点，关键是计划今年读哪些书。因为只有明确了读哪些书，才能评估是否值得和适合在这阶段去读。
+
+值得与否，就是关于成本与收益的评估，而为了更好制定有价值的计划，你就需要去仔细权衡这种关系。
+
+## 成本与机会
+
+计划即选择，而但凡选择就有成本。
+
+从经济学思维的角度，做计划就是做选择，选择了某些事情；而选择了这些事情，就意味着放弃了另外可能做的事情，这里面的成本就是机会成本。机会成本是放弃的代价，选择这些事情从而放弃的其他可能选项中拥有最高价值的事情。
+
+就好像同样一个晚上，有人选择了用来玩网络游戏，你以为的成本是几小时的点卡钱，但实际你放弃的是用来学习、看书等其他事项的潜在价值与收益。青少年时代谁还没玩过游戏，我也玩过十多年的游戏，虽不能简单地认为游戏毫无意义，但十年前，我明白了机会成本的概念后，就做出了选择。
+
+我的长期计划中有一项是写作。从我 2011 年开始写下第一篇博客放在网上到现在，已经过去了七年。那写作的成本和收益又是怎样的呢？
+
+一开始总有一些人愿意免费写一些优质内容放在网上，从读者的角度来看，他们总是希望作者能长期免费地创造优质内容。但从花费的时间成本来看，这是不太现实的，也很难长久持续下去。
+
+从作者的角度，时间成本其实是越来越高，而且很刚性。比如，七年前我写一篇文章的时间其实和现在差不太多，时间成本按说是增加的（因为单位成本随时间增加了）；但是写作会持续创造价值，我可以在持续写作中不断总结获得成长，而成长的价值都会通过职业生涯发展获得收益，这是间接收益。而一些成功的作者，可能还可以通过写作获得直接收益，比如目前蒸蒸日上的各类知识付费专栏。
+
+在中国互联网快速发展的这十多年间，我的学习路径也发生了转变。前期，我都是从网上去扒各种免费的电子书，看免费的博客，读开源的代码；但今天我几乎不会再去网上找免费的学习材料了，而是直接付费购买。
+
+而且你应该也发现了现在知识和内容付费的趋势在扩大，这是为什么？因为大家都意识到了时间的成本，是选择花费自己的时间去搜索、甄别和筛选内容，还是付出一点点费用得到更成体系的优质内容？大家已经做出了选择。
+
+学习计划是个人成长计划中的一部分，而成长计划中，最大的成本依然是时间。在你早期的学习阶段，虽然时间没那么值钱，但把钱和时间都花在加速成长上，其实是“成本有限，潜在收益巨大”的选择。
+
+而计划，就是对你的时间做分配。时间在不同的阶段，价值不同，那么成本也就不同。你要敏感地去感知自己时间的成本，去提升时间的价值，根据时间的价值再去调整自己的计划和行动。成长过程中，早期的成本低而选项多，后期的成本高且选项少。
+
+文艺复兴时期法国作家蒙田曾说过：
+
+> 
+真正的自由，是在所有时候都能控制自己。
+
+
+如蒙田所说，**计划才能给你真正的自由，你对计划的控制力越强，离自由也就更近了**。
+
+## 结果与收益
+
+计划得到了执行，产生了预期的结果，才会有期望的收益。
+
+但据抽样统计，制定了年度计划的人里面，仅有 8% 的人能完成他们的年度计划。年度计划通常都是一份从未向任何人公布的计划，从某种意义上来说，除了你自己自律，并没有任何约束可言。这个世界的外部环境变化那么快，你很容易找到一个理由说服自己：计划赶不上变化。
+
+变化之后的计划，只是一份更契合实际的计划，而非不再存在。很多外部因素是你无法预测和控制的，总会来干扰你的计划，所以这给了你足够的客观原因。但无论有多少客观原因，你做计划的初衷是：一点点尝试去控制自己的生活，然后得到自己想要的结果。
+
+在获得结果的路上，这个世界上似乎有两类人：
+
+- 第一类人，自己给自己施加约束，保持自律并建立期望；
+- 第二类人，需要外部环境给予其约束和期望。
+
+在我读高中时，现实中就有一种巨大的社会期望和约束施加己身，那就是高考。在这种巨大的社会外部约束和期望下，第二类人可以表现得非常好，好到可以考出状元的分数。但进入大学后，这样的外部约束和期望会瞬间下降，最后可能也就泯然众人之间了。
+
+心理学上有个皮格马利翁效应：
+
+> 
+人们基于对某种情境的知觉而形成的期望或预言，会使该情境产生适应这一期望或预言的效应。
+
+
+通俗点说就是，如果有人（可以是别人或自己）对你的期望很高，你会不自觉地行动去满足并符合这种期望；若周围没有这样的期望，最终你可能就是一个符合周围人群平均期望的人。而所谓的自驱力，就是你对自己的期望所形成的推动力量。
+
+**要获得好的结果，你就要做第一类人，需要对自己有更高的期望，需要有自驱力。**
+
+进入大学或工作以后，周围环境对你的期望已经降到很低。于我而言，来自父辈的那一代人，也就是上世纪四五十年代那一代，经历了饥荒甚至战争，他们的期望通常代表一代人，都是平平安安、健健康康，有个稳定的工作就够了。
+
+这样的期望对于大部分读了大学、有个工作的人来说都不足以形成驱动力了，更何况我们大多数人每日工作忙里忙外，不外乎忧心柴米油盐，困于当下。少了外部足够强大的期望推动，多数第二类人的内心驱动从此也就熄火了，但还是有少数的第一类人在 “仰望星空”，比如科幻小说《三体》的作者大刘（刘慈欣）。
+
+我是 1999 年在四川成都的一本科幻杂志《科幻世界》（现已停刊）上读到他的首部短篇小说的。实际他 85 年毕业，在电厂任工程师，89 年开始写科幻小说，直到 99 年才见到他的第一部作品公开发表。从 89 年到 99 年这十年间基本就是独自“仰望星空”来完成了写作这门技艺的打磨过程，并留下了自己的第一部作品，再之后到写完《三体》，这又是另一个十年了。
+
+而于我，除了写作，还有另一项长期计划：学好英语。快三年前了，我重启了英语提升计划，付出的成本是每天至少一到数小时不等的学习和听读文章的时间成本，那么收益呢？学好英语是能产生直接收益的，比如通过翻译就能赚钱，但这就落入了一种狭隘的思维。
+
+一方面，翻译的时间单价市场行情是非常低的，目前英译中的普通文章，恐怕不到 100 元每千字，相比一个初中级程序员的市场价，时间成本是很不划算的。所以，学好英语从我的角度来说，赚取的不是直接的经济收益，而是间接的结构性收益，增强直接收益结构价值。
+
+那么如何理解收益结构？以我现阶段的状态来说，已有三个直接收益结构：
+
+- 专业
+- 写作
+- 理财
+
+专业，自然是指程序专业技能，通过出售自己的时间和人力资源来获取一份相对稳定的工资收入来源。写作，到今天这个专栏出品后，终于可以通过作品的形式产生直接收益，它只需一次性投入时间来完成作品。而理财属于资产性收益，就是任何等价于钱的家庭动产或不动产，能产生利息、分红或租金的收入，它需要长期的收入结余积累。
+
+而英语技能的提升对这三个直接收益结构，都能产生增益作用。程序行业自不必多说，行业里最好的文章、书籍或专业论文材料等可能都是英文的，只有少部分被翻译了过来，但翻译总是有损失、有偏差、有歧义，能直接高效地阅读英语对提升你的专业技能和能力帮助巨大。
+
+而写作，英语给我提供了另外一个更广阔世界的写作素材和看待世界的角度。所以，我在时间分配上不仅看中文文章，也看一些英文媒体文章和书籍。
+
+至于理财，英语让我更直接高效地接收中文世界以外的信息，从某种角度来说，具备了更多元化的视角和思维结构。而思维和视角是投资理财的核心能力，在这个领域全是选择题，只有做对选择的概率高于做错的概率，才可能获得正收益。
+
+这就是我选择一项长期计划时关于结果与收益的思考，而成长计划的收益，从经济价值来说，都是远期收益，是为了变得更值钱。也许期望的结果达成，目标实现，真的会变得更值钱，就像上面例子里的大刘。但也可能没能实现目标，那么你还能收获什么？也许有来自过程的体验，这也是选择目标时，源自内心和兴趣是如此重要的原因。
+
+在考虑付出与收获时，后来读到一句话，大意如下：
+
+> 
+生活也许不会像计划那样发生，但对待生活的态度可以是：期待伟大的事情发生，同时也要保持快乐和幸福，即使它没能发生。
+
+
+如此，面对真实的生活，也当释然了。
+
+最后，留个思考题：关于计划你感觉是束缚了你的生活，还是让你更自由了？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/19 | 障碍：从计划到坚持，再到坚持不下去的时候.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="19 | 障碍：从计划到坚持，再到坚持不下去的时候" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0f/58/0fdd503e2f69409bdf77bbfbdeb6fe58.mp3"></audio>
+
+设定一个计划并不困难，真正的困难在于执行计划。若你能够坚持把计划执行下去，想必就能超越绝大部分人，因为大部分人的计划最终都半途而废了。
+
+为什么那么多计划都半途而废了？在执行计划时，你会碰到怎样的障碍？我想从计划生命周期的各个阶段来分析下。
+
+## 酝酿
+
+酝酿期，是计划的早期雏形阶段；这阶段最大的障碍来自内心：理性与感性的冲突。
+
+计划的目标是源自内心的，但也是有难度的，若是轻而易举的事情，也就不用计划了。这些需要坚持的事情，通常都 “不好玩”，而人是有惰性的，内心里其实并不愿意去做，这是我们感性的部分。但理性告诉我们，去完成这些计划，对自己是有长远好处的。这，就是冲突的地方。
+
+就以我自己写作的例子来看，我不是一开始就写作的，我是工作了 5 年后，碰到了平台期，撞上了天花板，感觉颇为迷茫。于是就跑到网上到处看看有没有人分享些经验，找找道路。然后，看到了一些 “大神” 们写的博客，分享了他们一路走过的经历，在我迷茫与灰暗的那个阶段的航行中，就像一盏灯塔指引着前进方向。
+
+于是我在想，也许我也可以开始写写东西。那时，内心里出现了两个声音，一个声音说：“你现在能写什么呢？有什么值得写的吗？有人看吗？”而另一个声音反驳说：“写，好过不写，写作是一件正确的事，就算没人看，也是对自己一个时期的思考和总结。”
+
+最终，理性占了上风，开启了写作计划，然后注册了一个博客，想了一句签名：“写下、记下、留下”。
+
+## 启动
+
+启动期，是计划从静止到运动的早期阶段；这阶段的最大障碍是所谓的“最大静摩擦力”。
+
+我们都学过初中物理，知道 “最大静摩擦力” 是大于 “滑动摩擦力” 的，也就是说要让一个物体动起来所需要的推力，比它开始运动后要大一些。这个现象，放在启动一个计划上时，也有类似的感觉，所以才有一句俗语叫：“万事开头难”。
+
+还是回到我开始写作那个例子，我的第 1 篇博客的写作过程，至今还记得很清楚：一个周六的下午，在租的小房间里整整写了一下午。写得很艰苦，总感觉写得不好，不满意。最后一看天都黑了，肚子也饿了，就勉勉强强把它发了出去。
+
+发出去后的前两天，我也会经常去刷新，看看阅读量有多少，有没有人评论啊。让人失望的是，前一个声音的说法变成了事实：的确没什么人看。两天的点击量不到一百，一条评论也没有，而且这一百的阅读计数里，搞不好还有些是搜索引擎的爬虫抓取留下的。
+
+但是，写完了第一篇，我终于克服了写作的 “最大静摩擦力” 开始动了起来，一直写到了今天，这已经过去了 7 年。
+
+## 执行
+
+执行期，是计划实现过程中最漫长的阶段；这阶段的最大障碍就是容易困倦与乏味。
+
+漫长的坚持过程期，大部分时候都是很无聊、乏味的，因为真实的人生就是这样，并没有那么多戏剧性的故事。所以，我在想这也许就是为什么那么多人爱看小说、电视剧和电影的原因吧，戏中的人物经历，总是更有戏剧性。
+
+美国当代著名作家库尔特·冯内古特在一次谈话中谈及人生，他用了一组形象的类比来描述人生。我翻译过来并演绎了一下，如下面系列图示：
+
+其中，纵坐标表示生活的幸福程度。越往上，代表幸福指数越高；越往下，代表幸福指数越低。中间的横线表示普通大众的平凡人生。
+
+<img src="https://static001.geekbang.org/resource/image/52/4f/5291d444d35ebe736de08bbb2503d74f.png" alt="" />
+
+那么先来看一个大家都很熟悉的从 “丑小鸭” 变 “白天鹅”的故事：灰姑娘 。
+
+<img src="https://static001.geekbang.org/resource/image/79/79/79d7281a2f4adfc6a4a509561f91fb79.png" alt="" />
+
+我们从小就听过这个故事，人们喜欢这样的故事。同样的故事内核，被用在不同的故事里书写了上千次，传诵了上千年。这是一个皆大欢喜的故事，而下面则是一个稍微悲伤点的故事。
+
+<img src="https://static001.geekbang.org/resource/image/aa/e5/aa7351ed56d7f29fc32cec41c96b4be5.png" alt="" />
+
+故事虽以悲剧开始，但好在以喜剧结束。人们也喜欢这样的故事，生活不就该这样吗？问题是，真实的生活可能是下面这样的。
+
+<img src="https://static001.geekbang.org/resource/image/36/7e/3684a990e54531a1206f54eda5ee177e.png" alt="" />
+
+没有那么多大起大落，我们大部分人的生活只是在经历一些平平凡凡的琐事。也许其中有些会让你感到高兴与兴奋，有些又让你感到烦躁与郁闷。但这些琐事都不会沉淀进历史中，被人们传诵上千年，它仅仅对你自己有意义。
+
+所以呢，你明白为什么你感觉你的坚持那么无聊、单调与乏味了吧，大多数时候它都缺乏像 “灰姑娘” 故事曲线的戏剧性。而对抗这种过程的无聊，恰恰需要的就是故事。你看人类的历史上为什么要创造这么多戏剧性的故事，让这些戏剧性的故事包围了我们的生活，让人们想象生活充满了戏剧性，这种想象是治疗乏味的良药，也成为了创造更美好生活的动力。
+
+万维钢的一篇文章《坚持坚持再坚持》里也提到：
+
+> 
+故事的价值不在于真实准确，而在于提供人生的意义。
+
+
+坚持，特别是长期的坚持，是需要动力的，而动力来自目标和意义。而获得目标与意义的最好方式是讲好一个故事。你看，成功的企业家会把未来的愿景包进一个美好的故事里，让自己深信不疑；然后再把这个故事传播出去，把所有相信这个故事的人聚在一起去追寻这个故事；最后，这个关于未来的故事就这样在现实中发生了。
+
+漫长的人生，你需要为自己讲好一个故事。
+
+## 挫败
+
+挫败，不是一个阶段，而是坚持路上的一些点；正是在这些点上你遭遇了巨大的挫败感。
+
+为什么会产生挫败感？可能的原因有，一开始你就不知道这件事有多难，直到走了一段后才发现这太难了。一开始就评估清楚一个计划的难度，需要投入大量的时间、经历和金钱，甚或有更高的技能与能力要求，这本身就是一件不容易的事。
+
+而如果你计划的是一件从来没做过的事情，这就更难准确评估了。在路上，行至中途遭遇 “低估” 的挫败感就再正常不过了，而不少人，因为挫败过一两次后，就会放弃了计划。有时，遭遇挫败，选择了放弃，这个未必就是不合适的，但这要看这个放弃的决策是在什么情况下做出的。
+
+遭遇挫败，你会进入一种心情与情绪的低谷，这个时候有很高的概率做出放弃的决策。而我的经验是，不要在挫败的情绪低谷期进行任何的选择与决策。可以暂时放下这件事，等待情绪回归到正常，再重新理性地评估计划还是否该坚持。
+
+每经历一次挫败之后，你还选择坚持，那么就已经收获了成长。
+
+最后总结来说，就是：你为了做成一件事，定一个计划，在执行计划的过程中，在 “酝酿”“启动” 和 “执行” 的不同阶段都会碰到各种障碍，可能都会让你产生一种快坚持不下去了的感觉。每到此时，你都要想想清楚，哪些是真正客观的障碍？哪些是主观的退却？
+
+从坚持到持续，就是试图让现实的生活进入童话的过程，而后童话又变成了现实。
+
+本文分析了计划的执行障碍，最后我也想问问你，在你成长的路上，遭遇过哪些障碍？是什么原因让你坚持不下去了的？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/20 | 执行：从坚持到持续，再到形成自己的节奏.md

@@ -0,0 +1,95 @@
+<audio id="audio" title="20 | 执行：从坚持到持续，再到形成自己的节奏" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b6/f9/b62917b0c3c54fba57cacc1b50b7f3f9.mp3"></audio>
+
+有了一个目标后，我们通常会做好全方位的计划，并满心期待启动它，本想着朝着既定目标“一骑红尘飞奔而去”。但计划赶不上变化，很多时候，执行了一段时间后，我们可能会觉得比较累，有种快坚持不下去了的感觉，然后就半途而废了。这种场景我们每个人应该都不陌生。
+
+其实，在执行过程中，容易半途而废的一个很可能的原因在于节奏出了问题。
+
+## 计划的节奏
+
+一个计划被制定出来后，我们通常会根据它的周期设定一个执行的节奏。
+
+**长期**，就像长跑，跑五千米是长跑，跑马拉松（四万多米）也是长跑，但我们知道跑五千米和跑拉松肯定是用不同的节奏在跑。
+
+一个长期的目标可以是五年，也可以是十年，因目标而异。要精熟一门技能领域，比如编程，确切地说应该是编程中的某一分支领域，对于一般人来说，可能就需要三五年不等了。而像精通一门外语，可能需要的时间更长，我是从初中开始学习英语的，如今二十多年过去了，别说精，可能连熟都谈不上。
+
+于我而言，可能因为编程技能是要解决吃饭温饱的需要，刚需比较强烈；而英语这么多年，都是考试的需要，刚需太弱，故二者的学习和练习节奏完全不同，最后学习掌握的能力也相差甚远。
+
+一个**中期**的目标，也许是一年。比如，计划用一年时间写一本书，假如一本书 20 万字，那每周大约需要完成 4000 字，再细化到每天就是800 字左右。这就是我们做一年计划的方式，计划成型后，相应做出分解，分解到周这个级别后，基本的计划节奏就出来了。
+
+一个**短期**的目标，可能是几个月。比如，我这个 “极客时间” 专栏，计划就是几个月内完成的事情。它上面已经形成了每周三篇更新的节奏，这样的写作节奏对于我来说基本已经算是全力冲刺了，所以时间就不能拉得太长。
+
+不同周期的计划，都会有一个共同的问题：计划总是过于乐观了，现实的执行很难完全符合计划。
+
+你可能也遇到过，计划的节奏总是会被现实的“意外”打断，每次计划的节奏被打断后，都会陷入一种内疚的挫败感中；然后就强迫自己去完成每日计划列表中的每一项，否则不休息，最终也许是获得了数量，但失去了质量。在这样的挫败中纠结了几次后，你慢慢就会发现，现实总是比计划中的理想情况复杂多变。
+
+不过，这才是真实的人生。偶尔错过计划没什么大不了的，如果人生都是按计划来实现，那岂不也有些无聊。
+
+万维钢有篇文章叫《喜欢 = 熟悉 + 意外》，这篇文章下有位读者留言说：
+
+> 
+贾宝玉第一次见到林黛玉说的第一句话就是 “这个妹妹好像在哪儿见过似的”。有点熟悉，也有点意外，这就是喜欢了。
+
+
+所以，当“意外”出现时你不必感到太过闹心，试着换个角度来看，这偶尔出现的“意外”也许会反而让你更喜欢这样的人生呢。
+
+计划更多是给予预期和方向，去锚定现实的走向，但在行进的过程中，“意外” 难免会出现。所以，你要从心理上接受它，并从行为上合理地应对它。
+
+下面我就来说说我是怎么应对这些“意外”的。
+
+按程序员的思考方式，我会为所有计划中的事情创建了一个优先级队列，每次都只取一件最高优先级的事情来做。而现实总会有临时更高优先级的 “意外” 紧急事件插入，处理完临时的紧急事件，队列中经常还满满地排着很多本来计划当天要做的事情。
+
+以前，我总是尝试去清空队列，不清空不休息，但实际上这很容易让人产生精疲力竭的感觉。如今，我对每个计划内的事情对应了一个大致的时间段，如果被现实干扰，错过了这个时间段，没能做成这件计划内的事情，就跳过了，一天下来到点就休息，也不再内疚了。
+
+举例来说，我计划今晚会看看书或写篇文章，但如果这天加班了，或者被其他活动耽误了，这件计划中的事情也就不做了。但第二天，这件事依然会进入队列中，并不会因为中断过就放弃了。只要在队列里，没有其他事情干扰，到了对应的时间段就会去执行。
+
+计划的节奏，就像中学物理课上假设的理想的无摩擦力环境，而现实中，摩擦力则总是难以避免的，所以你要学会慢慢习惯并适应这真实而有点“意外”的节奏。
+
+## 他人的节奏
+
+跑马拉松的时候，一大群人一起出发，最后到达终点时却是稀稀拉拉。这说明每个人的节奏是不同的，即便同一人在不同阶段的节奏也是不一样。
+
+同理，就拿我的写作节奏来说，在七年中也慢慢从每月一篇提升到了每周一篇。当然，有些微信公众号的作者写作速度一直都很快，可能是每天一篇。但如果我要用他们的节奏去写作，可能一开始坚持不了多久就会放弃写作这件事了。
+
+所以，从写作这件长期的事情中，我收获的关于节奏的体会是：每个人都会有自己不同的节奏，这需要自己去摸索、练习，并慢慢提升。如果开始的节奏太快，可能很快就会疲惫、倦怠，很容易放弃；但如果一直节奏都很慢，则会达不到练习与提升的效果，变成了浪费时间。
+
+执行长期计划，就如同跑马拉松，本来是一群人一起出发，慢慢地大家拉开了距离，再之后你甚至前后都看不到人了。是的，正如《那些匀速奔跑的人你永远都追不上》那篇文章所说：
+
+> 
+匀速奔跑的人是那些可以耐住寂寞的人，试想当你按照自己的节奏持之以恒默默努力地去做一件事情时，是极少会有伙伴同行的，因为大家的节奏各不一样，即便偶尔会有也只是陪你走过一段。
+
+
+但有时，我们看见别人跑得太快没了踪影，心里会很是焦急。我们身边有太多这样的人，把一切都当成是任务，必须要在某个确定的时间做完它，必须要在一个规定的时间内取得它应有的效益。
+
+的确，我们的世界变化太快了，快到我们都怕浪费一分一秒，快到我们被这个世界的节奏所裹挟，所以就逼迫自己去努力，去完成，去改变，但却完全失去了自己的节奏，直到我们决定随它去吧，和大家随波逐流就好。
+
+有时太急迫地“追赶”，最后反而阻挡了你稳步前进的步伐和节奏。
+
+## 自己的节奏
+
+找到并控制好自己的节奏，才能长期匀速地奔跑，才能更高效地利用好自己的时间和注意力。
+
+对于每日计划的执行节奏，我自己的经验是：**把自己的时间安排成一段一段的，高度集中和高度分心交叉分布**。
+
+假如某段时间需要高度集中注意力，就可以处理或思考一些比较难的事情。比如，50 ～ 60 分钟，集中注意力处理工作事务，远离手机信息推送及其他各种环境的打扰；然后休息一会儿，10 ～ 15 分钟左右，回复一些聊天或邮件这类其实不需要那么高注意力的事情。
+
+有时，当你想去处理一件复杂困难的事情，比如写作，这是一种短时间内需要高度集中注意力的活动，但这时脑中总是在同时想着其他很多事情或者被动地接收一些环境信息（周围的谈话声之类的），还控制不住，很难集中注意力。这种情况下，就不用勉强开始，我通常会通过切换环境，从外部去排除一些干扰。
+
+另外，如果感觉是比较疲惫，则更不能马上开始了，这种状态下，一般我都是立刻去小憩片刻或者闭目养神一段时间（20 ～ 30 分钟），进入一种浅睡眠状态再恢复过来，精力的恢复感会比较好。
+
+恢复精力，我的感觉是浅睡优于深度睡眠，一是因为进入深度睡眠需要更长的时间，二是因为从中恢复过来也需要更长时间。所以，一旦进入深度睡眠，中途被人打断叫醒，会感觉非常困倦，我想很多人都有过这种感觉，俗称：睡过头了。
+
+而另外一种中长期目标的执行节奏，控制起来可能要更困难一些。
+
+比如，我们大部分人人生中第一阶段的奔跑目标：高考。为了奔向高考这个目标，我们有十二年时间进入学校，按照固定的节奏学习。一开始轻松些，跑得随意些；慢慢长大后，学业的压力开始明显起来，竞争的味道开始浓厚起来。特别是进入高中后，所有的同学都开始加速奔跑，以这样一种被设计好的节奏奔向目标。
+
+这高考之前的学习节奏，更多是被整个社会和教育体系设计好的。我们只是在适应这个节奏，适应得很好的学生，高考一般都会取得不错的成绩；当然也有适应不了的同学，甚至有到不了参加高考就已经离开了赛道的。
+
+在这个过程中，外界会给予我们一些期望的节奏压力，但要取得最好的效果，我们还是要找到自己的节奏。节奏是我们能长期持续奔跑的很重要的因素。还好高考结束后，再没有一个固定的时间点，也没有那么强大的外部环境去制约甚至强迫改变我们的节奏。
+
+有时，只需要有一个目标，制一个计划，然后持续按自己的节奏跑下去。
+
+找到自己的节奏，就是在每天略感挑战的状态下，形成不断加速前行，直到一个最终接近匀速的状态。匀速是我们能长期坚持的临界点，它能让我们跑得更久，跑得更远。
+
+至此，关于计划一节的内容就全部结束了，我在文中分享了一些我的长期计划。那你有怎样的计划呢？是在用怎样的节奏去执行并完成它呢？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/21 | 信息：过载与有效.md

@@ -0,0 +1,113 @@
+<audio id="audio" title="21 | 信息：过载与有效" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/41/d9/4146fd46f78fddddc4aa26a0e5ee43d9.mp3"></audio>
+
+至此，专栏已用6篇文章讲完了我关于“计划体系”这个主题的理解与思考 ，你是不是已经有点按捺不住想要赶快上路实践了？不急，接下来分享的主题是关于 “精进思维” 的，它会让你在按计划上路时，会有更好的跑步姿态，从而跑得更轻松、更有效率。
+
+在我刚开始学编程时，国内还没有互联网，去到书店，发现偌大的书店就只能找到两本关于程序语言的书。那时感觉，想学点新东西，信息真是相当匮乏。而现如今，国内互联网已经发展了二十余年，信息早已不再匮乏，甚至是到了让人感觉过载的时代。
+
+## 现状：信息过载
+
+信息时代，作为离信息距离最近的职业之一，程序员应该最能感受这个时代的信息洪流与知识迭代的速度有多快。
+
+据 IDC（国际数据公司）研究报告：现在每 48 小时所产生的数据量，相当于从人类文明开始到 2003 年累计的数据总量。而每年产生的信息数据量还在不断增长，但我们处理信息的能力，特别是大脑接收信息，并将其消化为知识的能力，这么多年来并没有多少提升。
+
+信息数据量的高速增长，也带来了处理信息技术的快速发展，所以新技术层出不穷，而且现有的技术也开始在其深度和广度领域不断地开疆拓土。
+
+这样的发展状况说明了一个现实：我们没办法掌握这一切。别说“一切”，其实更符合实际的情况是，我们仅仅掌握了已有信息和知识领域中非常微小的一部分。
+
+在信息大爆炸的时代，我们对信息越发敏锐，信息就越会主动吸引我们，让我们产生一种过载的感觉。
+
+## 状态：疲于奔命
+
+在面对这股信息与知识的洪流时，有时我们会不自觉地就进入到了 “疲于奔命”模式中。
+
+因为每天感觉有太多的信息要处理，太多的知识想学习。计划表排得满满的，似乎每天没能完成当天的计划，就会产生焦虑感，造成了日复一日的 “疲于奔命” 状态。
+
+曾经，我就处在过这样的状态中，逼得过于紧迫，再奔命也只能被这股洪流远远抛下。总是焦虑着完成更多，划掉 TODO List 上更多的事项，希望每日带着超额完成计划的充实与满足感入睡，最后这一切不过是一种疲于奔命带来的虚幻满足感。
+
+如今算是搞清楚了，这种紧绷的状态并不利于我们的学习和成长，这可以从大脑工作的生理机制得到侧面的佐证。
+
+2017 年 2 月，国外著名《科学》期刊发表的一个研究成果表明，我们的大脑中存在约 860 亿神经元，神经元之间会形成连接，连接的点有个专有名词：突触，而每个神经元会和别的神经元形成大约 1000 个突触；大脑不断接收并输入信息，突触就会变强大，体积也会变大。但突触不能无限加强、变大，要不然就会饱和，甚至 “烧毁”，这就是大脑生理层面的 “信息过载”。
+
+突触饱和了，再继续摄入和接收信息，此时我们就很难再学习到并留存下新的东西了，所以为了保持大脑学习新事物的能力，就必须要休息，而最好的休息则是睡眠。在睡眠中，突触会被修剪，神经连接会被削弱。美国威斯康星大学麦迪逊分校的两位研究者发现，睡觉的时候，大脑里的突触会缩小将近 20%。
+
+所以，在感觉大脑处于 “过载” 的疲倦中时，别“疲于奔命”，别硬撑，最好的办法就是去小憩片刻。
+
+记得大学时代，那时喜欢玩组装机 DIY。当时穷，买不起或舍不得买高配的 CPU，就买低配的 CPU，然后自己跳线超频，让 CPU 工作在过载状态中。然后弄个软件，再跑个分，一种妥妥的性价比超高的满足感。
+
+而大脑的工作模式就有点像 CPU，而人只要活着，大脑会一直工作，从不停止。
+
+即使我们感觉并没有使用大脑，我们的大脑也会处于一种 “默认模式网络” 状态。这可类比于电脑 CPU 的空闲（Idle）模式：电脑 CPU 倒是可以进入接近100%的空闲，但大脑不会，它最低也会保持 20% 左右的利用率，即便我们在睡眠中。
+
+在 “默认模式网络” 下，大脑还会有 20% 左右的利用率，它在做什么？实际上，这个状态下，大脑会去发掘过去的记忆，去畅想未来，在过去和未来之间建立连接。而在生理层面，大脑中会有新的神经连接形成，这样的新连接，就是我们创造力的来源。
+
+进入了疲于奔命状态，其实我们就在不断给大脑喂任务，且不停地切换大脑任务，让它永远处于繁忙甚至超频状态。这样每个任务的执行效率都会下降且效果也不佳，所以导致执行任务的时间反而延长了，这就给我们营造了一种“忙碌、充实而疲倦”的虚幻假象。
+
+人脑毕竟不是 CPU，它需要休息，持续的过载与奔命，并不能让我们学会更多，但却会减少我们创造新的可能。
+
+## 筛选：心智模型
+
+面对大量的信息和知识，我们该如何应对？这可以从两个角度来考虑：
+
+- 信息和知识本身的价值
+- 我需要怎样的信息和知识
+
+第一点，信息和知识的价值是一个主观的判断，有一个客观点的因子是获取门槛。如果一个信息或知识随处可得，大家都能接触到，甚至变得很热门，那么其价值可能就不大。吴军老师有一篇文章讲了个道理叫：“众利勿为，众争勿往”，这在对信息和知识价值的主观判断上也是通用的。
+
+第二点，就提出了一个关于如何筛选信息和知识的问题。心理学上有一个 “心智模型” ：
+
+> 
+“心智模型” 是用于解释个体对现实世界中某事所运作的内在认知历程，它在有限的领域知识和有限的信息处理能力上，产生合理的解释。
+
+
+每个人都有这样的 “心智模型”，用来处理信息，解释行为，做出决策。不过只有少部分人会更理性地认知到这个模型的存在，而且不断通过吸收相关信息和知识来完善这个模型；更多的众人依赖的是所谓的 “感觉” 和 “直觉”。但实际上 “感觉” 和 “直觉” 也是 “心智模型” 产生的一种快捷方式，只是他们没有理性地认知到这一点。
+
+理解了如上对 “心智模型” 的描述，是不是感觉它和如今人工智能领域的机器学习模型有点异曲同工之处？我们可以将这两者作以类比。它们都是接收信息和数据，得到模型，再对未知做出预测和判断。只不过人的 “心智模型” 却又比现在所有的人工智能模型都高级，高级到如今还无法用科学来清晰地描述与解释清楚。
+
+理解了以上两点，再把大量的信息和知识限定在我们所处的程序领域，就会得到一个合理的答案。
+
+当我刚进入程序员这行时，就一直存在有关 “超级程序员” 的传说，似乎 “超级程序员” 无所不能，各种语言信手拈来，所到之处，Bug 都要退避三舍。江湖总有他们的传闻，但谁也没见过。
+
+后来慢慢开始明白了，那些 “超级程序员” 也仅仅是在一两个专业知识领域深耕的年头比较久，做出了一些脍炙人口且享誉程序界的好作品，他们在其专业领域拥有精深的专业知识和技能，同时也有大量通用的一般知识储备，适用于跨专业范围的程序领域中。因此，在这个信息过载的洪流中，需要的就是在这股洪流中筛选信息并建立自己中流砥柱般的 “知识磐石”。
+
+“心智” 这两个字合在一起是一个意思，分开为 “心” 和 “智” 两个字又可以分别解释为：**“心” 是你对需要的选择，从心出发；“智” 是对价值的判断，智力的匹配**。
+
+## 应用：一击中的
+
+储备了信息，建立了知识，最终都是为了应用。
+
+囤积信息，学习知识，如果不能被应用在改变自己上，那还有什么意义？
+
+没有目的的学习是徒劳的，它仅仅是在我们的头脑中流过一遍，流过的痕迹很快又会被新的信息冲刷干净。不管我们拥有怎样的 “最强大脑”，在面对这股信息与知识洪流时，都几乎可忽略不计。
+
+大脑确实和计算机的 CPU 有很多类似之处，比如它也有一个缓存单元：长短期记忆，类似 CPU 的多级缓存；它还有一个计算单元，用于任务处理与决策。这让我联想到像 Java JVM 的实现中有一种实时编译技术叫 JIT（Just-In-Time），它会根据代码的调用量来决定是否进行编译执行。而对于知识学习，我们也可以采用类似的策略，到底哪些知识需要提前编译储备在大脑中，哪些仅在特定场景触发下才需要 “实时编译”去边学边用。
+
+毕竟未来充满了太多的未知和意外，我们没法提前储备太多。
+
+而前文也提到大脑不适合长期持续地满负荷运转，这与我自己的真实感受是一致的。我感觉如果一次性让大脑满负荷（100%）运转达到 4 小时左右，就会感到很疲劳。而做不同的事情对大脑的利用率是不同的，下图结合自身感受画出了一个我自己的大脑消耗率示意图：
+
+<img src="https://static001.geekbang.org/resource/image/a5/bf/a5c64ac7e7b9392993a40147ef5550bf.png" alt="" />
+
+所以，这里就要有选择和取舍。万维钢的一篇文章中有句话是这么说的：
+
+> 
+注意力是一种有限的资源，你要是不擅长不集中注意力，你就不擅长集中注意力。
+
+
+你得挑选那些真正值得做和学的东西去让大脑满负荷运转，但凡投入决心去做的事情，就需要百分百投入。这就是专注于少而精的东西，深入了解这些东西，进入到更深的层次上。深可以无止境，那到底多深才合适？我的答案是：**让你的内心对取得的效果感受到满意的深度层次上**。它的反面是：但凡心存疑虑，不是那么确定要全力投入的事情，干脆就不做了。
+
+以前写一篇文章，我会给一个合理的时限要求。比如高考作文 800 字，要在 50 ～ 60 分钟内完成。而我每篇文章一般在 2000 ～ 3000 字，我给的时限也就在 3 小时左右。因为安排了这 3 小时，其他时间按计划还要干别的，但这个安排一直让我很焦虑，因为经常性写超时。
+
+现在明白了，写作本来是一件创造性的活动，一件 “脑耗率” 100% 的活动，需要百分百的投入，最终效果远重于时限。即便我在 2 小时写完了，但效果能达到让我内心取得满意的深度层次么？（题外话，每篇专栏文章的写作和反复修改，平均要 6 ～ 10 小时。）
+
+做得多和做得好的感觉很不一样。就像拳击，多，好似不停挥拳，很快就精疲力竭；好，则是看准目标，抓住机会全力出击，一击中的。
+
+最后，总结下在信息爆炸的时代，我们该如何有效处理、吸收和消化信息：
+
+- 信息过载是现实；
+- 疲于奔命是陷阱；
+- 心智模型是方法；
+- 一击中的是策略。
+
+那关于信息处理的有效方法和模型，你目前采用的是怎样的好办法呢？欢迎留言分享，我们相互学习下。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/22 | 领域：知识与体系.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="22 | 领域：知识与体系" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e6/b5/e623dc66304b424a7f8b4fdedb98deb5.mp3"></audio>
+
+今年年初，我学习了梁宁的《产品思维》课，其中有一篇叫《点线面体的战略选择》，我觉得特别有感触。虽然是讲产品，但假如把个人的成长当成产品演进一样来发展，会有一种异曲同工、殊途同归之感。
+
+在我工作的经历中就曾碰到过这么一个人，他一开始做了几年开发，从前端到后端，后来又转做测试，接触的“点”倒是不少，但却没能连接起来形成自己的体系，那他个人最大的价值就局限在最后所在的“点”上了。
+
+其实个人的成长有很多方面，但对于程序员的成长最重要的就是知识体系的构建，这其实就是一个 “点线面体” 的演进过程。
+
+下面我会结合自己的成长路线来梳理下这个体系的建立过程。
+
+## 点
+
+进入任何一个知识领域，都是从一个点开始的。
+
+如下图，是我从大学进入软件开发领域所接触的一系列的点，我将其从左到右按时间顺序排列。红色的部分是目前还属于我 “掌握” 与 “了解” 的领域，其他灰色的部分则是要么被时代淘汰了，要么已经被我放弃了维持与更新。
+
+<img src="https://static001.geekbang.org/resource/image/63/ff/638714dc6079ed98aca692b6e9f9aaff.png" alt="" />
+
+我入行的年代，流行的是 C/S 架构的软件开发模型。当时客户端开发三剑客是 PB（PowerBuilder）、VB（Visual Basic）和 Delphi，而我只是顺势选了其中的一两个点，然后开启了程序员生涯。
+
+没过两年B/S 架构开始流行，并逐步取代了 C/S 架构。于我，只是因为研究生阶段学校开了一门面向对象语言课，老师用 Java 做教学语言，所以我后来就又顺势成了一名 Java 程序员。而又只是因为 Java 的生命力特别旺盛，所以也就延续至今。
+
+早些年，前后端还没太分离时，因为项目需要，所以我又去涉猎了一些前端 JS 开发；之后移动互联网崛起，又去学习了些移动开发的东西；再之后就是 ABC 的时代（其中 A 是 AI ，人工智能；B 是 Big Data，大数据；C 是 Cloud，云计算），就又被潮流裹挟去追逐新的技术浪潮。
+
+如今回过头再看，每一个技术点，似乎都是自己选择的，但又感觉只是一种被趋势推动的一次次无意“捡起”。有些点之间有先后的承接关系，而更多点都慢慢变成了孤点，从这片技术的星空中暗淡了下去。
+
+在你入行后，我想你可能也会因为时代、公司或项目的原因，有很大的随机性去接触很多不同的技术点。但如果你总是这样被客观的原因驱动去随机点亮不同的 “点”，那么你终究会感到有点疲于奔命，永远追不上技术的浪潮。
+
+## 线
+
+当形成的点足够多了后，一部分点开始形成线，而另一些点则在技术趋势的演进中被自然淘汰或自己主动战略放弃。
+
+那你到底该如何把这些零散的点串成线，形成自己的体系与方向呢？如下图，是我的一个成长 “T 线图”，它串联了如今我沉淀下来的和一些新发展的 “点”。
+
+<img src="https://static001.geekbang.org/resource/image/f5/7b/f5d13b580da5d58e38423885b2020e7b.png" alt="" />
+
+我从成为了一名 Java 程序员开始，在这条 “T线” 上，先向下走，专注于解决业务需求碰到的技术问题。先自然地要向下至少走一层，接触 Java 的运行平台 JVM。而又因为早期做了几年电信项目，要和很多网络设备（包括各类网元和交换机等）通信，接触网络协议编程；后来又做了即时消息（IM）领域的工作，网络这一块就又继续增强了。而网络编程依赖于操作系统提供的 I/O 模型和 API，自然绕不过 OS 这一块。
+
+在 Java 领域走了多年以后，以前涉猎的技术点就逐步暗淡了。而再从程序员到架构师，就开始往上走，进入更纯粹的 “架构与设计” 领域，在更宽的范围和更高的维度评估技术方案，做出技术决策与权衡，设定技术演进路线。
+
+但是，再好的技术方案，再完美的架构，如果没有承载更有意义的业务与产品形态，它们的价值和作用就体现不了。所以不可避免，再往上走时就会去了解并评估 “业务与产品”，关注目标的价值、路径的有效性与合理性。
+
+在整个纵向的技术线上，最终汇总到顶点，会形成一种新的能力，也就是我对这条纵向线的 “掌控力”。到了这个 “点” 后，在这里可以横向发展，如图中，也就有了新的能力域：领导力和组织力。
+
+一个个点，构成了基本的价值点，这些点串起来，就形成了更大的价值输出链条。在这条路上，你也会有一条属于自己的 “T线”，当这条线成型后，你的价值也将变得更大。
+
+## 面
+
+线的交织，将形成面。
+
+当我试着把我最近六年多在电商客服和即时通讯领域的工作画出来后，它就织就了下面（如图所示）的这个“面”。
+
+<img src="https://static001.geekbang.org/resource/image/5c/ce/5cfaffafd4b327b9b9dbf48725cd2dce.png" alt="" />
+
+我从最早的聚焦于某个业务点和技术栈，逐步延伸扩展到整个面。因为 IM 这个产品本身具备很深的技术栈，而且也有足够多元化的应用场景，这样整个面就可以铺得特别宽广。这也是为什么我已经在这个面上耕耘了六年多之久。
+
+但事实上，我并不掌握这个面上的每个点，整个团队才会分布工作在整个面上，每个个体贡献者也只会具体工作在这个面上的某个或某些点。但我们需要去认清整个面的价值体系，这样才能更好地选择和切入工作的点，创造更大的价值。
+
+而有时候，我也了解到有些程序员的一些说法是这样的：在相对传统的行业，做偏业务的开发，技术栈相对固定且老化，难度和深度都不高，看不到发展方向，期望找到突破口。若你也出现这样的情况，那就说明你从事的业务开发，其单个技术点的价值上限较低，而选择更新、更流行的技术，你就是期望提升单个技术点的价值，但单个技术点的价值是相对有限的。
+
+反过来，如果很难跳脱出自身环境的局限，那么也可以不局限于技术，去考虑这些传统的业务价值，从技术到业务，再上升到用户的接入触达，考虑产品的场景、形态和人群是如何去为这些用户提供的服务、产生的价值。
+
+当你对整个业务面上的价值点掌握的更多，能抓住和把握核心的价值链条，去为更广、更大的价值负责，那么你就能克服自己的成长发展困境，找到了另外一条出路了。
+
+同时，你也为自己织就了一张更大的领域之网。在整个面形成了一个领域，在这个面上你所能掌控的每条线就是你的体系。在这条线的 “点” 上，你解决具体问题，是做解答题；但在整个面上你选择 “线”，是做选择题。
+
+## 体
+
+体是经济体或其中的单元。
+
+你的 “面” 附着在什么 “体” 上决定了它的价值上限。如果 “体” 在高速增长并形成趋势，你就可能获得更快的发展。
+
+从电力时代到信息时代再到智能时代，互联网、电商、移动互联网，这些都是 “体” 的变化。今天互联网行业的软件工程师，他们面临的挑战和难度不见得比传统的机械或电力工程师更大，只不过他们所从事的 “点” 所属的 “面”，附着于一个快速崛起的 “体” 上，获得了更大的加速度。
+
+“体” 的崛起，是时代的机遇。
+
+总结来说，就是：**在领域知识体系中，“点” 是利器，“线” 是路径，“面” 是地图；而就我们个体而言，“点” 是孤立知识点的学习掌握，而 “线” 是对这些点的连接，“面” 则构成了完整的知识体系网**。
+
+以上就是我建立知识体系并形成自己领域的思考。而在每个不同的阶段，你都可以先做到心中有图，再来画“线”，然后再在每个“点”上去努力。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/23 | 转化：能力与输出.md

@@ -0,0 +1,80 @@
+<audio id="audio" title="23 | 转化：能力与输出" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/17/ff/1785e440a1b85e16b14a9bf6e84417ff.mp3"></audio>
+
+个人，建立好了知识体系，各方面都明了了，但有时做起事来却还会感觉发挥不出来；团队，牛人众多，但感觉做出的事情效果却很一般。
+
+这类问题的症结，多就出在从体系积累到输出转化的环节，它涉及两个实体的转化问题：
+
+- 个体
+- 团队
+
+## 个体
+
+关于个体的能力转化，我想先讲一个发生在我自己身上的故事，通过类比想必你就能很快明白这个道理。
+
+前几年有几部华语电影，比如《叶问》《一代宗师》等，都是和一个人、一套功夫有关；而从前年到去年的一段时间，在我身上正好就发生了这么一件计划外的事情，我去接触学习了一下咏春。练拳这个事，一开始就不在我计划内，甚至也不算是兴趣内的事，但它就这么发生了，然后还意外地让我有了一些收获。
+
+在刚开始时，我的确对咏春有很多疑惑，但好在并不排斥。一开始老师并没有教什么招式套路，而是从架构开始。既然是功夫，当然这个 “架构” 就是指身体架构了。为什么不讲招式，而是讲架构？这也是我最初的疑惑。随后，老师用一个生动的示例说明了缘由。
+
+老师先拿上一个挡在胸前上的沙包，让我们挥拳全力击打，他来挡住。然后我们就全力挥拳了，阵势倒是挺大，打在沙包上也砰砰脆响，但老师纹丝不动。反过来，该我拿沙包挡在胸前了，老师出拳，拳头接触沙包后发出沉闷的响声，我用尽全身力气也站不住，连连后退，直到碰到墙边才止住退势，并且胸口还隐隐作痛。
+
+好吧，以上描写，有点武侠小说的感觉了，但实际并无夸张。以后每次老师演示沙包架构教学，各位同学都连连谦让起来。这里面的原理后来听老师讲解才算明了：我们平常出拳基本都是用的臂力，力量不会太大；而老师出拳用的是身体之力，借助身体架构发全身之力。
+
+力，从脚底触地而起，由腿上腰，扭腰推至背肩，再甩肩推臂，经腕至拳，最后触及被击打之物。在这个过程中，全身都会随这股力量而动，借助全身体重的推动力，会大幅度地放大这股力量。这股力量甚至超过了他的体重，试想一个成年人那么重的力量推向你，你如何能接得住？
+
+后来，我了解到，经过职业训练的拳击手，正常挥出重拳的力量可以是体重的好几倍。而我们普通人挥拳只用手臂发力，只有体重的几分之一。因为我们没有经过身体架构的训练，所以身体架构各自配合脱节，力量便耗散在了过程之中，而发不出全身之力。
+
+身体是一个系统，身体架构是一个体系，这个体系的输出能力便是出拳的力量。
+
+要放大这个力量，就需要不断反复地去协调应用这个体系，并不断得到反馈修正，最后形成肌肉记忆的习惯，就像老师一挥拳就能爆发全身之力一样。而我练习了几个月，估计也没到半身之力，这个过程和所有技能的刻意练习过程一样，快不了。
+
+同理，我们从学会一个知识，到能够熟练应用其去输出能力，大概会经历如下过程：
+
+<img src="https://static001.geekbang.org/resource/image/f7/d6/f7dc81387177314594fc40618eb94bd6.png" alt="" />
+
+所以，对于个体而言，刚建立起一个初步的知识体系，到能真正充分发挥出这个体系的力量，才仅仅是刚开始。
+
+## 团队
+
+如果说个体的能力输出像出拳，那么团队的输出就像战争了。
+
+在近年来大热的美剧《权力的游戏》中，一开始有两个家族，北方的狼家族和南方的狮家族，他们爆发了一场战争。战争之初，狼家族在战场上连战连胜，甚至一度俘虏了狮家族的重要人物，但后来突然急转直下，竟被人在战场之外全灭。
+
+而战争其实是发生在两个体系（这里的体系是国家、家族和部落）之间的能力较量。每一个战场、每一场战役仅仅是体系中一些“点”的较量，虽然北境的狼家族一开始在战场上连连获胜，但他们这个内部体系的薄弱环节和问题远多于狮家族这个体系，因而在被人抓住关键节点后，一下就瓦解了。
+
+团队这个体系比较复杂，即使个体的点很强，但仅仅是点的强化，也有可能不断赢了战役，但最后却输了整个战争。
+
+去年也有一本大热的翻译书籍《原则》，该书的作者是雷·达里奥，他是世界最大对冲基金——桥水联合基金——的创始人。这本书描述了他的一个思想和实践，就是把公司当作 “机器” （原文是 Machine）来管理运转。
+
+所以，在他看来管理者就像是工程师，而工程师维护机器运转的工作状态我们都能想象到，或通过机器的运行仪表盘监控机器的运转状态，或通过指标优化机器的运行效率。而达里奥的 “机器” 就是他建立的管理公司的体系。
+
+曾经，我们团队有个高级测试工程师，在他晋升测试架构师级别的述职时，提到他的一项工作就是搭建测试体系来帮助团队改善测试工作的效率和效果。在进行阐述时，他完整地描述了这个体系 “机器” 的各个零部件组成，他制造的很多工具和系统，却缺失了关于体系的一些最重要的方面：这个体系是如何运转的？它提供了哪些系统和仪表盘监控指标来支撑和反映其运转状态？为什么这个体系能在团队里运转？
+
+以上三个问题，就反映了 “机器” 体系的三个核心点：
+
+- 流程规则
+- 工具系统
+- 规范共识
+
+没有流程规则，“机器” 体系就不知该如何运转；缺乏工具系统支撑，就没法监视和控制这个体系的运转效率与效果；而如果未能在团队形成共识并达成规范，“机器” 体系就不可能“和谐”运转起来。所以，流程规则，建立其运行轨道；工具系统，支撑其高效运行；规范共识，形成了协调合奏。
+
+团队能力输出就是这样一个 “机器” 体系运行的过程。那么团队的强弱就由两方面决定，一是团队中所有个体形成的体系力量之和，二是由流程规则、工具系统和规范共识共同决定的转化效率。
+
+## 转化
+
+从个体到团队，都是通过搭建体系来积蓄力量，再通过体系的运转来输出能力。
+
+这里的共同思维方式是：体系化、工具化。这是一种标准的工程师思维模式，巧妙的是它依然可以用在非工程的领域。体系，从工程维度看就像生产流水线，而体系的运转就是开动了生产流水线。搭建并调校出一条高转化输出能力的体系生产线，是真正具有核心竞争力和护城河的事情。
+
+前阵子，看到新闻说台积电计划投资 250 亿美元研发建设 5 纳米制造生产线，这个投资额很好地说明了搭建一个真正具有护城河级别竞争力的生产体系所需要的成本。而台积电正是靠着这样具有核心竞争力的生产体系，成为全球半导体生产制造的霸主，制造了全球 60% 的芯片。
+
+所以我们也要像台积电学习，好好打磨出适合自己的体系，使其真正成为自己的核心竞争力。
+
+要想产生更大的成果，取得更大的成功，我们需要找到放大个体或团队能力的杠杆支点。曾经，也许我们也做出过好的产品，产生过好的结果，可能是我们能力不错，但也有可能只是运气不错。也就是说，好产品或好结果并不能成为支点，不断产出好结果或好产品的 “体系流水线” 才是。
+
+我们需要做的就是不断打磨这条流水线，提升转化输出好产品或好结果的效率与良品率。
+
+个体和团队的强弱，一方面取决于我们在体系中积蓄的力量的总量，另一方面在于体系运作的转化输出率。体系决定了力量的总量，而转化决定了拳拳到肉的痛感。
+
+每个人做事都存在转化输出率，读完本文，你对自己或所在团队的转化输出率的提升是否有了大概的方向？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/24 | 并行：工作与学习.md

@@ -0,0 +1,129 @@
+<audio id="audio" title="24 | 并行：工作与学习" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b1/1d/b12ce1f647e26df7c3a1f3b82beed81d.mp3"></audio>
+
+在工作中，你应该碰到过一些这样的情况，有同事工作的时间不短，经常加班加点，工作也很勤勉，但每每晋升时却碰壁了。你可能还会为其打抱不平过。难道这真的只是不公平或者运气不佳吗？
+
+其实这种情况，隐藏在背后更深层次的原因是：工作陷入了循环与重复，从此停止了成长。
+
+那么，你该如何在工作的同时，保持学习，并持续成长与进阶呢？我想，可以先从分析“程序员的工作本质是什么”开始着手。
+
+## 工作
+
+程序员的主要工作是：编程，产出代码，完成需求，交付程序系统。
+
+程序员按其工作技能和经验，大体又分为三个阶段：初级、中级和高级。这三个级别的程序员的主要工作都是编程与产出代码，产出代码的数量也许相差不大，但产出的代码属性就可能有明显差别。
+
+什么是代码属性？它包括资产与负债两类。由大量初级程序员产出的代码并以此构建的软件系统，如果最终能完成交付，那么很可能资产和负债性基本持平。这是很多早期创业公司产出代码的属性特征，因为创业公司早期缺乏资金和足够的知名度，难以吸引到又多又好的中、高级程序员加入。
+
+这样的代码构建的系统多属于勉强满足业务需要，虽看不出明显的 Bug，但一遇到特殊情况就容易宕机。整个系统虽然勉强能支撑公司运营，但其中欠下了大量的技术债；先活下来，未来再来慢慢还。
+
+若是完成了一个债务比资产还大的系统，会是个什么样的情况呢？那这就是一个还存在明显 Bug 的系统，是基本无法完成交付和上线的。
+
+因此，现在互联网行业创业团队的主流做法，都是先完成一个资产和负债刚好过平衡点的系统，发布上线，接受反馈，再快速迭代，最后在迭代中不断地提升其资产性，降低其负债性。
+
+这样的方式在行业里有一个实践的榜样：Facebook。它还有一句著名的标语：
+
+> 
+Done is better than perfect.
+比完美更重要的是先完成。
+
+
+但如果你仅停留于此，那工作就永远在完成，并不会走向完美。而且，工作的内容还会不断地重复，让你从此陷入成长的停滞区。
+
+从初、中级走向高级程序员，就不仅仅是交付代码，完成工作，还要有后续的更高要求。如：达成品质、优化效率。而在不断晋级的路上，跨越的门槛就在于此，很多人比较容易被卡在不断地在完成工作，但却没有去反思、沉淀、迭代并改进，导致一直停留在了不断重复的怪圈之中。
+
+程序员，工作以产出代码为主，从初级到高级，代码的负债属性逐步降低，资产属性不断提升，最终成为高品质的个人贡献者。而从完成到追求品质和完美的路上，不仅仅是靠工作实践的经验积累，还需要有意识地持续学习。
+
+## 学习
+
+持续学习，是让你突破不断循环怪圈的不二法门。
+
+在工作中，我一直有观察到一个现象，很多人因为离开学校后，工作任务多，压力大，从此就停止了系统地学习。在《浪潮之巅》一书中，吴军写道：
+
+> 
+<p>国内: 小时候努力，到大学后就不努力了。 <br />
+ <br />
+国外: 到大学后才开始努力，很快就超过国内学生。</p>
+
+
+吴军这对比国内外的教育，也反映了我们教育中作为学生的一种心态，觉得毕业了，离开学校后就不需要多努力学习了。但目前程序员这个职业所面临的技术发展和更迭远超其他行业，你即便只是为了能够保质保量地完成任务，也需要保持持续学习的节奏。
+
+现如今是个信息爆炸与知识过载时代，所以学习必须要有选择性。
+
+我读大学那阵儿，学程序期间喜欢电脑，就爱帮同学人肉组装（DIY）个机什么的，而且还反复折腾安装操作系统。那时的 Windows 系统的特点之一就是越用越慢，一年半载就需要重装一次，所以可没少反复和折腾，分散了不少我的时间和精力，原本以为能主动学到新东西，但结果发现其实都是被动的。所以，学习还是要聚焦和主动选择，毕竟你的精力和时间都是有限的。
+
+而有选择性的学习就需要找出真正与你近期规划有关的学习路径。
+
+假如你工作入职后公司使用 Java 为主要开发语言，而大学里你一直学习使用 C 或 C++ 编程练习，这里再假设你对计算机相关的基础性学科和知识掌握良好，比如：操作系统、数据库、网络、组成原理、编译原理、算法基础、数据结构等等。那么为了更好地完成工作任务，就需要你先主动学习 Java 编程语言、开发框架等编程技术相关的知识。
+
+而对于学习语言本身我觉得最高效的方法就是看一本该领域的经典入门书。比如，对于 Java 就是《Java 核心技术》或《Java 编程思想》，这是我称之为**第一维度的书，聚焦于一个技术领域并讲得透彻清晰**。
+
+在有了该语言的一些实际编程和工程经验后，就可以看一些该领域**第二维度的书**，比如：《Effective Java》《UNIX 编程艺术》等，这些是聚焦于特定领域经验总结型的书，这类书最有价值的地方是其**聚焦于领域的思想和思路**。
+
+如果过早地看这类书反而没什么帮助，甚至还会可能造成误解与困扰。例如，我看豆瓣上关于《UNIX 编程艺术》的书评，有这么一条：“很多例子和概念已经成了古董，当历史书看，无所获。”这显然就是过早接触了第二维度的书，却预期得到第一维度的收获，自然无所获了。
+
+而另外一些技能，像 Java 开发工作需要大量使用的开源框架又该如何学习？张铁蕾曾写过一篇《技术的正宗与野路子》，其中介绍了如何用真正 “正宗” 的方式去学习并快速掌握这些层出不穷的开源新框架和技术。
+
+这里就借用原文里的一张图（重新按统一风格绘制了下），每一项开源框架或技术相关的学习资料可以组织成下面这张金字塔形的结构图。
+
+<img src="https://static001.geekbang.org/resource/image/7c/f6/7cb9cd11da8af78da57dc4b22cabd1f6.png" alt="" />
+
+Tutorial（指南） 和 API Reference（应用编程接口参考） 层次的信息资料能帮助你快速上手开发，而 Spec（技术规范）和 Code（源代码）会帮助你深刻地理解这门技术。而其他相关的技术书籍和文章其实是作为一种补充阅读，好的技术书籍和文章应该有官方资料中未涵盖的特定经验或实践才算值得一读。
+
+张铁蕾在文中如是说：
+
+> 
+每当我们接触一项新技术的时候，都要把手头的资料按照类似这样的一个金字塔结构进行分类。如果我们阅读了一些技术博客和技术书籍，那么也要清楚地知道它们涉及到的是金字塔中的哪些部分。
+
+
+我深以为然，关于技术学习我们不能简单地蜻蜓点水、复制粘贴、拿来主义，应是去建立你的知识 “金字塔”，形成体系结构，而每次的学习实践都是在不断完善你的 “金字塔”。至于更多技术性学习的细节，若你感兴趣的话，也可以去看看那篇文章。
+
+## 路径
+
+保持学习，不断成长，工作也许还在重复，但成长却在迭代上升，然后才会有机会面临更多可选择的路径。
+
+程序员在攀登职场阶梯的道路上，走过了高级，后面还会有好些分叉路线。比如，转到脱离技术的纯管理岗或者技术管理岗。技术主管或架构师某种意义上都属于技术管理岗，不懂技术是做不了这两个角色的；或者继续沿着深度领域走，成为细分领域专家。
+
+这后面哪条路适合你呢？你是随大流，还是自己认真思考和决定？这是做选择题。如果一生要工作三十多年，前十年你多在做解答题，解决一个又一个问题。那么在大约走过这三分之一后，你就会开始做越来越多的选择题。为什么呢？因为一开始可能没有太多可供你选择的机会。而后续做好选择题，则需要大量学习，还需要不断地试错。
+
+面对怎么选路的问题，我近些年学习的收获是这样的：**选择走最适合实现个人价值的路**。这就是我的基础选择价值观。程序员的个人价值该怎么实现？该如何最大化？程序员作为个人贡献者，到了一定的熟练阶段，产出基本就稳定了，而技能的成长却呈现对数曲线的增长特征。
+
+任何一个你所尝试提升的事情都有一个增长曲线，这个曲线有两种形态：
+
+- 对数增长形态：这种类型在初期增长很快，但随后进展就越发困难；
+- 指数增长形态：这种类型在初期增长很慢，但存在积累的复利效应。
+
+增长要么是对数形态，要么是指数形态，很少有线性的。
+
+对数增长也意味着更容易退步，因为起步阶段是如此陡峭（见对数曲线示例图）。比如，学习一门新的技能，不持续去应用，很快就忘了，退回原点。那你应该如何应对这种“窘况”呢？我建议你在起初的高增长阶段，学习和工作的关注点需放在养成长期习惯上，因为虽然开始增长很快，但需要小心一旦停止努力它可能会向下滑落，所以一定要慎之又慎，坚持形成自己的习惯和节奏。
+
+<img src="https://static001.geekbang.org/resource/image/9f/07/9f7085a8a6d45f0ef4c30822fd58c907.png" alt="" />
+
+而指数增长则意味着存在一个拐点的 “突变” 时刻。很多人期望线性增长，但实际却是按指数增长的，这让许多人在拐点发生前就放弃了。比如，写作，在呈指数增长的领域内，到处都是半途而废者。所以，做本质是指数增长曲线的事情时，柔韧且持久的思维模式是关键。
+
+<img src="https://static001.geekbang.org/resource/image/e1/d0/e1cecc17151781c91decf2b044c9e0d0.png" alt="" />
+
+工作多年后，技能的增长就又进入了对数的平缓区域，通常其回报呈现递减趋势。也就是说你在其上花的功夫越来越多，但你感到越来越难产生洞察以获得新的收益。其难处在于找到新的突破点，重新回到曲线陡峭上升的部分。
+
+这就是所谓成长的瓶颈，你要学会应用指数增长的方法，找到价值贡献的放大器。作为程序员，你有可能很幸运地编写服务于数千万或数亿人的软件服务，这是产品自带的价值放大器。这样同是写一份代码，你的价值就是要比别人大很多。而转管理者或架构师，这些角色无非都是自带杠杆因子的，所以也有价值放大的作用。但个人能否适应得了这样的角色转换，又是另一回事了。
+
+拉姆·查兰有本书叫《领导梯队》，书里把人才潜能分成三种：**熟练潜能、成长潜能和转型潜能**。原书对这三点做了详细的特征描述，我简单提炼下主要特点：
+
+- 熟练潜能：关注当前专业领域且十分熟练，但没有显示出在开发新能力上的努力，竭力维持现有技能。
+- 成长潜能：按需开发新能力，显示出高于当前层级要求的其他技能，如：专业、管理、领导。
+- 转型潜能：持续有规律地开发新能力，追求跨层级的挑战和机会，展现雄心壮志。
+
+人力资源管理中的高潜人才盘点，基本就来自这套模型，主要就是识别出这三类潜能人才。“熟练潜能” 已是我们这行对学习的最低要求，在程序员这个技术日新月异的行业里，维持现有技能确实已经让不少人感觉很竭力了。
+
+那你拥有怎样的潜能呢？它不一定都是天赋，可能也是选择。
+
+成长这条路从来都不是笔直的，你的“奔跑速度”也不会一直是匀速的。在每一个拐弯处，都应减速，思考，学习，然后再加速，进步。
+
+到此我总结下今天的分享：
+
+程序员的工作形式是编程产出代码，本质是完成需求，交付系统；但在工作中容易陷入不断完成的循环怪圈，要打破它，就需要你持续学习并有意识地关注交付代码的品质和属性，一方面提升了交付质量，另一方面也获得了个人成长。
+
+而学习的路在时间上是永远持续的，在空间上也是有路径的；有效的学习需要你关注学习曲线的变化，遵循有体系的技术学习框架，匹配适合当前阶段的学习资源。
+
+最后，关于工作和学习，有人总感觉有些冲突，忙起来就没时间学了。那你是怎么看待这件事呢？欢迎留言分享你的观点，我们一起探讨。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/25 | 时间：塑造基石习惯（上）——感知与测量.md

@@ -0,0 +1,73 @@
+<audio id="audio" title="25 | 时间：塑造基石习惯（上）——感知与测量" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a6/b3/a69ba9cdbcdc39645df204a6b3c09eb3.mp3"></audio>
+
+至此，咱们专栏已用4篇文章分享了我关于“精进思维”这个主题的理解与思考，期待以后你能得心应手并游刃有余地持续进阶。
+
+接下来，咱们专栏又会进入一个新的主题：**习惯**。习惯的重要性想必你也很了然于胸了，习惯的养成，是让成长无意识自然发生的关键。然而习惯对于成长的具体作用是怎样的呢？
+
+想必你也知道，养成好的习惯能帮助我们更快地成长，而在所有的好习惯中，关于时间的习惯是其中的基础，我称之为 “基石” 习惯。如果你的时间习惯不好，那你做其他事情的效率往往也就不高。
+
+那么，该如何塑造好时间这块 “基石”呢？我觉得在有效地应用之前，先需要精确地感知与测量。
+
+## 感知时间
+
+有时，我们觉得时间过得很慢，慢如从周一到周五；有时，又会觉得时间飞逝，快到十年间一恍惚就过去了。
+
+当我站在十年后的这端看十年前的那一端，会惊讶地感叹：啊，时间过得真快！再把时间往前推一点，十多年前，将从学校毕业，走上社会工作岗位，我当时有想过十年后会如何吗？有过怎样的畅想呢？我依稀记得应该是畅想过的，才刚毕业怎么可能不畅想一下即将走出校园，怀揣理想，人生豪迈，激情万丈的未来之路呢？
+
+对，我确实畅想过，可遗憾的是我只能模糊记得有过畅想这回事，而到底畅想过什么具体的内容，却大多记不太清了。唯一还有印象的是，毕业前夕的一个凌晨，月挂高空，星光惆怅，一屋子的室友在校园的花台前，喝着啤酒，畅谈明日的分离，未来将会如何如何，十年后我们还会相约在此见面，再分享一下彼此的人生。
+
+十年过后，当时也有同学记起这个约定，就号召大家再回校园共聚一场。而我却未能赴约，当时正好孩子出生尚在医院，现实的粘连总会拖住理想的浪漫。江湖侠客分别时总喜欢说句：十年之后我们再会于此，就此别过，后会有期。可实际，很多别过都是后会无期的，我们从来不是侠客只是凡人，谁又能轻易承诺得了十年之约。
+
+我还能记起这个看似简单的十年之约，却已然记不起当初对未来十年之路作过何样的畅想与规划。苦苦回忆之后，只觉得当初作为一名软件工程专业的毕业生是清晰地知道最近的将来是会成为一名程序员的，而对于程序员的未来我当初应该想的就是架构师吧。
+
+也许当时我觉得架构师就是一个程序员的顶点，是我能看得到的顶点。而实际情况是这个架构师的称呼也只是当时我从几本翻译的国外技术书籍中的人物介绍中看来的，到我实际工作后却发现前三、四年所在的两个公司都没有架构师这个职位。理论上来说当时我应该感到迷茫，实际却没有，可能因为觉着还太遥远，所以我就不管不顾地走在当下的路上，活在当下。
+
+当你对生活有某种期待与畅想，却又觉得明天实现不了，三个月也实现不了，一年后大概还是实现不了，然后可能你就会不由自主地想大概十年后也许就能实现了。你会以为十年很长，把现在的期望与畅想交托给十年后的未来。
+
+十年也许是一个足够长的时间，长到对个人来说很难去做一个十年的计划，所以我们就这样经常把很多很多的期待放在了十年后，把期待交给了时间。
+
+所以，当我再次回顾彼时彼刻，虽然想不起太具体的当初对十年后期待的内容，但我依然能感受到当初对十年后充满期待的感觉到今天并没有实现。虽然今天我已经是一名架构师了，但这只是我昨日期待中的很小一部分，是我还能记得的具体的一部分。
+
+更大的一部分只剩下一个感觉，我甚至怀疑当初从未仔细地把这部分感觉具象化，所以导致我现在的记忆中只剩下一种感觉。这里再打个比方，若十年时间是一个人，我当初把一个期待的感觉托付给了她，十年后再见时，她依然还了我一个一样的感觉；如今我知道这怪不了她，她并非无所不能，只是我未曾很好地了解她。
+
+“时间如流水，从我们的指缝间悄悄流走；如轻烟，被微风吹散了；如薄雾，被初阳蒸融了”，这些中学语文课本上的关于时间的比喻，突然就从我的脑海中冒出来。时光无形，如流水、轻烟、薄雾，要想精确地感知它可不容易。
+
+从 30 到 40 岁的这十年我已经行程大半，突然就生出一种这十年似乎走得更快了的感觉，怎么一下就过了大半了，而 20 到 30 岁却明明觉得过了好久呀。20 岁之前我们才刚刚经历对中学的告别，此后很多小伙伴可能就将永远只活在我们的记忆中了。但没过几年我们又将经历另一次告别，对校园的告别。曾经的青春呼啸，江河奔流，未曾来得及说一声道别已志在四方了。
+
+一段又一段的校园恋情开始又结束，也许每一段我们都曾觉得刻骨铭心像延续了一生一般，实际不过匆匆几年。后来终于在职场上找到了最后的归属，走入婚姻的殿堂，安置幸福的蜗居，生下一个让你头疼的要命却又羡慕的要死的小家伙，人生的大事就这样一件接一件地完成了。然后一回首发现站在了 30 岁的门槛边，感慨原来这十年我做了这么多事啊，生出一种 “而立” 的感觉。
+
+迈过三十之后，七年瞬息而过，一回首却想不起什么激动人心的大事了呢？曾经在知乎上看到个问题：“为何人随着年龄的增大觉得时间过得越来越快？”这个问题的几句答案，解答了我多年以来的困惑：
+
+> 
+**有共性的回忆趋向粘合在一起，标志性的回忆倾向于鹤立鸡群**。心理学家认为：我们对时间的感知同时和我们的经历有关。如果一件事对于我们来说是 “激动人心” 的，这样的记忆在我们脑海中感觉到的时间会更长。
+
+
+确实，从 20 到 30 岁经历的每一件人生大事之于我们都是激动人心且独一无二的，自然在我们的记忆中就 “鹤立鸡群” 了，而三十之后就好像缺少了一些这样的大事。生命的精彩程度在慢慢下降，自然没有那么多激动人心的记忆了。
+
+对时间的感觉就这样，粘连在一起，如轻烟般飘走了。
+
+## 测量时间
+
+正因为我们对时间的感知非常模糊而不精确，若想更有效率地用好时间，就需要更精确地测量它。
+
+有一本书叫《奇特的一生》，主要是关于一位苏联科学家柳比歇夫的故事，他通过自创的 “时间统计法” 在一生内取得了惊人的成就。而我在遇到这本书之前，已经在使用一种类似的方法：**我会记下一年来经历的所有有意义的事件（除去每日的例行工作），我称之为 “时间日志”**。
+
+我按每周来记录，每周里面有每天的事件记录和所花费的时间。这个 “时间日志” 的习惯其实源自我小时候养成的记账习惯，那时钱不多就想知道钱花在哪里去了。现在其实都不怎么记金钱的账了，而是记时间的账。方法类似，把记金额明细改成了记时间明细，借此以追踪我的时间都花在哪里去了。
+
+记金钱的消费明细的一个副作用是容易让人变得 “小气”，所以我也一直担心记时间明细是否也有什么不好的副作用。但实践了好几年下来，发现并没有什么明显的坏处，唯一需要的是额外多付出一点点微小的时间成本，但这个记录与测量时间的实践好处却是明显的：
+
+> 
+它会使你对时间的感觉越来越精确。每个人都感觉 “时间越过越快”，为什么会有这样的感觉？这种感觉会使得我们产生很多不必要的焦虑。而基于 “事件-时间日志” 的记录可以调整你对时间的感觉。在估算任何工作时，都更容易确定 “真正现实可行的目标”。
+
+
+是的，这就是关于时间的第一个 “基石” 习惯，**在精确地感知与测量时间之后，你才可能更准确地“预知” 未来**。
+
+站在当下这端实际是很难看清未来的另一端的，因为存在太多的可能情况。在一部叫《彗星来的那一夜》的电影中假设了这种场景，一个人有很多种平行分支的存在，时间经过的部分形成了稳定的唯一一个版本。
+
+也许，过去的十年你也像我一样，曾站在起点却看不清十年后的终点。而现今，我总会想象站在每一个未来可能的终点去审视当前的自己、当下的决策与行动，就会得到一个完全不一样的理解，从此开启完全不一样的平行分支。
+
+**过去的你也许不曾是时间的旧爱，但未来的你可以成为时间的新欢。**
+
+下篇，我会继续分享切割 “时间原石” 与构建时间基石习惯的方法，敬请期待…
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/26 | 时间：塑造基石习惯（下）——切割与构建.md

@@ -0,0 +1,87 @@
+<audio id="audio" title="26 | 时间：塑造基石习惯（下）——切割与构建" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/78/8b/780233d15c6633e7ca3e668de1fe108b.mp3"></audio>
+
+上篇，我讲述了关于建立时间习惯的第一步：**感知与测量**；之所以需要先感知与测量，就是为了更好地了解你的时间都花在哪里去了。
+
+下一步，**为了更有效地利用好你每天有限的时间，就需要你重新审视并调整你的时间切割与构建方式**。
+
+## 切割时间
+
+时间无形，逝去匆匆，如流水、轻烟、薄雾，类似这样的比喻把时间看成无形的东西，不容易抓住和把握。但这样的比喻把时间看作了物质，物质有三态，所以轻烟也好，流水也罢，总是可以变成固态来使之更容易把握与塑造。
+
+是的，我想说的就是转换一下你看待时间的方式，有人把它看作流水，任其从指间溜走，你却可以把它看作石头，用它去塑造什么。
+
+一般二十岁出头我们离开校园开始工作，十年穿梭而过后，就至三十岁。古人说，“三十而立”，“立”的又是什么？无意间翻到一本旧书《大教堂与集市》，这是一本探讨程序员如何构建软件系统的书，颠覆传统，影响深远。但作为一名工程师、创建者，难道心里没有一座属于自己的大教堂？三十而立，有人也许三十已经立起了属于自己的大教堂，而有人，也许如你我，才刚刚为心中的大教堂破土奠基。
+
+程序员有时爱把自己的工作比作 “搬砖”，有个流行的关于“搬砖”的故事，大概是这样的：
+
+> 
+两个工人正在工地搬石头，一个路人正好走过，就问他们在做什么？
+第一个工人说：“我在把石头从这边搬过来，并垒在一起。”
+第二个工人说：“我在盖一座华丽的教堂，盖好后，你再来欣赏我的作品。”
+
+
+这个故事想说明的是，虽然两个工人都在干同样的 “搬砖” 工作，但第二个工人心中有一座大教堂，也许 “搬砖” 对他的意义就会有所不同。有时想想，过去的每一天、每一刻，难道我们不是都在搬石头吗？只不过，有些石头会被用来修建心中的大教堂，而另一些石头，我们只是拿起来把玩、欣赏。
+
+璀璨剔透的钻石，五彩斑斓的宝石，所有这些美丽、诱人的石头吸引着我们把时间花在去欣赏、迷恋它们，渐渐地就遗忘了，原来曾经我心中还有一座大教堂要建造啊，最后我们无意或有意地避开去搬起那些建造大教堂的沉重石块。
+
+后来当时间过去，我回过头来看，在感叹别人雄奇的大教堂时，发现自己曾经把时间这块原石，切割成了一些看上去漂亮却没用的鹅卵石，更甚者只是切成了一堆土块，最后风化为一堆沙尘。所以，如今我再来看时间时，我更愿把它们切割成用来建造大教堂的石材。
+
+记录测量时间，让我对时间的感知更精确，而面对自然产生的每天一块的“时间原石”，每个清晨就要确定：把它切成什么样？由哪些石块组成？哪些是用来建造大教堂的石材？确定后，将其压在心上，临睡前再记录下今天从心上搬走了哪些石块，以及花了多少时间。这样时间于我就真的变成了一块块石头，比轻烟、流水、薄雾更有形，更易抓住，也没那么容易悄悄地溜走了。
+
+每天搬的石头，不一定都适合建造大教堂，而建造大教堂的时间也可能比我们预期的要长。
+
+位于梵蒂冈的圣彼得大教堂的建造过程前后历时 120 年，由米开朗基罗设计，而文艺复兴时期的大师基本都曾参与其设计。
+
+<img src="https://static001.geekbang.org/resource/image/49/b9/490c8bc000322bfa125681c487052ab9.jpg" alt="" />
+
+而建造历时最长的是德国的科隆大教堂，于公元 1248 年 8 月 15 日动工，从这天起，漫长的修建科隆大教堂的道路开启。600 多年后，到 1880 年 10 月 15 日，这座荣膺当时世界最高建筑物的科隆大教堂举行了盛大的竣工典礼，成为建筑史上最杰出的成就之一。
+
+<img src="https://static001.geekbang.org/resource/image/8f/ff/8fe3fa29dd689118870a11571bb811ff.jpg" alt="" />
+
+如今看到这些雄奇、壮观、让人赞叹的大教堂，再感受到建造它们的历史过程，就能真切地感觉到时间是如何被切割成了一块块的石材，构建成了最后的大教堂。
+
+这就是关于时间的第二个 “基石” 习惯：**将时间切割成建造你心中“大教堂”的合适“石材”**。
+
+## 构建方式
+
+切割了时间，得到了合适的“石材”，你还需要确定适当的构建方式。
+
+而适当的构建方式，是指在时间的 “基石” 习惯之上，建立其他的习惯。比如，好些年前开始，我会从每周的时间里切出来一块，专用于写作，慢慢就形成了写作的习惯。这意味着，我从现有的 “时间石材” 中拿出了一部分，用于构建写作的习惯，然而 “时间石材” 的总量是有限的，我必须在其上建立有限数量的习惯，我得做出选择。
+
+每一个习惯的构建成本是不同的，甚至同样的习惯对不同的人来讲，构建成本也是不同的。比如，跑步这个事，对有些爱运动的人来说就是每天跑或每周跑几次的习惯，而于我而言，建立跑步这个习惯，从心理到生理都有更大的消耗。
+
+任何行动的发生，都需要两种努力才有可能：第一种，是行动本身固有需要的努力，如跑步，跑一公里和跑十公里固有需要的努力是不等量的；第二种，指决策是否执行这种行动的努力，决定跑一公里还是跑十公里的决策意志力消耗，我想也不会一样。
+
+**构建习惯的目的，以及它们能起作用的原因在于：它能消除行动中第二种努力的决策消耗。**
+
+我之所以选择构建写作习惯而不是跑步习惯的原因是，对一个像我这样的程序员而言，写文章和写代码的感觉很接近，它就好像是一种刚好在程序员的能力边界线外不远处的事情。这样，写作行动所需要付出的两种努力，感觉都还在可以应对的范围，属于能力边界附近不远的事情，也是正适合用来扩张能力边界的事，有一种挑战的刺激感，又不至于望而生畏。
+
+电影《功夫熊猫3》里，师父对阿宝说：
+
+> 
+如果你只做能力范围内的事，就不会成长。
+
+
+所以，在时间 “基石” 习惯之上构建的习惯应该是你能力范围之外的行动。如果一项行动通过习惯慢慢变成了能力范围之内的事，那么你以后再去做类似的事，其实就不需要再付出什么决策努力了，也就不再需要习惯来帮忙了。
+
+有时，习惯会让你产生日复一日、年复一年做一件事的感觉，这样日积月累下来消耗了大量的时间，但付出了这么多未必会产生真正的收获。怎么会这样呢？
+
+**习惯，它的表象和形式给人的感觉是在重复一件事，但它的内在与核心其实是不断产生交付，持续的交付。**
+
+好多万年前，人类的蛮荒时期，还没有进入农业社会，人类是如何生存的？那时的人类，以采集和狩猎为生，每天年轻力壮的男人负责出去狩猎和采集野果，女人则在部落内照料一家老小。这就是进化史上，自然选择让人类养成的共同习惯，并且这个习惯持续了数十万年。
+
+采集与狩猎这个行动习惯的核心就是必须每天产生交付，得有收获，否则一家老小都得饿肚子。而像狩猎这样的活动，就需要高度集中的注意力、熟练的技能运用和瞬间的爆发，它需要狩猎者所有的感官都高度专注在猎物的运动上，并随时调整适应猎物的运动变化。而采集，就需要采集者不断扩大或走出熟悉的边界，因为熟悉的地方可能早就没了果实，而陌生的地界又可能潜藏着未知的危险。
+
+这样的行动习惯，通过数十万年的进化，甚至已经刻画在了我们的基因中。这就是我想说的，**如果你要构建一个习惯，就要运用好基因中本已存在的关于 “采集和狩猎” 的本能：高度专注，跨出边界，持续交付**。
+
+末了，我把上、下两篇的内容一起提炼总结为如下：
+
+- 要形成时间习惯，要通过有意识的感知和测量来发现时间是怎么流失的。
+- 要完成建设你心中 “大教堂”，要通过切割 “时间原石” 来完成 “时间石材” 的准备。
+- 在养成了时间的基石习惯之上，挑选和构建其他习惯来完成 “大教堂” 的持续建设与交付。
+
+世界上多一些 “大教堂” 会变得更美好，不是吗？
+
+关于时间，你也可以回忆一下过去的数年间，有哪些让你激动不已的时刻？曾经梦想的 “大教堂” 开始破土奠基了吗？欢迎你留言，我们一起分享和探讨。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/27 | 试试：一种“坏”习惯.md

@@ -0,0 +1,88 @@
+<audio id="audio" title="27 | 试试：一种“坏”习惯" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7e/34/7e0700479718f0e0ac43f8d4edc65d34.mp3"></audio>
+
+曾经，我碰到一些程序员问我：“我以前是做安卓的，现在想试着学下后端服务开发，你觉得怎样？”我一下子就卡住了，不知该如何回答才好。原因是：学习本是个好事，但前面加个 “试着” 似乎感觉就不太好了。
+
+## 好的出发点
+
+“试一试” 的初衷本来就该是好的，它表达了一种好奇心，以及尝试走出舒适区的勇气。
+
+程序员这个职业，会带来一些职业习惯。比如，可能会经常性地去尝试一些新东西，然后看看它是否如预期般那样被应用或实现。
+
+这里，我就拿程序员“调试程序”这项日常工作来举例。调试，就是这样一种需要不断去试的过程。
+
+还记得我在前面《炫技与克制》一文中讲了我早年刚开始工作时的那个小故事吗？那时我带着炫技的心态应用了刚刚接触的 Java 线程编程通信来实现一个客户端小程序。结果后来程序出了 Bug，而我不断修改，Bug 从这里消失，又从那里冒出来，让那时的我产生了巨大的挫败感。
+
+当时，我花了很长时间一直在“抓”这个 Bug，用的方法就是调试技术。但因为这是一个机率性出现的 Bug，一步步调试反而从来没出现过，但真正运行起来又总是偶然出现，实在让人抓狂。在这样的单步调试中，我就是怀着一种期望凑巧能碰到的心态，做了很多无用功，最后也没能解决真正的问题。
+
+这个案例虽然已经过去了十几年，但还是给我留下了深刻的印象，久久不能忘怀。我把它分享出来，就是感觉想必这条路上曾经的我不会是特例。
+
+表面上看，是当时那种炫技的心态致使我选择了不恰当的实现方案，也最终导致出现了对于那时的我来讲很难解决的 Bug。但其实这里真正的症结是：我对于线程间通信的知识出现了认知性盲点，这属于 “我以为自己知道，其实不知道” 的问题。
+
+我习惯性地用调试去找 Bug，这就是一种 “试一试” 的方法，出发点（找到 Bug）是好的，过程也是很艰辛的，但最终结果却是无功而返。即便用这样的方法最终找到了 Bug，也有一定的运气因素，并不具备可重复性。
+
+当时，我正在读一本有关线程编程的书，后来读到某个部分时，关于这个问题的根源我突然就恍然大悟了，因为这个部分正好弥补了“我以为自己知道，实际却不知道”的认知盲点。我习惯性的调试方法，虽然有一个好的出发点，但问题是，我不知道我在调试什么。也许是想通过调试证明程序逻辑本不该出错的，或是通过调试发现其他的疏漏，但在这样的盲目调试中最终也没能定义清楚我调试的终点到底是怎样的。
+
+那时的我就是一个刚进入编程领域的小白，喜欢调试，然后在看上去很复杂的调试界面忙忙碌碌，感觉很专业，但最终收获的仅仅是对调试器的熟悉程度。而且一不留神，就自觉不自觉地养成了这种“试一试”的“坏”习惯。
+
+## 模糊的终点
+
+这里，“试一试”的“坏”习惯的“坏”字之所以加上双引号，就在于它的出发点本是好的，但如果终点是模糊的，那就“坏”了。
+
+近些年来，就出现过几轮的技术热，比如，刚进入移动互联网时代就大热、但如今已经回归常温的移动开发，曾经大热现已降温的云计算与大数据，以及还在热度中的人工智能、机器学习和区块链等。面对这些技术热，很多人都跃跃欲学之、试之。可能你也不例外。那么，到底为什么你会想去尝试一种新技术？是你仔细思考后的主动选择，还是说或多或少又被技术潮流所裹挟？
+
+好些年前，移动开发还在升温阶段时，我也不可避免地被这样一种潮流所裹挟过。我开始看一些关于 iOS 开发的书，从语言到工具。其实，尝试学习一种新技术并不是坏事，即使是被技术潮流所裹挟，但问题出在，这次尝试的终点在哪里？
+
+我是想转型成为一名移动开发工程师吗？还是说我有一个想法，需要开发一个 App 来达成？抑或我仅仅是想学习并了解下移动开发是怎么回事，从而进一步提升下技术的广度理解与视野？
+
+然而以上皆不是，我当时的尝试完全没想清楚终点在哪儿。后来热度下来了，其他工作任务也多了，也就慢慢遗忘了。回过头来看，这只是浪费了一些时间和精力罢了。
+
+几年后，人工智能与机器学习又热了起来，我又开始尝试学习起来，但较上次不同的是，这次我把尝试的终点定义得很清楚。我不是想转型成为一名机器学习领域的算法工程师，也不是因为它很热就“随波逐流”地被潮流裹挟，我这次尝试的终点就是想搞清楚关于人工智能与机器学习的三件事：
+
+- 它的原理与应用场景；
+- 它的前世今生；
+- 它如今已抵达的边界。
+
+搞清楚这三件事，虽不会让我成为机器学习的专家，但会提升我对于这个热门技术的判断力。因为，现实中我需要判断一些真实的业务场景该如何结合这样的技术，这就需要了解它们的应用场景和一些原理。
+
+另外，一门新技术很少是凭空冒出来的，了解它们的前世今生，会更有效地知道，哪些方面已经有了成熟的方案，哪些地方还在青涩的探索期。再结合它当前的边界，就知道如何定义清楚需要，形成合理的技术方案，而不会产生过度的妄想。
+
+**试一试，需要有更清晰的终点**。关于终点，你也可以从下面一些方面来考虑：
+
+<li>
+**验证猜想**。这个部分程序员就很熟悉了，因为编程中的调试其实最重要的目的就是验证猜想。引入一种新技术或框架，验证 API 的调用结果或运行输出是否如你所想，即使最终否决了，那你也获得了判断的依据与知识。
+</li>
+<li>
+**收获结果**。定义清楚你尝试的这件事，到底能收获怎样具体的结果。比如：考试，尝试的收获就是要通过。
+</li>
+<li>
+**体验过程**。有时候结果并不确定，比如，创业的结果未必就一定是成功，那么这样的尝试难道就没有意义了吗？有的，因为创业的超低成功率，所以，体验过程恐怕多于收获最终结果。
+</li>
+<li>
+**理解现实**。你尝试一个新东西或学习一个新知识，有时未必真是为了将来有朝一日能用上它，而主要是为了完善你的知识与认知体系，然后再去理解现实为什么是这样的。
+</li>
+
+## 现实的路径
+
+“试一试” 的路径是有限的，毕竟终究离不开现实的约束。
+
+有时候，你因为现实工作需要，可能需要不停地在各种技术栈上切换。而很多技术可能过了那段时间，就再也用不上了，这样的技术尝试难免会让人感觉可惜。但通过我前面列出的关于 “终点” 的方面，再来分析下这个现实场景。
+
+首先，你得面对现实，这样的技术尝试在现实中太多太多了，有时就是没得选择。当年，我也因为工作原因，从客户端桌面编程的 VB、PB、Delphi 到 Web 编程的 JS 语言和一堆相关框架，再到后端编程的 C 和 Java，而如今很多当年学习的技能早已过时了。但这样的技术切换尝试，从 “收获结果” 的维度看还是解决了当时的问题，满足了需要，获得了结果。
+
+其次，如果觉得仅仅一次性收获的结果，不值得你投入的时间和精力，那就可以从 “理解现实” 的角度去挖掘。这些知识，从学以致用的角度很快就过时了，但它们并不是完全孤立的，事实上计算机程序体系内的很多知识都不是完全孤立的，它们都有相互的联系与连接点。
+
+从理解的角度，这类技术切换的尝试事实上扩大了你的知识边界，尝试的也许是孤点，但你可以进一步找到它们的连接处，形成体系。因为很多现实的原因，每个人的起点和路径都不会一样，但我们都是从某一点开始去慢慢摸索、尝试，最终走出一个属于自己的体系来的。
+
+最后，当你有了自己的体系，也可能有了更多的尝试选择权，就可以体系为中心，去有选择地尝试对你更有意义或价值的事了。
+
+**总结来说**：
+
+试一试，是走出舒适区的一次行动，这本是一个好的出发点，但若只有一个模糊的终点，那么它带来的更可能就是无谓的浪费。
+
+试一试，不仅要有一个好的出发点，还需要一个清晰的终点，在这个终点你可能：验证猜想、收获结果、体验过程、理解现实。而在起点和终点之间，你需要选择一条更现实的路径，通过不断地尝试，走出自己的体系。
+
+试一试，本该是个好习惯，可别把它用坏了。
+
+想必很多人都有过盲目尝试的经历，欢迎留言分享你的经历及反思。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/28 | 提问：从技术到人生的习惯.md

@@ -0,0 +1,132 @@
+<audio id="audio" title="28 | 提问：从技术到人生的习惯" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7c/3d/7cfa611b492263b4fb46fba3e8564d3d.mp3"></audio>
+
+无论做什么工作，一路上你总会碰到各种各样的问题，而提问应是你解决问题的一种有效途径。更进一步，如果能把提问固化成为你的一种习惯，那它就不仅仅是一个解决问题的“工具”，甚至还能引导你的人生选择。
+
+提问这个习惯，我有三个层面的理解：
+
+1. 如何问？
+1. 问什么？
+1. 为何问？
+
+## 如何问？提问之术
+
+大部分情况，我们碰到的都是已经有了问题，但却问不好，从而得不到答案或得不到好的答案。
+
+比如说吧，我经常碰到的一种情况是：有同学常拿着一个具体的问题跑来，向我发问，他大概会交代一下想解决的场景，然后就会接着描述他的思路，以及解决这个问题的思路的一些其他约束，但这中间会有一个障碍，然后就问我该怎么解决这个障碍。
+
+这样的发问一般都会让我陷入两种困扰之中：一种是，问题的业务背景交代得太泛化，所以我只好跟着他的思路，感觉解决这个问题似乎只能有这一条路可走；另一种则正好相反，问题的业务背景描述得过于细致，让人最后陷入对复杂业务领域的理解中，迷失在细节的讨论里。
+
+即使是同一个场景，其实不同人还会产生不同的思路。比如：你想去一个十公里外的地方，对方也许会问你怎么套马鞍的问题，这时你就很困扰，因为你的思路是坐车或开车。这就是一个针对技术人员面对同一场景问题，所选取的不同技术方案可能处在不同的时代背景下的类比。所以，面对这类具体的障碍问题，我经常很难回答。
+
+再看看国内网上技术问答社区的情况，我有时会去看看，发现上面的问题大部分类似下面两种模式：
+
+- 某某出错了，怎么办？
+- 如何针对某某封装一个库？
+
+某某可以是一种具体的技术或框架，这两种提问模式代表了两个方向，都让人无法回答。第一种太模糊而无法回答，而第二种太庞大则不愿回答。
+
+如果你能绕过这两个提问的大坑，提出一个具体的问题，那么算是前进了一大步。但具体问题也有一个陷阱，就如前面套马鞍的那个例子，也许有人回答了你怎么正确地套马鞍，但你可能依然走在落后的道路上，因为你的工具本身就是落后的。所以就具体问题提问，除了问及手段，还最好跟上你的目的和你就此目的是怎样提出的手段，然后才走到了这一步的障碍，让你不得不在此提问的。
+
+一个能够回答的具体问题，一般都是解答题形式，表达清楚你的解答目的，也许你的困扰在高手那里根本就不存在。你只是走了一个弯路而已，这样不仅绕过了障碍，还获得了一条近（先进的）路，这就是有意义的提问。
+
+至此，就得到了提问的第一个原则：**提供足够的信息，让人能够回答**。
+
+草率的问题是懒惰的问题，通过搜索引擎就能简单获得；草率的问题是模糊的问题，让人没法回答。而更有意义的提问是把解答题变成选择题，提供你的选项，展现你探索了哪些路径，省去了可能产生的反问。也许你的某条路径已经非常接近答案了，只是卡在了某个点上，知道答案的人一看就明白了，也很容易回答。
+
+这就是提问的第二个原则：**提供更多的选项，让人方便回答**。
+
+即使你的问题能够回答，也方便回答，但也可能得不到回答。因为，回答问题需要有驱动力。提问本是一种索取，要让人有更多的回答动力，还需要付出。付出一种态度，表达感谢；付出一份可供交换的视角，建立讨论的基础。
+
+这就是提问的第三个原则：**提供交换价值，建立讨论基础，表达感谢态度，让人乐于回答**。
+
+《大教堂与集市》一书的作者埃里克·史蒂文·雷蒙德（Eric Steven Raymond）曾就如何提技术问题写过一篇影响颇大的文章：[How To Ask Questions The Smart Way](http://www.catb.org/esr/faqs/smart-questions.html)（中文名是《提问的智慧》），距今已经十多年了，修订了十多次，也被翻译成了十多个国家的文字，很值得一读。
+
+最后，我归纳下关于提问之术的三个方面：
+
+1. 提让人能够回答的问题：草率的问题，只能得到一个草率的答案。
+1. 提让人方便回答的问题：你得到的答案的好坏取决于提问的方式和开发答案的难度。
+1. 提让人乐于回答的问题：只索取而不愿思考和付出的提问者，要么什么也得不到，要么只会得到 RTFM（Read The Fucking Manual） 或 STFW（Search The Fucking Web）。
+
+## 问什么？求解之惑
+
+有时一个好问题，比如何问更有价值和意义。
+
+我觉着，前面一节关于如何提问本身也算是一个好问题，因为当你面对这个问题，找到了答案，并严肃地对待后，从此就会改变你提问的习惯。提出好问题比寻找已有问题的答案可能更有意义和价值。寻找答案，通向的是已有的结果；而提出新问题，也许会导向未知的宝藏，它可能是获得新知的起点。
+
+有时候，你会碰到一个问题不知道该问什么，甚至该如何提问，即使这个问题是一个非常具体的技术问题。而这一类具体的技术问题，我称之为答案藏在问题中，属于无法提问的问题。
+
+这可能说得比较抽象，下面我举个具体的例子：曾经碰到过一个线上问题，系统间隙性出现超时，只有重启能解决；而且出现的很无规律性，不和什么流量之类成正比，就是莫名其妙偶然出现，还不能恢复，只能重启。这个问题曾经困扰了我很久。这类问题虽然很具体，但你可能会发现，你竟找不到一个好方式来描述这个问题。
+
+如果我就把上面这段描述的关键现象，偶现超时并结合使用的具体技术，如：JVM、开源框架配置和业务场景一起抛出来问人，你觉得有人能回答吗？这类就属于答案藏在问题中的问题，唯一的办法只能是找和你一起共事的同事从各人不同的思维视角去分析，抽丝剥茧。当你能找出提问的方式，基本上答案也就出来了。
+
+后来，终于定位到上面现象的根源是服务线程池的配置有误，结合在某些慢业务场景下会引发连锁超时。这时的问题就是怎么配置服务线程池才最合理，这个问题本身就简单到完全无需再问了，自然就有了答案。
+
+在成长的路上，我碰到过好多问题，但早年还没有形成记录与写作的习惯，所以未能把这些问题记录下来，很多就遗忘散落了。这就是我想说的第二个需要建立的习惯：**当遇到暂时没有答案的问题时，先记录下来**。在成长这条路上，不是碰到了问题，就能立刻或很快找到答案的。
+
+当我开始写作后，就开始养成了这个习惯。大部分过去写的文章都来自于这些问题记录，定期地回顾下，曾经困扰我的问题，今天能解决了吗？一开始有很多具体的技术性问题，就因此写了很多技术文章。后来又有了更多复杂的问题，也就又写了不少思考性的文章。每写一篇，意味着当下的我对这个问题至少有了答案。无论这个答案如何，从某种意义上说，今天的我相比当时面临问题没有答案的我，就已经成长了。
+
+先从一个记录问题，积攒 “问什么” 的习惯开始，不断去积累并留下一些东西，将来再定时去回顾这些问题，也许就会得到意外的收获。对于程序员，总会碰到各种技术问题，就从这些最具体的问题开始，把暂时这阶段还没法回答的问题按一种模式记录下来，比如下面这样：
+
+- 问题的上、下文；
+- 问题的具体描述；
+- 问题的解决思考和思路；
+- 问题的解决方案和具体技术或办法；
+- 问题解决后留下的思考或其他延伸的疑问。
+
+这就是你积累的 “宝藏”，将来如果能回答了，就把答案分享出来。这就是我所认同的积累价值和传递价值的方式，分享你从中学到的一切（Share what you learn），最后自身的价值也就得到了提升。
+
+保持积累，持续给予，终有所获。
+
+## 为何问？价值之道
+
+提问的目标是获得答案，而答案于我们自己而言是一种价值；为何而问，就是发问于我们的价值之道，最终指向的目的是：认清自我。
+
+值得问 “为何” 的问题不多，但总会遇到，它是一道选择题，有关我们的价值选择。我们最关心的是自己的命运，而关于命运有一句话是这么说的：
+
+> 
+选择决定命运，什么来决定选择？价值观。
+
+
+价值观，是我们对事情做出判断，进行选择取舍的标准。每个人都有价值观，无论你能否清晰地定义与表述它，这些观念都决定了你的行为标准。这么说有些抽象了，下面我通过一个故事来将其具象化。
+
+这个故事的主角叫比尔（Bill）。21 岁时他成为一名程序员，获得了第一份正式工作，在加拿大多伦多的一家互动营销公司写程序，这家公司的主要客户都是一些大型药企。而在加拿大，法律限制药企直接对普通消费者做处方药的广告。
+
+所以，药企客户提出了需求，做个网站来展示公司的药品，对于浏览网站的用户，如果能提供处方就会被引导到一个病人的专属页面。在这个专属页面上，提供了一系列的测验问题，然后通过病人的回答来推荐相关的药品。
+
+这个网站仅仅是展示公司产品，提供通用说明的信息网站，这显然不是任何特定药物的广告。一切显得很合理，比尔收到了需求，它们包含了针对病人的测验问题，每个问题的答案，以及对答案的处理规则。
+
+比尔完成了开发，在交付给客户之前，他的项目经理决定对网站做个简单的快速验收测试。经理试了这个针对病人的小测验，然后走到了比尔的桌前：
+
+“测验不管用！” 经理说。
+
+“哦，出了什么问题？” 比尔问。
+
+“嗯，看来无论我填什么，测验都给我推荐同一种药物，唯一的例外是我回答过敏或者已经吃过了。”
+
+“是的，这就是客户要求的处理规则，其他情况都会把病人引导到这种药。”
+
+“哦，好吧。酷～”
+
+经理没再说什么，他们一起交付了网站给客户，客户对这个网站很满意。项目结束后，客户的代表还邀请比尔和整个团队一起去吃一顿丰盛的牛排大餐。就在吃大餐的当晚，一位同事给他发了一封电子邮件，链接到网上的一篇新闻报道：是关于一个年轻女孩，服用了他（创建）的网站推荐的药物，然后自杀了。
+
+网站推荐的药，其目标用户就是年轻女孩。比尔后来想明白了，他们所做的一切，建设这个网站的真正目的就是广告一种特定的药物。那时，作为团队中最年轻的开发人员，他虽然觉得客户需求的规则就是为了 “戏耍” 年轻女孩而设计的，编写的代码是 “错误” 的，但却没有多想，只是觉得这就是他的一份工作，有个开发任务要完成，而且他完成的很好。
+
+结果后来发现，这种药物的主要副作用之一就是会让人产生严重的抑郁和自杀念头。比尔说，他可以找到无数的方法来使自己在这个事情中的角色自我合理化，但当时他依然觉得自己的代码写“错”了。那顿大餐后不久，比尔辞职了。
+
+这就是比尔的价值观选择，他一开始是不清晰的，但这个事情让他问了自己为何，就变得越来越清晰了。我能知道这个故事，自然是比尔多年后自己写出来的。他说，“今天的代码（人工智能程序）已经开始接管你的驾驶，帮助医生诊断疾病，不难想象，它们很快也会推荐处方药。”
+
+比尔现在依然还写代码，但自从牛排大餐那一天起，比尔都会仔细考虑代码的作用，多问一个为何？因为程序已经越来越多地占据着我们生活的方方面面，那代码背后需要价值观吗？
+
+这就是第三个习惯：**为何而问？获得答案，认清自我，选择自己的价值之道**。
+
+关于提问，今天就分享到这里，我总结提炼下：
+
+- 如何问，是关于提问的 “**术**”，考虑让人能够回答，方便回答和乐于回答；
+- 问什么，是关于成长的 “**惑**”，去积累问题，寻找答案，并分享出来，从而完成了价值的积累、传递与交换；
+- 为何问，是关于选择的 “**道**”，价值观的选择决定了不同的道。
+
+成长的过程，一般都是从提出一个问题开始，找到答案，再融入自身的价值观，完成下一次更好的选择，周而复始，形成习惯，化作天性。
+
+最后，你也可以想想你最近有哪些问题，是否有了答案，以及该如何提问。请在留言区写下你的思考。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/29 | 偏好：个人习惯的局限与反思.md

@@ -0,0 +1,76 @@
+<audio id="audio" title="29 | 偏好：个人习惯的局限与反思" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/69/3a/690dccc45ce27868f694e5511b55653a.mp3"></audio>
+
+经过长时间的工作实践，我们会逐步养成一些做事的个人喜好或习惯，并且会自我感觉这种个人习惯会是很好的方法。
+
+不可否认，每个人做事情都有些个人习惯，有些特别强烈的，可能其程度还会上升到 “癖” 这个字。明朝散文家张岱在其文《陶庵梦忆》中留有名句：“人无癖不可与交，以其无深情也。”这里的 “癖” 就是指一个人强烈的个人喜好与习惯。
+
+作为程序员，过去这么些年干得最多的事情自然就是写程序，关于写程序也会形成一些个人习惯或者说癖好。自己的习惯或癖好对别人本该是无所谓的，但在团队合作中，有些时候，我们可能会不自觉地去维护，甚至推广这种习惯。这种 “不自觉” 的行为是值得我们警惕和反思的。
+
+## 习惯形成
+
+工作中的一些习惯是如何悄悄形成的呢？
+
+记得毕业几年后，我也成了需要带新毕业学生的 “老” 程序员。其中，带学生的主要任务之一就是一起做项目，指导他们上手开始写真正的项目代码，而不再是实验性质的课程作业。
+
+我开始工作的头几年，可以说是我写程序最多的几年，基本也就写出了我个人的一些习惯和喜好。比如，工程的目录结构、类的命名模式、接口的参数定义，甚至注释和签名的方式，都是我特别在意的地方。每当看到新同学们各自按自己的想象写得随心所欲，就感到非常地焦心。
+
+那时候像 Java Maven 这种约定优于配置的工具还没有流行起来，大家都是按自己的喜好使用 Ant（一种 Java 构建工具）来定义工程项目结构，所以最终导致结构千差万别。
+
+因而，我就忍不住去把新同学们的工程按我自己的定义喜好进行修改，以一种权威的说辞来强调自己的偏好：“我们要统一下，免得像以前旧项目一样差异太大，换个项目熟悉起来都要好半天，也不利于相互之间的代码交流。”
+
+如今回想起来，当时这种 “约定优于配置” 的个人习惯在行业里还并没有成为共识，而我仅仅是出于自己对代码的 “洁癖” 或者说强迫症，就产生了这种强加于人的冲动行为。一些年后，Maven 崛起逐步取代了 Ant，这种约定优于配置的方式就变成了 Java 程序员的普遍共识，而我，也可以确认这个习惯基本算是一个好方法，也不再需要去强迫别人了。
+
+以上，就是一个关于编程习惯的形成过程。从中我们可以看出，即使这样的习惯最后也许真的变成了大家认同的好方法，一开始也不该以个人的方式直接去强加于人。因为强加于人，总是容易带来分歧和争论，最终可能好习惯还没机会带来收益，却因为分歧争论直接带来了损失。
+
+但编程中总结出来的一些方法和原则，很多可能就是始于个人习惯，最后逐渐传播并演化形成了普遍共识。
+
+## 共识达成
+
+如今，很多约定俗成的代码规范，基本就是从早期一些人的习惯中加以提炼总结出来的，然后形成了大家共同认可的好方法，并在组织层面形成了规范。形成了规范的东西，就不再是从个人习惯的角度去强加于人了，而是大家的共识达成。
+
+写代码的一些方法能形成规范，但还有一些编程的好方法可能比较难用规范去描述，这些就慢慢形成了所谓的 “编程智慧”，并在程序员之间口口相传（如今的 “口口” 可能更广义一些，也包括了互联网上的文字交流和传播）。
+
+一些 “编程智慧” 类的好方法，不太好形成具体的规范描述。下面，我就结合我自己的工作经历和经验，列举一些规范建议：
+
+1. **设计模式**。遵守设计模式总是能让你少踩坑的，但如何灵活地采用合适的模式又是另一种智慧了。
+1. **术语约定**。约定了术语，总是能让口头的概念和落在代码上的东西保持一致，减少沟通歧义，从而更高效。
+1. **单元测试**。这比任何的代码评审都来得可靠，哪里该写多少测试用例，哪里可以不写，这又是智慧了。但不要刻意为了追求覆盖率而去写，覆盖率的技术统计方法其实是很唬人的，有些覆盖率很高的项目，该有的 Bug 还是有的。
+1. **随时重构**。对于技术债务，每个月付点“利息”，比好几年后“连本带息”去还要感觉轻松得多。这条的特殊点在于，这可能是大部分程序员都认可的好方法，但却不是大部分人的习惯。因为技术上的债，实在自己还不起，总是可以推脱出去给下个“倒霉的家伙”，但从长远角度看，这样的推脱不会让你获得成长，甚至还会阻碍你的发展。
+
+在程序界形成编程共识最经典的例子来自 Unix 的发展历史，而 Unix 几十年的发展历程，不仅仅是一个软件系统的进化，也是程序设计和编程方式的进化。从它的进化历程中，形成了独特的设计原则，而且已广为流传，达成共识。
+
+共识，意味着看待问题共同的思考方式和角度，所有能形成共识的方法都是值得关注的。
+
+## 分辨反思
+
+编程中除了好方法，还有些确实只是个人习惯的东西，如果我们不去留心区分，很容易模糊了两者的界限。
+
+举个例子，我曾经一直有个编程习惯是这样的。假如有一个查找接口方法叫 lookup()，而实现这个方法内部的逻辑要根据好几种条件来查找，按不同的参数条件来实现不同的内部逻辑分支，但最后执行时又会走同样的一段逻辑去存储里查找。这样描述起来比较绕，下面我用个简图来说明：
+
+<img src="https://static001.geekbang.org/resource/image/de/c5/ded4a70a4c19c670aa662c38fa9e6cc5.png" alt="" />
+
+如上，lookupByXXX 表达了不同参数逻辑的差异化处理，最后的 lookup0 则是一段共享的查找执行代码。 lookup 是一个公开的接口方法，而后面再加个 0 基本就是我的个人习惯了，表达了内部私有的一种技术性实现，它一定是私有的，不对外暴露的。
+
+这个例子中的编程方法，是让我对所有类似需要的接口实现模式保持一致。但这确实只是我个人的习惯偏好，我没办法并且也不会要求别人也用类似的方式来命名函数和编写实现，因为别人也可能有自己的习惯偏好，谈不上谁比谁更好，毕竟它并不是广泛的共识。
+
+那大家都认同并形成共识的方法就一定能形成习惯吗？也未必，这需要我们去分辨和反思。比如程序员都不爱写文档，很多人也没有这个习惯，但大家几乎都认同提供规范的设计和接口文档是个好方法，只是因为文档的优先级长期低于完成代码功能从而被搁置了。
+
+另外，一些流行的概念就一定是好方法吗？比如，结对编程，是一种流行的概念。它的行为要求是：两位程序员坐在同一工作台前开发软件。它的优势作用是：与两位程序员各自独立工作相比，结对编程能编写出质量更高的代码。其理论基础是：两个程序员具有相同的缺点和盲点的可能性很小，所以通过结对编程的时候会获得一个更好的代码实现。
+
+但在实际中，结对编程也有它的缺点和劣势，比如更高的开发成本（毕竟要同时占用两个人）。而且，有些人可能从心理上就很不喜欢结对编程的，比如我，因为坐在一起编程，难免分心而无法进入完美的心流状态，所以会感觉自己的工作效率都会下降一半以上；并且我也很难接受别人在看代码讨论时，用手戳屏幕指指点点。当然，不仅仅是我，还有更甚者，除了代码洁癖，还有生活洁癖，根本接受不了任何其他人和自己共用一个键盘的。
+
+也许稍微松散点，没有那么物理上的严格结对，而是确保每一个程序员写的每一行代码，都能有一个配对的程序员去进行检视，虽说这个过程完全是异步或远程的，但效果应该也是可以保障的。这几乎就是开源项目的协作模式。开源项目的繁荣与成功，也证明了其实践的协作模式是一种好方法。
+
+**总结来说**：
+
+在你从程序新人成长起来的过程中，要学会区分，哪些确实是值得学习与推广的好方法，哪些仅仅是自己的个人习惯，特别是在你成长到开始成为技术管理者之后。
+
+古语有云：“己所不欲，勿施于人。”而己之所欲，若是自己特有的习惯偏好，也就请勿妄施于人了。若确实觉得是个好方法，尽量建议于人，而非强加于人，即使你手上掌握有强加的权力。
+
+反过来看，程序行业，编程实践中，存在大量流行的概念、模式、原则，甚至哲学，它们的产生都有其历史背景和过程，并在一定范围内形成了共识。但你依然需要去对这些流行的共识进行分辨和反思，看看哪些才是适合你的好方法。若真是好方法，也可以进一步将其培养成自己的习惯。
+
+虽是以编程为例，但习惯的偏好不限于此。
+
+最后，在你成长的路上，都形成了哪些好习惯呢？欢迎你留言给大家分享下。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/30 | 写作：写字如编码.md

@@ -0,0 +1,128 @@
+<audio id="audio" title="30 | 写作：写字如编码" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5e/71/5ea9fe89f2ab01548c62ac6e96ec9171.mp3"></audio>
+
+程序员群体有个共同的弱点，那就是写得了代码，解决得了问题，但却不能很好地展现自己的能力。从今天开始，咱们专栏即进入一个关于 “展现” 的主题，聊聊（写作、画图和演讲）三类最常见的展现手段。
+
+其中，展现的最常见形式之一就是：**写作**，它是一种能随着时间去沉淀的长尾展现形式。
+
+曾有多人问起，写作除了坚持写、持续写、长期写，还有什么其他技巧么？答案是：有的。虽说我并没有上过专业的写作课，但在长期的写作过程中，我已通过实践摸索出来了一套符合程序员这种理性逻辑思维的写作技法，简言之，就是：写字如编码。
+
+把每一篇文字当作一个需求，把写作当成在编码的过程去完成这个需求，它会非常类似于程序开发的整个过程，包括**需求、设计、实现、测试和交付**五个阶段。
+
+## 一、需求
+
+程序的需求，对应于写作的主题。
+
+你之所以写程序，是因为有人给你提需求；但你业余的写作，通常就不会有人给你提相关的写作需求或主题了。所以，就需要你自己去主动寻找和发掘你自己的写作需求或主题。
+
+对于我来说，写作主题的来源可以有很多方面：有时，是来自身边的工作和生活中的事件引发的感触；有时，是阅读过程中突然产生的启发与领悟；有时，则是曾经一直困惑的问题突然碰到或找到了答案……这些都属于灵感乍现的时刻，也是我写作主题的来源。
+
+但只是等到写的时候去灵光一现是很难保障持续写作的主题供应的，所以为了持续写作，我很多时候在大脑的潜意识里都会考虑主题的问题，等有了灵光一闪的时刻，就随时记录下来，形成一个**主题列表**。这个主题列表，就有些像产品的需求特性列表了，呆在需求池里等待被 “实现”，也即，“写出来”。
+
+所以，如果你想要持续地写作，你得养成一个习惯，也就是前面《提问：从技术到人生的习惯》一文中关于提问和记录的习惯。
+
+随手记录的主题可能很多，但真正能写的时间和精力却有限，因此你得挑选值得写的主题。如果把每一篇文字想象成一件产品，那么定义写作的主题，就像定义产品的灵魂，你得确定一个产品的目标、定位，以及面向的读者人群。
+
+美国作家库尔特·冯内古特说：
+
+> 
+想一个你关心，其他人也会关心的话题来写。要记住，不论你用多么发自肺腑的情感表达，对于读者来说，除非是他们真正关心的主题，不然怎么都不会太关心，而只有主题才是读者最真切的关注点。所以，关注你的主题，而不是想办法去显摆自己的文字。
+
+
+是的，一个好的主题很可能是一篇好文字的开端，毕竟如果一开始产品方向错了，实现得再好又能有多大意义呢？
+
+## 二、设计
+
+确定了本次写作的主题（需求），接下来就该进入到设计阶段了。
+
+而程序开发的设计一般分为两个层面：
+
+### 1. 概要设计
+
+在软件程序系统的设计中，这部分内容主要是架构设计，系统或子系统的拆分、交互逻辑、边界等等。而对于写作而言，这部分对应的就是设计本篇文字的逻辑结构，换言之，即在主题确定的基础上，采用怎样的逻辑去展开主题，形成合适的衔接。
+
+比如，我写的文章多为随笔散文类，而散文的结构，上过中学语文课的我们都知道：形散而神不散。其中的 “神”，就包括了文章的核心主题观点，以及围绕主题展开的逻辑结构、文字附着的延展线条等。
+
+### 2. 详细设计
+
+有了逻辑骨架后，就需要补充真正有血有肉的文字了。
+
+围绕主题想表达的观点，考虑需要添加哪些支撑观点的素材，以及设计整理、引出和排布这些素材的方式。而为了让文字更有阅读的趣味，还需要有适当的故事，因为人们都喜欢读故事，而非说教，那故事又该如何切入与布局？这也是需要考虑的点。
+
+另外，这些素材或故事又从哪里来？只能来自平时的阅读积累。大部分我们读过的东西很快就会被遗忘，所以为了在需要的时候找到合适的内容，就需要在平时的阅读时记录笔记，留下索引，必要时再根据笔记索引的关键词去搜索。
+
+经过了编程强大且反复的逻辑训练后，对于你、我写作而言，逻辑结构的设计就不该有障碍了，其实最大的差异与障碍可能是在 “实现” 上。
+
+## 三、实现
+
+写文字和编码在实现层面最大的差异是：实现过程的技能和要求不同。
+
+在实现技能层面，程序是用计算机语言来表达的，文字是用自然语言来表达的。计算机语言的逻辑性和精确表达能力要比自然语言强得多，自然语言是模糊的、混沌的、不精确的。因此写得一手好程序的人，不一定能写得一手好文字，因为他们需要驾驭的语言的特性完全不同。
+
+刚开始写文章时，即使自然语言我们从小就学会了，也能熟练使用，但用它写起文章来也会有一种磕磕碰碰的感觉。就好像刚学写程序时，好不容易才能编译通过，也是磕磕碰碰的。
+
+对于编码，编译通过的程序才算刚刚开了头，接着还会进行程序的调测，有时还会优化重构。对于写文字也需要类似的过程，毕竟一气呵成地写出一篇完美的文章，就像是个不可实现的传说。其中，代码重构中的重命名、分拆过长的函数等，就类似于对文章重新进行文字的遣词造句、润色打磨、段落分界等过程。
+
+另外，之于编程和写作，不同的技能应用水平，实现效果就完全不同了。写过程序的都知道同样的架构设计，选择不同的语言、框架、算法和数据结构来实现，实现的技能水平要求可谓千差万别。而同样主题和逻辑结构的文章，不同文字技能水平的作者来写，高下立见。
+
+比如，网络小说兴起之后，我也看过一些，对男主角人物的描写，多是男神化。用词无非，帅则温润如玉、玉树临风；正则气宇轩航、丰神俊朗。但太过正的角色还不行，又会加点邪气，如狂浪不羁等描述，这样更讨读者喜欢。再对比下金庸是如何描述类似这样的人物的：
+
+> 
+这本来面目一露，但见他形相清癯，丰姿隽爽，萧疏轩举，湛然若神。
+
+
+短短四组词，一个身形清瘦、风度俊爽、洒脱轩昂、目光有神却又透出一股子高处不胜寒的人物——黄老邪——就跃然纸上了。金庸用词简练而韵味深长，境界高下立判。这就是文字技能的应用水平了，就像武功招式。金庸在文字上浸淫多年，随手用出一招，自是比普通人精妙许多。
+
+写程序和写文章，本是两种不同的 “武功”，“心法” 可以类似，但 “招式” 自不相同。而 “招式” 的积累与应用，无论写程序还是写文字，都没有什么捷径可走，只能多看、多写、多练。
+
+除此之外，写程序和写文字的实现过程的环境要求也有类似之处：程序员写代码的时候很讨厌被人打断，需要一段能安静且专注的时间，通常2～4 小时不等。写作也一样。所以，我经常选择在晚上夜深人静的时候进行写作的 “实现” 阶段。
+
+这一点，不仅程序员是这样，很多知名作家也都有自己独特的写作过程要求，他们的共性都是需要一段能实现不被打扰且专注的时间。
+
+村上春树，当他进入创作小说的写作模式时，他通常早晨 4 点起床，连续写作 5 到 6 个小时，然后会去跑上 10 公里或游 1500 米（或者二者都有）。下午就不再写作，而是读点东西，听听音乐，晚上 9 点便上床睡觉。他日复一日地保持这样的作息时间、这样的重复过程，据称能帮助其进入一种思维的深层状态。
+
+海明威，通常是早晨天一亮就开始动笔。在采访中，他说道：“没有人打扰你，早晨凉爽，有时候冷，你开始工作一写就暖和了。你读一遍你写好了的部分，因为你总是在你知道往下写什么的时候停笔，你写到自己还有活力、知道下面怎样写的时候停笔。”他通常每天只写 500 字，而且喜欢用一只脚站着，采取这种资势，据称可以使他处于一种紧张状态，迫使他尽可能简短地表达自己的思想。
+
+实际上，这些年写作下来，我也尝试了在很多不同的时间段，甚至分多次写完一篇文章。这里没有一定之规，你总会找到适合自己的写作实现方式。在这个过程中，你有一段专注、忘我甚至像是做梦的过程，与自己的思维深处对话。
+
+在这个过程中，你也可能会产生意外的大脑神经元连接，获得一些更高质量的思考，灵光乍现的启发，以及更好的文字表达。
+
+## 四、测试
+
+每次写完一篇文章后，就感觉自己好像是被清空了，甚至不再想去读一遍，这时我就会把它“扔”在一边。
+
+写作的过程中，大脑从冷的状态逐步升温，直到进入一种很热的状态，文字就是在这样的状态下自然流淌出来的。直到写完之前，大脑一直在高速运作，就像一颗 100% 利用率的 CPU，它的温度很高。写完后，CPU 终于降低了负载，但温度的降低还需要一个过程。
+
+而对写完的文字再读一遍，进行再编辑和优化，这就像软件开发中的测试过程。但我需要在一个冷却的状态下进行，站在一个读者或编者的视角去重新审视这篇文章。所以，这个过程通常发生在写作完成后的一天或几天之后。这中间的间隔，我称之为写作后的冷却时间。只有在冷却的状态下，我才能更客观地检视自己写的文字，同时进行合适地编辑和修改，这个过程就是对文字的测试。
+
+作为程序员，其实我并不喜欢做太多的测试工作，所以在以前我写作完，只是“履行”最简单的文字测试内容：必要的错别字、用词理解性和语句流畅性检查。和 “极客时间” 合作写专栏就给配备了专业的编辑，编辑主要会从下面几个方面进行测试或检查。
+
+- 文词使用：进一步发现有时作者自己很难发现的错别字和用词的适当性、理解性问题；
+- 逻辑结构：整体文字内容的逻辑结构，衔接过渡是否自然等；
+- 读者感受：站在读者的角度，去考虑其感受以及能够得到的收获；
+- ……
+
+这就是关于文字的测试，就像一个好的测试总是能帮助开发者得到一个更好的软件一样，一个好的编辑也总是能帮助原作者形成更好的文字输出。
+
+## 五、交付
+
+完成了必要的编辑测试工作后，就到了最终的交付（发布）阶段。
+
+写作本身是一个不断积累压力的过程，而交付之后则完成了一种压力的释放与转换。关于这一点，和菜头描述得特别精确：
+
+> 
+写作真正的压力来自于完成一件事情的压力，你要么一开始连个标题都想不出来，要么写两段之后就不知道如何继续下去。写第一篇文章会是一次漫长而痛苦的自我挣扎，你大概有 30% 的精力花在构思内容上，剩下 70% 的精力花在自我怀疑和自我否定上。
+
+
+而交付，就是发布这篇新写的文字，让它面对读者，获得反馈与验证价值。
+
+交付一篇新的文字，就像是往这个互联网的文字海洋中扔下一滴水珠，偶尔也会激起几丝涟漪。时有读者留言、评论，或有赞，或有踩，而从作者的角度出发，交付的目的之一是希望有一些更有价值、值得思考和讨论的声音出现。
+
+**写作与文字的价值实现分两部分，写完后就完成了对自我的价值实现，而交付后才算完成了对他人的价值实现。**
+
+当你把写作拆解成了类似编码的过程，也许阻碍你写作的障碍与阻力也就变得没那么大了。如果你能编写清晰有效的代码，也就应该能写出主题结构清晰的文字。至于一开始文字的好坏，技巧的高明与否，反而并不重要，在持续写的过程中，它们会自然而然地得到提升。
+
+方法有了，还需要找到写作的源动力，而大部分作者的源动力都来自于一颗想要表达的心；再配合一部分外部的激励机制，和相应的自律约束，才有可能持续地写下去。
+
+最后，多说一句，极客时间上的留言质量很多都不错，如果你还没有开始写点东西，不妨从留言开始记录一些你的思考和观点，留下价值。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/31 | 画图：一图胜千言.md

@@ -0,0 +1,91 @@
+<audio id="audio" title="31 | 画图：一图胜千言" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b4/07/b4a95fcdd1a38f12cc6a16d6eb690c07.mp3"></audio>
+
+对于写作这种展现形式，有一种最好的补充手段就是画图。有时文字描述了半天还不如一张图来得清晰，正所谓：一图胜千言。这对于程序员特别需要的技术性文档或文章写作，都是最好的补充注解，有时甚至起到了画龙点睛的效果。
+
+以前我在网上发一些技术博文，就常有读者留言问我是用什么工具画图的。其实我感觉他们很可能问错了问题，因为我曾经为了画好图尝试过各种不同的画图工具软件，但最后发现能不能画好图和工具的关系并不大。
+
+## 一、为何？
+
+程序员不是主要写代码的么，为什么需要画图？
+
+有些程序员会认为写好代码就好，画好图有什么用？程序员成为架构师后是不是就天天画架构图，成为了所谓的 PPT 架构师？曾经读过一篇文章《在首席架构师眼里，架构的本质是…》，里面提出了一个架构师能力模型图，（我重新绘制）如下：
+
+<img src="https://static001.geekbang.org/resource/image/4c/2d/4cd5ab238644a71832e0baf21cf88a2d.png" alt="" />
+
+结合我自己的经历和经验，这个能力模型针对架构师这个岗位来说还是比较符合的。程序员出色到了一定程度后想成长为一名架构师，就需要看看能力模型中的其他方面。而掌握好画图技法，对这个能力模型有什么帮助吗？
+
+前面讲系统设计的文章《多维与视图》中我已经给出过结论：“用更系统化的视图去观察和思考，想必也会让你得到更成体系化的系统设计。”
+
+在今天这个时代，我们都体验过各种各样的地图软件，一个国家，一个城市，一个街区，地图软件总是在不同的抽象维度上来展示地图。而对于一个复杂的软件系统，也需要类似的不同抽象维度：系统的全貌、不同子系统间的关联和交互、子系统内部模块间的接口和调用、某个关键实现点的处理流程等。一个架构师应该可以在这些不同的抽象维度上把系统或系统的一部分清晰地描绘出来。
+
+而画图对于能力模型中的 “抽象思维” 就起到了一种锻炼，其作用就是帮助你在不同的层次上去思考系统设计，并具象化这个设计。既然具象化了设计，那么再基于此去沟通交流自是事半功倍。成为架构师之后，你自己明白还不是主要的，要让别人明白才更重要。
+
+此外，站在一个多层次、全方位的系统架构图面前，在不同抽象维度上描绘了系统的各个重要方面，想必更容易看到问题的本质，也能更好地发现和找到系统的症结。如果解决系统的问题就像走迷宫，那么你是直接钻进去反复尝试寻找出路，还是站在更高的维度去俯视迷宫然后再找最佳的问题解决路径呢？
+
+想必在更宏观和全局的视野下，与系统所有相关人员进行清晰准确地交流，直击问题本质，那么再进行正确而适当的技术决策与平衡取舍也没那么难了，对吧？至于 “多领域知识” 和 “技术前瞻性” 这两方面好像确实和画图的关联性不强，但如果“多领域知识”不限于程序技术领域，那画图也算一个领域的知识吧。
+
+## 二、如何？
+
+上一节探讨了画好图有什么益处，这一节我们看下如何画好图？画一个清晰易懂的技术架构或交互流程的说明图例需要什么专门的绘图知识与技巧么？另外为了画好图会花费大量的时间么？
+
+过去几年在关于如何画好图这个课题上，我做了好些摸索和实践，想取得效率（即，画图花费的时间不会比用文字来描述同样的内容更多）和效果（即，图例表达的效果应该比文字描述更好）的平衡，在这个过程中我收获了下面一些基本认知和感觉还不错的实践方式。
+
+### 1. 图形
+
+我画技术图例时只会使用一些最基础的图形，比如：矩形、圆、三角、菱形、气泡、箭头，这些最基本的图形几乎所有的画图软件都会自带的，所以工具的依赖性很低，但真正画时的操作效率却又很高。
+
+当然，一些著名外部系统可能都有各自知名的 Logo 图标，如果有时为了表达和这些著名外部系统间的交互，也会直接使用它们的 Logo 图标。如下面图示，就是我常用的一些画图图形元素。
+
+<img src="https://static001.geekbang.org/resource/image/d1/87/d185ac94f095444616dc702fae72c087.png" alt="" />
+
+### 2. 颜色
+
+有时系统的组成比较复杂，只用基本图形不足以表达所有不同的系统组成部件，这时就需要用颜色来区分了。
+
+那么下一个问题就来了，该用哪些颜色呢？我的答案是使用大部分人觉得美的颜色。那大部分人觉得美的颜色是什么呢？彩虹色，当然这一点也我没有做过专门调查，只是凭经验得来。所以我一般用的颜色就是彩虹七色，外加两种经典色：黑、白。这样就有九种颜色加上好几种基本图形，可以组合出几十种表达不同组件的图形元素，基本也就够用了。
+
+彩虹七色包括：红、橙、黄、绿、青、蓝、紫。但七种颜色的选择也是有优先级，在一本讲设计的书中 Designing with the Mind in Mind（中文译本《认知与设计》）提出了下面一些色彩使用准则：
+
+- **使用饱和度、亮度以及色相区分颜色，确保颜色的高反差**，因为人的视觉是为边缘反差而优化的。
+- **使用独特的颜色**，因为人最容易区分的颜色包括：红、绿、黄、蓝、白和黑。
+- **避免使用色盲无法区分的颜色对**，比如：深红－黑，深红－深绿，蓝色－紫色，浅绿－白色。
+- **使用颜色之外的其他提示**，对有颜色视觉障碍的人友好，而且也增强了可理解性。
+- **避免强烈的对抗色**，比如：红黑，黄黑。
+
+以你看为什么交通灯是：红、黄、绿？为什么乔布斯选择这三个颜色作为 Mac 操作系统中所有应用窗体的按纽颜色，这也是暗合人类的视觉认知原则的。所以我现在多选择的是白底、黑字、黑色线条，色块优先选择红、绿、黄、蓝，实在不够用了才会选择橙、青、紫。
+
+当然红有好多种红，绿有好多种绿，该用哪种呢？看下图所示，给出了 RGB 三原色的配色数值，这属于个人偏好，在 Mac 的显示器下看起来很舒服。但若用在其他场合，比如投影什么的，就可能需要根据投影实际效果进行微调了。
+
+<img src="https://static001.geekbang.org/resource/image/f3/c0/f3c5d15b7ad9162e6277a797258c0ac0.png" alt="" />
+
+### 3. 审美
+
+除了基本的图形和颜色选择之外，另外一个关注点是审美。
+
+审美对最终的效果呈现有很大影响，这得感谢苹果总设计师乔纳森·伊夫（Jonathan Ive）把大众的审美倾向全部带入到扁平化时代，所以实际中我只需要把图形弄得扁平，去掉立体、阴影什么的，看起来就还不错了。毕竟我们画的是系统设计图，不是美术设计稿，审美方面的追求就适可而止了。
+
+<img src="https://static001.geekbang.org/resource/image/2d/56/2d227bb1042dfa64dd9d6eef23c1a856.png" alt="" />
+
+## 三、几何？
+
+探讨了如何，我们再接着看看几何。此 “几何” 不是数学里的几何，而是掌握画图技法到底代价几何？又价值几何呢？
+
+好些年前了，我画的技术图示（来自以前的一个分享 PPT）大概是下面这样的，总是觉得不好，不太满意，却又不知道不好在哪里，以及该怎么改进。然后就归咎于工具不好用，从一开始用 Viso 画，后来尝试了 Mac 下的专业绘图工具 OmniGraffle，觉得太复杂，后又找到个在线绘图网站 [draw.io](http://draw.io)，感觉还可以，但由于是国外网站，访问效率不太好，没多久就又放弃了。
+
+<img src="https://static001.geekbang.org/resource/image/d0/64/d0b835a8ca5f088241c564cb76db6d64.png" alt="" />
+
+之后需要做一些胶片演示时，用了 Mac 下的 Keynote（相当于 Windows 下的 PPT），需要画技术图示时想如果直接在 Keynote 里画最省事了，然后就开始用 Keynote 画了。按 “如何” 一节的指导原则，我重新画了下上面那个技术图示，如下：
+
+<img src="https://static001.geekbang.org/resource/image/c5/65/c527abb098dbc1a6bac04057e4643165.png" alt="" />
+
+这花费的时间绝对不会比画上面那个多，但呈现出的效果却要好很多。所以，学会使用一种简单的软件，使用简单的图形和配色，在最有效率的情况下画出一幅效果还不错的图例，也是很有价值的。
+
+当然你可能会认为只有写出的代码才有价值，其实这里你可能忽视了一个大部分程序员都认同的观点：代码也是写给人看的。程序员不会认为一份机器能运行而人很难看懂的代码是好代码，而画好图就能更好地帮助你去思考代码的组织和呈现方式。
+
+曾经问我关于画图工具的人，我知道他们差的不是一个画图工具，而是对于 “画图” 本身的思维认知与技法打磨。所以在本文我分享了我近些年一直在使用的一种极简绘制技术图例的技法，毕竟我们画图只是为了追求讲清楚一个技术方案或展示一个系统，而不需要考虑任何多余的艺术性。
+
+最低的代价，还不错的效果，在效率和效果之间取得性价比最高的平衡。曾几何时，你想象中很麻烦的事原来也可以如此简单。
+
+关于展现的第二种形式：画图，今天的分享就到这里。你平时是如何画技术图示的？在用什么工具？欢迎你在留言区和大家分享分享。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/32 | 演讲：表达的技术.md

@@ -0,0 +1,113 @@
+<audio id="audio" title="32 | 演讲：表达的技术" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a4/f7/a42efc15caea1b6afada163431f919f7.mp3"></audio>
+
+展现的另一种形式是：**演讲**。其实作为程序员出身的我，演讲水平非常有限，但在职业发展与成长的道路上，演讲却是必经之路。所以，我确实有比较系统地思考和琢磨过演讲的价值、效果以及提升的方法，现在我将其分享给你，希望能对你的成长或者职业道路有所帮助。
+
+## 一、价值与效果
+
+写作的展现，是一种广度路线，产生间接、长尾效应；演讲的展现，是一种深度路线，产生直接、深度连接。
+
+为什么说写作是广度而演讲是深度的？过去几年，我读过很多的文章、书，但还能记得住只言片语的都非常少。即使当时一些给我非常多启发与触动的文字，如今也只能记得当时触动的感觉，却忘了触动的内容。但好些年前，我参加过几次行业大会，有那么几场演讲，现在回想起来，不仅记得当时深受启发的触动感，甚至还能记得当时的内容。
+
+这就是演讲带来的深度效应，它的现场感更立体，有助于留下更深刻的记忆，持续发挥影响的时间也超过了文字。
+
+演讲的现场立体感带来的深度效应，也只能留在现场。即使我们把整个演讲过程录制成为视频，观看视频的过程也会损失很大一部分深度影响力，也许这就是为什么有人会去看现场演唱会的原因。
+
+所以，演讲的最大价值就在于这样的深度效应。但现场感并不一定带来深度影响，也可能是把人 “催眠” 了。那如何发挥好演讲的效果呢？这里我就先谈谈我自己的一些经历和感悟。
+
+## 二、经历与感悟
+
+成长路上，终究会遇上演讲；从没遇上演讲的程序员，可能天花板就会比较低。
+
+作为程序员，我的第一次演讲经历，当然是技术分享，团队内部的。如今回想，第一次分享暴露出了很多方面的问题。比如，材料准备时发现 PPT 技能太差，想展现的内容做出来的效果太挫；现场讲的时候容易跑偏或者陷入细节，整体节奏失控；想表达的内容太多，信息量过大。这些问题都导致第一次演讲的效果不尽如人意。
+
+后来再有技术分享的机会时，我已经开始写作了一段时间，发现写作实际对演讲是有帮助的。写作和演讲的共通处在于：内容、观点、信息传递的目标都是要考虑的，只是最终的表达形式不同。而且因为写了不少东西，也反而获得了更多的技术分享机会。
+
+从业这么些年，经历了从线上到线下，从组内到部门，然后再到公司或行业级的不同规模的分享演讲，挑战并不一样，其中最大的区别在于现场感的压力不同。而且除了分享式的演讲，还有另外一种汇报式的演讲，如：晋升述职。
+
+技术分享，一般时间会长一些（一小时左右），而晋升述职，时间则要短很多（十分钟左右）。前者的压力来自对象的规模，后者的压力来自对象的角色。
+
+而不同时长的演讲，准备的方式也不太一样。时间长的演讲，准备的内容就多，要精确地讲好这么多内容是一个挑战；而时间短的演讲，内容不多，但就需要合适地挑选和裁剪，并且精确地传递，这又是另外一种挑战。
+
+那对于不同的演讲类型，有通用的准备方法吗？下面我们尝试梳理下。
+
+## 三、准备与发挥
+
+一场演讲，包括前期准备和现场发挥两个阶段，而前期充分的准备是现场良好发挥的基础。
+
+世界上有一个著名的演讲论坛 TED，它上面的演讲，即使仅仅是视频，很多都给人留下了深刻的印象，而且传播范围也很广。它的演讲者通常是一些知名人士或至少是业内影响力比较大的人物。
+
+我一开始以为他们本身就已经是很好的演讲者了，但后来了解到他们为了参加 TED 短短十来分钟的演讲，需要全力以赴地投入以周为单位的时间。比如，《哈利波特》的作者罗琳去 TED 演讲时，为此全心投入准备了整整六周。
+
+那前期可以准备的内容有哪些？我梳理了有如下维度：
+
+### 1. 框架
+
+演讲的框架和程序的架构有点类似，一般我都从下面几个方面来设计：
+
+- **目标**：本次演讲需要达成的目标是什么？
+- **听众**：本次演讲的受众是哪些人？
+- **重点**：本次演讲要传递的关键点有哪些？
+
+那么一场技术分享的框架线，可能有如下：
+
+- **引出主题**：结合目标与听众来确定。
+- **自我介绍**：让听众了解你，证明你有资格讲这个主题。
+<li>**重点结构**：每一个关键点的分析、讲解，可以从以下方面来拆解。
+<ul>
+- 问题：这个点上存在什么问题？
+- 历史：这个问题的历史由来是什么？
+- 方法：你是用什么方法解决这个问题的？
+- 原因：为什么要用这个方法，要在这个阶段，以及这样解决问题？
+
+### 2. 材料
+
+在框架线清晰后，就进入了演讲材料的准备阶段。其中的材料包括三类：
+
+**第一类是幻灯片**。到底要准备多少页的幻灯片？这个取决于框架线和演讲时长。但这里幻灯片的最大作用在于：
+
+- 辅助演讲者的结构记忆与信息表达；
+- 辅助听众的信息吸收、理解与消化。
+
+也就是说，演讲的主角还是讲，而幻灯片仅仅是配角。
+
+**第二类是演讲稿**。讲之前你可以先写下来你所要讲的内容，这样会有助于组织信息、梳理逻辑和提炼语言。
+
+TED 的演讲以前多是18分钟，而现在分长、短两种：短的约6分多钟，长的也缩减到了12～15分钟。在信息爆炸的时代，听众的注意力是一种稀缺资源，想要吸引这样的注意力，就需要提供更精确且直击人心的内容，才能收获你想要的深度影响效果。
+
+我们的正常语速大约是每分钟150～200个汉字，但在演讲的压力环境下，可能会出现不自觉地加速，无意识地跑偏，甚至语无伦次。如果想要提供更精确的信息传递和表达，那么演讲稿就是必需的。
+
+让演讲的每一个字，都体现它的价值。
+
+**第三类是小故事**。人是情感动物，故事的影响效应远高于数据和逻辑，即使是在做技术分享时。
+
+以前听过一些技术分享感觉比较枯燥、催眠，就在于技术基本都在讲逻辑、讲数据，听久了自然疲劳。而穿插一些 “小” 故事，则可以加深前面数据和逻辑的影响效应。这一点很多慈善募捐组织早就学会了，再大比例的穷困数据，也比不上一张衣不蔽体的小女孩照片来得有效。
+
+### 3. 节奏
+
+一段持续时间的演讲中，有没有一些关键的时间点呢？当然是有的。
+
+**一个是开场**。据研究统计，一场演讲给人留下的印象和评价，开场的数秒至关重要。这可能和一开始是否能抓住听众的注意力有关。
+
+**另一个是峰终**。管理界有一个 “峰终定律（Peak-End Rule）”：在 “峰” 和 “终” 时的体验，主宰了对一段体验好或者不好的感受，而在过程中好或不好体验的比重、时间长短，对记忆的感觉差不多没有影响。也就是说，如果在一段体验的高峰和结尾，你的体验是愉悦的，那么你对整个体验的感受就是愉悦的，即使这次体验总体来看，更多是无聊和乏味的时刻。
+
+峰终定律，在管理上决定了用户体验的资源投入分布，只需要重点投入设计好 “峰终” 体验。而演讲，也是一门体验艺术，它的 “峰” 前面说了一处——开场（抓注意力）；另一处，可能是中间某一处关键点（提供独特的高价值内容或观点）。
+
+### 4. 表演
+
+演讲，包括讲和演，因而还有最后一个准备环节：演。
+
+演，即表演和发挥；表演的准备，有三个层级，如下图（原图来自 Tim Urban’s Memorization Spectrum，翻译后重绘制）：即兴发挥、框架内发挥和严格遵从剧本。
+
+<img src="https://static001.geekbang.org/resource/image/f2/e0/f25fe75fa3dfe192c01cf7b82f15d7e0.png" alt="" />
+
+做了前述准备的演讲，算是在框架内发挥。如果还准备了演讲稿，那么练习熟练后，基本算是接近了 3A 这个层级，但演讲稿，还算不上是剧本，所以只是接近。按 3 这个层级的准备，是把演讲当作了一出舞台剧，有严格的剧本，需要经过反复地排演练习。
+
+这样的准备投入是巨大的，所以你一般需要判断到底多么重要的演讲，才需要用上 3 这个层级的准备。但即使达不到 3 级的标准，按这个标准来准备也有好处，当你非常熟练了你想要精确表达的内容，在现场发挥时，你的大脑就会从记忆负担中腾出空间来应对临场那些很难提前准备的状况。
+
+“演” 需要关注和练习的东西比 “讲” 多得多，而且表演本身就是一种专业，甚至也是一种天赋。这条路上，你可以先有一个清晰的认知，但能做到何种程度，可能因人而异吧。
+
+演讲，本是表达的艺术，但对程序员的要求远没到艺术的层次；先能表达，再求精确，技术达标，足矣。
+
+关于展现的第三种形式：演讲，就分享到这了；而演讲也是很多程序员的一道槛，如今的你遇到这道槛没？欢迎你留言分享。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/33 | 定义：阶梯与级别.md

@@ -0,0 +1,90 @@
+<audio id="audio" title="33 | 定义：阶梯与级别" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/5f/6f/5fdeb13f8e3a9177add02cd854cca26f.mp3"></audio>
+
+从今天开始，咱们专栏会开启一个大家可能都比较感兴趣的主题：**程序员的职场阶梯，以及攀登阶梯的晋升博弈**。
+
+任何种类的职场上升通道都是一个阶梯，但程序员的阶梯有何不同呢？
+
+在程序员职业生涯的发展过程中，都会经历一个修炼成长、打怪升级的过程，而每个公司可能都会定义自己的升级阶梯。以 AT 为首的两大巨头，其对技术人员的级别定义在互联网业界比较公开。例如，阿里的程序员级别从 P4 到 P14，而腾讯则定义了五个大级别：从T1到T5，并且T4之前的级别内部还会细分为若干小级别。
+
+相对来说，腾讯的 5 个大级别与我自己一路走来经历的几个阶段感觉会比较匹配一些，而大级别之间的分界线也会更明显一些。我对升级阶梯的定义也是 5 个：初级、中级、高级、资深和专家。
+
+至于对不同级别的定义，我选择了三个相对容易判断的维度：
+
+- 具备什么能力？
+- 解决什么问题？
+- 产生多大影响？
+
+## 初级
+
+初级，多属于刚入职场的新人。
+
+一般刚从学校毕业的同学，具备基本的专业技能和素养，能快速学习公司要求的常用开发技术、工具和框架，能理解所在的业务和产品领域，并按照设计要求来实现功能。他们通常都工作在系统中局部某个区域内，能独立或在有限指导下实现功能并解决该模块碰到的具体问题。
+
+这个级别基本完成的都是螺丝钉级别的工作，影响很有限。但如果从这个阶段你就开始定期归纳总结这些局部的工作经验，不断优化工作内容，并能在团队小组内部做出分享，甚至帮助其他同学解决问题，那就说明你已经走上了一条快速成长的通道。
+
+刚入职场的同学，有本科，有硕士，还有博士，这有区别嘛？我个人感觉本科和硕士进入职场相差不大。当年我是硕士毕业，进入第一家公司算初级，本科算助理工程师，有一个小级别的差异，而薪酬待遇则相差无几。
+
+那时腾讯也来学校宣讲，本科年薪 6 万，硕士 8 万，而博士 10 万。仅仅从年收入差距来看，读硕、读博似乎不是个划算的选择，可恰恰很多人选择读硕就是为了能有一个更好的工作起点，而选择的标准也可能恰恰就是薪酬占据主导方面，这貌似是一个误区。
+
+以前看过一期《奇葩说》，一个清华男从本科读到博士，跑去节目上说了半天就是为找什么工作而苦恼，惹得同为清华毕业的高晓松当场发飙，而同为点评嘉宾的蔡康永也说了句很中肯的“实在话”：
+
+> 
+一直花时间求学，也许是为了拖延人生做决定的时间。
+
+
+## 中级
+
+中级，相对初级最大的质变在于：独立性。
+
+初级同学经过两三年工作历练，对实现各种业务功能、开发规范流程都很熟练了，摆脱了对基本指导的依赖性，这时就进入了中级阶段。中级工程师已经能够独立承担开发任务，设计实现他们负责的系统模块，以及通过搜集有效信息、资料和汲取过往经验来解决自己工作范围内遇到的问题。
+
+中级这个层面的基本要求就是：**完成动作、达成品质和优化效率**，属于公司 “动作执行” 层面的中坚力量。观察下来，这个级别的工程师多数都能做到完成，但品质可能有瑕疵，效率上甚至也有很多无效耗散。不过，效率和品质总是在不断的迭代中去完善，自身也会在这个过程中不断成长并向着下一个阶梯迈进。
+
+不少同学卡在这一阶段，就是因为虽然不断在完成工作，但却没有去反思、沉淀、迭代并改进，从而导致自己一直停留在了不断的重复中。所以，在工作中要保持迭代与改进，并把你的经验分享给新来的初级同学，这样在未来之路你不仅会走得更快，而且也可能走得更轻松。
+
+## 高级
+
+高级，不仅要能独立完成工作，还要能独立负责。他们能独立负责一个大系统中的子系统或服务，并成为团队骨干或最重要的个人贡献者。
+
+相比于中级，高级工程师在 “动作执行” 层面，不仅能独立完成高级难度的开发任务，而且在用户体验（品质提升）和性能优化（优化效率）方面还都能做出更全面的考量。也就是说，他们不仅仅可以把开发任务完成得又快又好，而且还能清晰地定义出多快、多好。比如，一个服务的响应时间 99.9% 是在 20 毫秒内，内存消耗最大不超过 1G，并发吞吐量 10000+/s，类似能用清晰的数据来定义服务品质和效率。
+
+另外，高级别需要面对的问题就不再是单一维度的技术问题了，他们需要结合业务特性去考虑设计合理的解决方案。熟悉业务领域内的应用系统架构以及各个部分使用的技术，能根据业务特性，合理进行分层设计，实现高效率、低成本的运维或运营。
+
+初、中级别的能力提升与影响输出是通过经验的归纳总结与分享，那么高级则需要在经验这种偏个体特性的基础上，再进行抽象提炼，沉淀方法论。换言之，通过个人的经验，研究行业的优秀实践，再结合自身实践和逻辑推导，沉淀出切合现实的方法论，并在团队内部推广应用。
+
+## 资深
+
+资深，有深度和资历（即广度）两个层面，对应到职业生涯路线上，也有两个方向。
+
+- 资深工程师
+- 架构师
+
+在偏基础研发、算法和特定技术复杂领域，会向 “资深工程师” 方向发展，属于深度优先。而在面向业务开发的领域，业务复杂度高于技术复杂度，则会向 “架构师” 方向发展，属于广度优先。
+
+但无论深度还是广度，进入这个级别即说明你在特定领域都已经具备了相当的积累。这时你是作为相关领域的专家，深度参与和支持团队项目，在领域内进行关键的技术判断和决策，进而帮助团队项目或产品加速成功。在这个层次上，你面临的都是一些更复杂的、具备一些灰度（不是非此即彼，而是需要折中权衡）特性的问题，这时就需要你能够全方位、多层次、多角度地深入理解问题，评估每种方案的收益、成本和潜在未来的长短期影响等。
+
+这个层次的影响方面，除了经验分享和方法论沉淀，还有**产品**和**团队**两个考虑维度：即使是做纯技术的东西，最终的影响也是通过技术产品来完成的；而另一方面则是团队的梯队建设、结构调整与协作优化，决定了团队外在表现。这两个维度，前者可能资深方向侧重多一些，后者则是架构师方向需要侧重思考实践的。
+
+## 专家
+
+专家，表明了某种领域的明确建立。
+
+也许架构师和资深工程师也具备在特定细分技术领域的深厚积累，说明他们和专家一样也有属于自己的领域，但这个领域还不算明确建立，它还需要有公认的影响力。公认影响力实际指一个范围，如果是公司的技术专家，那么范围就是公司或行业。
+
+虽然以 “家” 冠名会让人感觉太高不可攀，遥不可及，但实际 “家” 也分大小：一般的 “大家” 可能属于稀世珍宝，举国稀有的，确实是遥不可及；但也有 “小家” ，相对来说就没那么遥远了。“大家”和“小家”的区别，就在于影响建立的范围大小。
+
+影响力听起来可能很虚，那我换个相对实的角度来说说。作为一个 Java 程序员，在学习使用 Java 的过程中总有那么几个人，你不仅要去读他们的书还要去看并且使用他们写的代码，反正在 Java 这个领域你总是绕不过去。那么，这就是他们在这个领域实实在在的影响力，自然也是这个领域的专家。所以，专家可能就是“这个领域内你绕不过去的人”吧。
+
+积累多年，建立体系，形成领域，他们需要解决的最重要的问题是：面向未来不确定的战略问题。这就像机器学习用过去长期积累的数据，建立起一个模型，用来预测和判断未来。未来不可测，但建立好了一个领域体系后，当未来到来时，就可以很快地将新出现的信息加入到现有的领域体系中去，从而修正模型，做出快速地调整与决策。
+
+最后，我借用鲁迅在《故乡》里说的一句名言：
+
+> 
+其实地上本没有路，走的人多了，也便成了路。
+
+
+前面定义出来的阶梯就是那很多人已经走过的路。不管现在走到了哪个阶段，我们都走在同样的路上，但会遇见自己不同的风景。
+
+在你攀登职场阶梯的路上，你走到了哪一级？对每级阶梯有怎样的理解呢？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/34 | 晋升：评定与博弈.md

@@ -0,0 +1,93 @@
+<audio id="audio" title="34 | 晋升：评定与博弈" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ab/39/abf39e52baae31310acc336b11e35d39.mp3"></audio>
+
+一般来说，公司到了一定规模都会形成自己的职场阶梯，程序员在攀登这条阶梯时，肯定会涉及到一个评定的过程。那从评定者的角度，或者晋升者的角度，该如何看待你在阶梯上的位置呢？
+
+晋升的结果和个人利益有直接的绑定关系，而且这个过程从来都不是一个简单的是和否的选择，那你该如何看待这个“不简单”的晋升过程呢？
+
+## 标准维度
+
+先站在评定者的角度，假设你作为一名评委，你会如何去评定？又有怎样的标准呢？
+
+技术晋升评定是依赖人的判断，本是非常主观的一个过程，但为了规避这种过于“拍脑袋”的主观性，就需要去制定标准。制定标准的初衷也是为了给评定过程增加客观性，将人的主观判断约束在一定的客观范围内。
+
+这让我想起了奥运会的一些打分和结果具有主观特性的项目，比如：跳水。这样的项目不像跑步、球类等有非常客观的得分标准，打分还是靠人。但跳水项目，也有一些客观的标准，如：动作代码、动作姿势和难度系数。分解出了一些客观标准后，这样对于运动员完成情况的评判相对就会更容易形成一些共识判断。
+
+我在参考了一些行业里大公司的晋升和技术素质模型，并结合当时团队的具体现状，制定了出了一些标准维度：
+
+- 通用能力，包括学习能力、沟通能力和领导能力等；
+- 业务能力，包括业务理解和领域建模等；
+- 技术能力，包括深度、广度和技能应用等；
+- 影响力，如知识总结、知识传承和人才培养。
+
+除以上 4 个大维度外，还有一项 “工作业绩” ，不属于现场技术评定的维度，直接来源于过去一年的工作业绩评价。每个大维度会占据一定的比重，然后可以针对每个大维度去打分。
+
+曾经我在早期的实践过程中犯过一个错误，就是想在小维度上去打分，感觉这样可能会更准确。但经过一次实际操作后，发现很难在短短的晋升述职过程中去仔细判定这么多细分的维度，这对评定者会产生很高强度的判断疲劳，最后反而更可能产生更大的判定误差。后来在一本解读大脑工作原理的书上了解到，人的大脑一般只能同时记住和判断 4 到 5 个并行任务。过于细分的维度，会让人的大脑负担不过来。
+
+虽然有了客观的标准维度去细分判断，但人打分在细微之处依然会有主观的偏好。还是以跳水运动为例，郭晶晶和一个新秀一起参加国际大赛，她们跳同样的难度，同样的组别动作，并完成得同样好，但最后可能郭晶晶会得分高一点（我印象中有届奥运会上就出现过），这就是人主观评判的细微之处了。
+
+## 过程识别
+
+晋升识别过程是一条链路，而技术标准评定只是其中的一个环节。
+
+晋升过程启动一般由 HR 部门驱动发起，经过各个部门直属领导提报候选人，再经由技术委员会进行专业线评定，再去到管理层复议，最后又回到 HR 部门最终确定。这个过程是一条过滤器链路，有没有感觉像是编程中的责任链模式？
+
+第一个环节，HR 部门的责任是对提报候选人进行晋升资格确认，比如是否满足上一级别或岗位要求的工作年限，是否存在公司行政处分导致失去资格等；第二个环节，部门从满足资格的员工中进行提报，部门的作用是对提报员工过去一年在本部门工作绩效的认可；第三个环节，就进入了技术委员会组织的专业线技术评定，而通过技术标准评定后，是对其专业综合能力的认可。
+
+最后，就进入到管理层复议环节，这个环节会有一个冲突点存在。奥运会的跳水运动员，不管你得了多么突破历史记录的高分，但奖牌却只有 3 个；同样，公司每年的晋升名额也是有限的。一般公司每年的晋升名额都会有一个比例限制，这是出于控制成本与优化人才结构的考虑，因而经过前面的环节，最后到达这里的人数可能多于这个名额。所以，管理层复议其实就是对最后多出来的人数，综合考虑整体和局部的利益，进行调节筛选。
+
+了解了评定的标准和过程，就可以反过来站在晋升者的角度想想，如何才能更有效地被识别出来？
+
+晋升述职过程仅仅只有 10 到 20 分钟，即使采用了前面所述的标准维度，晋升述职者也只能在有限的时间内把过去一、两年的工作成果、能力成长展示在几个点的范围内。这对于评定者来说，就像在管中窥豹了，看不到全貌，看完几个展示的特征点后就需要判断这到底是 “豹子”（符合下一级别的晋升标准）还是 “猫”（不符合）。
+
+我在做晋升评委时，就一直被这样的判断所困扰，多数述职同事都在这几个点上表现得很好。这就像是说，如果是豹子，它确实该有这些特征点，反过来，拥有这些特征点的就一定就是豹子么？这些特征点，是豹子的唯一或足够有区分度的标志性特征吗？
+
+我发现靠 “点” 上的判断，准确度自己其实也完全没把握，后来就想到了一种更好的方式，靠 “域” 的判断。域，即领域，包含了：责任域和能力域。蜘蛛侠里有句台词是这样说的：“能力越大，责任越大（With great power comes great responsibility）”，能力和责任总是相辅相成的。
+
+责任域，就是你负责什么，这个相对容易识别。而能力域则过于抽象，很难清晰识别，在述职这样的形式中，最容易判断的仅仅是表达和沟通能力；至于业务和技术能力，虽不那么容易判断，但好在其有最好的展现形式：作品。
+
+对于程序员，作品可以是一个完整的系统，但其展现不应该是一系列的技术点，而是先有整体（面），再深入局部（点），应该是一个画龙点睛的过程。从这样的展现过程中就能很好地体现出晋升者的业务与技术能力。
+
+识别的过程，本质是在解一个概率问题，当参与这个过程的两方（评定者和晋升者）都这样努力去考虑时，我想这样的过程就会有更高的准确率。
+
+## 博弈权衡
+
+晋升过程因为涉及太多个人的利益，所以评定过程的公平性是所有参与方都关心的问题。
+
+以上过程乍一看还算公平，里面有绝对客观的资格筛查，而对于主观的人为评定也采用了多人制评定方式，分散了个人的好恶影响，并且还由客观标准限定了人为评价范围。但这里面依然存在不公平因素，这个因素就是评定过程本身的形式。
+
+程序员的特点是多擅长和机器打交道，编程能力强于表达能力。而评定的过程是靠述职这种形式，它偏重于表达。若一个完全不擅于表达，而编程和解决问题能力很强的人，在这样的形式下就会吃亏，这就有失公平性。但反过来说，如果要追求一个对所有人绝对的公平方式，那么可操作性和成本可能也没法很好地控制。
+
+以前读过吴军两篇关于讲法律的文章，在传统的理解中法律应该是最在意公平和正义的，但在文章中他提及了几个概念：民意与民义，民力与民利。这四个概念的含义如下：
+
+- 民意：人民的意图；
+- 民义：人民最在乎的公平和正义；
+- 民力：人民让渡给国家和政府维护公平和正义的必要力量；
+- 民利：人民的利益。
+
+吴军在文章中阐述了这些概念代表的内容与法律代表的公平和正义之间的博弈权衡过程，有如下：
+
+> 
+在现代社会中，一切都是有成本的，绝对的正义是不存在的。当给予一部分人正义时，可能要以在其他地方付出巨大的成本为代价。如果一个判决伸张了正义，但是让受害的一方更倒霉，这就违背了司法中关于民利的原则。
+
+
+这让我受到了启发，司法判定和晋升评定有异曲同工之处，都是需要判定一个事情，也都受这四个因素影响而导致博弈权衡。
+
+评定中的 “民意” 来自会参与晋升的员工，及其相关的直属领导和所在部门。而 “民义”，依然是保证公平。但 “民力” 的来源则不同，评定的权力实际来自于组织（公司），而非员工，所以最后的 “民利” 就应该是组织（公司）的整体利益。评定判断实际就是站在授予权力的一方，兼顾公平和利益。
+
+当绝对的公平和利益发生冲突时，法律的判定实际更站在利益一方，符合 “民利” 原则，这就是吴军文中给出的一些观点和启发。那么技术评定中的公平会和组织利益产生冲突吗？什么是更符合组织利益的呢？也许人员和团队的稳定与良性流动是有利于组织利益的，选拔出更能代表组织技术实力的技术人员是更符合组织利益的……
+
+当把这些因素都考虑进来后，真正的评定过程实际就是所有这些因素的博弈并达到平衡。你看，虽然评定的结果只有是或否，但过程却是多种维度的考虑与取舍。
+
+著名管理学家劳伦斯·彼得分析了千百个有关组织中不能胜任的失败实例，归纳出彼得原理：
+
+> 
+在一个等级制度中，每个员工趋向于上升到最终他所不能胜任的职位。
+
+
+晋升的本质是承担更大的责任，而责任和能力是需要匹配的，晋升就是完成这样一种匹配关系的过程。一个公司中的责任域是有限的、发展的、变化的，那你当下具备的能力域是否匹配相应的责任域？你正在学习和开发的新能力域，是否能在组织中匹配上合适的责任域？这才是看待职场阶梯与晋升的正确方式。
+
+保持不断学习和提升能力，找到并承担起合适的责任域，那么后续的晋升并贴上一个相应的职级标签，就是一件自然而然的事情了。
+
+晋升、职场阶梯和级别，更多是一种形式和标签，其实最后更重要的还是自己的成长，你说呢？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/35 | 关系：学徒与导师.md

@@ -0,0 +1,99 @@
+<audio id="audio" title="35 | 关系：学徒与导师" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e7/73/e7636503fe0627bcd93aade5bea19973.mp3"></audio>
+
+现在很多公司都有一种带新人的导师（Mentor）制度，导师制的初衷是为了帮助新员工快速熟悉公司环境，并提供工作技能和个人成长的帮助，正所谓 “传帮带”。
+
+这是用制度建立并约束了一种在新、老员工之间的关系，这本是一个很好的出发点。但想要类似这样的制度关系发挥期望的作用，恐怕就需要 “导师” 和 “学徒” 都有一个更高层次的清晰认知，毕竟制度只能在其中起到催化的作用。
+
+## 起源
+
+导师制诞生于十四世纪，随之带来的是一场翻天覆地的变化。
+
+突然之间，那时的年轻男女们可以用自己最富余的资产——时间，去交换当时最稀缺的资源——培训。在那个时代，经验丰富的手艺人，比如，铁匠、鞋匠、木匠等，他们指导这些年轻人，并承诺将来某天年轻人能学会他们的技能然后去开创属于自己的事业。作为交换，年轻人会提供低成本且廉价的劳动力。
+
+作为学徒，年轻人可能赚不到什么钱，但却能学到关于这门手艺的各种经验和技巧。比如：一个铁匠学徒，能学会或掌握如何去建造高温火炉，组合不同的金属以产生不同熔点的合金混合物，以及制作耙、刀或犁等工作技能。这些经验和技巧，在当时的学校里是都教不了的，只能进入这行业去获得第一手的经验。
+
+那么程序员这行的导师制，像是中世纪时期那样吗？似乎有点像，但也不完全一样。我们都知道编程这门手艺，你读的书再多、再好也不如真正动手去做。可是你一旦开始做了，也会很快掉入迷宫，因为路径千万，到底怎样才是对的？怎样才是好的呢？所以，现在好多公司都会说，“我们会为新员工或学生配备有经验的‘导师’来领路……”但，很多有经验的程序员并不能很好地理解（这也包括曾经的我），作为 “导师” 到底该做什么？要怎么做？以及做或不做于自己有什么关系？
+
+比如，一个有经验的程序员，走到一名新员工面前，问：“你会 Java 吗？会这个框架吗？”
+
+“学过 Java，但框架不太懂。”
+
+“来，这里是框架文档地址，你先看看，搭个 demo 先跑起来。”
+
+“恩，…”
+
+这样的场景，也许大量存在于新手程序 “导师” 和 “学徒” 之间。
+
+## 导师
+
+有经验的程序员、老员工，站在 “导师” 的视角，会如何看待这样的关系呢？
+
+从某种意义上来讲，经验丰富的程序员，就和中世纪的老师傅一样，他们经历了大量的时间犯过大量的错误，积累了很多难以言说的经验价值。他们已经经历过你所犯的错误，已然能够轻松应对如今让你痛苦和头疼的问题，所以他们具有能够引导你迈向正确方向的潜能。
+
+但反过来想，他们为什么要指导你？只是因为公司有个导师制，并安排了他成为你的导师？那么这样的指导通常也就变成了上面那种场景。为什么他们要牺牲自己的工作时间，甚至私人时间来无私地指导你？也许作为新同学的你，甚至包括制度的制定者本身，可能也没从这个角度来看待该问题。
+
+但如果不从这个角度来思考一种制度，那么很可能制度期望的是一回事，行动起来却是另一回事。若只是通过单纯的职业道德约束或价值观教育是解决不了这个问题的。毕竟中世纪的老师傅还可以靠利益交换与绑定来稳固这个机制和关系的。
+
+大学里读研读博，也会有个导师。这样的导师，相对比职场的导师更进一步，因为你们之间有经济交换，你交了学费，所以学校导师就对你的毕业负有一定的指导责任。但你能获得多少质和量的指导与帮助，其实取决于你的态度和反馈。
+
+所以你看，学生参加导师接的一些项目，本质上和中世纪的学徒提供廉价劳动力换取经验和指导是一样的。还有些学生，会为导师收集材料，用于发论文或写书，有些甚至干脆就是写好了论文或书，最后导师只是署个名。人品好点的导师可能还会给你留个第二作者的位置，差点的也许你连露脸的机会都没有。
+
+而职场导师制，如果公司没有相应足够的考核、评价和激励制度支撑，那么这种师徒关系实际上没有任何约束，完全靠运气、投缘之类的。站在导师的角度，对于凑巧碰到的一个职场新人，他有什么样的利益或情感驱动要去更积极地做这件事呢？其实最直接的，还是由对方的态度和行动来驱动的。
+
+而在没有这些更实质的驱动因素时，有人如果愿意去积极地做这件事，那一定是在更高的维度看这件事。借用一句话来说明：
+
+> 
+取得领先的方法，就是提携你身边的人。你对待别人的态度始终会伴随你，人们会忘记你所说和所做的一切，但永远不会忘记他们对你的感觉。帮助别人就是影响别人，如果你能帮很多人，你本身就是高手，你的影响力就很大，你就能做更大的事。
+
+
+这是一个气度问题。
+
+## 学徒
+
+反过来，站在 “学徒” 的视角，该如何看待这样的关系？万维钢有篇文章叫《给前辈铺路的人》说得很有现实意义：
+
+> 
+给人当学徒，就给你提供了这个机会。你现在把自己和一个高手连接在了一起，你可以从内部了解第一手的经验。这就是学徒工作的协议：用礼敬和服务，换取机会——而这个机会还不是立功露脸的机会，而是学习实践的机会。
+
+
+机会，就是得到更快的成长与发展。从导师多年积累的经验中获益，能够缩短获得这些知识经验的时间，并且避免重复错误。但这里面可能还有个障碍，就是自尊心的问题，态度不够谦虚，那么也许是性格还需磨练。如果态度谦虚，双方都投入了适当的时间和精力，那么导师当年花了十数年才学会或领悟到的东西，学徒也许只用短短几年就能学到，绕过了没必要的重复路线。
+
+从学徒方面来说，必要的、简单的、低技术含量或重复性的工作也是必须的，不应该被认为是一种浪费或牺牲。当你在免费获得大量的知识和帮助的同时，却抱怨时间投入太多，或者时间不够，其实是短视的。因为：
+
+> 
+当你给人铺路的时候，你实际上也在左右他的前进方向。
+
+
+这也是一个气度问题。
+
+## 关系
+
+师徒关系有很多种，最让你期待的是哪一种？
+
+对我来说，联想起师徒关系，一下映入我脑中的是金庸小说《笑傲江湖》中的令狐冲和风清扬。在看这部小说时，也曾梦想遇见自己的 “风清扬”，学会绝代天下的独孤九剑。但后来随着年龄增长，我开始觉得，现实中也许终究不会存在像 “独孤九剑” 这样的绝艺，也不会有风清扬这样的师傅，直到我遇到一位美国作者德里克（Derek），他在自己的文章里分享了一个他的成长故事。
+
+下面，我就从作者的第一人称来简述下这个故事。
+
+### 学徒视角
+
+那年夏天，暑假，我 17 岁了，高中刚毕业。开学后，我就将进入伯克利音乐学院学习音乐。那时，我困惑于一些音乐问题，又找不到人解答。所以，我随机打给了一个本地的音乐工作室，工作室的主人基莫（Kimo）接起了电话。
+
+我们聊了起来，当他听说我将去伯克利学音乐时，他说：“我就是从伯克利毕业的，之后还留在那里教了好些年的音乐。我打赌，我能在几节课内教会你学校安排了两年的音乐理论与编曲课程。另外，假如你能明白‘不要接受学校速度的限制’这个道理，我猜你也许能在两年内毕业。假如你感兴趣的话，明天上午 9 点来我的工作室上课，当然，这是免费的。”
+
+两年内毕业？太棒了，我喜欢这个风格，实在太激动了。第二天一早，8:40 我就到了他的工作室门口，但我等到了 8:59 才按响了门铃。
+
+### 导师视角
+
+一天早上的8:59，我的门铃响了，我当时完全忘了为什么这么早会有人来。一直以来，我偶然遇见过一些孩子，他们都说想成为伟大的音乐人。我告诉他们，我能提供帮助，然后让他们早上 9 点来我的工作室，但遗憾的是从来没有人早上 9 点来过。这就是我从一堆孩子中识别出那些只是随便说说，还是真正认真严肃地想干点事的人的办法。直到那天，他来了，按响了我的门铃，一切就这么开始了。
+
+后来的故事就是，德里克只用了两年半便从伯克利毕业了，并将这个抬高的标准和速度应用在了之后一生的事业与生活中。而他们也从师徒关系，转化成了朋友关系，维持了几十年，直到今天。
+
+这像不像一个现实版的 “令狐冲” 与 “风清扬” 的故事？而这，就是我期待的一种师徒关系。
+
+现实中，对于师徒关系，会有人有这样的疑问：“教会徒弟，会饿死师傅吗？”也许中世纪时期的师徒关系会有这样的担忧，但如今这个信息时代，知识根本不稀缺，也没有所谓的 “一招鲜，吃遍天” 的绝招。反过来说，**带好了徒弟，接手并取代了你当前正在做的事情，你才有可能解放出来去做更高层次和更大维度的事情**。
+
+而作为学徒，你需要吸取德里克的经验：**学习和成长是自己的事，严肃待之，行动起来，自助者，人亦助之**。
+
+在成长的阶梯上，无论你在阶梯上的哪个位置，都可以努力去寻找和建立这样一种关系，最好的状态，我想应该既是学徒又是导师。你觉得呢？
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/36 | 核心：安全与效率——工程技术的两个核心维度.md

@@ -0,0 +1,90 @@
+<audio id="audio" title="36 | 核心：安全与效率——工程技术的两个核心维度" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ec/b2/ec4b775652b574094744da6cdedcc3b2.mp3"></audio>
+
+在“**修行：由术入道**”模块的最后一个主题，我们聊聊工程，不是具体的工程的技术，而是抽象的工程之道。
+
+做了很多年的工程，开发了各种各样的系统，写了无数的代码，说起这一切，我们都在谈些什么？
+
+我们谈过程，从需求工程到开发流程，从编码规范到同行评审，从持续集成到自动部署，从敏捷开发到极限编程；我们谈架构，从企业级到互联网，从面向服务架构（SOA）到微服务架构（Microservice）；我们谈复杂性，从高并发到高性能，从高可用到高可靠，从大数据到大容量。
+
+那么对于这一切，你感觉这里面的核心是什么？
+
+## 核心
+
+核心，意味着最重要的，一切复杂的工程技术方案都是围绕着它来运转。
+
+在深入核心之前，我们先讲一个电力行业的故事。虽说电力项目我没做过，但电站大概的工作原理在中学物理课上就已经学过了，原理很简单。虽理论上是这么说，但现实中看到那些大规模的电站后，还是感觉很复杂的。
+
+故事是这样的：记得有个给我们上课的主讲老师是个须发皆白的老先生，进门后掏出一堆零件放在讲台上。一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一个小灯泡。老先生往壶里倒了些水，点燃酒精灯，不一会儿水开了，从壶嘴里喷出了蒸汽，带动叶片旋转，然后小灯泡就亮了。
+
+老先生说：“这就是电厂。如果烧的是煤炭，这就是燃煤电厂；如果烧的天然气，这就是燃气电厂；如果获得热能的方式是核裂变，这就是核电厂；如果带动叶片的能量来自从高处流向低处的水流，这就是水电厂。”
+
+“你们或许会问：那我们看到的电站怎么这么复杂？答案其实很简单，电站需要复杂系统的目的：一是为了确保安全（Safety），二是为了提高效率（Efficiency）。**安全与效率的平衡，是所有工程技术的核心**。”
+
+听完这个故事，我觉着所谓 “大道至简” 大概就是这样的感觉了。
+
+## 安全
+
+安全，之于信息工程技术领域，包括了 “狭义” 和 “广义” 两个方面的安全范畴。如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/38/0c/3859302c7915645585f972961c683c0c.png" alt="" />
+
+狭义的安全，就是传统信息安全领域的 “安全攻防” 范畴。比如，客户端的跨站脚本攻击（XSS）、服务端数据库的 SQL 注入、代码漏洞以及针对服务可用性的拒绝服务攻击（DDoS）等。这个方面的 “安全” 含义是信息技术行业独有的，但前面电站例子中指的 “安全” 更多是 “广义” 层面的。
+
+在程序技术上的 “广义” 安全范畴，我划分了三个方面：
+
+- 开发
+- 运维
+- 运行
+
+**安全开发**，就是为了保障交付的程序代码是高质量、低 Bug 率、无漏洞的。从开发流程、编码规范到代码评审、单元测试等，都是为了保障开发过程中的 “安全”。
+
+**安全运维**，就是为了保障程序系统在线上的变化过程中不出意外，无故障。但无故障是个理想状态，现实中总会有故障产生，当其发生时最好是对用户无感知或影响范围有限的。
+
+通过自动部署来避免人为的粗心大意，资源隔离保障程序故障影响的局部化；当一定要有人参与操作时，操作规范和日志保证了操作的标准化和可追溯性；线上程序的版本化管理与灰度发布机制，保障了若有代码 Bug 出现时的影响局部化与快速恢复能力。
+
+**安全运行**，就是为了应对 “峰值” 等极端或异常运行状态，提供高可靠和高可用的服务能力。
+
+## 效率
+
+效率，从程序系统的角度看，同样也是从 “开发”“运维” 和 “运行” 三个方面来考虑。如下图所示：
+
+<img src="https://static001.geekbang.org/resource/image/2b/6f/2b3a679cc254af1701c6a1f53c1a666f.png" alt="" />
+
+**开发效率**，可以从 “个体” 和 “群体” 两个方面来看。
+
+个体，就是程序员个人了，其开发效率除了受自身代码设计与编写能力的影响，同时还要看其利用工具的水平。更好的源码管理工具与技巧可以避免无谓的冲突与混乱；代码模板与开发框架能大幅度提升代码产出效率；而持续集成工具体系则能有助于快速推进代码进入可测试状态。
+
+群体，就是一个团队，其开发效率最大的限制经常是架构导致的。如果你在一个工程项目上写过几年代码后，多半会碰到这样一种场景，代码库越来越大，而功能越改越困难。明明感觉是一个小功能变化，也要改上好几天，再测上好几天，这通常都是架构的问题，导致了团队群体开发效率的下降。
+
+以后端服务架构技术演进的变化为例，从单体应用到面向服务架构思想，再到如今已成主流的微服务架构实践，它最大的作用在于有利于大规模开发团队的并行化开发，从而提升了团队整体的效率。理想情况下，每个微服务的代码库都不大，变化锁闭在每个服务内部，不会影响其他服务。
+
+微服务化一方面提升了整体的开发效率，但因为服务多了，部署就变复杂了，所以降低了部署的效率。但部署效率可以通过自动化的手段来得到弥补，而开发则没法自动化。另一方面，每个微服务都是一个独立的进程，从而在应用进程层面隔离了资源冲突，提升了程序运行的 “安全” 性。
+
+**运维效率**，可以从 “检查”“诊断” 和 “处理” 三个方面来看。
+
+一个运行的系统，是一个有生命力的系统，并有其生命周期。在其生命周期内，我们需要定期去做检查，以得到系统的 “生命体征” 的多维度信息数据汇总，以供后续的诊断分析。
+
+运行系统的 “体征” 数据是在实时变化的，而且数据来源是多层次的，从底层的网络、操作系统、容器到运行平台（如：JVM）、服务框架与应用服务。当异常 “体征” 指标出现时，很难简单地判断到底哪里才是根本原因，这就需要关联的因果性分析来得出结论，最后智能地发出告警，而不是被告警所淹没。
+
+准确地诊断之后，才能进行合适地处理。和治病不同，大部分的故障都可以通过常见的处理手段解决，极少存在所谓的 “不治之症”。而常见的线上处理手段有如下三类。
+
+- 恢复：重启或隔离来清除故障、恢复服务；
+- 变更：修改配置或回滚程序版本；
+- 限制：故障断路或过载限流。
+
+**运行效率**，关键就是提高程序的 “响应性”，若是服务还包括其 “吞吐量”。
+
+程序运行的高效率，也即高响应、高吞吐能力，所有的优化手段都可以从下面两个维度来分类：
+
+- 更多
+- 更快
+
+负载均衡器让更多的机器或进程参与服务，并行算法策略让更多的线程同步执行。异步化、无锁化和非阻塞的算法策略让程序执行得更快，缓存与缓冲让数据的读写更快。
+
+有时在某些方面 “安全” 和 “效率” 之间是相互冲突的，但工程技术的艺术性就恰恰体现在这冲突中的平衡上。
+
+打个比方，如果你的程序就跑在你开的车上，那么“安全” 特性会让你开得更放心，“效率” 特性会让你开得更带劲。
+
+做了多年程序工程的你，是如何看待工程的核心本质的呢？欢迎留言，一起探讨。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/37 | 过程：规模与协作——规模化的过程方法.md

@@ -0,0 +1,101 @@
+<audio id="audio" title="37 | 过程：规模与协作——规模化的过程方法" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4a/dd/4a931c8cd0fe91383d0d2dd1e2d2b2dd.mp3"></audio>
+
+在学校时，你学习编程，写写课程作业的代码，但你想过真正的行业里，公司中的规模化开发方式是怎样的吗？在上一篇[《核心：安全与效率》](https://time.geekbang.org/column/article/42517?utm_source=weibo&amp;utm_medium=xuxiaoping&amp;utm_campaign=promotion&amp;utm_content=columns)的文中，你应该还记得我讲的那个电站的例子，那么编写课程作业的代码就像搭建的 “酒精灯电站”，而工业级的规模化开发才是建设 “真实电站” 的方式。
+
+工业级规模化的程序系统开发包括了一系列的过程，而这一系列过程的起点是：需求。
+
+## 需求与调度
+
+需求，有时会有很多不同的表达形式，包括：客户的诉求、用户的请求、老板的要求，但这些不同的表达形式，不一定是真正的需求。
+
+客户的诉求，更多来自传统甲、乙方关系的场景，在软件工程过程中有一个子过程——需求工程——去对客户的诉求进行分析和提炼，并转化为需求文档。用户的请求，更多来自互联网 toC 的场景，通过洞察大量用户请求中的共性去提炼并转化为真正的产品需求。老板的要求，更多是因为老板也可能是你的产品用户之一，但这个用户的特殊之处在于，他为这个产品买单。所以，他的要求无论合理与否都能很容易地变成需要开发的需求。
+
+正因为需求的来源多，表达形式也多，因而真实情况是 “需求” 似乎总是源源不绝，但是真正的需求往往隐藏在这些诉求、请求与要求的表象之下。这是关于 “需求” 的第一个困难点。如果我们总是能找出真正的需求，那么也许需求也就没那么多了。但现实往往是我们不能，那么需求过载的场景就会常常发生。
+
+这时，你就会面临第二个困难，如何对过多的需求进行排序？
+
+为什么需要排序？我们进行需求排序的原因是，在有限的资源下我们想要达到如下目标：
+
+- 最大化用户、客户和老板的整体满意度；
+- 最大化价值与产出，让最多的资源投入到最有价值的需求上。
+
+只有当用户需求被快速地满足时，他们才会感到满意。但在有限资源限制的条件下，我们不可能让所有用户的需求都能被快速满足。面对这样的矛盾，我们也许可以学习、借鉴下**操作系统的资源调度策略**。
+
+我用了好多年的 Mac 和 iPhone，发现它们相对同等资源配置的 Windows 和 Android 机，在满足用户使用的响应性方面要好得多，特别是在使用了几年之后，这种差距会更明显。
+
+在同等硬件资源配置的情况下，Mac 和 iPhone 表现得更好，只可能是其操作系统的资源调度策略实现更优秀。通常，操作系统需要同时执行多个应用程序时，它的执行调度策略就会在多个应用程序间不停切换，有如下几种常见的调度策略：
+
+1. **先来**先执行
+1. 执行起来**最快**的先执行
+1. 占用资源**最少**的先执行
+1. 释放资源**最多**的先执行
+1. **高优先级**的先执行
+
+当资源充足，只用策略 1 就足够了，但更多情形下需要综合后 4 种策略。比如：老板的要求天生自带高优先级，需要先执行；而一些小需求，优先级不高，但执行快，占用资源少，随着它们排队的等待时间延长，优先级可以逐步提升，以免消耗完用户的等待耐心，形成负面评价。
+
+当用户同时运行的应用程序确实太多时，操作系统发现资源无论如何调度都不够了，它有一个选项是提供了资源消耗的监视器，来提示用户主动停掉一些同时运行的应用，而最后的底线是操作系统主动杀掉一些应用程序以释放资源，以保障系统还能正常地运转下去。那么我们在调度需求时，是否也能以透明的资源消耗监视提示用户主动控制需求或选择 “杀” 掉需求，然后还不降低用户的满意度呢？
+
+需求调度，可以像操作系统一样运转，形成一个规模化的需求调度体系，并通过多种调度策略来平衡需求的响应性和投入产出的价值最大化。
+
+## 设计与开发
+
+紧接需求之后的过程是：设计与开发。
+
+成为程序员后，你一开始可能会习惯于一个人完成系统开发，自己做架构设计、技术选型、代码调测，最后发布上线，但这只适合代码量在一定范围内的系统开发模式。在一定范围内，你可以实现从头到尾“一条龙”做完，并对系统的每一处细节都了如指掌，但当系统规模变大后，需要更多的人共同参与时，整个设计和开发的模式就完全不一样了。
+
+一定规模的系统，下面又会划分子系统，子系统又可能由多个服务构成，而每个服务又有多个模块，每个模块包含多个对象。比如，我现在所在团队负责的产品，就由数个系统、十数个子系统、上百个服务构成，这样规模的系统就不太可能光靠一个人来设计的，而是在不同的层次上都由不同的人来共同参与设计并开发完成的。
+
+**规模化的设计思路，一方面是自顶向下去完成顶层设计**。顶层设计主要做两件事：
+
+- 一是去建立系统的边界。系统提供什么？不提供什么？以怎样的形式提供？
+- 二是去划定系统的区域。也就是系统的层次与划分，以及它们之间的通信路径。
+
+今年世界杯期间，读到万维钢一些关于 “足球与系统” 的文章，感慨原来系统的顶层设计和足球运动十分类似。按文中所说，足球的科学踢法是：“球员必须建立 ‘区域（zone）’ 的观念，每个球员都有一个自己的专属区域”，通过区域的跑位来形成多样化的传球路线配合。
+
+而系统的区域划分，也是为了让系统内部各部分之间的耦合降低，从而让开发人员在属于自己的区域内更自由地发挥。而在区域内的 “控球”“传球” 与 “跑位”，就更多属于开发人员个体能力的发挥，这个过程中区域的大小、边界都可能发生变化，进而导致区域之间的通信路径也跟随变化。这样的变化，就属于自底向上的演化过程。
+
+所以，**规模化设计思路的另一面，就是要让系统具备自底向上的演化机能**。因为，自顶向下的设计是前瞻性的设计，但没有人能做到完美的前瞻性设计；而自底向上的演化机能，是后验性的反应，它能调整修复前瞻性设计中可能的盲点缺陷。
+
+记得，我曾经看过一个视频名字大概是 “梅西的十大不可思议进球”，视频里的每一个进球都体现了梅西作为超级明星球员的价值，而在前面提及的万维钢的文章中，有一个核心观点：“普通的团队指望明星，最厉害的球队依靠系统”。其实二者并不矛盾，好的系统不仅依靠 “明星” 级的前瞻顶层设计，也指望 “明星” 级的底层演化突破能力。
+
+所以，一个规模化的系统既要靠前瞻的设计视野，也依赖后验的演化机能，这样才可能将前瞻蓝图变成美好现实。
+
+## 测试与运维
+
+完成了设计与开发之后，系统将进入测试，最后发布上线进入运行与维护阶段。
+
+在前面需求、设计与开发阶段的规模化过程中，都存在一个刚性扩展的问题，也就是说，如果提出的需求数量扩大一倍，那么需要去对接、分析和提炼需求的人员理论上也要扩大一倍；如果提炼出的需要进入开发的需求也翻倍，相应开发人员只增长一倍那已经算是理想情况了，这说明系统的正交与解耦性做得相当完美了，所有的开发都能并行工作，不产生沟通协调的消耗。
+
+但真实的情况不会那么完美，需求的产生与爆发很可能是一种脉冲式的，而企业一般会维持满足需求平均数量的开发人员，当需求进入脉冲高峰时，开发资源总是不够，然后就会过载，进入疯狂加班模式。
+
+开发完成后，进入测试与线上运维的循环阶段，这个阶段与前面阶段的不同之处在于：需求提炼、设计开发基本都只能由人来完成，而测试、运维的很多步骤可以通过制作工具来完成自动化过程。所以，这个阶段随着规模化过程实际可以是一个柔性扩展的阶段。
+
+但它从来不是一开始就是柔性的，因为制作工具也有一个成本考虑。比如，在我做的这个系统发展的早期，系统架构简单、部署规模也很小，基本所有的测试与运维工作都是通过人肉来完成的，这样的效率也不算低，唯一的问题是对测试人员而言，大量的工作都是低水平的重复，不利于个人成长。
+
+随着后来的业务快速增长，系统增长越过某个规模临界点，这时人肉负载基本饱和，效率已没法提升，制作工具是唯一的出路。你可能或多或少都知道一些现代化的工业流水线，而在软件开发过程中，“测试与运维” 的运转体系是最可能接近工业流水线方式的。
+
+因此，以测试为例进行规模化的最佳方式，就是打造一条 “测试机器” 流水线，而我在[《转化：能力与输出》](https://time.geekbang.org/column/article/40371?utm_source=weibo&amp;utm_medium=xuxiaoping&amp;utm_campaign=promotion&amp;utm_content=columns)一文中写到了关于打造 “机器” 的三个核心点，这里再强调一次：
+
+- 流程规则
+- 工具系统
+- 规范共识
+
+围绕这三个核心点，我们再来看看 “测试机器” 如何打造？
+
+从开发提测，机器自动下载提测版本分支代码，进行构建编译打包，实施代码规范性检查测试，通过后发布测试环境，进行分层次的各类自动化专项测试。如：用户终端层、通信协议层、服务接口层、数据存储层的各项测试，全部通过后，生成相应的测试报告，进入下一步发布流程。这就是测试体系的“流程”，而“规则”就是其中定义的各种测试项检查约束。
+
+上述流程中涉及的“工具系统”包括：代码规范检查工具、终端 UI 的自动化测试工具、通信协议与服务端接口调用的模拟工具、数据一致性校验工具、测试报告生成工具、测试 Bug 统计分析与收敛趋势等可视化展现工具，等等。
+
+最后，“规范共识” 是整个团队对这个流程环节、里面具体规则的定义以及 Bug 分类等方面达成的共识，这决定了这台 “测试机器” 运转的协调性与效率。
+
+测试通过后，发布到线上就进入了运维阶段，行业里已经有大量的关于 DevOps 的分享内容，而它的本质也就是打造了一台 “运维机器” 流水线，这和我上面描述的 “测试机器” 运转类同，只是有不同的规范共识、流程规则和工具系统，便不再赘述了。
+
+到了规模化的测试与运维阶段，看一个团队的水平，就是看这台 “机器” 的制作水准与运转效率。
+
+在程序系统的开发过程中，当系统的大小和复杂度到了一定的规模临界点，就会发生从量到质的转变，规模不同，相应的需求调度、设计开发、测试运维的过程也都不同了。
+
+量级变了，逻辑就不一样了。
+
+每一个具备一定规模的组织都有对应的规模化工程过程，而且这个过程的形成受公司文化、团队构成、组织架构，甚至业务特性共同决定。那你所在组织的规模化过程是怎样的？这个过程系统如何运作的？欢迎你在留言区分享。
+
+

极客时间专栏/程序员进阶攻略/修行：由术入道/38 | 思维：科学与系统——两类问题的两种思维解法.md

@@ -0,0 +1,74 @@
+<audio id="audio" title="38 | 思维：科学与系统——两类问题的两种思维解法" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/17/26/1766a7ac014f667e056039066e89fd26.mp3"></audio>
+
+写了多年代码，做了好多的工程，不停地完成项目，但如果你一直仅仅停留在重复这个过程，那么就不会得到真正的成长与提高。你得从这些重复做工程的过程中，抽象提炼出真正解决问题的工程思维，用来指导未来的工程实践。
+
+什么是**工程思维**？我从自己过往经验中提炼出的理解是：**一种具备科学理论支撑，并成体系的系统化思维**。做了多年的软件开发工程，碰到和解决了数不清的问题，最终这些问题，我发现稍微抽象一下，可以归为以下两类：
+
+1. 可以简单归因的问题：属于直接简单的因果关系；
+1. 难以简单归因的问题：属于间接复杂的因果关系。
+
+上面的描述可能有点抽象，那具体该怎么理解呢？这里我分别举两个例子：线上有个 Bug，找到了有问题代码片段，需要一个优化实现方案来解决，这就是第一类问题，原因和结果非常明确清晰；线上老是出故障，而且反复总出意外故障，对于这个结果，它的原因是什么，这就很难简单归因了，就属于第二类问题。
+
+对于这两类问题，我想讲讲两种不同的思维框架提供的解法。
+
+## 科学与理论
+
+第一类问题，现象清晰，归因明确，那么它唯一的难处就是为这个问题找到最优的解决方案。求解最优化问题，就需要科学与理论的支持，也即：**科学思维**。
+
+先讲一个其他行业的故事：造船工程。很早以前，关于应该造多大的船，人们都是靠感觉摸索的。后来（十九世纪中期）有个英国工程师布鲁内尔（Brunel）意识到船应该尽可能造得大些，于是他设计了当时世界上最大的船。这是一艘挑战当时工业极限的船，该设计甚至还引发了当时社会激烈的辩论。
+
+布鲁内尔的目标是建造一艘足够大的船，大到无需中途停留，直接能从英国开到印度，那么如此远的航程就需要有足够的货物与燃料（那时的燃料主要就是煤）的装载能力。而支撑他设计背后的理论却很简单，船的装载能力是体积决定的，跟船尺寸的立方成正比，而船航行受到的阻力则是和船底的面积成正比。所以，船越大，装载能力越大，但单位载重量的动力消耗却下降了，这就是为什么布鲁内尔要尽可能地造大船。
+
+这就是科学理论给予造船工程的方向指引。吴军老师也曾在一篇文章《计算机科学与工程的区别》里指出：
+
+> 
+科学常常指出正确的方向，而工程则是沿着科学指出的方向建设道路；在工程中必须首先使用在科学上最好的方法，然后再作细节的改进。
+
+
+我做在线客服系统时碰到一个问题和滴滴打车的匹配问题非常类似，打车是人和车的匹配，而咨询客服是人和客服的匹配。抽象来看，这个匹配的算法并不复杂，但因为涉及到非常具体且繁琐的业务规则，实现起来就有特别多业务逻辑，导致性能有问题。这就是软件工程现实中的第一类问题，需要找到优化方案。
+
+对于这类问题的解法，就是先用计算机科学理论来分析其性能的复杂度边界与极限，而咨询分配就是在 N 个客服里进行挑选匹配，每次只匹配一个人，所以理论复杂度极限是 O(N)。只要 N 有限大，那么匹配的性能最坏情况就是清晰的。
+
+理论分析给出了边界，工程实现则是建设道路，这就需要在边界里找到最短路径。在客服匹配问题的工程实现总考虑的方式是：最坏的情况是每次匹配都要遍历 N 次，最好的情况是 1 次，那么实现方案评估就是尽可能让最好的情况发生的概率最大化。假如你的实现方案 90% 的场景概率都发生在最好情况下，10% 的场景发生在最坏情况，那么整体性能表现可能就比最坏情况高至少一到数个量级。实际提高多少，这取决于 N 的大小。
+
+而另一个工程实现考虑的维度是，如果每次匹配中有 M 个高消耗操作，那么进一步的优化方式就是如何减少 M 的个数或降低每次操作的消耗。
+
+这就是用科学思维来指导工程实践，科学理论指出方向，探明边界，工程实践在边界的约束范围内修通道路，达成目标。正如前面故事中，造船理论往大的方向走也有其极限，因为除了能源利用率的经济性外，越大的船对其他建造、施工和运营方面也会带来边际成本的提高，所以也就没法一直往大里造，这就是工程现实的约束。
+
+所以，理论的意义不在于充当蓝图，而在于为工程设计实践提供有约束力的原理；而工程设计则依循一切有约束力的理论，为实践作切实可行的筹划。
+
+**简言之，科学理论确定了上限，工程实践画出了路线**。
+
+## 系统与反馈
+
+第二类问题，结果明确，但归因很难，那么找到真正的原因就是第一个需要解决的难点。这时，我们就需要用另一种思维方式：**系统思维**。
+
+回到前面举的例子，线上老是出故障，而且反复出意外故障。如果简单归因，查出故障直接原因，发现是代码写得不严谨，实现有不少漏洞和问题，仔细看就能分析出来，但触发条件罕见不容易测出来，于是提出解决方案是增加代码评审（Code Review）流程来保障上线代码的质量。
+
+关于代码评审就是我从业多年来遇到的一个非常有意思的问题，大家都觉得它有用，也都说好，但很多时候就是执行不下去。因为它不是一个简单问题，而是一个系统问题。万维钢在《线性思维与系统思维》这篇文章里，给出了一些系统问题的典型特征，其中有两条是这样说的：
+
+- 多次试图解决一个问题，却总是无效；
+- 新人来了就发现问题，老人一笑了之。
+
+我呆过的很多公司和团队，都想推行代码评审，最后都无果而终。反而是一些开源项目，还搞得有声有色。还是万维钢的那篇文章里，其对系统的定义：“所谓系统，就是一个由很多部分组成的整体，各个部分互相之间有联系，作为整体又有一个共同的目的。” 简单想想就会发现公司项目所在的 “系统” 和开源项目所在的 “系统” 其构成就完全不同，而且目的也不同。
+
+> 
+一个系统中可以有若干个正反馈和若干个负反馈回路，正反馈回路让系统或者增长、或者崩溃，是要偏离平衡，负反馈回路则尽力保持系统的平衡。
+对你想要解决的这个问题而言，可能就有一个回路，正在起主导的作用！如果你能发现在系统里起主导作用的回路是什么，你就抓住了系统的主要矛盾，你就找到了问题的关键所在。
+
+
+曾有行业大牛在前公司有很好的代码评审传统和流程规范要求，自己也坚决支持代码评审。后来去了另一个同行差不多规模的公司，进入到团队后想推行代码评审时，就遭遇了巨大的阻力，不止是 “老人呵呵，一笑了之” 了，还甚至被公开地反对了。显然，对于代码评审这个问题，他的前后两家公司拥有完全不同的正、负反馈回路，以其个体之力，想要去改变已有的反馈回路，其实相当艰难。
+
+我自己也曾在团队做过一些尝试，但一直找不到合适地建立正反馈回路的好方法。引入严格的代码评审流程，其负反馈回路立刻发生作用：更多的工作量，更多的加班等。负反馈，团队立刻就能感知到，而其正反馈回路发生作用带来好处却需要一定的时间。而且另一方面，建立新的回路或者摆脱当前的循环回路，还需要额外的能量来源，也即激励。
+
+在解决系统问题，建设正反馈回路上也有过成功的样本。比如，在公司层面要求工程师产出专利，这对个体来说就是额外的负担，而负担就是负反馈。为了降低负反馈回路的作用，可以让专利和晋升到一定级别关联上，并增加专门培训来降低写作门槛；专利局每通过一份专利，就奖励一笔奖金（几千到上万），甚至没通过都能奖励几百块，这些就是建立正反馈循环回路的激励能量。
+
+另外一个例子是，为了让程序工程师们更有分享的意愿和提升表达能力，就出一个规则，把分享和每年的晋升提报关联起来，本质就是提供了潜在可能的经济激励。经济学原理说：人会对激励做出反应。是的，经济学原理很有效。
+
+软件工程，是研究和应用如何以系统性的、规范化的、可度量的过程化方法去开发和维护软件；而实际上软件开发本身就是一个系统工程，里面存在很多没法简单归因的第二类问题，它们没有通用的解法，只有通用的思维。
+
+一个优秀的工程师应该同时具备科学思维和系统思维，它们是工程思维的两种不同表现形态：**系统思维洞察问题本质，科学思维发现最优解法**。
+
+学完本章，你也可以去细心观察你周围的环境，看看都有哪些问题，属于哪类问题，以及你能发现它们的本质吗？欢迎你留言分享一二。
+
+