first commit

专栏/程序员进阶攻略/21信息：过载与有效.md

@@ -0,0 +1,125 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            21 信息：过载与有效
+                            至此，专栏已用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 小时左右，就会感到很疲劳。而做不同的事情对大脑的利用率是不同的，下图结合自身感受画出了一个我自己的大脑消耗率示意图：
+
+
+
+所以，这里就要有选择和取舍。万维钢的一篇文章中有句话是这么说的：
+
+
+注意力是一种有限的资源，你要是不擅长不集中注意力，你就不擅长集中注意力。
+
+
+你得挑选那些真正值得做和学的东西去让大脑满负荷运转，但凡投入决心去做的事情，就需要百分百投入。这就是专注于少而精的东西，深入了解这些东西，进入到更深的层次上。深可以无止境，那到底多深才合适？我的答案是：让你的内心对取得的效果感受到满意的深度层次上。它的反面是：但凡心存疑虑，不是那么确定要全力投入的事情，干脆就不做了。
+
+以前写一篇文章，我会给一个合理的时限要求。比如高考作文 800 字，要在 50 ～ 60 分钟内完成。而我每篇文章一般在 2000 ～ 3000 字，我给的时限也就在 3 小时左右。因为安排了这 3 小时，其他时间按计划还要干别的，但这个安排一直让我很焦虑，因为经常性写超时。
+
+现在明白了，写作本来是一件创造性的活动，一件 “脑耗率” 100% 的活动，需要百分百的投入，最终效果远重于时限。即便我在 2 小时写完了，但效果能达到让我内心取得满意的深度层次么？（题外话，每篇专栏文章的写作和反复修改，平均要 6 ～ 10 小时。）
+
+做得多和做得好的感觉很不一样。就像拳击，多，好似不停挥拳，很快就精疲力竭；好，则是看准目标，抓住机会全力出击，一击中的。
+
+最后，总结下在信息爆炸的时代，我们该如何有效处理、吸收和消化信息：
+
+
+信息过载是现实；
+疲于奔命是陷阱；
+心智模型是方法；
+一击中的是策略。
+
+
+那关于信息处理的有效方法和模型，你目前采用的是怎样的好办法呢？欢迎留言分享，我们相互学习下。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/22领域：知识与体系.md

@@ -0,0 +1,95 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            22 领域：知识与体系
+                            今年年初，我学习了梁宁的《产品思维》课，其中有一篇叫《点线面体的战略选择》，我觉得特别有感触。虽然是讲产品，但假如把个人的成长当成产品演进一样来发展，会有一种异曲同工、殊途同归之感。
+
+在我工作的经历中就曾碰到过这么一个人，他一开始做了几年开发，从前端到后端，后来又转做测试，接触的“点”倒是不少，但却没能连接起来形成自己的体系，那他个人最大的价值就局限在最后所在的“点”上了。
+
+其实个人的成长有很多方面，但对于程序员的成长最重要的就是知识体系的构建，这其实就是一个 “点线面体” 的演进过程。
+
+下面我会结合自己的成长路线来梳理下这个体系的建立过程。
+
+点
+
+进入任何一个知识领域，都是从一个点开始的。
+
+如下图，是我从大学进入软件开发领域所接触的一系列的点，我将其从左到右按时间顺序排列。红色的部分是目前还属于我 “掌握” 与 “了解” 的领域，其他灰色的部分则是要么被时代淘汰了，要么已经被我放弃了维持与更新。
+
+
+
+我的成长时间线上相关技术领域知识点
+
+我入行的年代，流行的是 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 线图”，它串联了如今我沉淀下来的和一些新发展的 “点”。
+
+
+
+我个人的成长发展 “T 线图”
+
+我从成为了一名 Java 程序员开始，在这条 “T线” 上，先向下走，专注于解决业务需求碰到的技术问题。先自然地要向下至少走一层，接触 Java 的运行平台 JVM。而又因为早期做了几年电信项目，要和很多网络设备（包括各类网元和交换机等）通信，接触网络协议编程；后来又做了即时消息（IM）领域的工作，网络这一块就又继续增强了。而网络编程依赖于操作系统提供的 I/O 模型和 API，自然绕不过 OS 这一块。
+
+在 Java 领域走了多年以后，以前涉猎的技术点就逐步暗淡了。而再从程序员到架构师，就开始往上走，进入更纯粹的 “架构与设计” 领域，在更宽的范围和更高的维度评估技术方案，做出技术决策与权衡，设定技术演进路线。
+
+但是，再好的技术方案，再完美的架构，如果没有承载更有意义的业务与产品形态，它们的价值和作用就体现不了。所以不可避免，再往上走时就会去了解并评估 “业务与产品”，关注目标的价值、路径的有效性与合理性。
+
+在整个纵向的技术线上，最终汇总到顶点，会形成一种新的能力，也就是我对这条纵向线的 “掌控力”。到了这个 “点” 后，在这里可以横向发展，如图中，也就有了新的能力域：领导力和组织力。
+
+一个个点，构成了基本的价值点，这些点串起来，就形成了更大的价值输出链条。在这条路上，你也会有一条属于自己的 “T线”，当这条线成型后，你的价值也将变得更大。
+
+面
+
+线的交织，将形成面。
+
+当我试着把我最近六年多在电商客服和即时通讯领域的工作画出来后，它就织就了下面（如图所示）的这个“面”。
+
+
+
+我近些年工作面的分层图
+
+我从最早的聚焦于某个业务点和技术栈，逐步延伸扩展到整个面。因为 IM 这个产品本身具备很深的技术栈，而且也有足够多元化的应用场景，这样整个面就可以铺得特别宽广。这也是为什么我已经在这个面上耕耘了六年多之久。
+
+但事实上，我并不掌握这个面上的每个点，整个团队才会分布工作在整个面上，每个个体贡献者也只会具体工作在这个面上的某个或某些点。但我们需要去认清整个面的价值体系，这样才能更好地选择和切入工作的点，创造更大的价值。
+
+而有时候，我也了解到有些程序员的一些说法是这样的：在相对传统的行业，做偏业务的开发，技术栈相对固定且老化，难度和深度都不高，看不到发展方向，期望找到突破口。若你也出现这样的情况，那就说明你从事的业务开发，其单个技术点的价值上限较低，而选择更新、更流行的技术，你就是期望提升单个技术点的价值，但单个技术点的价值是相对有限的。
+
+反过来，如果很难跳脱出自身环境的局限，那么也可以不局限于技术，去考虑这些传统的业务价值，从技术到业务，再上升到用户的接入触达，考虑产品的场景、形态和人群是如何去为这些用户提供的服务、产生的价值。
+
+当你对整个业务面上的价值点掌握的更多，能抓住和把握核心的价值链条，去为更广、更大的价值负责，那么你就能克服自己的成长发展困境，找到了另外一条出路了。
+
+同时，你也为自己织就了一张更大的领域之网。在整个面形成了一个领域，在这个面上你所能掌控的每条线就是你的体系。在这条线的 “点” 上，你解决具体问题，是做解答题；但在整个面上你选择 “线”，是做选择题。
+
+体
+
+体是经济体或其中的单元。
+
+你的 “面” 附着在什么 “体” 上决定了它的价值上限。如果 “体” 在高速增长并形成趋势，你就可能获得更快的发展。
+
+从电力时代到信息时代再到智能时代，互联网、电商、移动互联网，这些都是 “体” 的变化。今天互联网行业的软件工程师，他们面临的挑战和难度不见得比传统的机械或电力工程师更大，只不过他们所从事的 “点” 所属的 “面”，附着于一个快速崛起的 “体” 上，获得了更大的加速度。
+
+“体” 的崛起，是时代的机遇。
+
+总结来说，就是：在领域知识体系中，“点” 是利器，“线” 是路径，“面” 是地图；而就我们个体而言，“点” 是孤立知识点的学习掌握，而 “线” 是对这些点的连接，“面” 则构成了完整的知识体系网。
+
+以上就是我建立知识体系并形成自己领域的思考。而在每个不同的阶段，你都可以先做到心中有图，再来画“线”，然后再在每个“点”上去努力。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/23转化：能力与输出.md

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

专栏/程序员进阶攻略/24并行：工作与学习.md

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

专栏/程序员进阶攻略/25时间：塑造基石习惯（上）——感知与测量.md

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

专栏/程序员进阶攻略/26时间：塑造基石习惯（下）——切割与构建.md

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

专栏/程序员进阶攻略/27试试：一种“坏”习惯.md

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

专栏/程序员进阶攻略/28提问：从技术到人生的习惯.md

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

专栏/程序员进阶攻略/29偏好：个人习惯的局限与反思.md

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

专栏/程序员进阶攻略/30写作：写字如编码.md

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

专栏/程序员进阶攻略/31画图：一图胜千言.md

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

专栏/程序员进阶攻略/32演讲：表达的技术.md

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

专栏/程序员进阶攻略/33定义：阶梯与级别.md

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

专栏/程序员进阶攻略/35关系：学徒与导师.md

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

专栏/程序员进阶攻略/36核心：安全与效率——工程技术的两个核心维度.md

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

专栏/程序员进阶攻略/37过程：规模与协作——规模化的过程方法.md

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

专栏/程序员进阶攻略/38思维：科学与系统——两类问题的两种思维解法.md

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

专栏/程序员进阶攻略/39职业倦怠：如何面对？.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            39 职业倦怠：如何面对？
+                            从今天起，咱们专栏即进入第 4 个大主题——“徘徊：道中彷徨”。成长的途中，我们总会面临很多的困扰与惶惑，这些困扰和彷徨很多都关乎选择，只有了解并认清这类困惑，我们才可能做出最合适的选择。
+
+职业生涯的路上，每个人都会碰到职业倦怠期，我也不例外。曾经好几次，我都陷入其中。如今从中摆脱出来后，我就想尝试搞清楚这样一种状态的根源，思考一种方法来缩短它持续的时间，或者说增加它出现的时间间隔。
+
+那职业倦怠到底是怎样的一种感受呢？
+
+倦怠感
+
+1974年，美国临床心理学家弗罗伊登贝格尔（Herbert J. Freudenberger）首次提出“职业倦怠”的概念，用来指人面对过度工作时产生的身体和情绪的极度疲劳。
+
+职业倦怠感想必你也不陌生，一般将可以明显感知到的分为两种。
+
+一种是短期的倦怠感。它出现的状态，可以用两个英文单词来形象地表达：Burnout（燃尽，精疲力尽）和 Overwhelm（难以承受）。
+
+作为程序员的我们想必最能感知这样的状态，因为我们处在现代信息工业时代的最前沿，快节奏、高压力、大变化的环境很是常见。应对这样的环境，我们就需要更多的 “燃料” 和更强的承受力。但有时，环境压力突然增加，短期内超出了我们的负载能力，难免出现“燃尽”（Burnout）的时刻，并感到难以承受（Overwhelming）。
+
+此时，就进入了短时的倦怠期。这种短期的倦怠感觉其实和感冒差不多常见，年年都能碰上一两次，应对的办法其实也很简单：休个年假，脱离当前的环境，换换节奏，重新补充 “燃料”，恢复精力。就像感冒，其实并不需要什么治疗，自然就能恢复。人，无论生理还是心理，都是一个 “反脆弱” 体，“凡不能打垮我的，必使我更强大”。
+
+另一种更可怕的倦怠感是长期的，它与你对当前工作的感受有关。
+
+有些人把 “上班” 看作工作的全部，那么这样的人去上班一般都是被动的、勉强的。这样的人就是普遍存在的 “混日子” 的上班族，虽不情愿，但又没有别的办法，毕竟不能失去这份工作的收入。而这种 “混日子” 的状态，其实就是处在一种长期的职业倦怠期。
+
+其实真正的工作，应该是一种积极的、有目标的事情，它能让我们实现对自我和他人的价值，并且乐在其中。但即使一开始我们是在做这类真正的 “工作”，时间久了后，也难免碰到职业倦怠感，这时我们可能就会困惑：难道我已不再热爱现在的工作了？对于这种状态，有一个说法是这样的：
+
+
+倦怠，意味着你在这一关打到头了，而新的一关的钥匙，就在你手上。
+
+
+遇到这种情况的本质，其实是我们自己的 “工作区” 发生了转移和变化，从而脱离了原来的 “工作态”，碰到了倦怠感。
+
+当倦怠感出现时，“工作态” 就隐退了；而为了消除倦怠感，我们就需要找回 “工作态”。
+
+工作态
+
+工作态，如其名，是一种工作的状态，一种让我们在工作中感觉到美好的状态（beautiful state）；是做我们喜欢的工作时表现出来的一种状态。
+
+每周我们有五个工作日，但不代表我们每个工作日的工作时间都能处在 “工作态”。甚至很多时候我们都无法处在 “工作态”，但却又必须在某个时间点前完成工作。这样的日子久了，就难免会滋生倦怠。
+
+据说有一半的人，每天下班回家上床睡觉前，都会想想诗和远方，早上起床都有一种不想再去上班的冲动；当感到这种冲动时，差不多就进入了工作倦怠期，并对当前的工作产生了倦怠感。
+
+去年有部电影叫《魅影缝匠》，主角是一名裁缝。他每天起床后，从早餐时刻开始就进入了他的 “工作态”，排除和避免一切干扰，专注于他的服装设计工作。其实，这个电影本身的故事并不算吸引我，只是电影中这位缝匠的 “工作态” 深深地打动了我。也许，这就是一种同为创作性工作带来的共情吧。
+
+现代心理学上有个概念叫 Flow，一般译作 “心流”，也是一种工作状态，它是人在专注进行某些行为时所表现出的心理状态，比如艺术家创作时的状态。在此状态下的人们，通常不愿被打扰，也比较抗拒中断，个人的精神力将完全投注在某种活动上，同时还会伴随高度的兴奋与充实感。
+
+那么 “工作态” 和心流有何不同？“工作态”，其实是我自己发明的一个概念，它的定义覆盖的期限更长久，就像长跑中的节奏；而心流的定义更像是一种 “工作态” 的局部过程表现，像一次短程冲刺。你没法长时间地处于心流状态，但在相当长的一段时间周期内，你可以处在 “工作态” 中，就像电影中那位缝匠，几十年如一日的，每天早晨都会自动进入那样一种 “工作态”。
+
+职业倦怠期，显然是与 “工作态” 互斥的一种状态。所以，要脱离职业倦怠期，最有效的方式就是进入 “工作态” ；而进入 “工作态” ，最核心的地方在于找到自己的 “工作区”。
+
+工作区
+
+关于工作区，我想借用下面一张图来展示。
+
+
+
+工作的“三区域”图
+
+“工作区” 的概念不是我发明的，其原始概念图来自国外一个站点，我将其翻译和重绘了一下。其中定义了关于工作的三个区域，也就是说每一份工作都包含了这三个方面：
+
+
+目的意义 Purpose
+职业生涯 Career
+工作岗位 Job
+
+
+目的意义，这是工作的终极之问。它决定了你的很多选择，以及你接受什么、拒绝什么，是工作愿景背后的灵魂所在。每个人工作都会有自己的目的与意义，而且还会随着工作过程发生变化（或者说进化更合适些）。追寻目的与意义，这可能是你、我一生的工作。
+
+职业生涯，是个人一生职业愿望的追寻过程。它由长期目标驱动，是追寻 “目的意义” 的一条你所期望的路径。而这条路径并不唯一，它因人而异，因你的 “目的意义” 而异。它构建在你工作过程中的所有经历、经验、决策、知识、技能与时运的基础之上。
+
+工作岗位，这不过是你现在上班的地方，包括了位置、角色、关系、职责与薪酬的总和。
+
+这三个区域会有交集，这里我举个实际的例子。假如你工作的 “目的意义” 非常现实，就是希望有更多的收入改善家庭生活，住更大的房子，开更好的车。而现在的 “工作岗位” 能够提供这样让你满意的收入水平，那么你就会感到 “快乐幸福”。
+
+而若你对 “职业生涯” 路径的期望是从程序员到架构师，甚至再到 CTO，当前的 “工作岗位” 能提供这样的发展路径，那你就会充满 “激励驱动”。显然，职业生涯一路达到 CTO，收入水平会更高，与你的现实 “目的意义” 相符合，那你就会感到 “成就满足”。
+
+如图中所示，这三者相交的那个位置，就是你的 “工作区”。在这个区域内，工作让你有驱动力，感到快乐，充满成就感。找到了 “工作区”，很自然就会进入 “工作态”。
+
+当职业倦怠时，自然是远离了工作区，这时很容易产生的一个决策是：换一份工作。我曾经就做过这样的决策。换一份工作没有对错好坏之分，它能改变你的工作岗位，甚至也能改变你的职业生涯路径，但它唯一不能改变的就是你对 “目的意义” 的思考与认识。
+
+做自己所爱，是对的；爱上自己所做，也是对的，关键就是要找到什么在真正驱动你前进。
+
+丹麦哲学家索伦·克尔凯郭尔（Søren Kierkegaard）说过一句话：
+
+
+Life can only be understood backwards; but it must be lived forwards.
+
+只有向后回首时才能理解生活，但生活却必须向前。
+
+
+当你回首职业生涯的来路时，终于理解了职业倦怠，但前路之上，还会碰到它，而你已经知道该如何面对它了，对吧？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/40局部最优：如何逃离？.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            40 局部最优：如何逃离？
+                            之前看过一些关于算法方面的书，提到了一些最优化问题。最优化问题在现实中非常常见，比如工程设计中，怎样选择设计参数，使得设计方案能以尽量低的成本预算满足设计要求。而近年来热门的机器学习建模也是一个最优化问题，基于一组已知的数据去构建一个模型，让这个模型去适配未来未知的数据达到最优，然后求解关于这个模型的参数。
+
+在求解最优参数的算法中，很多都有一个缺陷，就是容易达到一种局部最优点，即：参数的选择尝试收敛到了一小块范围内，无论再怎么尝试变化都没法取得更优的结果。而从全局来看，这并不是最优的选择，但算法此时就进入了一种尝试的徘徊状态，这就是局部最优点，但算法并不知道这到底是不是全局最优的。
+
+对于我们这些自诩智能的人，在成长的路上，其实也经常陷入这样的成长局部最优点。
+
+爬山
+
+关于成长最形象的类比便是爬山，但爬到山顶的路并不总是向上的。
+
+我长居成都，每过一阵就会去爬一回成都附近的青城山。像青城山这种著名景区的山，总有很多路标告诉你，沿着这条路一直走，你就能到达山顶。即使这条路有时会向下走，让你产生下山的感觉，但你也不会动摇，因为路标已经告诉你了，山顶就在前方，那里才是你的目的地。虽然成长这一路就像爬山，成长路上的感觉也和爬山相似，但不同的是，成长的路上并没有清晰的路标告诉你山顶在哪里。
+
+有时你很幸运地爬上了一个高点，你并不知道这个高点是否就是山顶了，因为再往前走，无论哪个方向的路都是向下的，你会心下疑惑：这是要下山了吗？
+
+即便你明确知道了这个高点便是此山的山顶，有时也会遗憾地发现原来这山只有这么高啊。就像青城山名气虽大，但山并不高，海拔只有 1200 多米。你站在山顶，虽然是此山的最高点，但你知道这不过你成长路上的局部最优点，继续前行，则不可避免地先要下山。
+
+爬山的全局最优点，应该是珠峰顶，但不是所有人都能爬得上去的。每个人都有自己期望的一个高度，比如我登高爬山是想看看云海，但青城山的高度还不够，也许峨眉山（海拔 3100 米）就够了。
+
+我们在成长（爬山）的路上，会进入局部最优点。一方面可能是 “山形” 所致，要继续上山的路需要先向下走，而向下的疑虑又会让我们徘徊不前。另一方面，可能是此 “山” 只有这么高了，就像青城山，你想看云海，可能就得换一座山了。
+
+徘徊
+
+所有的局部最优点，都意味着我们爬到了一定阶段，在这个位置徘徊不去，恋恋不舍。
+
+十多年前，我刚毕业找工作那时，外企在国内的吸引力可以相比今天互联网行业的头部企业。我也想进入外企这座 “山”，屡屡尝试，但每次都卡在英语口语面试，屡屡失败。同寝室的另一位同学则顺利进入一家国外的电信行业外企，获得的 offer 薪酬比我们平均高了 50%，让人羡慕不已。
+
+数年后，我们同学再次相聚，听闻该外企在中国已经被当时的华为、中兴竞争的步步退缩，业务缩水不少，已有裁员迹象。当时，同学会上，都劝这位同学早做打算，但他表现为瞻前顾后，徘徊不决，还想看看情况。一年后，我当时也正在做浙江省的电信项目，该同学所在公司的系统正被我当时的公司取代，没多久就听闻该公司进入了破产清算。
+
+曾经领先的电信行业设备服务公司，就这样退出了市场。那位同学就算曾经站的位置再好，“山” 都塌了，何谈继续攀登。这样的情况，有时主动的转身，比被动的离开可能要从容得多。
+
+而另一个朋友的故事，经历过后再回首一看，更让人扼腕叹息，可惜当时的我也是见识有限，给不了更好且更坚决的建议与支持。
+
+那时，小米公司刚成立不到一年，第一款手机尚未发布，正处在快要井喷发展的扩张期，到处找人，正好也找到了我这位朋友。但朋友觉得自己所在公司也还不错，也能成长，正“爬山爬得不亦乐乎”，遂放弃。
+
+过了两年，朋友又有了另一次机会，微信来了，给了机会，但她正考虑准备生孩子，同时又考虑在当前公司已经熟悉，且业务稳定，换新公司难免需要打破现状和当前的节奏，遂徘徊一阵，选择停留。
+
+后来再看，以前公司的最高点，相比这两座 “山”，也就相当于它们的山脚下。但有时职业的路径就是这样，我们迷茫、徘徊，正是因为 “不识庐山真面目，只缘身在此山中”。跳脱不出来，看不见 “山” 的全貌。
+
+审视下你的当下，再回顾下你的职业生涯，你花了多少时间和功夫来看清自己正在攀爬的 “山”，它的高点能让你去到你想去的地方吗？能让你看到你想看的风景吗？有时，我们大部分的努力，都没有什么进展和结果，仅仅是让我们能勉强呆在同一个地方。
+
+看清了自己目标的高山，发现自己爬错了山，要舍得离开；停留在低矮的山上，无论再努力，看到的风景也有限。
+
+逃离
+
+如何知道你正站在局部最优点上徘徊呢？当你知道自己做得很好，但却没有感觉到成长与进步时，那么也许你就正在徘徊了。
+
+在我的成长路上，也经历过一些徘徊点，这里我分享几个这一路上关于逃离的故事。工作早期，我做银行业的企业软件开发，被外派到了客户公司的项目组。在那里，不仅仅需要写程序、查 Bug，还需要兼顾从售前技术咨询、需求分析谈判到售后技术支持，甚至包括客服咨询解答都要涉及。正常的白天（朝九晚五）是没有一刻安静的时间能写写代码的，都是在客户下班后才能有个安静时段做做编码的事情。
+
+一年后，我有些困惑，因为我感觉自己做的事情太杂，但似乎又没一样东西做精、做深的。当时的想法是以技术立身，一年下来却不免惶惑。我感觉自己选错了山，没必要继续爬下去，因为我已经看到了当时大我十岁的项目经理也许就是这座山的一个局部最优点。一年后，我选择了逃离。
+
+之后，该怎么选下一座山？第一考虑自然是想离技术更近，做的更纯粹一些，另一个无法免俗的考虑自然还是希望收入也能提高一些。如今回想起来，当时为了一千块的差距，纠结了半天也不免哑然失笑。最后的选择，其实也是马马虎虎，运气好的一面是选对了技术，这次不做项目，做产品了，作为程序员在里面做的工作更纯粹了；运气差的一面是，还是没选对行业。
+
+从金融行业软件开发转到了电信行业软件开发，而当时一个新的行业——互联网，正方兴未艾。相比之下，当时的电信行业应该正在迅速步入成熟期，拥有成熟度最高且用户流量也最大的信息化系统。一入此 “山” 中，便埋头修炼技术，熟悉行业业务，直到数年后，蓦然发现似乎又到了一个局部最优点：技术无法再快速进步了，业务领域也已经熟得不能再熟了。
+
+在原地徘徊了一段时间后，我选择了第二次逃离，但这次困惑更大。我换了一个城市，在这里找了好几个月工作，见了很多很多的 “山”，却发现居然没有一座 “山” 乍一看比之前的更高、更大，顶多和之前差不多。
+
+我有些沮丧，我只是不愿又重新立刻去爬一次差不多的山。就像有次一早爬青城山，下午回到山脚，有人问“谁愿意再爬上去一次”一样，当然没人愿意。但如果山顶有一百万，再爬上去就能得到呢？我想这样也许会有不少人愿意吧。但现实的生活是，有时会让你迫不得已重新爬上刚下来的“山”，但“山顶”却没有任何额外的奖励。
+
+在我的故事中，我一次次逃离，是为了什么？因为失去了成长的感觉。每一座 “山” 刚开始爬时，你会对它的风景充满新奇，会有一条陡峭的上升之路，之后慢慢失去了新奇感，而很多工作任务渐渐变成了自动化的处理，不需要学习新的技能，失去了有意识的反思，从而让成长停滞。
+
+当然，逃离，不一定都是换一座 “山”，也有可能是换一种爬山的方式，找到一条新的路。
+
+在日常工作中，你可以尝试问问自己，对于十年后而言，现在的工作和事情，哪些会是很重要的？哪些会让你的技能变得更好？这就需要你有意识地试图在一些你已经知道如何做的事情上，再去做得更好。如果没有这种有意识的尝试与努力，很可能你就还在原地依赖过往的经验和技能自动化地完成同样的事情。
+
+算法进入了局部最优解，通常都是通过在环境参数中引入一些震动来帮助算法脱离，继续寻找更优点，而成长的路何尝不是呢？
+
+有时，有人会同时面对好几座山都想爬，但因为种种原因（主要还是生活所迫）只能爬其中一座。当你站在你选择的这座山的一个高点，远远看到曾经放弃的山峰，会感到徘徊遗憾么？
+
+进入局部最优，徘徊于局部最优，逃离局部最优，都是你的选择。而站在局部的最优点，走出徘徊的第一步，总是从下山开始，而这样的选择并不容易。
+
+最后，能否分享一下：如今你正在爬怎样的“山”？爬到了什么位置？以及你是如何选择的？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/41沟通之痛：如何改变？.md

@@ -0,0 +1,146 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            41 沟通之痛：如何改变？
+                            沟通问题，一直都是程序员的痛点。
+
+隔壁专栏（左耳听风）的陈皓以前在他的博客上写过一篇文章叫《技术人员的发展之路》，里面提及职业发展到一定阶段，也许你就会碰上一些复杂的人和事，这种情况下他写道：
+
+
+这个时候再也不是 Talk is cheap, show me the code! 而是，Code is cheap, talk is the matter!
+
+
+这里的 Talk 其实就是沟通，在工作中你要是留心观察，就会发现很多沟通问题，比如，跨团队开会时常发生的一些分歧和争论。沟通，越发成为一件重要的事，至少和写代码同等重要；沟通清楚了，能让我们避免一些无谓的需求，少写不少无效的代码。
+
+然而现实中， 沟通问题，有时却被作为程序员的我们有意或无意地回避与忽略了。面对沟通问题，我们该如何看待和分析这个问题，并做出一些改变呢？
+
+一、木讷与沉默
+
+木讷与沉默，这两个名词似乎已变成了程序员的标签，它们形象地体现了程序员在沟通中的表现。
+
+在程序员的世界里，沟通的主要场景可能包括：与产品经理沟通需求，与测试同学推敲 Bug，与同行交流技术，给外行介绍系统，还有和同事分享工作与生活的趣闻，等等。然而，有些程序员在分享趣闻时，与谈需求或技术时的表现大相径庭，刚才明明还是一个开朗幽默的小伙，突然就变得沉默不语了。
+
+沉默有时是因为不想说。特别在沟通需求时，有些程序员默默不言，但心里想着：“与其扯那么多，倒不如给我省些时间写代码！”然而，程序员写出的代码本应该是公司的资产，但现实中代码这东西是同时带有资产和负债双属性的。
+
+需求没沟通清楚，写出来的代码，即使没 Bug 将来也可能是负债。因为基于沟通不充分的需求写出来的代码，大部分都是负债大于资产属性的，这最后造成的后果往往是：出来混都是要还的，不是自己还就是别人来还。
+
+有些程序员可能会争辩道，“与人沟通本来就不是我们所擅长的，再说了我们也并不是因为热爱跟别人聊天才做软件开发这一行的。”这个言论很有迷惑性，我早年一度也是这么认为的。
+
+我毕业去找工作那年，外企如日中天，所以我也去了当时心中很牛的 IBM 面试。面试过程中的大部分交谈过程和内容现在我都记不清了，但就有一个问题至今我还记忆犹新。面试经理问我：“你是喜欢多些跟人打交道呢，还是跟电脑打交道？”当时的我毫不犹豫地回答：“喜欢跟电脑打交道，喜欢编程写代码，而且我自觉也不擅长和人打交道。”
+
+然后，我就被淘汰了。后来我才明白了，其实当时的这类外企挂着招工程师的名义，实际需要的更多是具有技术背景和理解的售前技术支持，因而就需要所招之人能更多地和人沟通去解决问题，而不只是写代码解决问题。
+
+结合我自己多年的工作经历和经验来看，即便你仅仅只喜欢写代码，那么和人的沟通能力也依然是你必须跨过去的门槛。《计算机程序的结构与解释》有云：“程序写出来是给人看的，附带能在机器上运行。”
+
+其实，写代码本身也是一种沟通，一种书面沟通。沟通从来都是个问题，书面沟通也同样困难。
+
+二、争论与无奈
+
+程序员最容易产生沟通争论的地方：沟通需求和沟通技术方案。
+
+在程序员的职业生涯路上，我们不可避免地会碰到和同事关于技术方案的争论。我从中得到的教训是：千万不要让两个都自我感觉很牛的程序员去同时设计一个技术方案。
+
+假如不巧，你已经这么干了并得到了两个不同的方案，那么记住，就别再犯下一个错：让他们拿各自的方案去 PK。因为这样通常是得不到你想要的“一个更好的方案”，但却很可能会得到“两个更恼怒的程序员”。
+
+既然分歧已经产生了，为了避免无谓的争论，该怎么解决呢？
+
+1. 以理服人
+
+首先，把握一个度，对事不对人，切勿意气用事。
+
+有些程序员之间的分歧点是非常诡异的，这可能和程序员自身的洁癖、口味和偏好有关。比如：大小写啦、命名规则啦、大括号要不要独立一行啦、驼峰还是下划线啦、Tab 还是空格啦，这些都能产生分歧。
+
+如果你是因为 “该怎么做某事或做某事的一些形式问题” 与他人产生分歧，那么在很多情况下，你最好先确定分歧点是否值得你去拼命维护。这时，你需要判断一下：技术的 “理” 在什么地方？这个 “理” 是你值得拼命坚守的底线不？用这个 “理” 能否说服对方吗？
+
+我所理解的技术的 “理” 包括：先进性、可验证性、和团队的匹配性、时效性、成本与收益。另外还有一些不合适的“理”，包括：风格、口味、统一、政治等。
+
+不过有时候，有“理”也不代表就能搞定分歧，达成一致。毕竟林子大了，不讲“理”的人也是有的，那么，就需要换一种方式了。
+
+2. 以德服人
+
+分歧进入用 “理” 都无法搞定时，那就是应了那句古词：“剪不断，理还乱”。
+
+这时继续“理”下去，不过都是互相耍混罢了。“理” 是一个需要双方去客观认可的存在，而越“理”越乱则说明双方至少没有这种客观一致性的基础，那就找一个主观的人来做裁决吧。
+
+这个人通常就是公司所谓的经验丰富、德高望重的“老司机”了，并且双方也都是认可的，比如架构师之类的。但是这类主观裁决也不一定能保证让双方都满意，有时实力相当的技术人也容易产生类似文人相轻的状况。不过看在“老司机”的 “德” 面上，也能勉强达成一致。
+
+“老司机”裁决最好站在他所认同的 “理” 这个客观存在上，这是最好的，不过这也取决于“老司机”的工作素养和价值观了。
+
+3. 以力服人
+
+最差的状况就会走到这一步，特别在跨大部门的沟通中。
+
+技术方案无法达成一致，也没有一个跨两个部门的有德之人可以转圜化解，就会升级到这个地步。最后就是靠粗暴的权力来裁决，看双方部门老大或老大的老大，谁更有力或给力。一般来说，非关键利益之争实在没有必要走到这一步了。
+
+三、认识与改变
+
+做出改变的第一步是要能认识到，否则改变不可能发生。
+
+程序员会认识到沟通很重要，有时甚至会比写代码更重要吗？著名的技术型问答网站——Stack Overflow的两位创始人杰夫·阿特伍德（Jeff Atwood）和乔尔·斯波尔斯基（Joel Spolsky）都对此有正面的认识和见解。
+
+杰夫说：
+
+
+成为一名杰出的程序员其实跟写代码没有太大关系。
+
+做程序员确实需要一些技术能力，当然还要有坚韧不拔的精神。
+
+但除此之外，更重要的还是要有良好的沟通技巧。
+
+
+乔尔的观点是：
+
+
+勉强过得去的程序员跟杰出程序员的不同之处，不在于他们掌握了多少种编程语言，也不在于他们谁更擅长 Python 或 Java。
+
+真正关键的是，他们能不能把他们的想法表达清楚，杰出的程序员通过说服别人来达成协作。
+
+通过清晰的注释和技术文档，他们让其他程序员能够读懂他们的代码，这也意味着其他程序员能够重用他们的代码，而不必重新写过。
+
+要不然，他们代码的价值就大打折扣了。
+
+
+按照程序员解决技术问题的习惯，就是把一个大问题拆解为多个部分的小问题，那这里我们也对沟通做下拆解，它包括三个方面：
+
+
+内容
+形式
+风格
+
+
+从内容上看，虽说你想沟通的本质是同一样东西或事情，但针对不同的人，你就需要准备不同的内容。比如，同内行与外行谈同一个技术方案，内容就是不同的。这里就需要你发挥同理心和换位思考的能力。保罗·格雷厄姆（Paul Graham）曾在他的书《黑客与画家》中写道：
+
+
+判断一个程序员是否具备 “换位思考” 的能力有一个好方法，那就是看他怎样向没有技术背景的人解释技术问题。
+
+
+换位思考本质上就是沟通技巧中的一种。
+
+从形式上看，沟通其实不局限于面对面的谈话。面对面交谈是一种形式，书面写作又是另外一种形式，连写代码本身都是在和未来的自己或某个你尚未谋面的程序员沟通。
+
+程序员确实有很多都不擅长面对面的沟通形式。面对面沟通的场景是很复杂的，因为这种沟通中交流传递的载体不仅仅是言语本身，眼神、姿态、行为、语气、语调高低，甚至一种很虚幻的所谓“气场”，都在传递着各种不同的信息。而大部分人都不具备这种同时控制好这么多传递渠道的能力，也即我们通常说的“缺乏控场能力”，这里面隐含着对你其他能力的要求，比如：临场应变、思维的活跃度与变化等。
+
+从风格上看，不同方式和场景的沟通可以有不同的风格。比如面对面沟通，有一对一的私下沟通，风格就可以更随性柔和些；也有一对多的场景，比如演讲、汇报和会议，风格就要正式一些，语言的风格可能就需要更清晰、准确和锐利一些。
+
+沟通之难就在于清晰地传递内容和观点。当你要向其他人详细解释某样东西的时候，你经常会惊讶地发现你有多无知，于是，你不得不开始一个全新的探索过程。这一点可以从两个方面来体会：
+
+
+你只需要尝试写点你自认为已经熟悉掌握的技术，并交给读者去阅读与评价。
+每过一段时间（比如，一个季度或半年）尝试去总结，然后给同事分享下你工作的核心内容，再观察同事们的反应和听取他们的反馈，你就能体会到这一点了。
+
+
+所以，沟通改变的第一步就是从考虑接收方开始的，看看接收方能吸收和理解多少，而非发送了多少。而沟通问题的三个方面——内容、方式与风格——的考虑，都是为了让接收更方便和容易。
+
+江山易改，本性难易，有时候我们做不到就在于这一点。但现实并不要求程序员成为所谓的沟通达人，只是需要主动认识到身边的沟通问题，去进行理性和逻辑地分析、拆解并做出适当的调整。
+
+从认识我们的本性开始，控制情绪，从而去规避无奈的争论；认识清楚沟通问题的本质是要方便接收，达成共识，保持换位思考和同理心，改变自会发生。
+
+关于沟通的各种形式，每个人可能都有自己擅长和偏好的方面，比如我就更擅长文字沟通，而不擅长一对一当面沟通，那么你呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/42技术停滞：如何更新？.md

@@ -0,0 +1,128 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            42 技术停滞：如何更新？
+                            我们从开始学习程序，到工作十来年，中间可能会出现几次自我感觉技术停滞了。而在这个过程中，我们也会不断地学习很多新技能，但而后其中的不少也会被淘汰在时间的旅程中。
+
+一方面，我们在不断地打磨、提升技能，去解决工作中的问题，但久而久之，就会发现技能的提升速度越来越慢，竟渐至停滞，感觉不到进步了。另一方面，程序员所处的这个行业，技术的变化很快，潮流此起彼伏，难免产生技能焦虑。
+
+有时，我们会不免幻想要是学会什么屠龙之技，从此高枕无忧，该多好！但这终究只是幻想，哪里又有什么屠龙之技呢？那面对技术停滞，技能过时，又该如何保持更新，与时俱进？
+
+技术停滞
+
+技术停滞是如何发生的？
+
+程序员，最重要的就是编程技能。每天的工作可能就是编程写代码，在早期还不够熟练时，你还能感觉到进步，这种进步就是从不熟练到熟练。进入熟练期以后，你可能感觉这项技能就提升得很慢，甚至一度停滞了。
+
+单纯的编程实战其实并不能持续地提高一个人的编程技能，想想体育运动员，又有哪一个每天的日程就只是参加比赛。运动员平时都是在进行刻意地训练，而关于习得甚至精通一门技能，最著名的理论应该是 “刻意练习”，如果非要在这份练习上加上一个期限，那就是：一万小时。
+
+关于 “刻意练习”，不少书或文章中都讲了很多案例来说明它的有效性，但总结起来关键就下面三点：
+
+
+只在 “学习区” 练习，练习时注意力必须高度集中。
+把训练的内容分成有针对性的小块，对每一个小块进行重复练习。
+在整个练习过程中，随时能获得有效的反馈。
+
+
+刻意练习是为习得真正的技能所设计的，它和获取知识不同，知识就是那些你知道即为知之、不知即无知的东西，这可以通过读书获得。但技能是那些你以为你知道，但如果你没做过，就永远不会真的知道的事情。
+
+在程序员足够熟练了之后，每天的这种编程实战型工作就不会再是处于 “学习区” 的练习了，而是进入了 “舒适区” 的自动完成。真正的职业竞技体育运动员每天的日常训练都是在 “学习区” 的刻意练习，到了上场比赛则是进入 “舒适区” 的自动完成。然而很多熟练程序员的日常工作则是在 “舒适区” 的自动完成，工作之外则是另一种 “舒适区” 的娱乐休闲。
+
+停滞，就是这样发生的。
+
+技能保养
+
+感觉停滞的技能，如果工作依然需要它，其大的技术方向发展趋势依然明朗，那么这样的技能是值得好好保养，并继续提高的。而保养和提升技能的方法，“刻意练习” 依然是不二之选。
+
+关于 “刻意练习”，有时我们即使一直保持在 “学习区” 的重复练习，却也可能感觉不到进步，这有可能是因为重复的次数和强度还不够。我曾经就犯过这个错：英语这门技能从毕业后就停滞了（可能还倒退了些）十年，在工作十年后我重启了学习掌握英语这门技能的练习，但刚开始阶段我完全低估了需要重复练习的次数和强度。
+
+第一年，仅仅在每日的工作之余，我会花上大约一小时来进行听说读写的练习。但即使每日都能保障一小时的时间，一年下来也不过区区 300 多小时，更别提分散在听说读写四个分支上了。最后的结果可想而知，就是那一年结束后，并没有哪一项在让我感觉到一点点的进步。
+
+在决策科学中有一个概念叫 “基础比率（Base Rate）”：
+
+
+所谓基础比率，就是以前的人，做同样的事，做到的平均水平。
+
+
+也就是说，如果别人做这件事需要那么长时间，基本上你也需要那么长时间，因为可能你没有那么特殊，只是每个人都会“觉得”自己是特殊的、例外的罢了。所以，当我调查了下学英语人群的基数和真正算是掌握并熟练运用这门技能的人数，以及他们所花费的时间，我就知道自己大大低估了需要重复练习的强度。
+
+重复，是有针对性的强化练习，其本身是练习过程，而非练习内容。每一次的重复过程中都需要根据反馈进行有针对性的调整，以取得练习效果的进步。
+
+而重复的刻意练习总是辛苦的，辛苦就是我们付出的技能保养成本。
+
+技能开发
+
+技能不仅仅会停滞，还有可能会过时。
+
+就拿我来说，我这十多年编程生涯走过来，从早年的 Basic 语言，到后来的 C，再到后来为了做 C/S 架构的项目学习了 Delphi，之后 B/S 架构开始兴起，又开始写起了 JSP，转到 Java 上来。经历了如此多艰辛的学习路线，曾经掌握过不少技能，但如今除了 Java ，其他的都过时淘汰得差不多了。
+
+旧技术过时了，肯定是因为有另一种新的技术来取代了它，我们只需定期保持跟踪，观察现有掌握的技术是否可能被新出现的技术所取代。一般来说，新旧技术的更替都是有一定周期和一个持续的过程的，这期间给了我们足够的时间来学习和开发基于新技术的新技能。
+
+而针对不同的学习目标，采用的学习路线也会不同。
+
+如果需要学习新技能来解决工作上的一个具体问题，那这样的目标更适合采用深度路线学习方式，这是解决特定问题的一种捷径，属于痛点驱动式方法，能让你快速排除障碍，解决问题，而非先找到相关书籍，从头读到尾，知道一个整体大概。
+
+一般技术书籍的组织方式都是按主题的相关性来编排的，系统体系性很强，但却不是按你解决问题需要知道的内容来组织的。所以，技术书籍更适合于在你解决问题的过程中用来参考。完整地读技术书籍能增长你的知识，但却无法快速习得技能，并解决你的问题。
+
+反过来，另一种情况，面临一种新兴技术，比如，近年火热的人工智能与机器学习，你不是需要解决一个具体问题，而是要对这类新兴技术方向做评估、判断和决策。那么学习的方式就又完全不同，这时采用广度路线学习就更合适。
+
+对如何开发一门新技能，《软技能》一书的作者曾在书中分享过他的一个十步学习法：
+
+
+了解全局
+确定范围
+定义目标
+寻找资源
+学习计划
+筛选资源
+开始学习，浅尝辄止
+动手操作，边玩边学
+全面掌握，学以致用
+乐为人师，融汇贯通
+
+
+这个方法和我自己在实践中养成的习惯基本一致。在深度路线学习中，对全局、范围、目标的定向更聚焦，因此寻找、筛选的资源会更窄，学习计划的迭代期更短，很快就走完了前 6 步，并进入动手实践、反复迭代的过程中，直到把问题解决。
+
+而在广度路线的学习中，前 6 步会花去大量的时间，因为这时你面临的问题其实是对新技术领域边界的探索。这就像以前玩《魔兽争霸》游戏中，先去把地图全开了，看清楚了全貌，后面再进军时就能选择最优路径，避免了瞎摸索。
+
+这个类比中不太恰当的是，游戏中开地图实际挺简单的，但现实的技术领域中，地图全开基本是不太现实的，一是地图实在太大，二是地图本身也在演变中。只能说尽可能在前期的探索中，所开的地图范围覆盖更广至需要去解决的问题领域。
+
+沉淀能力
+
+技术也许会停滞，技能也可能会过时，但其中的能力却可以沉淀下来，应用于下一代的技能之上。
+
+汉语中容易把能力和技能混为一谈，在英语中，技能对应的词是 Skill，而能力对应的是 Ability。技能是你习得的一种工具，那么能力就是你运用工具的思考和行为方式，它是你做成一件事并取得成果的品质。
+
+程序员爱说自己是手艺人，靠手艺总能吃口饭。五百年前，鞋匠也是手艺人，但进入工业革命后，制鞋基本就由机器取代了。手工制鞋是一门技能，它的过时用了几百年时间，但如何做一双好鞋的能力是不会过时的，五百年后人们还是要穿鞋，还要求穿更好的鞋。这时鞋匠需要应对的变化是：换一种工具（现代流水线机器生产）来制作好鞋。而现代化的制鞋机器技术实际上还进一步放大了好鞋匠的能力，提升了他们的价值。
+
+对程序员来说，程序技能的过时周期相比制鞋技能却要短得多，每过几年可能就大幅变化了，是需要定时更新的消耗品，而能力才是伴随技能新陈代谢，更新换代的固定资产。技能用熟练了就成了工具，熟练应用工具能快速解决已碰到过的老问题。而沉淀下来的能力，是为了应对并解决新问题，甚至为了解决新问题，可以去开发新的技能或创造新的工具。
+
+那么程序员需要去沉淀哪些能力？
+
+作为程序员最基本的自然是代码能力。能够写程序，只能算是技能过关吧，而能写好程序，才算具备了程序员的基本代码能力。代码能力的识别，最简单的方式就是维护一份公开可跟踪的记录，比如参与开源项目贡献，在 GitHub 上留下你的代码简历。
+
+从程序员到架构师，“架构”显然不是一种技能，而是综合应用多种技能的能力。架构师也许不像在工程师阶段需要写大量代码，但实际没有代码能力是做不了架构的。代码能力是架构能力的底层能力要求。但仅此一项能力却也远远不足，这里就先不展开了，后面会专门有一篇文章谈架构师能力模型这个主题。
+
+除了技术能力，如果有可能可以适当跨出技术的边界，去了解下产品、管理、运营和传播等方面的能力。为什么呢？一方面，技术能力的提升总会到达平台期，增长变得缓慢，而了解学习一下其他方面的全新能力，可能会让你找到新的成长点，重新找回快速成长的感觉。
+
+另一方面，个人很多综合能力的差别，有时就是要靠作品来体现的。完成作品需要有一些产品思维，需要自我规划与管理能力，而推广作品需要运营和传播能力。这些相关的能力，最终都会成为你核心能力体现——作品——的放大器。
+
+如果你是一棵树，能力是根，技能是叶；春去秋来，时过境迁，技能过时，落叶归根；沉淀下来的能力，将如春风吹又生，新的技能自会发芽。
+
+而这一切的能力与技能之母，又叫元能力，自当是学习能力。
+
+虽有俗语说：“技多不压身”，但实际很多技能是有保养成本的，编程技能就是一种，特别是和特定技术有关的编程技能。所以，同时保养很多技能是不太合理和现实的，更优化的选择是：持续保养主要的生存技能，合理开发辅助技能，形成自己独有的技能组合，沉淀能力模型，发展能力矩阵。
+
+当时代发展，某些技能会过时，但能力矩阵不会过时，它当与时俱进；永不会有停滞的时候，它总是在进化。而对于过时的技能，除了既往不恋，我们还能做什么呢？
+
+技能如剑，金庸老爷子笔下有一 “剑魔”，一生用剑经历 “利剑无意”“软剑无常”“重剑无锋”“木剑无俦”“无剑无招”，最终剑已埋冢，人却求败。
+
+如今你的哪些技能已过时？又沉淀下来怎样的能力呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/43无法实现：困扰与反思.md

@@ -0,0 +1,107 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            43 无法实现：困扰与反思
+                            程序员有句口头禅叫：“技术上无法实现！”这句话，在我过去多年的程序员职业生涯中经常听见，甚至我自己就曾说过很多次。如今，当我再次听到有人说出这句话时，不禁开始反思起来，为什么程序员爱说这句话呢？为什么曾经我也时不时说这句话呢？
+
+一仔细思考，就惊讶地发现一个事实：这句口头禅背后隐藏着一个阻碍我们成长的陷阱。
+
+一、困扰
+
+当接到一个需求或碰到一个问题，我们回上一句：“技术上无法实现！”这是真的无法实现吗？还是隐藏着其他的困扰？
+
+1. 不知
+
+当我刚开始工作的第一年，我在一家银行客户现场工作。当时要给银行的出纳管理部做一个系统，这个系统有个功能就是上传各个国家的高清真假币鉴别对比图片，然后银行的出纳和柜员就可以在系统上学习各个国家纸币的鉴别方式了。
+
+针对这些高清纸币图片，客户因为怕别人盗取乱用，就要求必须对图片做加背景水印的功能。当我们在召开需求讨论会时，我听到这个需求就懵了，因为完全不知道要怎么做。毕竟当年我才刚刚开始学习如何做 Web 化的管理系统，从来没有用程序处理过图片。
+
+彼时，当我想起程序化的图片处理时，我就只能想起像 PhotoShop 那样高度专业化的图片处理工具软件，觉得这肯定是一个很复杂的事情。所以，当我们讨论起加背景水印的功能时，我自然脱口而出：“这在技术上无法实现！”
+
+然后我们进一步谈起，当前客户他们是怎么做的。客户确实是找了专门的外包设计公司用 PhotoShop 来给图片一张张手工加水印。这听起来就是一个比较繁琐的过程，所以，当我回答“在技术上无法实现”时，客户都是业务人员，也不太懂程序技术上的事，听到我的答案也就略显失望。
+
+好吧，如今回想起来，我说“技术上无法实现”时，仅仅是因为当时的我并不知道如何去实现。而且想当然地感觉要进行图片处理，必须要具备有 PhotoShop 一样的专业背景知识，而这对当时的我而言是完全不能想象的。
+
+因此，当时我说出的那句“技术上无法实现”，仅仅是因为不知和不解而心怀畏惧。因为畏惧，所以我用了这句口头禅来回避了这个问题，甚至没有去调研一下技术可行性，就由此固步自封，在这片知识领地留下了一片空白，也不能为客户创造更进一步的价值。
+
+“技术上无法实现” 的口头禅，此时成为了遮挡我们因不知而畏惧的面具。
+
+2. 不愿
+
+有一年，我出差在客户现场赶项目，连续加班了四个周末，也就是大概一个月在连续上班。终于我们的项目快要如期上线了，每个通宵的早晨，看着东方慢慢变得红润透亮的天空，感觉已经快要看到胜利的曙光了。
+
+就在这样一个曙光照耀的早晨，项目经理跑来对我们说：“原有的一块业务逻辑今天在和客户聊起时，他们说也只是试试这个流程，可能要改变。但我们的实现方式太僵硬，都是硬编码赶出来的。要不我们改成更灵活的、可以通过配置的方式，一旦上线后再改起来就更麻烦了。我可以先去和客户再沟通下，给我们再争取点时间。”
+
+一下子，我们都被打击得不行，改成配置怎么改？逻辑那么复杂，又不是那种简单的开关式配置。当时，项目经理早已脱离技术一线时间颇久，也一时半会儿没啥方案。在沉默地思考了一阵后，我又说出了那句话：“逻辑太复杂，变动太大，这短期在技术上无法实现的。”
+
+其实，那时我心里是有一个方案的，如今看来虽不是什么优秀的方案，但也是当时我唯一知道且可行的方案。就是通过 Java 的动态类加载机制，把业务逻辑外移，流程内置的方式以便可以动态热加载新的业务逻辑类。但这意味着可能要面临一次重大的重构，又是两周的持续加班，而我当时只是想赶快离开这沉默的讨论会，去美美地睡上一觉。
+
+后来，这个故事在我睡醒后依然以我妥协结束。我建议了这个方案，最后当然也是我去实施了这个方案，庆幸的是并没有如“预料”那般加上两周班，只用了一周，项目就上线了。再之后的后续维护中，我又学习了新的东西，流程引擎，动态脚本，继续下一版本的重构，我们升级成了一个更好、更通用的方案。
+
+当时我说出的那句“技术上无法实现”，只是因为觉得很麻烦，不愿意而已。后来睡醒后，回了一些血，有了能量，觉得应该接受这个挑战。因为客户的需求变化就是一个客观事实，也不会因为我的主观意愿而改变。
+
+“技术上无法实现” 的口头禅，此时成为了我们推脱的借口。
+
+二、反思
+
+不论是 “不知” 还是 “不愿”，“技术上无法实现” 的口头禅看来都不会给我们带来什么帮助，它反而阻碍了我们进一步做出更好的产品，从而给客户留下遗憾。
+
+随着工作经验的增多，技能的积累，我便越来越少说这句话了。事实上，我发现大部分的用户需求，技术上总是可以实现的。这些需求的真正限制，要么是时间，要么是资源。
+
+所以，面对一个紧迫的或不合理的客户需求，甚至诉求时，不应该再以如此苍白的一句话去应对了。这个需求背后涉及的技术实现，要么可能你现在未知，要么你至少知道一个方案，只是觉得过于复杂，而且会带来很多“副作用”，所以不愿意这样去做罢了。
+
+但总之，你需要一个办法去应对一个让你觉得 “技术上无法实现” 的需求。我建议不要立刻像我当年那样做出如此简单的判断就推脱过去，其实我们完全可以把这样的问题放在下面这样的框架中去思考下。
+
+1. 全局背景
+
+这一步的目的并不是要找到并确定实现方案，只是对这一问题涉及主题的相关内容有一个全局性的了解。
+
+近年我都在做京东咚咚，一个 IM 系统，所以就以此举个例子吧。不时我们会收到用户反馈在安卓客户端应用切到后台就会收不到消息，这里用户只是提供了一个说法，甚至都不算现象。但这是一个问题，而且是一个我觉得在技术上无法百分百根除的问题，换言之就是我可能想不出一个方案能让我的所有用户都再也不会碰到类似的问题。
+
+而用户碰到这样的问题可能的原因有：
+
+
+移动弱网络，消息投递失败率高；
+应用切后台就被系统杀掉，所以收不到；
+第三方推送渠道，比如：某一类用户完全没有这种渠道可达；
+应用本身的问题，比如：Bug，版本碎片导致的兼容性问题。
+
+
+以上简单的问题分类，背后都隐藏着一个解决或优化问题所需的巨大且复杂的实现方案。针对每一类问题的方案，可以先去大概有个了解，但这里还不需要很深入。
+
+2. 聚焦范围
+
+对上面列出的全局背景问题分析分类后，会发现没有一个是轻松容易就能解决的。而且这时还必然面临资源和时间的问题，也就是在特定的资源和时间下，我应该优先解决哪类？所以，这一步的本质就是从上面的全局分类中，聚焦一个范围，然后集中深入调研评估。
+
+3. 定义标准
+
+前面说了用户仅仅反馈了一个说法，站在用户的角度，他们总是希望没有任何问题的。但站在我的角度，我知道我只聚焦了一部分问题，所以我需要清晰定义这部分问题解决的成功标准。
+
+比如，针对应用切后台就被系统杀掉，对用户无感知，所以认为收不到消息是有问题的。针对这个问题的聚焦范围，我可以提供第三方推送渠道在十分钟内的推送通知补偿，重新唤醒用户重回应用，避免消息的遗漏。通过估算每日活跃用户和可能投递给第三方渠道消息通知量以及第三方渠道自己标榜的投递成功率和业界一些经验数据，就能估算出该解决方案的标准：通知唤醒到底能补偿多少用户的指标。
+
+4. 深度评估
+
+有了范围和标准，剩下的就是深度评估方案路径问题。大体上任何一个方案，其中有些是你已经轻车熟路的实现路径，另一些则是你可能从未走过的陌生之路。
+
+轻车熟路的部分可能更容易评估，但很多程序员还是容易高估自己；而从未走过的陌生之路，就评估得更离谱了。关于评估，可以保守一些，因为一般来说现实总是比理想的路径曲折一些的。
+
+经过了上面四层思考框架的过滤，这时想必你已成竹在胸了，并能很好地衡量该技术实现方案的成本与收益。除此之外，进一步还需斟酌考虑的是方案是否足够优化，毕竟我们做工程就是要找到一条最优化的实现路径。
+
+当面对任何一个需求，除非能一下从理论上发现其实现的物理限制，我们恐怕不能够再轻易说出 “技术上无法实现” 了。即使真的是无法实现的需求，也有可能通过变通需求的方式来找到一条可实现的路径。“技术上无法实现” 的口头禅仅仅是我们阻挡需求的快捷方式，但这样的思维也阻碍了我们进一步去找到真正的实现路径和优化方案。
+
+
+“你看这个需求能实现么？”
+“哦…”
+
+
+改掉了这句口头禅后，有些问题也挺难简单地回答了。
+
+那你是否爱说这句口头禅呢？又是在怎样的情境下说的呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/44完成作品：理想与现实.md

@@ -0,0 +1,87 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            44 完成作品：理想与现实
+                            有时工作久了，会陷入这样一种状态中，整天不停地写代码，开发业务需求，周而复始，日子长了，自然觉着厌倦，感到似乎真的有点像 “码农” 了，日出而作，月落而息。在过去的某个时期，我应该也陷入过这样的循环之中，后来又是如何脱离的呢？
+
+困境：代码与罗马
+
+陷入这样一种写代码的 “困境”，还是要回归到写代码这件事本身上。
+
+写代码是因为有需求，需求来自业务的发展需要，经过产品经理再传递到程序员。刚开始，作为一个新手程序员，不停地为各种需求写代码。开发完一个，接着又是下一个，生生不息，循环不止。
+
+一开始也许会感觉有些累，但并没有产生太多的厌倦。这是一个从不熟悉到熟悉再到熟练的过程，这里有太多的新东西可以去探索和尝试，让你在疲惫中依然能获得了好奇心的满足和成长的快感，因此不会感觉厌倦。
+
+那技能从不熟悉到熟练需要多久呢？现在成为专家的要求已经有了共识：一万小时的刻意练习。但达成熟练要不了那么久，也许两三年足矣。有句俗语叫：“条条大道通罗马”。罗马，一座城市，包罗万象，类比到程序员这里就像一个个需要完成的业务需求。几年过去，每一条通往“罗马”的大道都被你走过了，再去往“罗马”时，自然找不到新鲜感了，困倦油然而生。
+
+继续停留在通往“罗马”的循环往复中，已无法让你继续成长为专家。而要想跳出这循环往复的路，无非就是不再去走那熟悉的条条通往“罗马”的大道，而是选择一条离开“罗马”的路，走出去，走向未知与未来。
+
+在一万小时的刻意练习中，“罗马”已逐渐成为过去的熟悉、熟练区，而离开“罗马”便是要进入下一个陌生的学习区。但也许还会有一种 “现实” 的困境让你不得不继续走向当前的“罗马”，那么这时就不妨换一个视角：既已对通往当前“罗马”的所有路都了然于胸，闭眼可达，那就仔细观察了解现在“罗马”的构成与运作机制，也许将来有机会去创造属于自己的“罗马”。
+
+从走向“罗马”到创造属于你的“罗马”，这里你的 “罗马”，就是你的作品。
+
+理想：作品与创作
+
+也许条条通往罗马的大道，堆砌罗马的砖石，有些已经消失在历史的尘埃中，但罗马作为一个时代和历史的作品，留了下来。
+
+今天我们再看什么是作品？维基百科上对“作品”的定义是：
+
+
+作品，亦称创作、创意、著作，是具有创作性，并且可以通过某种形式复制的成品。
+
+
+从这个定义来看，作品最重要的特质是：创作与创意。所以，只有包含了创意和创作性质的事物才能叫作品。那对于程序而言，怎样才算作品？你从网上复制来一段代码，解决一个问题，这不是创作，也不会成为你的作品。
+
+代码作品，可以小到一段函数、一个类，大到一个库或框架、一个服务，甚至一个系统。但打磨代码作品的方式，应该是定期对自己写完的代码进行沉淀、梳理和规整，提取可复用的功能，同样的功能只写一次，形成自己专属的编码脚手架和代码库。在以后的学习实践中定期反思，不断优化其效率和品质。
+
+当你再碰到类似功能的实现时，能直接复用库就复用库，不能直接复用的就在脚手架代码上进行扩展，后续的重心就放在了优化实现思路上。这样日积月累下来，你的程序思维和能力才会变得科学、高效，而且产生积累效应。最终，这些留下的代码库或脚手架都成为了你的作品。
+
+不过，同是作品，却有高下之分。吴军老师曾在文章里写过：“完成一件事，做到 50 分靠直觉和经验，做到 90 分要靠科学和技艺，而要做到 90 分以上则要靠艺术。”我是认同这个观点的，而且我们完成作品的目标应是 90 分以上，这是作品的特性决定的，因为创作就是艺术的核心所在。
+
+到了 90 分或以上的作品，也许分数相差无几，但市场价值却可能差异巨大。iPhone 就是一个很好的例子，它当是一件 90 分以上的作品，90 分的工程技术加上几分的艺术，相比差几分的同类，在市场上的价值和价格却是遥遥领先。
+
+作品，是创作的，创作是需要设计的，而设计是需要品味的，正如《黑客与画家》一书里所说：
+
+
+优秀作品的秘诀就是：非常严格的品味，再加上实现这种品味的能力。
+
+大多数做出优美成果的人好像只是为了修正他们眼中丑陋的东西。
+
+
+也许，我们可以先从感知和修正代码中丑陋的东西来训练这样的品味和能力。
+
+而完成作品的收益是什么？理想的情况下，也许我们期待直接从作品中获得经济收益，但这并不容易。十九世纪，有一名画家，一生作画数千幅，但只卖出过一幅，换回了四百法郎，这名画家就是梵·高。
+
+梵·高的例子比较极端，他的作品都是 90 分以上的，但在直接换取收益方面依然困难。而对于你来说，今天的作品虽不一定能立刻给你带来经济收益，但在你打磨作品的过程中，把“条条通往罗马的大道”都走完了，甚至还反复走试图找到更优化的路线，这会让你掌握系统化的知识和体系化的能力，同时还会让你的作品变得更值钱。你可以想象这样一个场景：当你给别人介绍自己时，只需要介绍自己的作品，而不再需要介绍自己的技能。
+
+成长的路上，写过的代码最终也许会烟消云散，但完成的作品会成为你点亮的勋章。
+
+现实：产品与特性
+
+作品要实现直接的经济收益，必须还要走完从作品到产品之路。
+
+产品，是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品，无形的服务、组织、观念或它们的组合。现实情况是，大部分时候我们的代码作品，都是存在于产品之中的，所以你需要关注包含了你的代码作品的更大范围的产品及其特性。
+
+如果产品无法获得市场的价值认同，技术作品自然也就埋没其中了。
+
+有个说法是：要做好技术需要懂业务和产品。这大体没什么问题，但需要提到的细节是懂的方向。技术不需要了解业务产品的每一个显性特征，一个足够大的业务产品，有无数的显性特征细节，这些全部的细节可能分散在一群各自分工的产品经理们中。所以应该说，技术需要懂的是产品提供的核心服务和流程，并清晰地将其映射到技术的支撑能力与成本上。
+
+另外，技术不仅仅需要支撑满足产品的全部显性和隐性服务特性，这些对于技术都相当于显性服务特性。而技术还有自己的隐性服务特性，这一点恰恰也正是高级和资深程序员需要重点关注的。所谓技术的隐性特性，通俗点就是程序员常说的非功能性需求，它的产生与来源都是源自程序和程序员本身。
+
+用一段新算法实现的函数取代了旧函数，那么多余的旧函数就变成了负债而非资产，是需要去清理的。重构代码变得更简洁和优雅，可读性增强，节省了未来的维护成本。一个能同时服务一万人的程序实例，你知道你没法加十个实例就能简单变成能同时服务十万人的系统。这些都是技术冰山下的隐性特征，显性的错误会有测试、产品甚至最终用户来帮你纠正，但隐性的错误却很难有人能及时帮你发现并纠正。
+
+产品的显性特性就如泰坦尼克号，而技术的隐性特性则是泰坦尼克号撞上冰山后的反应。一旦隐性的错误爆发，就像泰坦尼克号撞上了冰山，一切外显的繁华最终都将沉入海底。
+
+技术从特性到作品，去支撑产品的体验与服务，这是一条更现实的技术作品实现价值的路。
+
+从反复写代码实现需求的重复困境中，到打磨作品实现价值的理想，再回归产品化的现实之路。
+
+代码，有些人写着写着，就成了 “码农”；有些人写着写着，就成了作者；还有些人写着写着，就改变了你、我的生活。那你想成为哪一类人呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/45代码评审：寄望与哀伤.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            45 代码评审：寄望与哀伤
+                            我们都知道代码评审（Code Review）很有用、很重要，但现实中我所经历的和看到的团队，很少有能把代码评审落地得很好，并发挥出其应有作用的。这个问题困扰我已久。
+
+感性认识
+
+代码评审的作用，有一定经验的程序员们想必都会有感性认识。
+
+它是很多软件工程理论和方法学中的重要一环，对于提升代码质量和找出一些潜在隐患很有帮助，如果你有一些正式的代码评审经历过程，想必也能感性认知到其正面作用。但在我过去工作的这些年里，经历了几家公司，数个不同的团队，却几乎没有哪一个会把代码评审作为必要的一环去执行的。
+
+过去，我们总是在线上出现一些奇怪的疑难问题后，一群相关程序员才围坐在一起，打开相关代码来逐行分析，根据线上现场的“尸检”来做事后分析和推导。这样的事后代码分析实际上根本不是代码评审，也完全违背了代码评审的初衷。
+
+代码评审的初衷是提高代码质量，在代码进入生产环境前经过同行评审来发现缺陷，降低损失概率。这一点程序员都好理解，提前的代码评审就像雷达扫描我们重点关注的代码领地，以期发现或明显或隐藏的危险因素。
+
+漫画《火影忍者》里有一种忍术技能：白眼，这种技能有近 360° 的观察范围。程序员在写程序时力求思考全面，不留死角或盲点，但实际死角或盲点总是存在的。随着我们经历和经验的成长，思考和认识得越发全面（越发接近 360°），拥有了近乎 “白眼” 的能力，但即使是像 “白眼” 一样，也依然会存在盲点。
+
+正如世界上没有两片完全一样的树叶，也许也不会有两个认知视角完全重叠的人，这样相互进行代码评审也就弥补了个人单一视角和认知思考的盲点问题。除此之外，代码评审还有一个社会性功用，如果你在编程，而且知道一定会有同事将检查你的代码，那么你编程的姿势和心态就会完全不同。这之间的微妙差异正是在于会不会有人将对你的代码做出反馈与评价。
+
+代码评审的编程实践正是基于这样的感性认知，影响你的编码心理，并试图通过群体视角来找出个体认知盲点区域的隐患或 Bug，但到底这样的做法能降低多少出现 Bug 的概率呢？
+
+理性分析
+
+有人对代码评审的作用进行了更理性且量化的分析，结论如下（来自维基百科）：
+
+
+卡珀斯·琼斯（Capers Jones）分析了超过 12,000 个软件开发项目，其中使用正式代码审查的项目，发现潜在缺陷率约在 60%～65% 之间；若是非正式的代码审查，发现潜在缺陷率不到 50%；而大部分的测试，发现的潜在缺陷率会在 30% 左右。
+
+一般的代码审查速度约是一小时 150 行，对于一些关键的软件，一小时数百行代码的审查速度太快，可能无法找到程序中的问题。对于产品生命周期很长的软件公司而言，代码审查是很有效的工具。
+
+
+从如上的实验分析结论来看，代码评审对于发现潜在缺陷很有用，相比测试能发现的缺陷率高一倍，但也需要投入巨大的时间成本 —— 一小时审查 150 行代码，再快就不利于发现潜在缺陷了，而且更适用于长生命周期的产品。
+
+所以，下面这个现象就容易理解了。我发现在同一家公司做代码评审较多的都是研发通用底层技术产品或中间件的团队，而做业务开发的团队则较少做代码评审。两者对比，底层技术产品或中间件的需求较稳定，且生命周期长；而业务项目，特别是尝试性的创新业务，需求不稳定，时间要求紧迫，并且其生命周期还可能是昙花一现。
+
+多种困境
+
+从感性和理性两个角度认知和分析了代码评审的好处，但其适用的场景和花费的成本代价也需要去平衡。除了这点，如果把代码评审作为一个必要环节引入到研发流程中，也许还有一些关于如何实施代码评审的困境。
+
+困境一，项目期限 Deadline 已定，时间紧迫，天天加班忙成狗了，谁还愿意搞代码评审？这是一个最常见的客观阻碍因素，因为 Deadline 很多时候都不是我们自己能确定和改变的。
+
+困境二，即使强制推行下去，如何保障其效果？团队出于应付，每次走个过场，那么也就失去了评审的初衷和意义。
+
+困境三，团队人员结构搭配不合理，新人没经验的多，有经验的少。新人交叉评审可能效果不好，而老是安排经验多的少数人帮助 Review 多数新人的代码，新人或有收获，但对高级或资深程序员又有多大裨益？一个好的规则或制度，总是需要既符合多方参与者的个体利益又能满足组织或团队的共同利益，这样的规则或制度才能更顺畅、有效地实施和运转。
+
+困境四，有人就是不喜欢别人 Review 他的代码，他会感觉是在找茬。比如，团队中存在一些自信超强大的程序员，觉得自己写的代码绝对没问题，不需要别人来给他Review。
+
+以上种种，仅仅是我过去经历的一些执行代码评审时面临的困境与障碍，我们需要找到一条路径来绕过或破除这样的障碍与困境。
+
+参考路径
+
+在国内，我并没有看到或听闻哪家把代码评审作为一项研发制度或规则强制要求，并落地得很好的公司。
+
+而对于一些硅谷的互联网公司，倒是听闻过一些关于代码评审的优秀实践。比如，在一篇介绍 Google 代码评审实践的文章中说道：在 Google，任何产品，任何工程的代码，在被进行严格或者明确的代码评审之前，是不允许提交的。这一点，Google 是通过工具自动就控制了未经评审的代码就没机会进入代码库。
+
+Google 以一种强硬的姿态来制定了关于代码评审的规则，规则适用范围是全公司，对任何人都不例外。即使面对团队中超自信且强大的程序员也无例外，要么遵守规则，要么离开组织。这一点从 C 语言和 Unix 的发明者、图灵奖得主——肯·汤普森（Ken Thompson）在 Google 的趣事中可以一窥其规则的强硬性，作为 C 语言发明者之一的他因为没有参加 Google 的编程语言能力测试所以无法在 Google 提交 C 代码。
+
+所以，像 Google 这样的公司对于代码评审属于高度认可且有公司制度和规则的强硬支持，再辅助自动检测和控制工具的严格执行，一举就破解了以上四类困境。但要实践类似 Google 这样严格的代码评审制度和规则，似乎对于大部分公司而言都有不小的挑战，这需要公司制度、团队文化和技术工具三方面都能支持到位，而且还要让各方对实施此项制度的收益和代价取得一致认可，岂是易事？
+
+所以，现实的情况是，大部分公司都是在各自的小团队中进行着各种各样不同形式的代码评审，或者完全没有代码评审。
+
+现实选择
+
+以前尝试过要在团队内部做代码评审，听说兄弟团队搞得不错，然后就一起交流经验。交流开始不久就跑偏了，重心就落在了应该选个什么好用的代码评审工具来做，如今想来这完全是舍本逐末了。
+
+这就像以为有了好的编辑器（或 IDE）就能写出好的代码一样，而事实就是有很多好用的代码评审工具我们依然做不好代码评审。这让我联想起了古龙小说《陆小凤传奇》中的一段描述，记忆尤深：
+
+
+西门吹雪：此剑乃天下利器，剑锋三尺七寸，净重七斤十三两。
+
+叶孤城：好剑。
+
+西门吹雪：的确是好剑。
+
+叶孤城：此剑乃海外寒剑精英，吹毛断发，剑锋三尺三，净重六斤四两。
+
+西门吹雪：好剑。
+
+叶孤城：本就是好剑。
+
+
+剑是好剑，但还需要配合好剑客与好剑法。
+
+即使在最差的环境下，完全没有人关心代码评审这件事，一个有追求的程序员依然可以做到一件事，自己给自己 Review。就像写文章，我写完一篇文章不会立刻发布，而是从头脑中放下（Unload），过上一段时间，也许是几天后，再自己重新细读一遍，改掉其中必然会出现的错别字或文句不通畅之处，甚或论据不充分或逻辑不准确的地方，因为我知道不管我写了多少文字，总还会有这些 Bug，这就是给自己的 Review。
+
+给自己 Review 是一种自省，自我的成长总是从自省开始的。
+
+代码评审，能提升质量，降低缺陷；代码评审，也能传播知识，促进沟通；代码评审，甚至还能影响心理，端正姿势。代码评审，好处多多，让人寄予希望，执行起来却又不免哀伤，也许正是因为每一次评审的收益是不确定的、模糊的，但付出的代价却是固定的，包括固定的评审时间、可能延期的发布等。
+
+哀伤过后，我们提交了一段代码，也许没人给我们 Review，稍后我们自己给自己 Review 了，也可以得到了一段更好的代码和一个更好的自己。
+
+最后，我曾在前文《思维：科学与系统》中就用代码评审作为例子说明了这是一个系统问题，每个团队面临类似的系统问题都会有具体的情况。关于代码评审，不妨谈谈你所在环境所面临的情况和你的理解？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/46人到中年：失业与恐惧.md

@@ -0,0 +1,91 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            46 人到中年：失业与恐惧
+                            刚入行的时候，听说程序员是吃青春饭的，只能干到 30 岁。过了几年，这个说法变成了 35 岁。如今走在奔四的 “不惑” 之路上，想到如果突然丢了工作，会怎样？还是不免为此有一些惶惑。
+
+人到中年，突然就多了一些恐惧感。
+
+恐惧感：谋生
+
+当你感到害怕丢掉工作时，说明已经不再年轻了，一种为了谋生的恐惧感油然而生。
+
+记得我步出学校后，刚工作满一年，攒下了约一万元的积蓄，然后裸辞了。但只休息了一个月，就开始恐慌起来了。第二个月初，拿着手上的账单计算着，当时在广州，大约每个月的生活成本需要 3000 元。再看着卡上不多的储蓄，不得不从魔幻的虚拟世界回到苟且的现实之中，开始了新一轮的找工作之路。
+
+彼时的恐惧不是失业的恐惧，而是没钱继续生活的恐惧。并不害怕失去工作，是感觉工作随时都可以换一个，要不干嘛要傻乎乎地裸辞呢？所以反倒是想着下次应该多攒点钱才辞职的。而下次是什么时候？当时的我也不知道。
+
+第二次裸辞，已是三年后，这次我不仅想换个工作，还想换个城市，中间休息间隔的时间更长了。辞职好几个月后，我才又在成都开始了找工作。这一次感觉到了，工作没有那么好找，看上去还行也匹配自己的工作并不多，并且工资相对原来的一线城市也整体低了一个档次，但这些也未能让当时的我产生恐惧，仅仅是困惑，看不清前路。
+
+又过了好些年，真的到了中年后，每月都有很多账单要付，贷款要还，再也不会觉得切换工作是一件很随意的事情，裸辞也早已从我的字典里消失。不随意，但未必会恐惧，只是年龄与处境让我此刻更需要认真地面对和思考这个问题。
+
+中年，每个月比年轻那会儿挣得更多了，职位也更高了，生活变得更安适和稳定，这时真正潜伏着的威胁开始出现：技能的上升曲线可能越过了高点，走入平缓区，甚至也许在以缓慢而不易觉察的方式下降，而我们却安之若素。
+
+但中年，悄然而生的恐惧感，并不是阻止我们再进一步的 “鸣枪示警”，而像是中场的哨声，提醒我们人生的上半场快结束了，短暂的休整之后，就该提起精神开始下半场了。
+
+所以恐惧感不应是一种束缚，而是一种警醒。
+
+无惧感：舍生
+
+假如你在一份工作中，对丢掉工作本身产生了恐惧，那你做工作的形式很可能会走向谨小慎微。
+
+这时工作让你产生了恐惧感，你就将会被工作绊住，只想兢兢业业、如履薄冰地做好份内工作，以保护好自己的位置。但为了保护位置所做的所有努力都会是徒劳的，因为恐惧感绊住了你，这样的工作状态，自己也是缺乏信心的，而一个对自己信心不足人，也很难让别人对你产生信心。最终，几乎没有任何办法阻止别人占有你当前的位置。
+
+而偏偏是要对工作的无惧感才能真正释放你的潜力，发挥你的能力，让你能够留在原地甚或更进一步。
+
+作为程序员，我们只有一个位置：专业阵地。这是一个专业性要求比较高的职业，我们被雇佣并要求成为一名专业人士，所以应该像一个专业人士一样行事。普通劳动者和专业人士的区别在于，普通劳动者主要被动接受指令去执行任务，而专业人士则在其领域内自己生成指令，同时在领域外还会向同事或上级提供来自该领域的输出：专业建议。
+
+普通劳动者是一种劳动力资源，他们保证执行，而专业人士则是保证选择的执行方向是有意义的，执行路径是优化的。作为专业人士，我们需要去坚持和持续地打磨专业力，守住这块阵地。
+
+有时我在想，是专业让人拥有无惧感呢，还是无惧了才能走向更专业？也许，“谋生的恐惧”害怕失去的不过是工作岗位，“舍生的无惧”才能塑造专业的职业生涯吧。
+
+安全感：重生
+
+安全感，是渴望稳定、安全的心理需求，是应对事情和环境表现出的确定感与可控感。
+
+本来丢掉工作并不可怕，如果我们很容易找到下一份工作，并能很快适应变化的话。但现实是，如果是因为经济大环境变化导致的失业或技术性淘汰，找下一份工作并不容易，适应这种变化也不轻松。
+
+二十年前，上一辈的中年人，他们从自认为的铁饭碗（国企大厂）中批量下岗了，这是一种社会经济与技术变革引发的批量淘汰。近一点的，如美国 2008 年金融危机，一夜之间失业的也不在少数，而且之后很长一段时间都找不到工作，这并非专业能力过时的技术性淘汰，而是环境剧变导致的萧条。
+
+而离程序员更近的案例，来自TOMsInsight的深度调查采访，也就是 2015 年的事。
+
+
+Tony 37 岁，清华本硕，毕业后加入全球知名的 A 记公司中国研发中心工作 11 年，年薪 80 万。在北京东三环，置业豪宅，老婆全职太太，两个孩子。但 2014 年 5 月，A 记公司中国研发中心裁员，Tony 就成为了其中之一。
+
+Tony 作为专业技术人士的价值依然存在，更以百万年薪身价加入著名的互联网巨头 B 厂。但后来，Tony 却无法适应互联网的节奏，感觉工作上周边环境各种 “浮躁”，管理也不 “专业”，只好再度离职。
+
+辞职后Tony很难找到合适的工作：不能很好地适应互联网公司，外企整体不景气招聘冻结，进入体制内早已过了年龄，创业没有机会和资源，当然也没勇气。而维持家庭高品质生活还需要不小的开支。Tony 在 37 岁这年，学会了抽烟、喝酒，仿佛人生的不顺利，来得稍微晚了一些。
+
+
+最可怕的失业就来自变革引发的技能性淘汰（如：国企下岗），其次是环境引发的萧条（如：金融危机），再次是技能虽然还有普适价值，但自身却适应不了环境变化带来的改变与调整（如：Tony 的危机）。
+
+Tony 面对的危机还是比较少见，属于个人问题。而金融危机也不多见，面对萧条 “血”（储蓄）够厚也可以撑得过去。只有第一种，技能性淘汰，积重难返。四十而不惑，不过四十岁程序员的悲哀在于，他们拥有十五年以上的经历与经验，有时却在和只有五年经验的年轻程序员竞争同样的岗位。
+
+中年人和年轻人本应在不同的战场上。年轻时，拼的是体力、学习力和适应能力，是做解答题的效率与能力；中年了，拼的是脑力、心力和决策能力，是做对选择题的概率。
+
+年轻时，是用体力和时间积累经历，换取成长与机会。就拿我来说，从年轻到中年我的体力状态变化是：20 岁以前可以通宵游戏后再接着上一天课；30 岁以前连续一个月加班通宵颠倒，睡一觉后就又精神满满；35 岁以前，还能上线到凌晨两、三点，睡上几小时后，早上 9 点又正常上班；35 岁以后，就要尽可能保持规律作息，否则可能第二天就精神不振了。
+
+所以，中年了体力下降是自然生理规律，但和脑力有关的学习能力并不会有明显改变。记得以前看过一篇万维钢的文章讲了一本书《成年大脑的秘密生活：令人惊讶的中年大脑天赋》，其中提到：
+
+
+跟年轻的大脑相比，中年大脑在两个方面的性能是下降的：计算速度和注意力。其他方面，比如模式识别、空间想象能力、逻辑推理能力等等，性能不但没有下降，而且还提高了。
+
+
+计算速度和注意力下降应该是对学习力有一些影响的，但丰富的经历和经验应该可以缩短学习路径，更有效地学习。回顾过往，年轻时学习的路径试错曲线要长得多，所以这一点在学习效率上得到了弥补。而从其他方面看，模式识别、空间想象和逻辑推理意味着中年人的大脑擅长更多高级的工作技能，所以完全没必要担心 “老了” 会导致学习能力下降。
+
+缺乏安全感，正是源自变化，变化带来的不确定性。
+
+环境和人都处在长期持续的变化中，变化总是不确定的，我们没法消除变化，只能把变化纳入考虑，承认变化是永恒的，不确定是长期的。面对这一点很难，难在反人性，我们真正需要做的是战胜自己人性里的另一面 —— 适应变化，无论世界怎样变化，内心依然波澜不惊，就像大海深处，无论海面如何波浪滔天，深处依然静谧悠然。
+
+简言之，人到中年，转换了战场，重新定位自己的优势，转变核心竞争力，浴火重生，开启人生的下半场。
+
+年轻时，我们打的是突击站，左冲右突；中年了，我们打的是阵地战，稳步推进；如今，我们进入了人生的中场战事。这场战事从谋生的恐惧感开始，给予我们警示；到舍生的无惧感，让我们摆脱束缚，整装待发；最后经过重生的安全感，推动我们再次上升。
+
+关于中年之惑，你有哪些看法呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/47该不该去创业公司？.md

@@ -0,0 +1,93 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            47 该不该去创业公司？
+                            大约是 2015 年时，那是一个大众创新、万众创业的 “双创” 年代。当时，创业公司如雨后春笋般出现，又如昙花一现般凋零。也是在那年，招聘时碰到过一个人，一年换了三个公司，我就问：“为什么这么频繁跳槽呢？”而他的答案也让我吃了一惊，他说因为他加入的每家公司，没几个月就都倒闭关门了。
+
+那时候，我和我身边的同事都收到过来自创业公司的邀约，有的同事就此去创业了，而我最终选择了拒绝。后来，我复盘了当时的场景，面临这样的选择，会同时有感性和理性的因素。感性的因素也许每个人都不尽相同，但理性的方面，更有普适性，从中我慢慢提炼和完善成了一组选择决策框架。
+
+一、期望
+
+为什么要加入创业公司，你的期望是什么？也许有下面几种原因：
+
+
+自由成长
+变身土豪
+追求梦想
+
+
+1. 自由成长
+
+创业公司相对成熟的大公司，会有更大的自由度，能接触的东西更多，但需要处理的问题也更多、更杂，会让人更容易自由成长为一种解决各类问题的多面手。这对于程序员而言，很可能就是综合能力更强，但在特定的专业领域又不够精深。
+
+但有些人就会觉得在大公司过于拘束，缺乏自由度，干的事情专业分工很精细，并不适合自己相对广泛的兴趣路线。那么这类人在初创公司也许就会有更多的尝试机会，更大的发挥空间。
+
+2. 变身土豪
+
+业界坊间一直流传着创业公司上市 IPO 一夜变身土豪的故事，但我们不妨理性地来分析一下。
+
+最早期的创业公司，大概处在天使轮阶段。作为技术人，如果你的经验和背景足以让你以技术合伙人的身份加入，那么你可以大概拿到公司占比 5% 左右的期权。假如公司最后成功 IPO 上市了，市值 100 亿，那么你的股票兑现就值大约 5 亿了（这里忽略行权和各类税务成本），成功变身土豪。但关键点在于，从天使轮到上市途中，统计数据上显示会倒下 99% 的创业公司。
+
+如果创业公司进展到了 A 轮，你再加入，成为合伙人的概率就低了，更可能成为一名高管。这时能分到的期权会少一个量级，大约 0.5%。最终公司上市，还是 100 亿市值，勉强还能成为一个“瘦”点的土豪。
+
+进一步到了 B 轮，再加入时，想成为高管的能力和背景要求都更高了，这时能拿到的期权比例会进一步下降一个量级，大约 0.05%。100 亿的市值，按这个比例就不太能成为土豪了。
+
+到了 C 轮，公司上市的可能性大大增强，前景可期。但这时加入，能拿到的比例进一步下降一个量级到 0.005%，如果这时公司的上市预期市值就 100 亿，估计也吸引不到什么人了。
+
+变身土豪，其实需要的是增值 100 倍的机会，而最低的下注金额是一年的收入。加入创业公司就是用你的时间下注，能否撞上 100 倍的机会，很多时候就是靠时运。因上努力，果上随缘，尽人事，听天命。
+
+3. 追求梦想
+
+也许创业做的事情正是你梦想的、喜欢做的事情，人生有时不就是挣钱来买一些 “喜欢” 么？那么你愿为 “喜欢” 支付多大的成本与代价？
+
+在成熟的大公司工作，无论工资还是配股的收益都有很高的确定性。而创业公司即使给你开出同等的工资加上对应的期权，相比大公司的稳定性和持续性，也依然处于劣势。更可能的情况是，创业公司给你的工资加上按目前融资轮次估值的期权价值一起，才勉强和你在大公司每年的确定收益相持平。
+
+站在创业公司的角度，公司通常也不希望招一个只要高工资，不要公司期权的人吧。公司当然会觉得期权价值的不菲，而且每进入下一轮融资期权价值一般都会增幅巨大，拥有很大的增值潜力。而站在你的角度，给期权的正确估值应该是 0，因为期权的兑现日期你无法预期，也许是五年，也可能是十年后，再考虑创业的高失败率，所以一开始就不要寄予太多期望的好。
+
+将期权更多的看作彩票，如果期权让你发了财，这非常好，但是你应当确保自己的工资报酬至少可以接受，也就是说即使你的合同中没有期权，你也仍然会选择加入这家创业公司。这中间相对你在大公司的确定性收益的差距便是追求梦想的直接经济成本，也可以理解为你选择创业的风险投入资本。
+
+最理想情况下，通过一次创业的成功，上述三者期望都一次性实现了。但，现实却往往没那么理想。
+
+二、条件
+
+搞清楚了自身的期望与需要付出的成本和代价，再来理性地看看其他方面的因素。
+
+1、创始人创业的目的是什么？期望是什么？创业毕竟是一段长期的旅程，大家的目的、价值观、期望差距太大，必然走不长远，身边就目睹过这样的例子。
+
+2、创始人以前的口碑和信用如何？有信用污点的人并不值得合作与跟随，而且前面说的创业公司期权，最终能否兑现？就国内的创业环境而言，这一点也很是关键。
+
+3、公司的核心团队成员如何？看看之前都有些什么样的人，你对这个团队的感觉契合么？价值观对味么？这个团队是合作融洽，还是各怀鬼胎？有些小公司，人虽不多，办公室政治比大公司还厉害。
+
+4、对你的定位是什么？创业公司在发展初期容易遇到技术瓶颈，会以招 CTO 的名义，来找一个能解决当前技术瓶颈的专业人才。也许你会被名头（Title）吸引，解决完问题，渡过了这个瓶颈，但这之后老板会觉得你的价值还足够大么？有句话是这么说的：“技术总是短期被高估，长期被低估”。而你自身还能跟得上公司的发展需要么？
+
+5、公司是否有明确的业务方向？业务的天花板多高？有哪些对手？相对竞争的核心优势是什么？很多做技术的同学都不太关心业务的商业模式，也许这在大公司可以，毕竟船大，一般也就感觉不到风浪。但在创业公司则不然，业务的天花板有多高？也就是能做到多大？如果公司业务没有明确的方向和优势，你憧憬着踏上了火箭，结果却是小舢板，起风时感觉还走得挺快，风一停，就只好随波荡漾了。
+
+也许还有很多其他方面你关注的条件和因素，在选择前都可以先列出来比较。只是最后我比较确定的一件事是，不会有任何一家公司满足你所有心仪的条件，这时就需要你做决策了。
+
+三、决策
+
+决策之前，期望是内省，条件是外因；决策就是将客观的外因与主观的内省进行匹配判断选择的过程。
+
+决策很难，让人经常很矛盾，很沮丧。往回看，我们总能找到适合自己的最优决策路径，但当初却并没有选到这条路，所以沮丧。往前看，其实有无数的路径分支，我们怎么可能选中最优路径，有这样的方法吗？没有。
+
+这样的决策就像古时先哲讲过的一个故事，大意是：你有一个机会经过一条路，这条路两边都是大大小小的宝石，但你只能走过这条路“一次”，捡起其中“一块”宝石，中间不能更换。这里捡到最大的宝石就是最优策略，但你怎么实现这个最优策略呢？其实没有方法能保证。
+
+而先哲的建议是，前 1⁄3 的路径，你只观察周围的宝石，最大的有多大，平均大小大概在什么水平，但不出手捡。经过这前 1⁄3 的路程，你应该有一个预期的大小标准，这个标准可能略比平均大小大一些，但不应该以之前看见的最大的宝石为标准。再走剩下的 2⁄3 路程时，你只要看见第一个符合这个标准的宝石，就可以出手捡起，之后快速走完全程。
+
+这个方法虽不能保证你捡到最大的宝石，但可以很大概率保证你捡到符合自己预期标准大小的宝石，而这个预期标准，就是你的 “满意标准”。这个捡宝石的决策就是 “满意决策”，满意决策是一种折衷决策，只是在当时情况下可选的最佳行动方案。
+
+人生中会有很多类似 “捡宝石” 这样的决策场景：找工作、找伴侣、选房子、买股票，甚至是买任何东西，只不过因为其中大部分东西的购买支付代价低，所以你不会有太大的决策压力。前 1⁄3 的路程就是让你在决策前充分观察、调研、确定你的满意标准，之后面对第一个满意对象就能够直接决策，然后继续快速前行。
+
+满意决策的方案就是让你做完决策不纠结，即使后来回头看离最优还有差距，也不遗憾。因为，人一生要面对的决策很多，“满意决策” 的办法让你省下了 2⁄3 纠结的路程，继续快速前行。
+
+最后，当你面临加入创业公司的选择时，问问你的期望，评估现实的条件，再做出满意的选择；决策过后，可能有遗憾，但没不甘。
+
+如今在创业公司的你，当初是如何选择的呢？或者你是怎么看待这件事的呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/48该不该接外包？.md

@@ -0,0 +1,111 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            48 该不该接外包？
+                            以前我曾接到过一些关于程序外包站点的营销邮件，也看到过身边有些人选择去接一些外包，赚点外快。当然也有人找到过我做外包项目，这时我就必须做出一个评估和选择，面对外包赚钱的诱惑，到底该如何进行更好的选择呢？
+
+赚钱与诱惑
+
+外包的直接诱惑，就是能立刻增加工资之外的收入，赚点外快。
+
+但反过来，我们需要问自己的是：需要为赚点外快去接外包吗？为此，我先去调研考察了一番现在的程序员外包市场。好几年前，我留意了一个程序员外包平台，已有好几万签约开发者了，如今再去看时，已有近二十万程序员了。这不免让我思考：什么样的程序员会去这样的平台上接外包项目呢？
+
+我把该平台上的程序员页面列表挨着翻了十来页，发现了一个规律。我看过的这些签约程序员多数工作经验在三到五年之间，还看到一个创业公司的创始人，可能是目前创业维艰，接点外包项目来维持团队生存吧。
+
+但总的来说，来这里接单的很大一部分程序员应该都是想要赚点工资之外的钱吧。赚钱本无错，只是程序员除了接兼职外包项目还有什么其他赚钱方式吗？我想了想，程序员赚钱的方式大概有下面这些。
+
+咨询/培训。一般被外部企业邀请去做咨询或培训的程序员，根据个体差异可能报酬从几千到几万不等吧，但能够提供此类服务的程序员，对其本身的素质要求较高，而且来源不稳定，所以不具有普适性。
+
+演讲/分享。程序员圈子经常会有一些技术分享大会，有些组织者会对提供分享的讲师支付一点报酬，具体数额可能因“会”而异吧，但一般不会比咨询和培训类更多。
+
+投稿/翻译。一些写作和英语能力都不错的程序员可以向技术媒体去投稿或翻译稿件。原创千字标准一百五左右，而翻译会更低些，看译者的水平从千字几十到一百左右。
+
+写书。也有不少程序员写书出版的，但基本都是技术类图书。对于图书版税，一个非著名作者不太可能超过 10%，而能卖到一万册的国内技术书籍其实并不多，假如一本书销售均价50元，那你可以自己算下大概写一本书能挣多少。畅销和长销的技术类图书，基本都成了教材，而现实中要写一本优秀的教材保持十数年长盛不衰，是件极困难的事。
+
+写博客/公众号。十年前大家写博客，现在很多人都写公众号。博客是免费阅读，靠广告流量分成赚钱，但其实几乎就没几个有流量的独立博客，都是聚合性的博客站赚走了这部分钱。
+
+而公众号开创了阅读打赏模式，有些人看见一些超级大V随便写篇文章就有几千人赞赏，觉得肯定赚钱。但其实写公众号的人真没有靠赞赏赚钱的，赞赏顶多算个正向鼓励罢了。一个拥有十万读者的公众号，实际平均每篇的打赏人数可能不到 50 人，而平均打赏单价可能不到5元。这么一算，假如一篇文章 2000 字，还不如投稿的稿费多。所以持续的博客或公众号写作基本靠兴趣，而能积累起十万读者的程序员几乎属于万中无一吧。
+
+课程/专栏。这是今年才兴起的形式，一些有技术积累和总结表达（包括：写和讲）能力的程序员有机会抓住这个形式的一些红利，去把自己掌握的知识和经验梳理成作品出售。但能通过这个形式赚到钱的程序员，恐怕也是百里挑一的，普适性和写书差不多。
+
+兼职/外包。这就是前面说的外包平台模式，平台发布项目，程序员注册为签约开发者，按人天标价，自己给自己的人天时间估值。我看平台上的跨度是一天从 300 到 2000 不等。
+
+各种赚钱方式，分析了一圈下来，发现其实对于大部分程序员而言，最具普适性的还是兼职外包方式。因为其他方式都需要编程之外的一些其他技能，而且显然兼职外包方式相比较而言属于赚钱效率和收入最高的一种方式，无怪乎会有那么多程序员去外包平台注册为签约开发者。
+
+只是，这种方式的赚钱性价比真的高吗？短期的直接收入回报诱惑很大，但长期的代价和成本呢？
+
+成本与比较
+
+接外包的短期成本是你的时间，那长期的成本和代价呢？
+
+桥水基金创始人雷·达里奥（Ray Dalio），也是近年畅销书《原则》的作者，制作过一个视频叫《三十分钟看清经济机器如何运转》，他在视频的末尾提出了三条建议：
+
+
+
+不要让债务的增长速度超过收入。
+不要让收入的增长速度超过生产率。
+尽一切努力提高生产率。
+
+
+
+这三条建议虽然是针对宏观经济的，但我理解转化一下用在个人身上也是无比正确啊。特别是第二条，现下多接外包提高了当下的收入，但长期可能会抑制你的生产率，让你失去竞争力。为什么呢？举个例子，我们经常在电影里能看到这样一些熟悉的画面，白天晚上打着几份工的人为生活疲于奔命，那他（她）还有时间来做第三条吗？疲于奔命导致个人生产率增长的停滞，未来竞争力的下降。
+
+生产率是一个宏观经济术语，用到程序员个人身上可不能直白地理解为产出代码的效率，正确的理解我认为是个人价值的产出率，即如下等式：
+
+
+个人生产率 = 个人价值的产出率
+
+
+基于以上理解，面临当初的外包项目我的选择是：拒绝。因为，它带来的收入是一次性的，不具备积累效应，而且相比我的全职工作收入还有差距，短期也许能增加点收入，但也没有其他任何意义了。如果老是去接这样的事情，长期的代价必然是个人生产率的降低，得不偿失。
+
+但我确实还做一些不赚钱的事，比如过去多年经常写作，偶尔翻译，我所做的这些事情的直接目的都和提高现阶段的收入（立刻多赚钱）没关系，只是想尽可能地在提高个人价值的同时提升价值产出率，也就是说在做达里奥所说的第三条建议。
+
+不过，个人价值的提升可能不会立刻反映到当下的收入上，就像公司的内在价值提升了可能股价还没涨一样。但长期来看，价格总是要回归价值的，这是经济规律，宏观如国家，微观如个人。
+
+值钱与选择
+
+该不该接外包的选择本质是：选择做赚钱的事，还是值钱的事？
+
+梁宁有篇文章就叫《赚钱的事和值钱的事》，文中总结了这两点的差别：
+
+
+赚钱的事，核心是当下的利差，现金现货，将本求利。
+
+值钱的事，核心是结构性价值，兑现时间，在某个未来。
+
+
+从赚钱的角度看，前面分析的所有赚钱方式的赚钱性价比都很低，完全不值得做。你可能会反驳说，外包项目的收入可能也不低，甚至比你的全职工资还高，怎么会认为赚钱性价比很低呢？一方面，全职工作提供的收入是稳定的；另一方面，兼职外包的收入多是临时的，一次性而不稳定的。若你能持续稳定地获得高于全职工资的外包收入来源，那么仅从赚钱角度看，更好的选择可能应该是去全职做外包了。
+
+从值钱的角度看，前面分析的所有赚钱方式，在以个人价值增值为出发点的前提下，是值得尝试的。正因为兼职外包接单对很多程序员具有普适性，所以针对这件事情的出发点应该是看是否以个人价值及其增长为归依，而非是为了当下能多赚点钱。过于专注短期的收入提升，可能会“一叶障目”，忽视了长期的价值增值。
+
+为了多赚点外快牺牲当下所有的业余时间，这值得吗？这种兼职外包项目对于自身的价值增值有多大的帮助？这是你需要反问和思考的问题。我估计很多兼职项目都是低水平的重复劳动，其实不止是兼职，甚至很多全职工作亦是如此。
+
+说个例子，刚毕业时，我被分配维护一些历史遗留 Java Web 项目，可能因为毕业时我已有了些 Java Web 相关的课程设计经验；而和我一起加入公司的另一个校友则完全没有这方面的基础，所以被安排维护另外一个历史遗留基于 IBM Lotus Notes 的系统。
+
+估计 Lotus 这套东西现在几乎绝迹了，在当时也是非技术主流，只不过因为历史原因还需要维护。既然公司出钱招聘了我们，为了生存和生活，刚毕业的我们其实没有多少挑选工作内容的机会。因此他在维护 Lotus 项目之余，还在不断地学习 Java 相关的内容，找一些业余项目来做并练习，为下一次的工作转型做准备。我认为像他这样以此为出发点的兼职或业余项目都是没问题的。
+
+为什么外包平台上（我观察下来）三到五年的签约程序员最多？我揣摩可能与他们所处的阶段有关，正是处在结婚安家的阶段，收入敏感度较高。但牺牲未来潜在的生产率增长来换取当下收入临时且不高的增幅，是不值得的。
+
+在价值积累到一定阶段之前，收入增长得并不明显，这阶段人和人之间的收入差距其实很小。想想同一家公司、同一个岗位、同样工作三到五年的程序员，收入能有多大差距呢。这阶段你即使花费所有的业余时间来赚钱，与你的同龄人拉开的收入差距也不会大。
+
+而我观察多数真正拉开差距的阶段是在工作的十年到二十年之间，根据个人的价值积累大小，价值结构变现的机遇，拉开的差距是数量级的差别，会让你生出“当时看起来我们差不多，但如今他干一天能抵我干上一个月甚至一年了”的感慨，所以前十年不妨把关注的焦点放在个人价值的增值上。
+
+最后，再总结下到底“该不该接外包”这个问题。我认为值得接的外包，它包括下面一些特性：
+
+
+如果外包项目对你的技术积累有好处，那么收点钱去实践提升下正好一举两得；其实参与开源项目，本质上不就是不收钱的外包项目？它的收益就是让你更值钱。
+外包项目的成果具有可复制、可重用性，这样就可以通过大量复制和重用来降低一次性开发成本；而成本和比较优势才是外包模式的核心竞争力所在啊。
+外包项目不是临时一次性的，而是需要长期维护的，而这种维护的边际成本可以依靠技术工具手段不断降低，那这样的外包项目就是一个长期赚钱的 “机器” 了。
+
+
+所有以上特性都反映了一个本质：去做值钱的事，打造值钱的结构，从知识结构、技能结构到作品结构与产品结构，然后等待某个未来的兑现时间。
+
+末了，也谈谈你对外包项目的看法吧，欢迎留言。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/49技术干货那么多，如何选？.md

@@ -0,0 +1,99 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            49 技术干货那么多，如何选？
+                            在我刚进入行业的早些年，也是互联网的早期，其实网上的信息都不算特别多，而技术干货类信息更是少，所以就养成了一个习惯，遇到好的技术干货类文章就会收藏下来。这个习惯延续了多年，后来某天我突然发现仅仅是微信收藏夹内保存的技术干货型文章就已经累积了半年之多，都没时间去阅读和筛选。
+
+收藏了如此多的干货，半年没读似乎也没缺了啥，那么还有必要读吗？2011 年时，我刚进入互联网行业，那已是互联网时代的成熟期，移动互联网的孕育期，也肯定是信息爆炸的时代，但依然是技术干货寥寥的时期。如今，却已是连技术干货也进入了爆炸期，那我们该如何挑选与应对？
+
+循证与决策路径
+
+为什么我们会去挑选和阅读技术干货文章？我想，循证大概是一个原始诉求，通过分析别人走过的路径，来拨开自己技术道路探索上的迷雾。
+
+循证方法，也是我早年刚接触 J2EE 开发时遇到的技术决策指导思想，记得J2EE Development without EJB一书的译序中有一段话，很好地阐释了 “循证” 方法：
+
+
+任何一个从事 J2EE 应用开发的程序员或多或少都曾有过这样的感觉：这个世界充斥着形形色色的概念和 “大词”，如同一个幽深广袤的魔法森林般令人晕头转向，不知道该追随这位导师还是该信奉那个门派。
+
+这时，Rod Johnson 发出振聋发聩的一呼：尔等不必向泥胎偶像顶礼膜拜，圣灵正在尔等自身 —— 这就是他在书中一直倡导的 “循证架构”。选择一种架构和种技术的依据是什么？Rod Johnson 认为，应该是基于实践的证据、来自历史项目或亲自试验的经验……
+
+
+所以，我们去阅读技术干货文章，想从别人的分享中获得对自己技术方案的一个印证。这就是一种行业的实践证据，毕竟想通过听取分享去印证的，通常都是走过了一条与自己类似的道路。技术道路的旅途中充满着迷雾与不确定性，我们不过是想在别人已走过的类似道路中获得指引和启发，并得到迈出坚实下一步的信心。
+
+这就是循证方式的技术决策路径。
+
+多年前，我们刚开始做咚咚这个 IM 系统时，就是沿着这条路径一路过来的。
+
+刚启动是 2012 年，一开始其实是完全不知道怎么迈步，专门花了三个月时间来研究业界的 IM 软件系统都是怎么做的。当时行业 IM 第一的当属 QQ，但那时腾讯公司的技术保持神秘而低调，在互联网上几乎找不到任何公开的技术分享资料。
+
+退而求其次，我们只好研究起开源的 IM 软件，也就是基于 XMPP 开放协议实现的一类开源 IM 服务端和客户端，并以此为基础去设计我们自己的 IM 架构，然后实现了一个最初的原型。
+
+再后来，腾讯终于有一位即时通讯的 T4 专家出来分享了一篇关于 QQ 的后台技术架构演进之路，记得是叫《1.4亿在线背后的故事 —— QQ IM后台架构的演化与启示》。我仔细听了一遍，又把分享材料翻过好多遍，思考并体会其中的架构演化道路。
+
+数年后，微信在移动互联网时代崛起，并且在 IM 领域甚至还超越了 QQ，微信团队也分享了其后端架构演进之路。此时，我们自身的架构也基本成型并运行一些年了。而我也注意到，关于 IM 类消息应用最核心的一个技术决策是：消息模型。微信的方式和我们并不一样。
+
+微信的方式是基于消息版本的同步加存储转发机制，而我们则是基于用户终端状态的推送加缓存机制。微信的机制从交互结构上更简洁和优雅一些，在端层面的实现复杂度要求更低，符合其重后端、轻前端的设计思路和原则。
+
+然而，循证的方式就是：即便你看到了一个更好的技术与架构方式，但也要结合自身的实际情况去思考实践的路径。消息模型，作为一个核心的底层架构模型，也许刚起步未上线时，变更优化它只需要一两个程序员一两周的时间；但经过了数年的演进，再去完全改变时，就需要各端好几个团队配合，并忙上一两个季度了。
+
+循证，不一定能立刻给你的当下带来改变，但可以给你的演进路径方向带来调整，未来将发生改变。
+
+切磋与思考方式
+
+技术干货多了以后，在类同的领域都能找到不同公司或行业的实践分享，这时不仅可以循证，还能够达到切磋和多元化思考的目的。
+
+处在 IM 这个领域，我就会经常去看关于 IM 相关技术领域的干货文章，所以我知道了微信的消息模型采用了推拉结合，还有基于版本的同步机制。但我不会再纠结于为什么我们不同，而是去看到它的好处与代价。
+
+一个更具体的切磋案例：大家都熟悉且特别常用的功能 —— 群消息。关于群消息模型，微信采用的是写扩散模型，也就是说发到群里的一条消息会给群里的每个人都存一份消息索引。这个模型的最大缺点就是要把消息索引重复很多份，通过牺牲空间来换取了每个人拉取群消息的效率。
+
+好多年前我们刚开始做群时，也是采用了的写扩散模型，但后来因为存储压力太大，一度又改成了读扩散模型。在读扩散模型下，群消息只存一份，只需记录每个群成员读取群消息的偏移量，偏移量的记录相比消息索引量要小几个量级，所以减轻了存储压力。
+
+而之所以存储压力大在于当时公司还没有一个统一的存储服务组件，我们直接采用Redis的内存存储，当时原生的 Redis 在横向和纵向上的扩展性都比较受限。这在当时属于两害相权取其轻，选择了一个对我们研发团队来说成本更低的方案。
+
+再后来公司有了扩展性和性能都比较好的统一存储组件，实际再换回写扩散模型则更好。毕竟读扩散模型逻辑比较复杂，考虑自己不知道加了多少个群了，每次打开应用都要检查每个群是否有消息，性能开销是呈线性递增的。
+
+同一个技术方案在不同的时期，面临不同的环境，就会带来不同的成本，并做出不同的选择与取舍。虽然看起来是在走类似的路，但不同的人，不同的时代，不同的技术背景，这些都导致了终究是在走不同的路。路虽不同，但可能会殊途同归吧。
+
+切磋带来的思考是：你不能看见别人的功夫套路好，破解难题手到擒来，就轻易决定改练别人的功夫。表面的招式相同，内功可能完全不同，就像金庸小说里的鸠摩智非要用小无相功催动少林七十二绝技，最后弄得自废武功的结局。
+
+切磋，主要是带给你不同的思维方式，用自己的功夫寻求破解之道。
+
+连结与知识体系
+
+干货多了，时间有限，自然就存在一个优先级的选择阅读问题。
+
+就我个人来说，我的出发点很简单，有两点：基于功利性和兴趣。说起功利性也别觉得不好，毕竟整个商业社会都是基于功利性为基础的，所以基于此的选择其实是相当稳定的。考虑下所在组织和团队的功利性需求来做出技术的选择，有时甚至是必须的，而不能完全由着兴趣来驱动。
+
+我在前文《领域：知识与体系》中已经有过说明，我会把过去自己所掌握的所有技术总结编织成一张“网”，若一个技术干货分享的东西离我的“网”还太远，我就会放弃去了解。因为如果不能连结到这张“网”中，形成一个节点，我可以肯定它就很难发挥任何作用，很可能是我看过之后没多久就遗忘了。
+
+如今技术发展百花齐放、遍地开花，但人生有限，所以你必须得有一种方式去做出选择，最差的可能就是所谓的随性选择。我觉得很多情况下是需要一个选择指导框架的，而对于如何选择阅读技术干货的问题，前面比喻的那张“网”就是一个我自己的指导框架。
+
+即便是针对同一个问题或场景，我们也可以将已知的部分连结上新的知识和实践，形成更密、更牢固的技术体系之网。
+
+刚做 IM 时，曾经有个疑惑，就是 IM 的长连接接入系统，到底单机接入多少长连接算合适的？很早时运维对于长连接有个报警指标是单机 1 万，但当时我用 Java NIO 开 2G 最大堆内存，在可接受的 GC 停顿下，一台 4 核物理机上测试极限支撑 10 万长连接是可用的。那么平时保守点，使用测试容量的一半 5 万应该是可以的。
+
+之后一次机会去拜访了当时阿里旺旺的后端负责人，我们也讨论到了这个长连接的数量问题。当时淘宝有 600 万卖家同时在线，另外大概还有 600 万买家实时在线，所以同时大概有 1200 万用户在线，而当时他们后端的接入服务器有 400 台，也就是每台保持 3 万连接。他说，这不是一个技术限制，而是业务限制。因为单机故障率高，一旦机器挂了，上面的所有用户会短暂掉线并重连。若一次性掉线用户数太多，恢复时间会加长，这会对淘宝的订单交易成交产生明显的影响。
+
+他还说了一次事故，整个机房故障，导致单机房 600 万用户同时掉线。整个故障和自动切换恢复时间持续了数十分钟，在此期间淘宝交易额也同比下降了约 40% 左右。因为这种旺旺在线和交易的高度相关性，所以才限制了单机长连接的数量，而当时已经有百万级的单机长连接实验证明是可行的。
+
+在一篇关于微信红包的的技术干货文章《100亿次的挑战：如何实现一个“有把握”的春晚摇一摇系统》里提到：
+
+
+在上海跟深圳两地建立了十八个接入集群，每个城市有三网的接入，总共部署了 638 台接入服务器，可以支持同时 14.6 亿的在线。
+
+
+简单算一下，大概就是 228.8 万单机长连接的接入能力，14.6 亿怕是以当时全国人口作为预估上限了。实际当然没有那么多，但估计单机百万长连接左右应该是有的。这是一个相当不错的数量了，而采用 Java 技术栈要实现这个单机数量，恐怕也需要多进程，不然大内存堆的 GC 停顿就是一个不可接受和需要单独调优的工作了。
+
+以上就是从干货中提取知识和经验总结的案例，形成对已有知识的连结。这就是不断加固并扩大自己的技术知识体系之网。
+
+总结来说：面对众多的技术干货，从循证出发，找到参考，做出技术决策，决定后续演进路线；在演进路上，不断切磋，升级思考方式，调整路径，走出合适的道路；在路上，把遇到的独立的知识点，不断吸收连结进入自己的技术知识体系之网。
+
+回答了标题的问题，这篇文章也该结束了。面对技术这片大海，我们都是一个渔民，三天打鱼，两天结网。愿你的“网”越结越大，捞的“鱼”也越来越多，也欢迎留言分享下你的“打鱼”和“结网”经历。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/50技术分歧，如何决策？.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            50 技术分歧，如何决策？
+                            作为一名程序员或技术人，总会碰到这样的场景：在一些技术评审会上，和其他程序员就技术方案产生分歧与争论。如果你是一名架构师或技术 Leader，站在技术决策者的立场和角度，该如何去解决分歧，做出决策呢？
+
+这背后，有什么通用的方法和原则吗？
+
+绝对
+
+曾几何时，我以为技术是客观的，有绝对正确与否的标准判断。
+
+在学校我刚开始学习编程技术时，捧着一本数据库教材，它在述说着经典的关系数据库表设计原则：第一、第二、第三范式。后来，我参加工作，那时的企业应用软件系统几乎都是以数据库为核心构建的，严格遵守范式定义的表结构。所以，当时觉得所有不符合范式设计的应用肯定都是错的，直到后来进入大规模的分布式领域，碰到了反范式设计。
+
+也还是在学校做课程设计时，一起学习的同学总跟我讨论设计模式。一边写代码，一边研究这个代码到底符不符合某种模式，似乎没有套进某种模式中的代码就像没有拿到准生证的婴儿，带有某种天生的错误。直到后来，我碰到了反模式设计。
+
+刚工作不久，同事和我讨论当用户删除自己的数据时，我们到底应不应该删掉它？我那时觉得理所应当写个 Delete 的 SQL 语句把它删掉。因为当时是这么想的：既然用户都不要他的数据了，我们还把它保留下来做什么呢？不是浪费资源嘛，而且服务器存储资源还算挺贵的。
+
+但今天的互联网大数据时代，用户主动或非主动提交的任何数据，你都别想再将它真正地删除了。这个时代，受益于摩尔定律，存储设备容量不断增加，而价格不断降低，所有关于用户的数据总是可能有用的，都先存下来再说。
+
+做技术这么些年下来，关于技术方案的判断，曾经以为的绝对标准，今天再看都是相对的。
+
+相对
+
+的确是的，适合的技术决策总是在相对的条件下做出的。
+
+曾经，读到一篇英文文章，其标题翻译过来就是《简化：把代码移到数据库函数中》。我一看到这个标题就觉得这是一个错误的技术决策思路，为什么呢？因为曾经我花了好长时间做了一个项目，就是把埋在数据库存储过程中的代码迁移到 Java 应用里；而且，现在不依赖数据库的代码逻辑不正大行其道吗？
+
+作者是在正话反说，还是在哗众取宠？我很是好奇。所以，我就把这篇文章仔细读了一遍，读完以后我发现作者说得似乎有些道理，他的说法我大概概括为如下。
+
+作者说，如今绝大部分的 Web 应用包括两部分：
+
+
+一个核心数据库，负责存储数据；
+以及围绕数据库的负责所有业务智能与逻辑的代码，体现为具体编程语言的类或函数。
+
+
+现在几乎所有的 Web 系统都是如此设计的，所以这像是真理，业界最佳实践，事实工业标准，对吧？但作者描述了他自己的经历，是下面这样的。
+
+他从 1997 年开始做了一个电子商务网站，用了 PostgreSQL 作为数据库，第一版网站用 Perl 写的。1998 年换成了 PHP，2004 年又用 Rails 重写了一遍。但到2009年又换回了 PHP，2012 年把客户端逻辑拆出去用 JavaScript 重写，实现了前后端分离。
+
+这么些年下来，代码重构过很多次，但数据库一直是 PostgreSQL。可是大量和数据存取有关的逻辑也随着代码语言的变迁而反复重写了很多遍。因而，作者感叹如果把这些与数据存取有关的逻辑放在数据库里，那么相关的代码将不复存在，他也不需要反复重写了。
+
+这里有个疑问，作者没事老换语言，到底是在折腾啥？他虽然没有在文中明说，但作为程序员的我还是能设身处地感受到其中的缘由。作者本身是学音乐出身，目标是建网站卖音乐唱片，自学编程只是手段。作为一个过来人，我相信他早期的代码写得肯定不咋地，又在各种流行 Web 技术趋势的引诱下，充满好奇心地尝试各种当时时髦的技术，不断重构改进自己的代码。
+
+在这个过程中发现，有一些和业务关系不太大的数据存取逻辑，被反复重写了很多遍，所以才产生出了这样的思路：假如把这部分代码移到数据库中。其实对这个思路的挑战，也是显而易见的：
+
+
+如何进行调试、回滚？
+如何做单元测试？
+如何进行水平扩展？
+
+
+上述“挑战”在一般情况下都成立，但对于作者来说却不是很重要。因为作者思路成立的前提是：第一，他维护的是一个小网站，数据库没有成为瓶颈；第二，这个网站的开发维护人员只有作者一个人，而不是一个团队。
+
+是的，围绕这个网站，作者创办了一家公司，雇佣了 85 名员工，并成为了公司的 CEO 也是唯一的程序员。因此，这就是一个在作者所处特定环境下的技术决策，虽看上去明显不太对，但在作者的相对限定条件下，这个决策实际省了他个人的负担（虽然扩展有明显的极限，网站也不会发展太大）。
+
+仔细看作者这个案例，可以发现其技术决策方案也是符合 “康威定律” 的。“康威定律”是这么说的：
+
+
+任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。
+
+
+换句话说，就是系统设计的通信结构和设计系统的团队组织的沟通结构是一致的。案例中，作者的系统只有他一个人负责设计与实现，只需要和不同阶段的自己产生沟通，在他的系统和场景下，变化最小、稳定度最高的是数据存储和结构，所以他选择把尽可能多的代码逻辑绑定在系统中更稳定的部分，从而降低变化带来的代价。
+
+而康威定律告诉我们系统架构的设计符合组织沟通结构时取得的收益最大。这是一个经过时间检验和验证过的规律与方法，体现的就是一个相对的选择标准，那在这背后，有没有隐藏着关于技术决策更通用的判断原则呢？
+
+原则
+
+康威定律，是和组织的团队、分工、能力与定位有关的，其本质是最大化团队的核心能力，最小化沟通成本。
+
+在足够大的组织中，沟通成本已经是一个足够大的成本，有时可能远超采用了某类不够优化的技术方案的成本。每一次人事组织架构变动的背后，都意味着需要相应的技术架构调整去适应和匹配这种变化，才能将沟通成本降下来。而技术方案决策的核心，围绕的正是关于方案的实施成本与效率。
+
+曾经很多次的项目技术评审会上，后端的同学和前端的同学经常就一些技术方案产生争论。而争论的问题无所谓谁对谁错，因为同样的问题既可以后端解决，也可以前端解决，无论哪条路都可以走到目的地。那么还争论什么呢？无非是各自基于局部利益的出发点，让自己这方更省事罢了。
+
+这些问题的解决方案处在技术分工的临界地带就容易产生这样的争论，而技术的临界区，有时就是一些无法用技术本身的优劣对错来做判断的区域。这时，最佳的选择只能是将前后端整体全盘考虑，以成本和效率为核心来度量，应该由哪方来负责这个临界区。
+
+而成本与效率背后的考量又包括如下因素：
+
+
+团队：这是人的因素，关于团队的水平，掌握的技术能力和积累的经验；
+环境：能利用的环境支持，公司内部的平台服务或外部的开源软件与社区；
+技术：技术本身的因素，该项技术当前的成熟度，潜在的发展趋势；
+约束：其他非技术约束，比如管理权限的干涉、限定死的产品发布日期等。
+
+
+不同的人，同样的技术方案，成本效率不同；不同的环境，同样的技术方案，成本效率也不同；不同的技术，同样的环境和人，成本效率也不同；不同的约束，同样的团队和环境，会得到不同的技术方案，成本效率自然不同。
+
+在技术的理想世界中，技术决策的纯粹部分，其决策原则都和成本效率有关；而其他非纯粹的部分，其实都是 “政治” 决策，没有所谓通用的原则，只和博弈与利益有关。
+
+最后，简单总结下：技术没有绝对的标准，适合的技术决策，总是在受限的约束条件下，围绕成本与效率做出的选择权衡。对于一些纯粹的技术理想主义者，追求技术的完美与合理性，初心本不错，但也许现实需要更多的行动柔性。
+
+关于技术方案分歧，你是否遇到过类似的争论呢？又是采用的是怎样的决策方式？欢迎留言分享和大家一起讨论。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/51技术债务，有意或无意的选择？.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            51 技术债务，有意或无意的选择？
+                            在编程的路上，我们总会碰到历史系统，接手遗留代码，然后就会忍不住抱怨，那我们是在抱怨什么呢？是债务，技术债务。以前说过，代码既是资产也是债务，而历史系统的遗留代码往往是大量技术债务的爆发地。
+
+然而，技术债务到底是如何产生的？它是我们有意还是无意的选择？这里就先从技术债务的认知开始谈起吧。
+
+认知
+
+技术债务，最早源自沃德·坎宁安（Ward Cunningham） 1992 年在一次报告上创造的源自金融债务的比喻，它指的是在程序设计与开发过程中，有意或无意做出的错误或不理想的技术决策，由此带来的后果，逐步累积，就像债务一样。
+
+当作为程序员的我们采用了一个非最优或不理想的技术方案时，就已经引入了技术债务。而这个决定，可能是有意的，也可能是无意的。有意产生的债务，一般是根据实际项目情况，如资源与期限，做出的妥协。
+
+而无意产生的债务，要么是因为程序员经验的缺乏引入的，要么是程序员所处的环境并没有鼓励其去关注技术债务，只是不断地生产完成需求的代码。但只要程序员在不断地生产代码，那他们就是在同时创造资产与债务。债务如果持续上升，软件在技术上的风险就不断增加，最后慢慢走向技术破产。
+
+以前看过另一位程序员写的一篇文章，名字就叫《老码农看到的技术债务》，印象还是比较深刻的。文中把技术债务分成了好几类，我记得的大概有如下：
+
+
+战略债务
+战术债务
+疏忽债务
+
+
+战略债务，是为了战略利益故意为之，并长期存在。我理解就是在公司或业务高速发展的阶段，主动放弃了一些技术上的完备与完美性，而保持快速的迭代与试错性。在这个阶段，公司的战略利益是业务的抢占，所以此阶段的公司都有一些类似的口号，比如：先完成，再完美；优雅的接口，糟糕的实现。
+
+这类债务的特点是，负债时间长，但利息不算高且稳定，只要保持长期 “付息”，不还本金也能维持下去。
+
+战术债务，一般是为了应对短期紧急情况采取的折衷办法。这种债务的特点就是高息，其实说高利贷也不为过。
+
+这类债务，一直以来经常碰到。比如，曾经做电信项目时，系统处理工单，主流程上有缺陷，对某一类工单处理会卡住。这时又不太方便停机更新程序，于是就基于系统的动态脚本能力去写了个脚本临时处理这类工单，可以应对当时业务经营的连续性，但缺陷是资源开销大，当超过一定量时 CPU 就会跑满了。这样的技术方案就属于战术债务的应用。为避免“夜长梦多”，当天半夜的业务低谷，我就重新修复上线了新程序，归还了这笔短期临时债务。
+
+疏忽债务，这类债务一般都是无意识的。从某种意义上来说，这就是程序员的成长性债务，随着知识、技能与经验的积累，这类债务会逐步减少。另一方面，如果我们主动创造一个关注技术债务的环境，这类债务就会被有意识地还掉。
+
+从上面的分类可以看出，战略和战术债务都是我们有意识的选择，而疏忽债务正如其名，是无意识的。但不论技术债务是有意的还是无意的，我们都需要有意识地管理它们。
+
+管理
+
+对于技术债务，开发团队中的不同角色关注的债务分类与形态也不太一样。
+
+比如架构师关注的更多是战略债务，保持系统能够健康长期演进的债务平衡。作为架构师，就像 CFO，需要长期持续地关注系统的资产负债表。战略债务可能更多体现为架构、设计与交互方面的形态。而具体某个功能实现层面的代码债务，则更多落在相关开发工程师的关注范围内。测试工程师，会关注质量方面的债务，而一到交接时，各种文档债务就冒出来了。
+
+那对于一个软件系统，我们如何知道技术债务已经积累到了需要去警示并着手计划进行还债的阶段了呢？一般来说，我们直觉都是知道的。
+
+举个例子来说明下，好几年前团队接手继续开发并维护一个系统，系统的业务一开始发展很快，不停地添加功能，每周都要上好几次线。一年后，还是每周都要上好几次线，但每次上线的时间越来越长，回归测试的工作量越来越大。再后来，系统迎来了更多的新业务，我们不得不复制了整个系统的代码，修改，再重新部署，以免影响现有线上系统的正常运行…
+
+到了这样的状况，每个人都知道，债务在报警了，债主找上门了。一次重大的还债行动计划开始了，由于还债的名声不太好听，所以我们喜欢叫：架构升级。架构升级除了还债，还是为未来铺路。当然，前提是要有未来。如果未来还能迎来更大的业务爆发增长，架构升级就是为了在那时能消化更多的长短期债务。
+
+管理债务的目标就是识别出债务，并明了不同类型的债务应该在何时归还，不要让债务持续累积并导致技术破产。一般来说，只要感觉到团队生产力下降，很可能就是因为有技术债的影响。这时，我们就需要识别出隐藏的债务，评估其 “利率” 并判断是否需要还上这笔债，以及何时还。
+
+有时，我们会为债务感到焦虑，期望通过一次大规模重构或架构升级还掉所有的债务，从此无债一身轻。其实，这是理想状态，长期负债才是现实状态。
+
+清偿
+
+在产品突进，四处攻城略地时，还需要配合周期性地还债，保持债务平衡，才能保证系统整体健康稳步地发展。
+
+首先，我们认识并理解了技术债务，识别出了系统中的各种债务，并搞清楚了每种债务的类型和利率，这时就需要确定合理的清偿还债方式了。
+
+对于战略债务，长期来说都是持续付利。就像现实中一些大企业从银行借钱经营发展，每年按期付息，但基本不还本金；等公司快速发展到了一定阶段，基本进入成熟期后，市场大局已定，再主动降低负债风险和经营成本。
+
+创业公司从小到大的发展过程中，业务在高速增长，系统服务的实现即使没那么优化，但只要能通过加机器扩展，就暂时没必要去归还实现层面的负债。无非是早期多浪费点机器资源，等业务到了一定规模、进入平稳期后，再一次性清偿掉这笔实现负债，降低运营成本。
+
+这就是技术上的战略债务，业务高速发展期保持付息，稳定期后一次性归还。
+
+战术债务，因为利息很高，所以一般都是快借快还。而疏忽债务，需要坚持成长性归还策略，一旦发现过去的自己写下了愚蠢的代码，就需要主动积极地确认并及时优化，清偿这笔代码实现债务。
+
+其次，还债时，我们主要考虑债务的大小和还债的时机，在不同的时间还债，也许研发成本相差不大，但机会成本相差很大，这一点前面分析战略债务时已有提及。而按不同债务的大小，又可以分为大债务和小债务。一般，我把需要以周或月为单位计算的债务算作大债务，而只需一个程序员两三天时间内归还的债务算作小债务，所以这不是一个精确的定义。
+
+小债务的归还，基本都属于日常的重构活动，局限在局部区域，如：模块、子服务的实现层面。而大债务的归还，比如：架构升级，就需要仔细地考虑和分析机会成本与潜在收益，所以大债务归还要分三步走：
+
+
+规划：代表愿景，分析哪些债务需要在什么时间还，机会成本的损失与预期收益是多少。
+计划：代表路径，细致的债务分期偿还迭代计划。
+跟踪：代表过程，真正上路了，确认债务的偿还质量与到位情况。
+
+
+如今微服务架构的流行，基本把小债务锁定在了一个或几个微服务体内。即使债务累积导致一两个微服务技术破产，这时的还债方式无非就是完全重写一个，在微服务拆分合理的情况下，一个服务的重写成本是完全可预期和可控的。
+
+除了技术债务的管理与清偿，我们还需关注技术债务与作为程序员的我们之间的信用关系，因为毕竟债务也是我们生产出来的。
+
+信用
+
+生产并拥有技术债务的程序员，并不代表其信用就差。
+
+现实生活中，债务依附于借债的主体方，比如金融债务依附于个体或组织，但如果个体死亡或组织破产了，债务就失去了依附体，自然也就消失了。而技术债务的依附体，并不是程序员，而是程序构造的产品或系统，所以当产品或系统的生命周期结束时，相应的技术债务也会消失。
+
+因而，此种情况下，程序员是有充足的理由不还技术债的，这是技术决策的一种，并不会降低程序员的信用。
+
+任何一个程序系统或其一部分都会与某一个程序员建立关联，如果这个程序员此时就负责这部分系统，那么他在此基础上继续创造代码时，既增加了资产也可能引入了新的债务。这时他的一个重要职责就是，维持好资产与债务的平衡关系。如果在此期间，系统的债务失衡导致技术破产，需要被迫大规模重构或重写时，那么这个程序员的信用必将受到关联伤害。
+
+所以，程序员的信用，更多体现在面对技术债务的态度和能力——有意识地引入债务，并有计划地归还债务；无意识地引入债务，发现之后，有意识地归还。
+
+再有代码洁癖的人也没法写出无债务的代码，而无债务的系统也不存在。面对负债高的系统，我们不必过于焦虑，高负债的系统往往活力还比较强。作为程序员的我们，应把技术债务当作一门工具，而不是一种负担，那么可能就又获得了新的技能，得到了成长。
+
+总之，面对债务，做一个有信用的程序员；将其当作工具，做一个有魄力的技术决策者。
+
+最后，你也可以聊聊你对技术债务的态度和看法，欢迎留言一起讨论。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/52选择从众，还是唯一？.md

@@ -0,0 +1,97 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            52 选择从众，还是唯一？
+                            想要取得成就，就会面临竞争，几乎所有的成就，都是直接或间接通过与他人的比较来评价的。理解了这样的评价与竞争关系，想要取得成就，出类拔萃，就意味着你要做出选择：选择从众、随大流，还是选择一条只属于自己的路？
+
+不同的选择，意味着面临的竞争水平不同，付出的努力自不相等。
+
+众争
+
+有时，我们会下意识不自觉地选择从众，随大流；这样的选择往往给人更安全的感觉，但这样的选择也意味着更激烈的竞争。
+
+随大流，属于众争之路，感觉是安全的，看上去也是热闹的，但竞争是激烈的，而且竞争所处的水平并不高，属于中等平均水平。比如：作为一名职业的普通程序员，你的任何一次求职、晋升或加薪，都面临类似水平的竞争，这样的竞争规模局限于一个局部市场，比如公司或部门内，规模不大，但人数不少。
+
+在这样水平的竞争层面，其实最顶尖的那部分程序员已被排除在外了，因为这类人在市场上其实供不应求，而且没有大规模的生产方法。处在这样的众争之地，如果你永远都在看周围的人在做什么，和他们保持类似，那么你就很可能处在这群人中的一个平均水平区间。
+
+其实，在这样的竞争水平下，你只需要稍微付出一些努力，就能超越平均水平；即使想要脱颖而出，也只需要持续地多付出一些努力。有一句流行的话是这么说的：“以大多数人的努力程度之低，根本轮不到拼天赋”，这就是众争层面竞争关系的本质。
+
+先努力拉开差距，再去找到少有人走的适合自己的路。
+
+稀少
+
+2% 的人创造内容，而 98% 的人消费内容；写作，就是这么一件少有人走的路。
+
+写作的竞争，其实就比职场的竞争高了一个层次。因为职场求职、晋升的竞争都是局部区域性质的，而写作不受地域的限制，最厉害和成功的写作者可以直接与你竞争。然而，写作也可以通过专业化和差异化来划分领域，从而缩小你的竞争范围。但即使是这样，你仅仅是成为你所在的小集体组织（如：部门或班级）中写作水平最高的人，也不足以赢得竞争，而是需要成为该领域最优秀的写作者之一。
+
+正因为写作所处竞争维度的残酷性，所以才会只有这么少的人在长期写作。我的写作之路，一开始本是因为有兴趣，偶尔有了感触或灵感就写写，属于灵感事件触发的兴趣写作。但这种没有约束感的兴趣写作导致的结果就是一年下来也没写出多少东西来，灵感这么飘忽的东西，似乎总也不来。后来，觉得需要增加点限制，保底平均每月至少写一篇，就像有人每月要去健一次身、跑一次步一样。
+
+就这样带着个限制，持续写了五年，从灵感触发的兴趣写作，到主动选择的规律写作，也算是写出了点东西。再后来，我把这个约束提高到了每周一篇，虽说这会带来更大的消耗，但我逐渐想清楚了它的意义：这就是一个 2% 的选择，少有人走的路。
+
+持续写作并不是为了写而写，它是为了满足自身。一开始即使写完一篇文章没人读，也是完成了最基本的价值，于我，即是每周一次的思维训练。就像每周健身一次，肯定比每月去一次效果更好。而一个写作者只需要持续去写对自己有意义和价值的东西就好，从一、两篇到一百、两百篇，也许其中某篇就和更多的人产生了共鸣，让写作和文字有了更大的意义。
+
+曾在和菜头的公众号看到有人留言：“菜头叔，我可以写，但是没人看，就非常难受……都大半年了，看的人还是二十几个……心累啊！”和菜头的回复是：“我写了十年的时候，也只有 400 人看，半年时间很长么？”
+
+当你写完一篇文字，把它推向这个世界的文字海洋，然后扑咚一声，便安静了下去，没有掀起一朵浪花。没必要纠结于此，继续写，继续改进，直到终于能掀起一丝涟漪，那么浪花也就不远了。
+
+当然，也并非一定要选择写作，本杰明·富兰克林是这么说的：
+
+
+要么写点值得读的东西，要么做点值得写的事情。
+
+
+写作本身就是一个关于选择的活动，而值得写的东西，本来也是稀少的。选择少有人走的路，通常也意味着你要大量地尝试，考虑自己的长处加上刻意的练习，虽不能保证成功，但却在创造可能性。
+
+稀缺
+
+稀少的事情，你可以有计划地去持续做；但真正稀缺的东西，比如：机会，却不会随时有。
+
+在前面 “计划” 系列的文章中，分享了我会采用计划清单来安排时间，每天其实早就做好了计划。计划得满满当当的，一件接一件地划去待办事项列表（TO-DO List）上的条目，成就感满满的。但执行了一段时间后就发现了问题，虽然有计划，但总是有变化，计划得太满，变化来了就总会让计划落空；计划得不到执行，就会产生懊恼与愧疚感。
+
+一开始我以为是计划得太满，缺乏弹性，所以无法应对变化。如果在计划里留出弹性空间，那么这些空间就是空白的，但如果一天下来没有太多变化发生，那这些留出的空白空间我又该做什么呢？这么一想，我突然就明白了，原来所有的日常计划都应该是备用的 B 计划（ Plan B），而真正的 A 计划（Plan A）就是变化，那种让你产生 “哇～噢～” 的惊叹感觉的变化。
+
+我们大多数人，对太多的东西做出了过度承诺。这些东西通常就是一些日常计划，都是些小而平庸的事情，它们填满了我们的生活。但问题是，偶尔遭遇到“哇～噢～，我的天！”这样的变化，一些事情发生了，却没有给予足够的时间和精力去注意它们，因为满脑子都在想着那些还没完成的日常计划。
+
+当一件事情来到你面前，决定是否需要去做时，如果你觉得不能让你产生 “哇～噢～” 的感觉，那么就可以坚决地说 “不”。这为你的生活留下了空间，然后当真正稀缺的 “哇～噢～” 时刻来临时，才可能有机会注意到并全身心地投入进去。“哇～噢～” 的稀缺时刻不会经常出现，所以才需要备用计划，既然是备用的，也是可以随时抛弃的。
+
+平时，计划做一些少有人做的事，然后等待稀缺的 “哇～噢～” 时刻与机会出现，这样的时刻或机会是没法规划或计划出来的，否则它就不是稀缺的。而能否让你碰到 “哇～噢～” 的稀缺选择机会，这好像有点运气。如果没碰到也就算了，但如果碰到了当时却没注意到，好几年后回过头来才发觉，那留下的将是 “哦～哎…”了。
+
+独一
+
+独一无二的路，要么是没有竞争的，要么是别人没法竞争的。
+
+瓦叔就曾走过独一无二的路，那瓦叔是谁？你多半熟悉，就是阿诺德·施瓦辛格，跟他有关的标签有：健美先生、终结者、美国加州州长。看过他的一个采访后，才明白：这看起来傻傻的大块头真有大智慧。
+
+他在自己发展的路上，问了自己一个问题：
+
+
+How can I carve myself out a niche that only I have?
+
+
+这句话怎么理解？Niche 这个词的原意是 “壁龛”，如果你参观过像千佛洞这样的地方，应该对山壁上放佛像的凹洞有印象，那就是 “壁龛”。而 Carve out 的原意是“雕刻”，所以比较形象的理解就是：如何在崖壁上雕刻出一个凹洞，把我这尊佛放进去。后来 Niche 引申为“职业生涯中合适的位置”，所以这句话就可以理解为：我如何为自己谋得一个独一无二的位置？
+
+这是他从健美先生转型进军好莱坞时问自己的问题。所以，在好莱坞他从不去试镜：“我才不会去尝试走这些常规路径，因为你知道我看起来长得就不像是一个常规的家伙。”因此，他没有急着去试镜一个角色，然后赚租金养家糊口。
+
+作为之前的全美乃至全球健美先生，已有一定的经济基础去支撑他等待一个合适的稀缺选择机会，然后他等到了一个独一无二的角色：终结者。导演詹姆斯·卡梅隆说：“要是没有施瓦辛格，我可能不会拍《终结者》这部电影，因为只有他像个机器人。”
+
+独一，可遇不可求；遇，也先得有遇的基础，它包括：异常的努力，不错的运气，非凡的能力，也许还有特别的天赋。
+
+可惜，我们很多时候都选择了随大流。
+
+最后，总结提炼下今天的内容：
+
+
+走众争之路，拼的是努力，只能成为平均的普通人；
+走少有人走的路，拼的是选择、勇气和毅力，可以让你遇见独特的风景，为稀缺的机会创造可能性；
+走独一无二的路，真的是要拼天赋了。
+
+
+那么，现在你正走在哪条路上？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/53选择工作，还是生活？.md

@@ -0,0 +1,100 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            53 选择工作，还是生活？
+                            从大学到职场，会经历一次失衡。
+
+在学校的时候，虽有时间课程表，但大部分时间还是属于我们自己自由安排的。毕业后，一进入职场，就会发现工作开始占据了主导，而后随着工作日久，越发陷入一种关于工作与生活平衡的选择困惑。
+
+处境
+
+工作与生活的平衡，到底是怎样一种状态？
+
+曾经我以为的平衡是这样的，我想很多人也这样以为过，工作与生活是完全隔离的。
+
+工作逼迫我们在寒冷的冬天早晨从热乎乎的被窝里不情愿地钻出，去日复一日地完成一些枯燥、乏味甚至令人心生畏惧的事情，但却又不得不安慰自己，工作让我们所做的这一切都是为了生活啊，再忍忍吧。
+
+而下班之后才是我们真正热切期待的生活，迫不及待地去玩热爱的游戏（对，那时我还热爱玩魔兽），周末就和朋友去游山玩水，感觉这才是生活。但似乎永远缺乏足够的时间去过这样的生活，假期总是太短，而工作的时间却总是在不断地变长。工作的第一年，我发现越来越少有时间玩游戏，总是在加班，总是坐最后一班公交车回到租住的小屋，冲个凉后，再一看时间，已经过了凌晨。
+
+而工作之后的第二、三、四年，长期地出差，似乎连周末都剥夺了，感觉总是在工作。我期待的平衡，完全地失衡了。不仅是我感觉如此，也有好些同事因此选择离开了广州，回到二、三线城市的家乡，比如：西安、长沙。那时我也在想，“我是不是也可以回成都，听说成都是一个休闲的城市呢，回去后，工作与生活是不是就会更平衡些呢？”
+
+是的，后来我就这么回来了，但却没有找到期待的平衡，工作反而变得丧失了充实与成就感，生活也变得更焦虑了。如今回首想来，当时我并没有认清和想明白自己的处境与状态，并去定义好属于那个阶段的平衡点。
+
+每个阶段会有每个阶段的生活目标。刚毕业时，对我来说合适的目标应该是：自力更生，好好生存下来并获得成长。再之后几年，生活目标会进化到：恋爱成家。再往后，目标也随之发展为：事业有成，家庭幸福。而我当时的症结在于，错把平衡当作了目标，而实际平衡更多是一种感受。有句话是这么说的：
+
+
+人若没有目标，就只好盯着感受，没有平衡，只有妥协。
+
+
+认清自己当前阶段的目标，定义清楚这个阶段的平衡点。一个阶段内，就不用太在意每一天生活与工作的平衡关系，应放到整个阶段中一个更长的周期来看，达到阶段的平衡即可。通过短期的逃避带来的平衡，只会让你在更长期的范围内失衡。
+
+作为个人，你需要承担起定义并掌握自己生活轨迹的重任，如果你不去规划和定义自己的生活，那么别人就会为你规划，而别人对平衡的处理你往往并不认同。
+
+结合当下的处境与状态，没有静态的平衡，只有动态的调整。
+
+关系
+
+工作与生活的关系，短期的每一天总在此消彼长地波动，但长期，应该是可以动态平衡的；当从长期的视角来看待工作与生活时，会发现二者之间并没有那么明显的分界线。
+
+长期的视角决定了，无论工作还是生活追求的都不应该是最后的目标或目的 —— 一种終点状态。你必须得关注过程，这个过程才是你的生活。所以，生活包括了工作，有时候甚至是非常艰辛的工作，就像我刚开始工作的那几年。那时，工作填满了我绝大部分生活，让我错觉工作剥夺了我的生活。
+
+只是因为当时我并没有想清楚自己到底想要一种什么样的生活，什么对我是重要的？我只是感觉从学校毕业进入工作，然后工作就逼迫着我放弃了曾经热爱的游戏。工作似乎在剥夺着我曾经生活中的很多东西，于是工作与生活就这样对立起来了。
+
+然而工作不该是受罪，我们应当从中找到乐趣，王小波是这么说的：
+
+
+人从工作中可以得到乐趣，这是一种巨大的好处，相比之下，从金钱、权利、生育子女方面可以得到的快乐，总要受到制约。人在工作时，不单要用到手、腿和腰，还要用脑子和自己的心胸。我总觉得国人对这后一方面不够重视，这样就会把工作看成是受罪，失掉了快乐最主要的源泉，对生活的态度也会因之变得灰暗…
+
+
+当想清楚了这点后，工作就不过是生活的一部分，何必需要去平衡。与其去平衡两者，不如从整体长期的角度去选择一种平衡的生活。一段时间，也许你的生活中充满了工作；一段时间，你决定减少一些工作，去交交朋友，谈个恋爱。再一段时间后，有了孩子，你决定把曾经生活里的一部分，比如玩游戏，换成陪孩子玩游戏。也许你没法每一天都能做到这样自如地选择，但从一个长期的角度（五到十年）你总是可以选择的。
+
+紧要的是，去过你想要的生活，而非不得不过的生活。
+
+而这里所指的“工作”已不再仅仅是“上班、打工”这样的狭义含义，而是更广义上的“工作”。比如，现在我正在写这篇文字，写到这里，时间已过了凌晨，窗外有点淅沥声，下起了小雨。我喜欢成都夜晚的小雨，突然想起了杜甫《春夜喜雨》中的某几句：
+
+
+随风潜入夜，润物细无声。
+
+晓看红湿处，花重锦官城。
+
+
+写作，于我就是另一种广义上的 “工作”。而且我喜欢上了这样凌晨夜里的写作，有一点点的辛苦，也有一点点的美好，是吧？这也是当下我选择的生活。
+
+比例
+
+既然要主动选择，从一定的长周期看，就需要确定到底怎么样的比例合适。
+
+选择工作在生活中的比例问题，是一个关于优先级和价值观的问题。从操作上来说，它其实是一个交易问题，关乎自己的所得和所失的交易。选择二者间的交换比例，意味着我们要进行权衡取舍，并为之承担相应的结果。
+
+工作与生活的平衡比例选择，既然从操作上是交易问题，那么我们也就可以借用一下投资交易中的一种颇有启发的策略：年轻时，要更多投资于风险更高、波动更大、但潜在收益也更大的股权类权益；随着年纪见长，就要慢慢增大更稳定和确定的债券类投资比例，降低股权比例。
+
+而且，这个策略还有非常具体的量化指标。就是用 100 或 120 减去你的年龄来得到你应该投资股权的比例。至于到底是用 100 还是 120，取决于你心理的风险承受能力和偏好。
+
+把这个思路用在平衡工作与生活上的话，大概是这样，假如对于一个非常有事业心和野望的人（可以理解为风险偏好大的人），大学毕业平均是 22 岁，那么就应该是 120 - 22 = 98，也就是 98% 的精力花在工作上，当然这里是广义上的 “工作”。而对于那些刚毕业但没有那么大野心的年轻人，也应该投入大约 80%（这是用 100 来减） 的精力在 “工作” 上。
+
+对于这个策略，我的理解是早期的高投入，是为了将来需要更多平衡时，能获得这种平衡的能力。在我有限的见识和理解能力之内，我是认同这个比例的。一开始就想获得安稳与平衡，人过中年之后是否还能获得这样的安稳与平衡，感觉就比较靠运气。掌控自己能把握的，剩下的再交给时代和运气。
+
+人生，就是在风险中沉浮，平衡的交易策略就是用来应对风险与波动的。
+
+工作是我们度过很长一段生命的方式，还有句话是这么说的：“我不喜欢工作，但我喜欢存在于工作里的东西 —— 发现自己的机会”，工作才会让我们找到属于自己的真正生活。
+
+而我们应该追求过好这一生，而非追求平衡，如何才算 “好”，每个人都会有自己的答案。我的答案是：不是通过努力工作来过上想要的生活，而是先设定了想要的生活，自然而然工作就会成为生活中合适的一部分。
+
+末了，我总结下今天的内容：
+
+
+缺乏真正的目标时，就只好盯着感受，把平衡当作了目标，由此带来了平衡选择的困扰；
+不同的处境与状态，会有不同的平衡点，需要做出规划与选择；
+短期只有此消彼长，长期才能动态平衡；
+早期年轻时的高投入，换取将来平衡的能力与选择权。
+
+
+那么关于工作与生活的平衡选择，你有怎样的看法呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/54侠客行：一技压身，天下行走.md

@@ -0,0 +1,101 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            54 侠客行：一技压身，天下行走
+                            从今天开始，我们进入了专栏的第 5 部分 —— 寻路：路在何方？这是一条关于方向、角色和自我定位的探索，那就让我们开始一起走走这条程序江湖路吧。
+
+大约三年前吧，读到一篇文章《为何我工作十年，内心仍无比恐慌》，来自一位腾讯产品总监的演讲分享。文中分析了一个让其感到恐慌与焦虑的深层次原因：好像不会什么技能，技能门槛低。
+
+这种恐慌和焦虑感在这个行业中普遍存在，不止于产品经理，程序员也一样。一些传统行业的生命已经远超过一个人的寿命，而 IT 互联网行业还不满三十岁，也许正是因为其还很年轻，生命力旺盛，远超传统行业的发展速度和新陈代谢规律，让其中的从业者深感疲惫，同时对未来又充满了不确定性，而未来的不确定性通常正是让我们感到焦虑的一个主要原因。
+
+门槛
+
+技能的门槛高低，决定了让我们产生恐慌和焦虑的水位线。
+
+在前面提到的《恐慌》一文中说，产品的从业门槛足够低，作者十年的从业经历中见过从事产品的人来自各种专业，还有各种改行做产品的。而从业门槛主要来自于技能门槛，特别是硬技能，硬技能属于行业的专有技能，需要足够的时间积累，通常这个积累时间就是你可能熟悉的理论值：一万小时。
+
+产品看起来是一个缺乏硬技能门槛的职业，因而感觉门槛低。而程序员职业其实是有一定硬技能门槛的，但这种门槛随着技术和工具的进步正在变得越来越低。如今 IT 互联网行业当然是繁荣的，繁荣的行业带来利差，自会吸引大量其他行业的从业者进入，而这些进入者自然会选择门槛低的职业工种来跨越边界。
+
+在其他行业干了些年头的人，有些可以在这个 “互联网+” 的时代通过垂直行业专家来进入互联网行业，但要进入程序员这个职业就得赶早了，毕竟硬技能需要的积累时间是很难省却得了的。大部分人都是在大学期间或刚毕业不久就完成了转行到程序员职业的切换，如我的一个高中同学，她本是文科专业中文系的，大二就毅然开始辅修计算机的第二学位了。
+
+还有个行业一直繁荣，需求永续存在而且供不应求，但却从没见过任何其他行业的人进入。我说的就是“医生”这个职业，它的硬技能门槛之高不免让人联想起《冰与火之歌》里的绝境长城，让人完全兴不起翻越的欲望。我听说过小说写得好的前妇产科医生，却没听说过手术做得好的前小说家。
+
+医学院的学生本科都要比其他专业多读一年，但本科毕业可能都找不到什么好工作，至少要读到硕士，想有点发展还得读博，十年一晃而过。而本科毕业的程序员，一进入 IT 互联网行业可能拿的工资比医学博士生刚进入医院还高，这就是行业繁荣的好处。但坏处是，这个行业变化太快，有时你没什么错，只是因为老了。很多互联网公司喜欢年轻人，标榜年轻，员工平均年龄二十多，所以才能最懂年轻人。
+
+而医生呢？这么说吧，你是喜欢年轻有激情的医生，还是经验老道的中年 “老” 医生？
+
+程序员看似是很有技术含量的硬技能门槛，实际远不如医生这个千年来的 “古老” 职业，行业的最低技能门槛要求挡不住很多人热情地涌入，而技能成长的天花板也感觉并不高，如何能不恐慌与焦虑？
+
+模型
+
+有时可能我们会有一个职业理想，叫 “一技压身，天下行走”，就像一名侠客一样，学好了功夫，从此闯荡江湖，好不逍遥自在。
+
+之前看过一本武侠玄幻小说，里面有一些角色就叫 “天下行走”，他们都有自己厉害的独门绝技，不厉害怎能天下行走。其中，剑客的剑快，野人的身体坚硬如铁，和尚从不说话修的闭口蝉，一开口就人人色变，这些就是他们独特的技能模型。
+
+技能模型才是区分不同专业人才特点和价值的核心关键点。
+
+而技能模型的形成是一系列选择的结果。以前玩过一个游戏叫《暗黑破坏神》，正常不作弊地玩，一个角色是很难点亮所有技能的，游戏是故意这样设计的。所以你可以反复玩来尝试点亮不同的技能组合方式，这样游戏才具备反复的可玩性。而与游戏不同的是，人生只有一次，你无法点亮所有技能，只有唯一的一种点亮路径选择塑造独一无二的你。
+
+而这种选择，可能一开始是无意的，比如我成为一名 Java 程序员是偶然的，而你成为一名 C++ 程序员也可能是偶然的，早期的技能点亮策略有很多的偶然性。但到了后期，我们逐渐成长，有了更多的经验和选择权，这时就需要主动选择去建立自己的技能模型。
+
+记得有一篇关于工程师思维的文章是这么说的：
+
+
+工程师思维的大道，就是先创造一个好模型，然后想办法实现这个模型，工程师关心的是能不能用这个模型创造出东西来。
+
+
+而技能模型其实正是工程师创造的第一个元模型，这个模型决定了后续作为工程师的你还能基于此创造怎样的模型，从而完成产品的实现。
+
+当只拥有一些零散的技能点，而且这些技能点还会随着时间流逝而过时，我们当然会感到恐慌与焦虑；但如果能够将这些技能点组合成我们独有的技能模型，提供独特的价值，从此独步江湖，甚至开宗立派，想必也就没那么恐慌与焦虑了。
+
+以前文章写过关于 “知识体系”的内容，那它和技能模型有什么区别？知识体系本质也是一种知识模型，但技能模型更深一个层次，因为技能是对知识的应用。知识模型构筑了理论边界，技能模型是实践的路径。
+
+路径
+
+那么，关于技能模型这条实践路径该如何去选择和构建呢？
+
+程序员作为工程师的一种，必须得有一项核心硬技能，这是需要长时间积累和磨练的技能，要花大力气的，而这个大力气和长时间，也正是这门技能的门槛。关于技能的习得有一个流行的看法是：花 20% 的时间快速获得某个领域 80% 的知识和技能。这看起来像是一种学习的捷径，但一个硬技能领域最核心的竞争力往往都是最后那 20% —— 也就是你用那 80% 的功夫反复磨练出来的最后 20% 的技艺。
+
+古龙小说中有个角色叫荆无命，他腰带右边插着一柄剑，剑柄向左，是个左撇子，江湖中都知道他左手剑快，但其实他右手剑更快。荆无命要是个程序员的话，那可能就同时具备了两个核心硬技能，属于那种 Java 很强，但 C++ 更牛的人。但我从业这些年还没碰到过同时点亮两者的，无论 Java 还是 C++，因为各自都有足够大的生态和体系，已经需要很长的时间来积累和打磨了。
+
+我们大部分普通人，拥有的是有限的时间与才华，面对的是无限的兴趣和技能，同时修炼多个核心硬技能是不明智，甚至是不可行的。记得以前读万维钢有篇文章介绍了一本书叫《达芬奇诅咒》，文艺复兴时期的达芬奇是一位多才多艺的人，但一个人如果像达芬奇一样对什么东西都感兴趣，但又没有和达芬奇匹敌的才华，很可能尝试了很多，最终却一事无成，这就中了 “达芬奇诅咒”。
+
+所以，构建核心技能模型其实是关于才华和技能的战略。《达芬奇诅咒》一书作者就选择技能领域推荐了三个标准：
+
+
+你确实喜欢
+你在这个领域有天赋
+这个领域能挣到钱
+
+
+我仔细回味了下这三个标准，真是很接地气，实在可行。你喜欢的领域，至少在启动进入时也容易一些，长时间的坚持时也更有毅力一些；而你有天赋的领域，信心也足一些，并且拥有相对竞争优势；能挣到钱的领域，最好还比别得领域更挣钱，那么外在的经济激励会更强，而同等努力相对收益也更大。无怪乎，一个技术热潮起来后，大家都看到了第三点，急匆匆跳进去，但往往忽视了前两点。
+
+另一方面，多个核心硬技能之间是一种加和关系，若非迫不得已，再下同样的大功夫去修炼另一项核心硬技能显得就不是那么明智了。所以应先深度修炼“一门”核心硬技能，建立门槛，但需要深到何种程度才能天下行走？如果刚开始起步算 0， 1 算是行业平均水准，那至少先要专注在核心硬技能上，并修行到 1 以上，能进入前 20% 就更好了。
+
+然后，就可以围绕核心硬技能适度练习和发展一些辅助技能，这些辅助技能大多属于软技能，也有部分硬技能，只是没有核心技能那么硬，通常起到放大和加强核心技能的作用，可以发挥指数效应。这也是为什么核心硬技能要先修行到 1 以上，因为指数关系只有在大于 1 时才有意义。
+
+有些辅助软技能可以通过刻意练习来掌握，而有些则很难，属于埋藏在天生的基因和后天的成长性格中。在漫画《火影》的忍术体系中对这种天生的技能有个术语叫 “血继限界”，其中最厉害的当属 “写轮眼”。想想在职业发展的技能体系中，有什么是可媲美 “写轮眼” 的辅助软技能的？如果你幸运拥有这种 “血继限界”，可别浪费了天赋。
+
+程序员怕什么？就怕技术潮流的颠覆直接废了全身武功。我读大学时就经历过一次，当时主流的企业应用开发是 C/S 架构的 Delphi 和 VB，如今已是明日黄花。而武功体系由内力加招式组成，技术的演进容易废了招式，却不容易废了内力。
+
+张无忌学会九阳神功，一身内力惊人，招式现学现卖也打的少林龙爪手高僧叫屈，所以在点亮技能模型树的过程中，你得分清九阳神功和龙爪手的区别。类比于技能模型树，内力是根茎，招式如花叶，时间流逝，落花残叶，冬去春来，复又发新。
+
+到这里，关于技能的焦虑和建立技能模型的方法，我们就探讨完了，最后总结提炼下：
+
+
+程序员这行的技术门槛没想的那么高，所以就此易引发恐慌和焦虑；
+建立你自己的技能模型，才能提升门槛和核心竞争力；
+避开 “达芬奇诅咒”，围绕核心硬技能，发展“一主多辅”的技能模型树。
+
+
+从此，种下技能模型之树，让其茁壮生长，方能一技压身，天下行走。
+
+在程序这个江湖上，你又是靠什么在行走天下呢？欢迎你留言分享。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/55江湖路：刀剑相接，战场升级.md

@@ -0,0 +1,91 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            55 江湖路：刀剑相接，战场升级
+                            回首自己的成长之路，通常每五年就会感觉碰到一个成长的瓶颈点。在传统 IT 行业的第一个五年后，我就感觉明显进入技术成长的瓶颈期；之后也算有点运气，通过转换到互联网行业升级到了新的技术维度。
+
+又过了五年，站在十年后的一端，回望过去，刀剑相接，如梦似幻，我渐渐感知到突破这次瓶颈的道路，就意味着走向一个升级后的新战场。
+
+刀剑相接：杀人术
+
+天下风云出我辈，一入江湖岁月催。
+
+你狠狠地敲下键盘的回车键，终于看见程序按预期输出了正确结果。长长吐了一口气，点上一支烟，环顾四周，独自一人，又是一个夜深人静的晚上。在一种搞定 Bug 的满足与空旷寂寥的忧伤中，你不禁迷惘。
+
+记不清这是你修复的第多少个 Bug 了，甚至记不清这是你参与开发和维护的第几个系统了。就像一个剑客在这个江湖上行走多年，已记不清死在自己剑下的人有多少，拔剑，收剑，有人倒下，你继续行走，如今 “杀人术” 已成。
+
+对一个程序员而言何谓 “杀人术”？你选择了一门语言开始学习编程，就像一个刚入江湖的人选了学剑或刀。再弄几本江湖宝典，假想了一个项目开始练习，熟悉基本的使用套路。然后走入江湖，拜入门派，腥风血雨，数年后剑鸣空灵，刀啸云天，飞刀无影，“杀人术” 终成。
+
+这就是一个程序员的成长之路，你选了门武器，学了基本招式，然后进入江湖不停地在厮杀中成长。终于你能搞定各种各样的系统问题，了解不同系统的设计模式。每过数月或一年半载，你总会发现过去的代码写得不好，再重构上一遍，改进你的招式，数年后，终成江湖高手。
+
+一个程序员修成 “杀人术” 大概需要多久？按照一万小时理论，如果你在某一领域每天持续学习和实践练习十小时，最快也要三年。但这三年是没算各种可能的中断的，比如：生病、偷懒、假期休闲娱乐等等，所以大部分人的平均时间可能需要五年。
+
+五年成术已算理想，实际上我自身用了更长的时间，走了更多弯路。从 Basic 程序入门，后来 VB 再到 Delphi ，然后 C 最后 Java，Java 也经历了几代变迁，但还算一脉相承。技术的发展，时代的变迁会让 “杀人术” 也在不停地演化。而今剑术已成，然拔剑四顾，却发现已进入枪炮时代，不免心下茫然。
+
+经历了一万小时的杀人术训练与实战后，技能增长曲线已经进入了对数增长的平缓期，过于单一的技术维度成为了我们的瓶颈和焦虑的源头，该如何去突破这样的瓶颈点？
+
+认知升维：化形
+
+爱因斯坦说过：“我们不能用制造问题时同一水平的思维来解决问题。”
+
+技能维度的瓶颈问题，经常会让作为程序员的我们陷入一种常见的平面思维方式。比如，一个程序员做了十多年桌面客户端开发，后来移动崛起，桌面式微，就颇感焦虑，这就是他所面临的技能维度的瓶颈。而他想尝试突破的方法，可能却是转到服务器的后端开发，因为感觉这个领域还一直比较长青。
+
+然而这只是从一个领域的核心硬技能转换到了另一个领域，但这两个领域基本是独立的，关联性很弱，而且交叉的区域也很薄，也就意味着很多经验和能力要重新积累。这就是从问题本身的维度去寻找到的解决方案，而爱因斯坦说了，我们需要到更高的维度去寻找答案。而更高的维度就是认知的维度，所以首先需要的是升维我们的认知结构。
+
+在我修行成术的过程中出现了好多新技术，当时我总想忙完这阵就抽空去学习了解下。但一过几年也一直没能抽出空去看，如今再去看时发现好些当年的新技术已不需再看了。五年成术是立足于一点，成立身之本；而下一阶段不该是寻找更多的点，而是由点及线、由线成网、由网化形。围绕一个点去划线，由一组线结成网，最后由网化成形，“化形” 表达了一种更高级的知识和技能运用形态，比一堆离散的知识技能点有价值得多。
+
+而对于认知升维，由点及线、由线成网、由网化形，其实走的是一种 “升维学习” 之道。这个过程几乎没有终点，是一个持续学习、不断完善的过程，最终结多大的网，成什么样的形，全看个人修为。一条线至少要两个点才能画出，那么第二个点的选择就要看能不能和第一个点连起来了，而这比在一个维度上去预测和乱踩点要有效得多。
+
+其实这套道理在金庸设计的武学体系中也很是明显。这里就以大家最熟悉的《射雕》三部曲为例来看下。郭靖一开始师从江南七怪，后来又跟全真七子中的几位学过功夫。这在功夫里就是两个点，但没看出这两个点有何联系，最后郭靖江湖成名，终成一代高手靠的是什么？降龙十八掌。为什么有十八掌这么多，从小说里的描述表达了一个体系的意思，一个体系结网成形，最后的形态命名为降龙十八掌。
+
+其实郭靖还学了另一个更有体系、形态更牛的武功秘籍——《九阴真经》。除了郭靖，《九阴真经》还有很多人看过、学过，有高手如：黄药师、王重阳等，也有一般人如：梅超风。高手们本身有自己的武功体系和形态，所以看了《九阴真经》也仅仅是从中领悟，融入自己的体系中甚至因此创造出新的武功形态。而梅超风之流则仅仅是学点其中的招式，如：九阴白骨爪，和之前自身所学其实没有太多关联，武功境界终究有限。
+
+所以，升维化形，化的正是技能模型，而这套模型基本决定了你的功力高低。
+
+再回到前面那位桌面端程序员的瓶颈问题，升一点维度看更泛的终端，桌面端不过是这棵技能模型树上的一个分枝。树并没有死，甚至更壮大了，只是自己这棵枝干瘪了些，所以可以去嫁接其他分枝获取营养，而非想要跳到另一棵树上去，重新发芽开枝。
+
+战场升级：十面埋伏
+
+结网化形，走上升维之道，因而战场也变大了，但你的时间并没有增多，这就存在一个理论学习和战场实战的矛盾。
+
+到底是应该更宽泛地看书学习建立理论边界，还是在实战中领悟提升？关于这点，你需要选择建立适当的平衡，走两边的极端都不合适。在学校的学习更多是在建立理论体系，而在工作前五年的成术过程则更多是偏实战。
+
+再之后的阶段又可能需要回归偏理论，提升抽象高度，从具体的问题中跳出来，尝试去解决更高层次、更长远也更本质的问题。而从更现实的角度来看，你的环境也会制约你能参与实战的经历，导致有些东西靠实战可能永远接触不到，不去抽象地思考是无法获得和领悟的。
+
+历史上关于理论和实战有很多争论，还留下了一些著名的成语。理论派的负面历史代表人物有：赵括。还有一个关于他的成语：纸上谈兵。他谈起军事理论来一套一套的，一上战场真打起来就葬送了数十万将士的性命，所以大家都会以赵括为例来批评没有实战经验支撑的理论靠不住。
+
+但其实还有另一个更著名的历史人物，也是理论派出身，在真正拜将之前也没什么实战经验。并且也有关于他的成语，如：背水一战，这是他抽象地思考过很久的战法，但也是第一次上战场使用，一战而青史留名。
+
+他就是韩信，历史上说他率军出陈仓、定三秦、擒魏、破代、灭赵、降燕、伐齐，直至垓下全歼楚军，无一败绩，天下莫敢与之相争。王侯将相韩信一人全任，一时国士无双，属于中国古代从理论到实战的谋战派代表人物。
+
+韩信的对手项羽在历史上就是一个实战派代表人物，个人的 “杀人术” 相比韩信高出怕不止一个等级。但其实他和韩信根本不在一个维度上，韩信在最后面对项羽前，已通过众多大大小小的战斗去不断实证和完善了他的谋战理论。垓下之战项羽中十面埋伏，致其乌江自刎，更像是一场高维打低维的降维攻击。
+
+所以，关于理论和实战的关系，从这个历史故事可以有所体会。而 “十面埋伏” 这样的技能维度显然比 “霸王举鼎” 要高出不少，而升维后的技能，也需要升级后的战场才发挥得出来。
+
+技能的成长速度总会进入平缓阶段，并慢慢陷入瓶颈点，然后也许你就会感到焦虑；而焦虑只是一种预警，此时你还未真正陷入困境，但若忽视这样的预警，不能及时进行认知和技能升维，将有可能陷入越来越勤奋，却越来越焦虑的状态，结果走入 “三穷之地”（包括如下三种“穷”）：
+
+
+结果穷：技能增长的边际收益递减；
+方法穷：黔驴技穷，维度过于单一；
+时间穷：年龄增长后你能用来成长的时间会变少，分心的事务更多，而且专注力会下降。
+
+
+认知和技能升维带来新的成长收益，同时防止了单一维度的死胡同，而年长的优势正在于经验带来的理解力和思考力的提升。
+
+最后，总结下今天的分享内容，在程序江湖上，从刀剑相接到战场升级走的是这样一条升维路：
+
+
+刀剑相接的战场，我们靠 “杀人术” 也即硬技能求生存，但时间久了就会有瓶颈；
+技能升维，需要认知结构先升维，“我们不能用制造问题时同一水平的思维来解决问题”；
+升维后的技能，也需要一个升级后的新战场，走上理论结合实践的 “谋战” 之路。
+
+
+在我的寻路过程中，我找到的就是这样一条技能升维之道，那你呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/56御剑流：一击必杀，万剑归心.md

@@ -0,0 +1,83 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            56 御剑流：一击必杀，万剑归心
+                            在前文《江湖路》中我找到的路是一条 “战场升级，技能升维” 之路，技能与战场的升维演化是一个相辅相成的过程。进入了升级后的战场，也需要升维后的技能模型，那我们该如何从旧有的技能模型进行升维演化呢？
+
+我想还是用一些形象点的武功招式来类比说明。
+
+拔刀斩
+
+拔，提手旁，喻义需要亲自拔刀动手。
+
+而拔刀术源自日本古武道，其核心思想便是一击必杀，利用瞬间高速的拔刀攻击对敌人造成出其不意的打击。其讲究的是快，也即速度和锋利度。
+
+武士不断修行拔刀术，力求一击杀敌，而程序员学习和练习编程的过程也是类似的。最终，你的编程技能到达了一个什么样的程度，就是看它的锋利度，即面临一个个程序问题能否一刀见血，一击必杀。
+
+刚入门的程序员上线发布碰到了一个问题，抓耳挠腮，冥思苦想，加班加点终不得解。于是跑来向你这个高级程序员请教，此时时钟指向了凌晨一点。你放下手中刚泡好正准备吃的方便面，一支燃烧着的半截烟头挂在你的指尖。你犹豫了一下：是猛抽两口还是灭掉烟头去处理这个紧急问题？
+
+最终，你终究不舍地把半截烟头小心地放在方便面盒边沿，再用塑料的方便面叉把面盖和烟头一起固定住。然后，你挽起了袖子走到这个年轻程序员的电脑前，迅速扫了几眼报错的错误日志，再调出你心爱的 vi 编辑器，噼里啪啦地改动了几行代码，保存，关闭，再重新构建，发布。电脑黑底白字的界面不停地滚动着，你已站起身向散发着两种味道的方便面走去，并回头轻轻对年轻程序员说了声：可以了。
+
+这就是你向年轻程序员展示你的拔刀术，问题一斩而绝。好吧，这是一种诡异的优雅，似乎任何问题对于电影里的程序员而言，在电脑前噼里啪啦敲上几行代码都能解决。但现实中大部分时候都比看上去要更困难一些，真实世界的拔刀术和动漫《浪客剑心》里剑心的 “天翔龙闪” 相比，终归显得笨拙了许多。
+
+而拔刀术正是我们第一阶段的技能模型，在我们追求 “天翔龙闪” 的境界时，看上去并不遥远，但越走到后面，却越来越慢了，似乎永远也到不了，这就是已经进入了第一阶技能的瓶颈区间了。
+
+在瓶颈区中，进境缓慢近乎停滞，就可以尝试下技能升维 —— 从 “拔刀” 到 “御剑” —— 看能否在新的战场找到突破点。
+
+御剑术
+
+御，双人旁，喻义贴身教授与把控。
+
+御剑术，这个招数的类比来自好多年前（我那会还读初中吧）玩过的一个电脑游戏——《仙剑奇侠传》，我记得这也是游戏里主角在第二阶段学会的技能。如果过去面临问题你需要拔刀解决，那这里的 “刀” 就是你的知识、技能和经验。那御剑术里的 “剑” 又是什么？
+
+记得以前读过一篇关于高级程序员的文章，其中提出了一个组合三角的观点，先看下面这张图：
+
+
+
+程序员成长阶段要求的帮助和提供的指导变化趋势示意图
+
+图中蓝色三角区域表明，随着你从入门初级成长到高级程序员的过程中，需要得到的帮助和指导越来越少；而红色三角区域表明，你能提供的帮助和指导应该越来越多。所在，在前面那个想象的 “泡面拔刀” 的场景中，作为高级程序员的你，更理想的做法应该是去指导年轻程序员如何解决问题的思路，而不是自己拔刀，唰唰两下搞定。
+
+对，很多高级程序员都会以 “等把他教会，我自己早都搞定了” 为由，忍不住自己拔刀。理解、掌握并应用好一种知识和技巧是你的 “拔刀术”，但分享传递并教授指导这种知识和技巧才是 “御剑术”，而 “剑” 就是你面前更年轻、更初级的程序员。
+
+曾经多少次面对年轻初级程序员交付的结果，我都有一种懊恼的心情，怀疑当初是不是该自己拔刀？那时就突然理解了驾校老司机为何总是满腔怒火地吼着：“让你松点离合，只松一点儿就好…”，而当初的我刚学开车时，一开始不是松少了，就是熄火了。
+
+从 “拔刀术” 到 “御剑术”，其技能模型的招式和对象变化了，但本质框架却是类同的，这里的关键点是：如何剥离自我，通过他人来完成设计和实现，并达成解决问题的目标。
+
+万剑诀
+
+诀，言字旁，喻义以言引导，影响多于控制。
+
+所有的程序员都是从修行 “拔刀术” 开始，但只有极少数人最终走到了剑心 “天翔龙闪” 的境界，所有未能突破的我们都进入了瓶颈停滞区。我们不断学习和练习，终于练到拔刀由心，收发自如，终成习惯，但要将这个技能升维，跨越战场，却正是需要打破这个习惯。
+
+其中，从 “拔刀术” 到 “御剑术” 是习惯的打破；从 “御剑术” 到 “万剑诀” 则是量级的变化。因而，“御剑术” 是修行 “万剑诀” 的必经之路。嗯，游戏里也是这么设定的。
+
+“万剑诀” 正如其名，御万剑而破敌。回到现实中，这是一项高杠杆率的技能。而高杠杆率的活动包括：
+
+
+一个人可以同时影响很多人。
+一个人可以对别人产生长远的影响。
+一个人所提供的知识和技能，会对一群人的工作造成影响。
+
+
+这就是 “万剑诀” 的核心要诀。应用到程序员修行之路上：如果走上同时影响多人的路线，这就是一条团队管理和领导者之路；如果走上影响长远的路线，你可能乐于分享、传授，这可能是一条布道师的路线；如果你通过提供知识和技能来影响其他一群人的工作，那么这可能是一条架构师的路线。
+
+“万剑诀” 和 “御剑术” 的共通之处在于都以人为剑，观察、揣摩每把剑的特性，先养剑再御剑最后以诀引之。若 “拔刀术” 是自己实现的能力，那 “御剑术” 和 “万剑诀” 都是借助他人使之实现的自信和能力，只是后者相比而言规模更大，杠杆率更高。“万剑诀” 的重心在追求问题解决的覆盖面，而面临每个具体问题时就需要依赖每把剑的锋利度了。
+
+另外，“御”之一字更着重了一层控制的含义，而 “诀” 之一字在于影响多于操控，这里面的关键点就是：剑本身的成熟度。不够成熟的剑只能 “御” 之，足够成熟的剑方能 “诀” 之。
+
+走上 “万剑诀” 之路后，还能再领悟 “天翔龙闪” 的奥义么？也许这是时代演进让我们不得不做出的选择，今天的程序江湖掌握了 “天翔龙闪” 奥义的 “神” 级程序员已经越来越成为一个传说，数十年前，那个英雄辈出的年代已不复再现。
+
+拔刀术，是亲自动手斩杀问题，难处在于维度单一，后期进境陷入瓶颈停滞；御剑术，是指导他人解决问题，难处在于打破习惯，剥离自我；万剑诀，是借助他人使之实现，难处在于剑的养成。
+
+它们的共通之处，都是基于长期的编程和工程训练，建立的系统化思维能力，创造模型来解决问题，而变化在于模型的适用对象不同，导致需要不停地调试合适的 “模型参数” 来适配问题，并且不论是技术框架还是人的 “模型参数” 都是在变化之中的。
+
+最后，在你的技术升维演进转型路线上，你对这类变化的感受和认知是怎样的？欢迎留言分享。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/57三维度：专业、展现与连接.md

@@ -0,0 +1,158 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            57 三维度：专业、展现与连接
+                            曾经在和朋友探讨个人发展的问题时，讨论出一个 PPC 理论，该理论粗略地把涉及个人发展的方向分成了三个维度，包括：
+
+
+专业 Profession
+展现 Presentation
+连接 Connection
+
+
+而像程序员这样的专业技术人员，都倾向于在专业维度不断发展提升，却往往忽略了另外两个维度。如果三个维度综合发展的话，可能会得到 1 + 1 + 1 >> 3 的效果，即三个维度相加远远大于 3 的效果。
+
+一、专业 Profession
+
+什么才算是 “专业”？其实没有一个标准定义，我尝试将其进一步分解为三个子维度。
+
+专业能力
+
+专业能力，包含了知识和技能。以程序员为例，具备专业能力的软件工程师应该拥有系统的知识体系和相应技能。
+
+那么程序员的系统知识体系和技能又包括哪些？曾经在知乎看到过一个抽象的类比，它用我们在学校学习的各种学科体系来类比程序员的专业知识体系和技能，我结合自己的理解也做了一些延伸，包括下面这些方面：
+
+
+数学：这个不算类比，因为数学就是计算机科学的基础；
+物理：程序世界中的基本定律，如CAP、NP、算法与数据结构；
+化学：程序世界中的 “元素” 和属性，如编程语言平台、各类框架和系统特性。
+
+
+在程序世界里，学好 “数理化” 基本也算走遍天下都不怕了，到哪都能找个工作，但这还不够。“数理化” 属于硬知识与技能，实际工作中还需要软知识与技能。而软知识与技能又包括如下内容：
+
+
+语文：除了能写代码，还得能写好文档，起得好名字，表达好逻辑，让代码更可读、可懂；
+英语：高级编程语言几乎都是英语的子集，第一手的技术材料多来自英语世界；
+生物：不同的技术都发展出了不同的生态体系，今天的系统几乎都在某种生态之中；
+历史：任何一门新技术，都有其历史渊源，它从哪里来，将会到哪里去；
+艺术：编程是一门艺术，一种逻辑与审美的表达；
+经济：成本、收益、效率，有关技术决策的核心；
+建筑：有关架构的一切，钢筋、水泥、脚手架、灾备、抗压、防单点以及相关的权衡。
+
+
+当把这些学科的知识和技能都掌握得七七八八了，那么才算具备了专业能力。
+
+专业行为
+
+专业行为，包括规范化的工作流程和作风，严格的职业纪律与操守。
+
+这些专业的行为，最终会内化成一个人的习惯，敏捷专家肯特·贝克（Kent Beck）说过一句话：“我不是个优秀的程序员，我只是一个有着优秀习惯的普通程序员。” 所谓 “优秀习惯”，就是专业行为的一个重要体现。
+
+专业能力加上专业行为，会让你从周围的合作者那里得到一个做事很专业的评价。
+
+专业产出
+
+专业产出，指最终产出的结果是稳定的，可预测的，处在一定品质标准差范围内的。
+
+这一点可以用小说家类比。比如，金庸写了 15 本武侠小说，从第一本到最后一本的产出质量都在一定的水平之上，他的最低标准也高于绝大多数人，品质标准稳定可靠。而同时代的古龙，就不是这样的，早期古龙的小说良莠不齐，品质标准的波动范围很大；其中的分水岭是《绝代双骄》，之后的小说才开始逐渐稳定在一个很高的品质标准之上了。
+
+所以，一个专业的程序员，交付的程序应该像金庸和后期的古龙那样，在一个可预测且稳定的品质标准之上波动。
+
+所有技能维度的成长都是一条对数增长曲线，迟早会进入上升的平缓区，在这个区间 “投入增长比” 不高，这时就可以适当发展下后面两个维度，将会是不错的选择。
+
+二、展现 Presentation
+
+展现建立于专业的基础之上，所以展现也对应着专业的三个子维度。
+
+
+展现专业能力：包括代码、架构、认知、决策；
+展现专业行为：包括沟通、交流、表达、协作；
+展现专业产出：包括作品、方案、洞察、演示。
+
+
+对应这些展现的需求，有不同的展现形式，无外乎下面这些。
+
+
+代码：Github 等开源站提供了最直接的围绕专业能力中编程能力的所有展现形式、证据和历史；
+交流：在日常的即时通讯、邮件、会议、交谈与协作中，展现了关于专业行为的一切；
+演讲：有关专业产出的重要形式，如汇报（业绩产出）、分享（作品与影响力产出）；
+写作：文字作品，一种长尾影响力的产出形式。
+
+
+在大部分情况下，你的专业价值评估都是由你的展现水平来决定的。
+
+三、连接 Connection
+
+我把社交连接分成了 5 个圈层，一般每个人都会具备前两个圈层，而只有在展现的基础之上，才有扩大连接到后面三个圈层的可能性。
+
+10
+
+人生的每一个阶段，都会有一些最要好的朋友，也就是好朋友，这是我们社交关系中最强的连接了。
+
+一般这个数字都低于 10，而我自己的经历是，每一个阶段其实都没有超过 5 个。从小学、中学、大学、工作，包括从一个城市到另一个城市的不同阶段，各个阶段都有一些关系很好的朋友，但每经历过了一个阶段，这些好朋友就会发生变化。
+
+很少有人，小学时候的好朋友，到了如今还是好朋友的，人生的变化实在太难预测。而这种好朋友的亲密关系，在每个阶段对你都是最有意义和价值的，会让你感到生活的快乐与幸福。
+
+因而，50% 以上的社交时间都值得花在每个阶段最好的这 5 个朋友身上。
+
+100
+
+有一个神奇的数字叫 “邓巴数”，它来自神经科学领域，研究认为：
+
+
+人的大脑新皮层大小有限，提供的认知能力只能使一个人维持与大约 150 人的稳定人际关系，这一数字是人们拥有的，与自己有私人关系的朋友数量。也就是说，人们可能拥有 150 名好友，甚至更多社交网站的 “好友”，但只能维持与现实生活中大约 150 个人的 “内部圈子”。而 “内部圈子” 好友在此理论中指一年至少联系一次的人。
+
+
+按这个定义，我自己的感受是很难维持这么多联系，因为社交负担太大了。当然如果把上文中的 “联系” 理解成朋友圈点个赞也算的话，勉强也能达到吧。实际上，好多曾经阶段属于好朋友的人，过了那一个阶段，比如考上大学，大学毕业后各奔东西，慢慢也就进入了这个圈层。一开始还常联系，慢慢联系会越来越少，最后只在重要节假日（如春节）发个短信或红包了。
+
+曾经熟悉的同学、同事们，大部分都在这个圈层中，除此，也会有一些当下新认识的熟人。总之，这个圈层中都是一些你们彼此还算认识，并且在一定程度上也彼此认同对方一部分价值的人。
+
+以上就是几乎所有人都有的社交连接圈层。再往后的三个圈层，就只有极少数人拥有了。
+
+1000
+
+2008 年，著名科技作家凯文·凯利写了一篇文章《一千个铁杆粉丝》（1000 true fans），这里的 1000 连接圈层就是这么来的。不过这有个前提，就是你必须是一个创作者，而凯文·凯利的观点是：
+
+
+任何从事创作或艺术工作的人，例如：艺术家、音乐家、摄影师、工匠、演员、动画师、设计师或作者等，只要能获得一千位忠实粉丝就能维持生活。
+
+
+他大概是这么计算的，通过出售创作作品每年从每个铁杆粉丝上获取100美元的收入，那么每年大概有10万美元的收入，就足够生活了。今天，获得 1000 个粉丝不算太难，但在前面加上铁杆，就太难了。所谓铁杆，就是不论你创作的是什么，他们都愿意支付买单。
+
+而我理解 1000 个铁杆也不必是固定的同一批人，可能是流水变化的 1000 人，他们只是每年为你不同的作品支付买单而已，但前提就是你得有持续的创作能力。
+
+10000
+
+这个层次是拥有一万个关注者（如：微博）或订阅者（如：微信公众号）。
+
+这个量级才算是拥有了培育自己观点和内容种子的一块自留地，在这块土地上你可以播下你的观点，可能有人支持，也有人反对，更多人是不置可否，但至少你可以开始拥有了反馈。但若没有这块自留地，你的声音或观点几乎不会在互联网上收到什么反馈，也无法形成有效的讨论和互动。
+
+100000+
+
+自从有了微信公众号，100000+ 现在也是一个神奇的数字了；100000+ 的存在，体现了一个信息、观点与影响力的传递网络。
+
+五种连接圈层，第一层次 “10” 的连接是强连接；其他的都是弱连接，弱连接的价值在于获取、传递与交换信息。强连接交流情感，弱连接共享信息。
+
+而建立连接的关键在于：给予。也许并不需要物质上的给予，仅仅是心理上或是虚拟的给予。所以说为什么展现是扩大连接的基础，展现即创作表达，创作即给予。另外，建立连接得先提供价值，而且还得源源不断。
+
+关于 PPC 个人发展理论的分享就到这里了，我们总结一下：
+
+
+专业，建立价值内核；
+展现，提供价值输出；
+连接，完成价值交换。
+
+
+专业是价值，展现是支点，连接是杠杆。
+
+最后，补充说明下：虽然本文指出了三个维度，但实际这三个维度并不是均衡发展的，每个人都需要根据自己的具体特点和主观意愿去做选择平衡。其实，任何一个维度发展到极致，都会有巨大的价值，但极致，何其难矣。
+
+关于这三个维度的发展，你有怎样的观点呢？欢迎留言分享。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/58三人行：前辈、平辈与后辈.md

@@ -0,0 +1,93 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            58 三人行：前辈、平辈与后辈
+                            成长的路上，有时会陷入停顿，感到迷茫，就像前行的一辆车陷在了泥地里，不管你怎么加油踩油门，它只是在原地打转而无法继续前行。这时，你就需要有人来帮助，或推或拉或扶。而从广义的角度看，总会有三类人在身边，你未必是独行。
+
+孔子说：“三人行，必有我师”。原意中的“三”是虚数，泛指多人，意思是身边的任何人都可以成为你的老师，拥有值得你学习的地方。成长的路，本是一条越走人越少的路，但若有伙伴同行，你会走得更远，走得更久。
+
+这就是成长路上的三人行，此时的“三”不再是虚数，而是指代身边的三类人，它们是：
+
+
+前辈
+同辈
+后辈
+
+
+这三类人代表了不同的成长路径和成长阶段。你应该有一个动态的列表，在成长的不同阶段将这三类人中的典型代表放在这个列表中仔细观察。
+
+如果放在职场上，前辈可能就是你的上级，是比你更资深和有经验的人，是走在你前面的人；同辈自是你的同事，你们在不同的领域各有所长，甚至在同一领域做得比你还好，但不管怎样肯定是让你尊敬的人；而后辈可能是你的下属，他们也许正在走你曾经走过的路，可能正在做你一年、两年或三年前做过的事，而且可能做得比当时的你更好。
+
+如果你在身边都找到了这三类人的典型代表，你观察他们，便是以他们为尺来度量自己；你学习他们，便是以他们为模来塑造自己；你加入他们，便是从后辈的重复中去反思过去，从同辈的领域中去扩展当下，从前辈的脚印中去引领未来。
+
+前辈
+
+前辈，是那些走在你前面的人，他们不止一个，且每个人都会有不同的路径。观察他们的路径，哪个更适合自己，哪个人的哪些方面让你更想要去模仿。在职场上，这些人似乎都有差不多的等级，但实际上每个人都有不同的特点和路径。
+
+在不同的阶段，会有不同的前辈。而最适合作为前辈代表的人，应该在你前方不远处，因为这样的观察、模仿和借鉴才更有意义。毕竟走在你前方太远的人，他们的行为方式和路径你都很难看得清晰，而且很可能你们的工作活动已经处在不同的维度了，这阶段的你还理解不了。比如，刚入门的新手，适合观察和借鉴的前辈应该是比较熟练的中级工程师，而不是架构师。
+
+程序员有时爱自比农民，自称 “码农”，因为程序员每天写代码的工作，就像农民种地。一个初出茅庐的程序员，不断地通过提升技能、吸收经验和改进工具来提升产量。从一开始的手工作业，到利用耕牛（新的技能和工具），再到现代化的机器工程作业（进一步改进的技能和工具），所负责的田地亩产量越来越高，每天能耕耘的土地面积也越来越大。直到有一天，技能提高和工具改进接近了极限，耕种的土地面积和单位产量增长都渐渐停滞。
+
+之前的这个改进过程都是一个自然连续的成长过程，而当你进入极限区增长停滞后，再给你更大的土地，要求更高的产量时，这个连续的增长过程就被打断了，你会看到虽有前辈在前方，但中间的路却断了。
+
+在这个断点之前，前辈的价值在于：他们走过的路，你不用再去摸索，只需快速顺着走下去。这个过程中你只需要刻意地玩命练习去解决自然连续的快速成长问题，而在断点之后，前辈在没路的地方留下的 “脚印” 也解决了非连续性的跨越问题。
+
+十多年前，我以为程序员的成长终点是架构师，后来我知道了，程序员的自然连续成长终点是资深程序员，也许还有 “神” 级程序员。但架构师却是从某个点开始断裂分叉的另一条路，从程序员到架构师，就需要跨越非连续性断点，而转型到技术管理者也会面临同样的非连续性断点。
+
+跨越非连续性的断点转变意味着什么？有一部电影叫《爆裂鼓手》，电影中有两个角色，一个鼓手，一个指挥。鼓手类似程序员，指挥则像架构师。成为顶级鼓手的路是玩命练习打鼓，成为指挥的路则是放下鼓槌，拿起指挥棒，协调各种乐器的演奏。
+
+放下了乐器，未必是放弃了音乐，电影中的指挥，任何时候乐队中的任何一个乐器吹（拉、弹、打）错了一个音，他都能立刻分辨出来。这就是另外一条路的另一套技能，是为了得到更大规模的生产力和更震撼的演奏效果（品质）。
+
+除此之外，前辈的另一个价值在于塑造环境，而环境决定了整体的平均水平线，在这个环境中的个体很少有能大幅偏离的。
+
+就以我的中学环境为例，当年我进入这所少数民族中学时，那一届高考最好的学生是考上了中央民族大学。六年后，到我参加高考时，学校师生都在为实现清华北大的零突破努力，虽然依然没能实现，但这届学生的最高水平已经可以考上除清华北大之外的任何大学了。
+
+在我所在中学的这个环境中，每一届高考学生都是下一届的前辈；每一年这些 “前辈” 们都在把学校的高考水平线抬高一点点，在前进道路的尽头继续探索走出长一点点的路来，而到我的下一届终于实现了零突破。
+
+所以说在一个既定环境中，有强悍的前辈是我们的好运气。
+
+同辈
+
+同辈，本是那些与你并行前进的人。
+
+同辈，特别是临近的同辈间普遍存在竞争，这也是所谓的 “同辈压力” 的来源。而很多时候我们的进步就是被这种压力逼出来的，这样压力转化为动力，同辈就成为了动力源。
+
+还是以中学这个环境为例，同届的同学之间就是一种同辈关系，而且有相当的竞争压力，都在竞争大学的录取名额。在参与考试竞争这件事上，我可以做到期末或模拟考试班级第一或者年级第一，但高考的竞争其实是在全省范围的同届学生之间展开的，每次模拟考试下来发现离最高分还差很远，我就产生了一个困惑：为什么会觉得无论如何我也不可能达到那个最高分？
+
+如今我自然明白了，我当时做不到是因为在学习和考试这个领域，我没有一个参考视角获知最高分的同学是如何学习的，而且这样的同学所在的学校环境，其整体水平线要远高于我所在的学校。因而，我想如果当时能有一个环境，让我和这样的同学产生交流和共同学习，那么必然我也可以得到提高。
+
+中学是一个相对单一维度的领域，同辈同学间都是在忙于学习和考试；而到了职业和工作领域后，维度就丰富了很多，每一个同辈都可以拥有自己独特的领域，他们之间得以互相观察，并能相互沟通、交流与合作。
+
+那什么是领域？这听起来有点像是一个玄幻小说的术语，在一些玄幻小说中，拥有领域的人物都是超厉害的，在他们的领域中，都是近乎无敌的存在。领域，是一个你自己的世界，在这个世界中，你不断地提出问题并找到有趣或有效的解决方案。进入这个世界的人，碰到的任何问题，你都解决过或有解决方案，慢慢地人们就会认识到你在这个世界拥有某种领域，并识别出你的领域。然而，计算机专业毕业的程序员们，人人都拥有专业，但工作十年后，不是人人都能拥有领域。
+
+所以，在你前行的路上，碰到一个拥有领域的同行者，是一种幸运。所谓术业有专攻，每一个拥有领域的人，都有值得敬佩的地方，因为这都需要付出艰辛的努力。
+
+每个人都能拥有一个自己的领域，在自己的领域内去耕耘、创造、提升，纵向提升这个领域的深度，横向扩张领域的维度，当和其他人的领域发生交集时，取长补短，也许还会产生意外的收获。
+
+同辈，除了竞争，也有碰撞与交流，它会成为你的催化剂。
+
+后辈
+
+后辈，他们正沿着你走过的路直面而来。
+
+好些年前，工作没几年，带了两个刚毕业的学生。我把我的自留地分了一点让他们种，每隔两天我就去看看他们种的怎么样？每次看完，我都忍不住想去自己再犁一遍。后来我还是没忍住，最后又自己种了一遍。如今回想起来，虽然保障了当时的产能，却牺牲了人的成长速度。
+
+人，似乎不犯一些错，就成长不了，也许这就是成长的成本。
+
+如今，我再回头看这样的路径和例子，就会以成长思维去考虑，而不仅仅是产能视角。为了获得长期的产能效率，有时不得不承担一些短期的成本压力。而后辈们，既可能重复犯下曾经的错误，也可能走出更好的路径。通过观察他们的来路，我反省到了过去的错误，也看到了更好的路径。
+
+回望后辈直面而来，假如再来一遍，我能做得更好吗？我们无法改变过去的事实，但可以从思想上修正过去，以更好地作用于现在和未来。
+
+成长路上三人行，有前辈、同辈和后辈。前辈塑造环境，开辟道路，留下脚印；同辈之间有竞争，也有交流与合作，既带来压力，也激发动力，催化能力；后辈带来反思，也提供支持。
+
+前辈探路开拓，同辈携手并行，后辈参考借鉴。
+
+在成长的路上，你需要找到当前阶段的三类人，也许就会感觉这条路走起来也就没那么迷茫和孤单了，你觉得呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/59三角色：程序员、技术主管与架构师.md

@@ -0,0 +1,99 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            59 三角色：程序员、技术主管与架构师
+                            还记得[开篇词]中我画了一个程序员的成长路径图，其中在图的左侧部分展示了程序员成长路径上一些主要阶段的定义，在我们从初级走向资深的过程中，会面临一条支路，在这条路上不仅普遍称呼的名称不同了，工作内容可能也发生了变化，角色的转换会带来不少的困惑。
+
+这条路就是从 “程序员” 到 “技术主管” 再到 “架构师” 的路径，下面我们就来看看这条路径上的三个角色有何不同？
+
+程序员与寻路
+
+当我刚进入软件行业成为一名程序员时，我的理想就是成为一名架构师。
+
+“架构师”这个词的英文叫 Architect，原意是建筑师，因为软件行业参照借鉴了很多建筑行业的概念，所以就借用这个词。我是在学校读书时知道“架构师”这个名词的，当时很多软件方面的书都是翻译过来的，也不知道是谁最早把 Architect 翻译成了“架构师”的。总之从那时起，“架构师”这个名词对于我这个刚准备走出校门的学生来说就特别高大遥远，自然当成了最初的一个职业目标。
+
+但遗憾的是在我从业前几年的好几家公司，都没有架构师这个职位，直到后来进入了互联网公司。到了京东后，不仅有架构师职位，还有架构师团队；在这里，不仅有了方向，还可以放心地作为一名程序员发力狂奔：不停地写程序，优化代码，追求更优、更简洁的代码，重构了一遍又一遍，解决了一个又一个问题。
+
+在前面的文章中，我将程序员具体和代码相关的工作比作剑术，修炼代码技能类似练剑的过程。很多程序员梦想着有一天能成为一代高手，面对敌人，抽刀拔剑，刹那间交击，归剑入鞘，敌人倒下。就像线上系统突然出现大问题，你打开电脑，看了几眼日志，敲下几行代码，系统分分钟恢复。
+
+一个好的程序员当然要能写得一手好代码。在工作前十年中，我每天的主要工作内容就是编程写新代码，重构旧代码，直到有一天发现这样不断继续下去，我的“剑术”已精进迟滞，进境有限。而当时所在的系统开始向大规模分布式化方向发展，更大的价值已不再是代码实现层面上的局部优化。
+
+那时我开始在团队承担起整体的系统设计工作，此时若再专注于局部代码优化其实是在驱动细节而非本质了。作为资深程序员出身的架构师，单兵作战能力都是极强的，就像《进击的巨人》中的利威尔兵长，具备单挑巨人的能力。可当面对成群结队的巨人来袭时，个人单挑能力的作用始终有限。
+
+这时，从程序员到架构师不仅仅是一个名称的变化，它也意味着技能和视角的转变。在地上飞奔了七八年的程序员，在面对成群的巨人袭来时，深深地感觉到，杀光巨人不应是目的，真正的目的应是到达彼岸。所以，选择合适的路径，坚定地前行，清除或绕过挡道的巨人，到达目的地。
+
+是的，我是到了资深程序员阶段直接转向了架构师。而在路径图上还有另一条路，会经历另一个角色：技术主管，这是一个从程序员到架构师阶段的过渡角色。
+
+技术主管与过渡
+
+技术主管，有些公司可能又叫 “技术经理”，英文一般是“Tech Leader”或简称“TL”。
+
+技术主管是开发团队中的某位程序员需要对整个开发团队负责时所承担的角色。既要对最终交付的软件系统负责，另外也会像一个程序员一样去开发实现系统。一般一个技术主管约 70% 的时间可能花在了开发任务分解分配、开发实践、代码审核和风险识别上，而余下 30% 的时间则花在为了保障系统按时交付所需要的各种计划、协作、沟通和管理上。
+
+在拉姆·查兰 (Ram Charan) 写的《领导梯队》一书中提到：一个人的工作角色中至少有百分之五十以上的时间是花费在管理事务上，那么他的角色才算是一个经理（Manager）。所以技术主管（经理）更多还是偏重于技术工作，有点类似产品经理属于以经理命名却非真正的经理角色。
+
+例如：在一个开发团队中经常会碰到技术方案和实现细节方面的分歧，如果程序员无法自主友好地完成对不同技术意见的统一，这时候技术主管就需要介入去了解两种不同意见所造成的冲突，对事不对人地去把问题搞清楚，分析各自方案的利弊，必要的时候甚至能够提出第三种更好的技术方案，以帮助开发团队达成共识。
+
+另一方面，技术主管即使在日常的开发实现中，重点的内容一般也不是放在某个具体的功能实现上。在完成了具体的开发任务评估、分解并分配后，技术主管应该负责设计整体代码的结构和规范，必要时引入能提高整个团队生产力的新工具，推广代码模板，总结最佳实践。并且技术主管需要经常性地关注整个团队完成一项研发任务的水平和实际要求的水平之间的差距问题，让团队不仅满足及时的软件系统交付，同时又得到成长。
+
+现实中，一个开发团队中最优秀的程序员容易被指定承担技术主管的角色，但优秀的程序员又很容易陷入到实现功能的细节中，满足于完美的实现，优雅简洁的代码。但实际上，这样优秀的程序员转入技术主管这个角色后，就很容易尝试控制设计和代码的实现，他们很难接受代码不按照他们希望的方式去编写，这个是他们作为优秀程序员一直以来的工作习惯，长此以往他们自身很容易变成整个开发团队的瓶颈，而团队里的其他成员也未能得到足够的锻炼和成长。
+
+所以技术主管实际相比团队里的其他程序员对系统的视角更开阔，以更有策略和长远的方式来考虑问题。他们即使拥有比团队里所有其他程序员更高超的开发实现技能，对所有开发任务拥有最强大的实现自信，也需要转变为另一种 “借助他人使之实现” 的能力和自信，因为技术主管是一个承担更广泛责任的角色，必然导致能够专注有效编码的时间会相比以前减少很多，而这一点正是优秀程序员转变为技术主管所面临的最大挑战之一。
+
+最适合技术主管角色人，不一定是团队中编程能力最好的人，但必然是团队中编程、沟通和协作能力最综合平衡的人。而技术主管之所以是一个过渡，就在于继续往前走，如果偏向 “主管” 就会成为真正的管理者（经理），如果偏向 “技术” 就会走向架构师。
+
+架构师与取舍
+
+架构师是一个在业界拥有知名的称谓，但在绝大部分公司却不属于一个职位序列，许多公司都很纠结于如何定义架构师的角色，以及架构师所做的工作。
+
+以前听阿里的同学说 P7 属于架构师职位，不过最近在看另一个阿里同学写的文章提及：前几年是有专职的“架构师”职位的，现在已经回归到 “工程师”“技术专家”“研究员” 这样的纯技术职位。可见在一线互联网公司关于架构师的定义也是很模糊的。
+
+[前面]我曾引用过一篇文章《在首席架构师眼里，架构的本质是…》中提到的架构师能力模型图，我结合自己的经验和理解，稍微扩展解释了一下，如下：
+
+
+
+架构师能力模型
+
+正因为业界和公司对架构师这个角色的职责定义很模糊，所以很多经验积累到一定程度的优秀程序员，并且在公司内被提升到一定高度的技术级别后，都会冠以 “架构师” 之名。但实际情况是大部分刚刚冠以“架构师”之名的优秀程序员，其能力模型大部分还停留在上图中的蓝色区域，而对其他区域并未有过系统性的认知和训练。
+
+看过了架构师的能力模型，我们再来试着分析下其对应的职责。技术主管的角色与架构师这一角色会产生一些职责上的重叠，事实上我认为在团队规模比较小的时候（十来人的规模），架构师和技术主管的职责几乎完全重叠，甚至技术主管还会代理一些团队主管的角色。
+
+随着软件系统复杂度和规模的提升，团队也相应变大，那么一个架构师此时所处的职责位置就开始和技术主管区别开来。如果把技术主管想成是站在楼顶看整个系统，那么架构师此时就是需要飞到天上去看整个系统了。
+
+开发功能，解决 Bug，优化代码，这是一个高级或资深程序员的拿手技能，也是地面作战的基本技能。而一个架构师还需要掌握空中的技能，也许就像《进击的巨人》中的立体机动装置，让其能在需要时飞在空中看清全局，也能落地发起凌厉一击。
+
+那多了一个空中的维度，过去在地面练到精熟的剑术，飞在空中还有效么？这就需要时间去学习，适应新维度的技巧。这不是一个容易掌握的技能，这也正是前面我写过的从一个点到另一个点连成线的技能升级，需要一个升维的学习过程。
+
+架构师站在更高的空中维度去做关于软件系统的抽象和封装。如果技术主管的抽象和封装层次更多考虑的是语言函数、设计模式、代码结构等这一类的事务，那么架构师是站在整体软件系统高度，考虑不同子系统之间的交互关系、技术的合理性、需求的完整性、未来的演进性，以及技术体系发展与组织、产品商业诉求的匹配度。
+
+这是相对技术主管更高维度的全局视角，另一方面依然有很多技术主管可能感觉没把握的技术决策和技术争端需要架构师的介入协调。之所以要找架构师来对一些技术争端和方案进行决策判断，很多情况在于程序员对架构师在技术领域内专业力和影响力的信任，而建立这种专业力和影响力是实际构建架构师非权威领导力的来源。
+
+何谓 “非权威领导力”？非权威自是相对权威而言，管理者的权威领导力来自于公司正式任命的职位和职权，而架构师在大部分公司基本连职位职责都没定义清楚，更没有职权一说，所以实际上就不会有任何权威领导力。所以，架构师要发挥更大的作用和价值就需要去构建自己的非权威领导力，而这需要长期的专业力和影响力积累。
+
+除此之外，架构师还承担着在技术团队和非技术团队（例如：产品设计等团队）之间的接口作用，明确产品的边界，勾勒技术蓝图，协调不同技能的技术团队协作，完成最终的软件系统交付。这时架构师的角色就像服务化架构中的 API，定义了协作规范、交互协议和方式，但并不会聚焦在具体的实现上。
+
+在更大规模的系统上，架构师似乎还要去涉猎更多的跨领域知识，否则很可能无法做出最适合的技术决策。但人终究是有局限的，你不可能学完所有的领域，所以特定的领域又会涌现一些垂直领域的架构师。比如：数据架构师、网络架构师、业务架构师、安全架构师。因而某一个领域背景出身的架构师，对其他领域也只能做个初步了解，当需要做出关于涉及其他领域的架构决策时，就需要和其他领域的垂直架构师做深度的沟通交流，以辅助决策判断。
+
+一旦选择走入架构师这条路，基本你就从一名出色的程序员这个领域走出，需要尽快去补充上面能力模型中指出的其他能力。这一点会让刚刚走上这条路的程序员很不适应，因为承担了更多其他职责，就必然会减少在编码实现的时间，慢慢就会怀疑自己的编码能力会退化，也跟不上一线最新的技术栈、各种酷酷的新工具。
+
+舍得，舍得，没有舍就没有得。成为架构师会拥有一个更立体的知识、技能矩阵，这是你的得，获得了一个面，在某些点上必然面临被超越的结局。工作在一个面上，一个有经验的架构师应该能够很好地表达某些技术指导原则，借助他人使之实现，并且了解和把握什么时候该插手，什么时候该放手。
+
+这就是架构师从技术 “实现力” 到 “掌控力” 再到 “决策力” 的能力变迁。
+
+从程序员，到技术主管，再到架构师，名称变化了，角色的困惑我们也分析了，最后总结下这三种角色的工作内容和职责，如下表：
+
+
+
+程序员、技术主管和架构师的职责表
+
+每种角色有不同的技术和组织职责，只是在每种职责分配的时间比例不太一样。看完上表的职责范围，是不是感觉有时安安静静地做个程序员，要心净多了。
+
+如今的你，正走在哪条路上呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/60三视角：定位、自省与多维.md

@@ -0,0 +1,125 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            60 三视角：定位、自省与多维
+                            记得以前阅读时碰到过一个观点，是关于 “视角” 的，其中说道：“视角的选择，对解题的难易，关系重大”。而关于成长，放到程序模型中来类比，就是一道图论题，我们求解的是适合自己的最优路径。
+
+面对这道成长路径的难题，我们可以从哪些视角来求解？我自己找到了下面三个视角。
+
+定位
+
+定位，是一个时间视角，回顾初心，定位未来。
+
+还记得当初为什么选择程序员这个职业么？如今程序员所在的行业处于发展上升期，薪酬待遇整体高于传统行业，所以各类程序员培训机构如雨后春笋涌现，流水线般地为各类只差程序员的公司批量供应，这样的批量生产似乎有点把程序员当成了工厂的工人。
+
+而程序员的工作实际更贴近于工匠，既有创造性的工艺性工作，也有模式化的工程性工作。想清楚自己成为程序员的初衷是什么？如果只是为了进入一个相对高薪的行业，得到一份工资高于平均水准的工作，终究是走不了太远的。
+
+很多入门的新手程序员都是刚从学校毕业的，曾记得在吴多益的一篇工程师成长分享的材料上，如是说：
+
+
+从小到大的教育，你习惯性被安排：“课后作业是 X1、X2，后天必须交”“本学期的必修课有 XX、YY，必选的选修课有 ZZ、WW”。
+
+十几年来你都是这样度过的，但现在你已经不在学校了，你要安排你的未来。
+
+
+刚入职场的程序员依然保持这个习惯，等着主管来安排。但如果你每天的工作就只是完成被安排好的任务，那么你自己的成长就会非常缓慢，因为主管安排任务时并没有那么多的精力来考虑任务是否适合个人的成长发展。这些任务是组织发展的需要，而不一定适合个人的成长发展，但组织是付了薪酬来让你完成任务的，所以这是工作的必需部分。
+
+自己才是职业生涯的管理者，要想清楚自己的发展路径：远期的理想是什么？近期的规划是什么？而今日的任务和功课又是什么？今日之任务或功课哪些有助于近期之规划的实现，而近期之规划是否有利于远期之理想？
+
+为什么今日除了任务外还要有功课？功课是学校里的概念，职场里没有，所以离开学校进入职场的功课都是自己给自己安排的。任务来自主管的安排，功课来自自己的安排。很多时候你只去完成任务却从未给自己安排功课，而等着被安排和主动安排之间，在未来将产生巨大的差别。
+
+一开始你可能只有模糊的远期理想，也没那么清晰的近期规划，但一定要有足够清晰明确的今日任务和功课，即使在你的主管因为各种原因没给你安排的情况下。虽说方向不太可能一朝就定好，但也不要不管不顾地埋头走路，你需要抬头看路，定期检视，因为如今环境和大势的变化也很快。在边走边看的过程中逐步就清晰了近期的规划，甚至远期的理想。
+
+另外，主管在你职业发展的路上，除了大部分时候给你安排任务，偶尔也可能给你创造机会，而机会出现时你能否抓住，全在今日之功课上。
+
+定位的视角，是关于一条成长的时间路径，它关乎：昨日初心，今日功课，明日机会。
+
+自省
+
+自省，自我的视角，关乎自身，是一个观察自己成长路上行为的角度。
+
+乔治·海尔迈耶（George Heilmeier），是一位美国工程师和技术管理者，他也是液晶显示技术的主要发明者之一。他在科研领域最著名的事情就是他提出的 “海尔迈耶系列问题”：
+
+
+你要做什么？不要用术语，清晰地表述你的目标。-
+
+这件事现在是怎么做的？现在的做法有什么局限？-
+
+谁在关心？你的方法有哪些创新？你为什么觉得你的方法能够成功？-
+
+如果你的方法能够成功，它能带来怎样的变化？-
+
+你的方法需要花多少钱？需要花费多少资源？要怎样在过程中和结束时进行评估？
+
+
+我觉得这个系列问题，用在程序员个人成长上也有异曲同工之妙，因为现在的技术方向和路线太多，即使选定了路线依然会有很多茫然和困惑。如果你想要学习一门新技术或在项目中引入一项技术，就可以试试套用 “海尔迈耶系列问题” 来自省一番。
+
+
+你学习这项技术的目标是什么？清晰地表述出来。
+这项技术现在是怎么做的？有什么局限吗？
+这项技术有什么创新之处？为什么它能够取得成功？要是在项目中引入这项技术，谁会关心？
+如果这项技术能成功，会带来怎样的变化？
+采用这项技术的成本、风险和收益比如何？你需要花费多少资源（时间、金钱）？如何去评估它的效果？
+
+
+程序员有时粗浅地学习并了解了一点新技术，就想着如何应用到真实的项目中。这时用上面的问题来问问自己，如果有回答不上来的，说明你对这项技术掌握并不充分，那就还不足以应用到实际项目里。
+
+除了技术领域，你成长路上的许多行动，都可以此为参考坐标来反思：“这项行动的目标清晰吗？行动的方法有可参考的吗，局限在哪？我能有何创新之处？完成这项行动，会给我带来怎样的变化？我要付出多少时间、金钱和精力？行动过程中我该如何评估？行动结束的标准是什么？”
+
+这就是自省，从埋头做事，到旁观者视角的自我反思。
+
+多维
+
+多维，是一个空间视角，关乎如何选择不同维度的成长路径。
+
+有些时候，程序员写了几年代码，觉得太枯燥乏味，就想着是不是可以转管理，比如转技术主管之类的。从技术到管理似乎就是一条多维度的发展路径，是这样吗？不是的，这不叫多维扩展，而仅仅是想从一个维度逃离，转换到另一个维度。
+
+打造多维度竞争力的前提是，要先在一个维度上做得足够好，让其成为你赖以生存的维度，这个维度就是你的核心基础维度，而它是其他维度得以发展的根基。其中，“足够好”的程度，可能就是指我们常说的 “精通”。
+
+关于“精通”的概念，每个人的理解可能会有所不同，但我认为“精通”肯定不是无所不知，而是可以拆解成两个层面：第一，如学校时期学过的卖油翁所说的“无他， 惟手熟尔”；第二，在一个领域形成自己的体系和方法论。
+
+第一个层面，表达了在当前维度的不断精进，在精进这个方向上，有一本书和咱们专栏主题类似，但更微观一些，偏向于 “术” 的层面，但又有点从 “术” 悟 “道” 的意思。这本书叫《程序员修炼之道：从小工到专家》，书里覆盖了一名程序员真正面临的一些问题，比如：
+
+
+与软件腐烂作斗争-
+避开重复知识的陷阱-
+编写灵活、动态、可适应的代码-
+使你的代码 “防弹”-
+捕捉真正的需求-
+无情而有效的测试-
+无处不在的自动化
+
+
+这些具体问题的解法，就是第一层面。然后逐步上升到了第二层面，它的方法体系，一篇书评中将其称为本书的 “哲学”：
+
+
+本书的哲学将渗入你的意识，并与你自己的哲学交融在一起。它不鼓吹，它只是讲述什么可行，但在讲述中却又有更多的东西到临，我们有时称之为 “无名的品质（Quality without a name）”。
+
+
+当这些问题倒下而你还在程序员的阵地上时，想必你就会让人感受到那种 “无名的品质”，此时你也就在当前维度走到了 “精通” 的门前。在第一层面上你达成了品质和效率，然后在第二个层面上，抽象出了当前维度的 “解”，那么就可以通过 “启发式” 方法应用到其他维度，具备了向其他维度扩展的基础，从一个细分领域到另一个关联领域的 “精通” 能力。
+
+所谓 “启发式” 方法，就是 “在某个视角里，使用这个规则能够得到一个解，那么你受此启发，也许可以把这个规则用在别的问题上，得到别的解”，而规则就是你在一个维度里抽象出来的方法论体系。
+
+当你感觉在技术维度进境迟滞时，可以尝试扩展到英语维度去，接触一手的技术论文或资料，说不定就能获得启发，找到新的技术维度进境之路。作为多年的程序员，已经形成了用工程师思维分析和求解问题。抽象出来看，程序员都是对问题领域进行建模，然后再用代码实现求得一个 “概率解”。
+
+编程实现得到的难道不是一个确定的系统或服务吗？为什么是 “概率解”？系统或服务是确定的，但解决的问题，如：需求满足率、服务可靠性，却是概率的。每完成一个系统版本的发布，到底多大程度地满足了用户需求，其实是一个概率，这个概率可以通过用户反馈得到一个大概的感知，但你几乎不会知道一个确定的值。而可靠性，相对来说会更可量化，比如在 99.9% ～ 99.99% 之间波动，但也不会是确定的百分百。
+
+工程师的这个求解模型，可以转移应用到其他很多与你息息相关的工作生活领域，比如投资理财，把钱存银行定期赚钱的概率解无限接近百分百；但买基金、买股票的概率解对大部分人来说就完全靠赌和猜了，因为缺乏一个合适的模型去求解，而对领域建模应该是程序员的强项，也是可迁移扩展到其他维度的能力。
+
+即使是学习成长本身，也可以用工程模型来求解。这时你的学习维度就需要扩展一下，不仅仅局限于你当前的专业领域，还可以了解点神经科学，认知心理学之类的，并配合自己的现实情况、作息习惯，去建立你的学习模型，获得最佳学习效果。而学习效果，也是一个 “概率解”。虽然你不能知道确切的值，但我想你肯定能感觉出不同模型求解的效果好坏。
+
+简言之，多维的路径，其实是从一个核心基础维度去扩散开的。
+
+最后，我们总结下，在求解成长的最优路径时，视角的不同，对求解的难度差别巨大。我分享了我的三个视角：定位，时间视角；自省，自我视角；多维，空间视角。通过三个不同的视角，探讨了关于 “我” 与所在现实的时空关系，从中尝试提炼出一种方法，用于探索最适合自己的成长路径。
+
+成长最优路径，求的依然是一个概率解，只是我感觉通过这三个视角去求解，也许概率会更高。
+
+你不妨将这个三维度，套在自己身上，感受一下呢。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/61工作之余，专业之外.md

@@ -0,0 +1,106 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            61 工作之余，专业之外
+                            程序员的主流成长发展路线，是一个明显的“T”形线路。在纵深方向上，工作到一个阶段后，可能我们就会感到深入不下去了，而且越走会越有沉滞的感觉；在横向上，是广度方面，包括技术专业之外的领域，也会感觉了解甚少，短板明显。
+
+有时候，要想产生真正的成长转变与发展突破，就不应自我局限于当下的工作内容和技术专业。
+
+一、工作之余
+
+工作，是技术发展纵深线中很重要的一个实践部分，但因为工作的内容和环境的限制，会把你困在一定的阶段，此时工作之余的内容将发挥很关键的作用。
+
+工作之余，你都在做什么？我猜有人会说，工作已经够忙碌了，业余时间就该好好休息和娱乐了。的确，有很多人是这样选择的，但也有不少人不是的。即使再忙，有些人就喜欢在业余时间做点事情，这可能是一种性格特质，拥有这种性格和热情的人，总是能在忙碌的工作之余安排点其他内容，比如：
+
+
+看看程序设计相关的书、文章和博客；
+参加一些技术主题论坛或会议；
+写写技术博客；
+创建自己的业余项目（Side Project）。
+
+
+以上前两条是接收和学习知识，第 3 条是总结和提炼知识，最后第 4 条则是实践所学，获得新的技能或加强旧的技能经验。
+
+特别是第 4 条“创建自己的业余项目”，我感觉这是每一个程序员都应该做的事，为什么呢？在现实中切换一次工作环境是有比较高的成本的，开启自己的业余项目能帮助你打破工作内容和环境的限制，让你去做一些你喜欢做，但在工作中还没机会做的事。另一方面，业余项目也是你练习新技术和新技能的最佳试验场，相比你直接用真实的项目去实验，承担的风险和压力都要小很多，这样你也就有了机会去接触你想要学会的新技术。
+
+记得几年前，我还参与过一个关于程序员业余项目的活动，那个活动的口号是下面这样的：
+
+
+世界在被代码改变着，而我们在创造着代码。
+
+仅仅是因为好玩，他开发了一款操作系统，连想都没想过，这会让自己有一天成为开源世界的领袖级人物。
+
+只是想创造一个很酷的东西，所以他动手，坚持，因而有了让这个世界上的每一个人都可以免费地获取人类所有知识的百科全书。
+
+成功者和其他人最大的区别就是，他们真正动手去做了，并且做了下去。
+
+
+这也说明了业余项目的积极价值，而且这个世界上也有不少著名的产品来自业余项目的转正，比如：Gmail、Instagram、Slack，甚至包括 Facebook 本身。确实这些闪耀的例子激励着我们去尝试着各种各样的业余项目，但真正能做到像上述例子中那样光彩夺目，只怕这概率也和中头彩差不多了。
+
+即使没有辉煌的成功，那么你做业余项目对自身还有什么积极的意义和价值吗？我想应该有的，你之所以要用自己的业余时间来开启一个业余项目，想必它是让你感兴趣的。全职工作的内容是你的职责，它支付你的账单；业余项目的内容则是你的兴趣，它满足你的好奇和探索之心。
+
+在我学习写程序的前七八年里，业余时间也做了一些练习性质的项目。在 GitHub 之前的时代，Google 还能访问，我就在 Google Code 上维护了应该不止十万行的业余代码之作。后来 GitHub 兴起后迁移过来，不断练习重构优化和维护自己的专属工具库，删减了很多冗余代码，又新增了不少，剩下几万行代码。这个过程大约持续了七年，基本每年重构优化一次。每一次重构，都是对以前自己的否定，而每一次否定又都是一次成长。
+
+在做业余项目中最大的收获是：完整地经历一次创造。这样的经历，对于程序员来说可能在很多年的工作中都不会有太多机会。写程序，实现系统，发布交付，仅仅是创造的一个中间部分。而完整创造的第一步应是确定你要创造什么，明确它，规划它，找出创造它的方向和路径，做出决策，然后才是下定决心去实现它。
+
+一方面，业余项目只能在业余时间做，而业余时间又是那么有限，这样的时间制约决定了你只能走极简路线，要么保持足够简单，要么就可能陷入膨胀的泥潭，从而失控导致失败。另一方面，正因为业余项目不会给你带来直接的金钱收益，所以你选择增加的每一个特性，要么让你感觉有意思，要么能磨练提升你的手艺，打磨你的深度。
+
+然而，大部分的业余项目最终都失败了，但这没什么关系，你已经从中收获了趣味与成长。
+
+二、专业之外
+
+专业是你的核心领域，而专业之外则是你的辅助领域；核心属于硬技能领域，辅助属于软技能领域，这也是“T”线中的横向延伸部分。
+
+那么该怎样选择辅助的软技能领域呢？如果你的工作之余是在做一件业余项目，那么我想下面一些领域就是你在做业余项目之时更感缺乏的技能。
+
+1. 创造与洞察
+
+工程师，是一个创造者，创造模型来解决问题，但又不应该止步于此。
+
+你的业余项目是你的作品，作品是创造出来的，按作品原始的需求是满足了作者创造的愿望，但业余项目要能取得成功就需要得到真正的用户，而获取用户就需要洞察，洞察用户的需要。
+
+我记得以前读过一篇博文，来自著名 JavaScript 程序员尼古拉斯·泽卡斯（Nicholas C.Zakas，《JavaScript高级程序设计》一书作者），他写了几条职业建议，其中第一条就是：
+
+
+不要成为做快餐的 “厨师”。
+
+
+也就是说，不要像外卖接单一样，别人点什么，你就做什么。应该搞清楚你正在做的事情的价值和出发点，你不仅仅是实现代码，还要想想为什么要实现它。当你多想了后一步，在实现的过程中就会有更多的洞察。
+
+开启过自己业余项目的程序员，已经走出了 “创造” 这一步，但多数还是失败在 “洞察” 这一点上。
+
+2. 表达与展现
+
+安安静静地写代码固然是不错的，但代码很多时候没法很直接方便地展现出你的真实能力和水平。
+
+你可能会用 Linus 的“Talk is cheap, show me the code.”来反驳我。是的，也许在开源的世界，每个个人贡献者都隐藏在网络的另一端，他们只能通过代码来直接交流。但其他更多的现实是，当别人要来判断你的能力和水平时，通常都不是通过你写的代码，而是其他的表达与展现方式。
+
+如果你的代码能给你作证，只有一个可能场景，那就是找到了大量直接使用你代码的用户，这就是成功开源作品的方式。否则，大部分时候你只能说你用代码完成了什么事情，做出了什么作品。
+
+如果，你有好作品，就值得好好地展现，甚至还要不遗余力地推销它。
+
+3. 沟通与决策
+
+一个人的能力再强，也是有限的。当你想做更多、更大的事情时，就不可避免地要借助他人的力量，这时所面临的就将是大量的沟通了。
+
+沟通一般有两个目的：一是获取或同步信息；二是达成共识，得到承诺。前者需要的是清晰的表达和传递，后者就需要更深的技巧了。这些技巧说起来也很简单，核心就是换位思考、同理心，外加对自身情绪的控制，但知易行难在沟通这件事上体现得尤其明显。
+
+关于决策，如果都是在好或更好之间的话，那就真没什么纠结的问题了。而决策，是在优劣相当的情况下做出选择，更多的决策难点发生在取舍之间。程序员能碰到的大部分决策场景都是关于技术的，技术相对来说还有一些相对客观的标准来掂量，比如通过测试数据来验证技术决策的结果。
+
+而其他方面的更多决策会让人陷入困境和纠结。如果要问我在这点上获得过怎样的教训，那就是：即使是一个坏的决策也比始终不做决策要好，因为在行动的过程中比“陷”在原地有可能产生好的改变。
+
+决策和沟通有时是紧密联系的，大量的沟通之后可能产生决策，而决策之后也需要大量沟通来落地实施。
+
+最后总结下：工作之余你可以有多种选择，但若被工作环境所困，导致专业力进境阻碍，可以开启业余项目来突破这种限制；而业余项目带来的诸多益处，从此也为你走向专业之外打开了一个新的视角与空间。
+
+工作之余，专业之外，就是一条“T”线纵横交错发展的路线，当两条线都画得足够长了，在面临成长路上的断层时，才有机会与可能实现跨越。
+
+那么，你的工作之余和专业之外都在忙些什么呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/62跨越断层，突破边界.md

@@ -0,0 +1,105 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            62 跨越断层，突破边界
+                            在前文中定义过程序员的职场阶梯，而阶梯不过就是很多人已经走过的路，我们只需要沿着这条路去持续成长就能爬上还算不低的楼层。只是到了一定楼层后我们会发现上面似乎还有几层，但却看不见下一层的楼梯了。因为再往上走的人就不多了，也就没能成了路，自然也就看不见，这可能就是所谓成长阶梯的断层。
+
+在程序员的成长阶梯上，到了一定阶段，我们可能会面临方向的选择，不同的方向选择意味着不同的路径，会碰到不同的断层，而跨越断层也需要不同的方法。
+
+那我们会面临怎样的方向选择呢？
+
+方向
+
+在我的技术成长路上，我看到了三个方向，正好可以用三个字来表达：“高”“精”“尖”。
+
+“高” 指的是 “高级（High-grade）”，“精” 代表 “精确（Precision）”，而 “尖” 则是 “尖端（Advanced）”。这是我所看到的技术人前进的三个主要方向，而这三个方向的走向往往还是互斥的。
+
+高级，说的不是更高级的技术，因为技术之间的横向比较没有高低级之分，比如操作系统、数据库、网络编程、机器学习等技术，没法比出个高下。这里的“高级”，如其英文是更高等级的意思，是职位和人的级别。而往高等级走的技术人，离 “精” 自然只能越来越远，毕竟站的高就只能看得广，但很难看得精确了。
+
+精确，就是把一门技术做到真正的精通。现在技术的分工越来越细，通常能精通一两个细分领域已实属不易。而要做到精，其实越往后付出越多，但感觉提升却变得越来越慢。都到 95 分了，再往后每提升 1 分都需要付出艰辛的努力。走到细微深处，也很难再看得远、看得广了。
+
+尖端，似乎听起来像 “精” 的极致，其实不然，这完全是另一条路。“高” 与 “精”，是工业界的实践之路，而 “尖” 是理论界的突破之路。只有能推进人类科技进步的技术才称得上尖端，就如 IT 界历史上著名的贝尔实验室里的科学家们做的工作。
+
+“高”“精”“尖”三个字，三个方向，三条路，各有各的机遇与风险。在三条路的岔路口，工作多年的你若止步不做选择，也许就止于一名普通的程序员或资深的技术人。若继续选择一个方向走下去，越往高处走，高处不胜寒，一旦落下，你知道再也回不去了；而走向精深之处，沿着技术的河流，溯根回源，密林幽幽，林声鸟不惊，一旦技术的潮流改了道，你知道你可能会迷失；而尖端之路，或者有朝一日一鸣惊人，青史留名，或者一生碌碌。人工智能的发展史上，曾有一段时间找错了路，让学界止步不前，而这一段时间就是走尖端之路的学者们二十年的岁月。
+
+“高” 是往宏观走，“精” 是往微观走，“尖” 是去突破边界。
+
+这三条路，“高” 和 “精” 的方向在业界更常见，而 “尖” 不是工业界常规的路，毕竟业界拥有类似贝尔实验室这样机构的公司太罕见，所以 “尖” 的路线更多在学术界。因而后面我们主要探讨 “高” 和 “精” 两个方向的路径断层与跨越方法。
+
+高
+
+高的两条典型路线如下：
+
+
+程序员—架构师—技术领导者
+程序员—技术主管—管理者
+
+
+往高处走，每一次角色的转变，都是断层。有时候，公司里到了一定级别的程序员就会被冠以架构师的称呼，但工作的实质内容依然是资深程序员平时做的事，如：一些关键系统的设计和实现，解决一些困难的技术问题。
+
+这些工作中的确有一部分也算是架构师的内容，但如果不能认识到架构师工作内容的实质，再往高处走也就很难实现断层的跨越了。而架构工作的实质是创造一个模型，来连接、匹配关于业务、技术和团队之间的关系。
+
+其中的 “业务” 属于架构师工作内容中的领域建模；“技术” 是匹配领域模型的技术实现模型；“团队” 是关于个体之间如何组合的结构，需要满足个体技术能力与技术实现模型的匹配。由这三个元素连接和匹配构成的模型中，“业务” 是变化最频繁的，其次是 “团队”，而变化频次最低的反倒是 “技术”。
+
+每一项元素发生变化，都意味着架构模型需要去适应这种变化，适应不了变化的模型就需要升级。而常见的组织架构调整，也就意味着 “团队” 的沟通路径变化了，因为康威定律（系统设计的通信结构和设计系统的团队组织的沟通结构是一致的）的缘故，必然带来架构模型的适应性变化调整。
+
+透过具体的实质再往高处抽象到本质，你会发现架构工作的本质是在通过模型调优生产关系，从而提高生产效率和生产力。这是一条杠杆之路，通过找到其中的关键支点去放大输出，扩大价值。
+
+在架构模型三元素中，技术本身就是一种杠杆，而团队和业务是价值支点。
+
+曾经，技术的草莽时期，是一个英雄辈出的年代。两个人可以创造 Unix、C 语言，一个人也可以发明 Linux，也可以写出 Foxmail。掌握了技术，就可能创造历史，那时技术的杠杆很高。
+
+如今，是技术的成熟时期，个体英雄少了，更多是一种团队和集团军作战的方式。如果你是技术的绝世高手（精的极致），那你也需要找到一支契合你技能的场景与队伍，加入进去。此时个人的技术杠杆也许不像曾经那么高，但也许你们这个队伍还是有机会能创造历史的。
+
+前几年，Facebook 曾收购了一家叫 WhatsApp 的公司，花了 190 亿美元。这家公司当时仅 50 人，而其中一半是技术人员，这应该是近年用技术杠杆撬动价值之最了吧。
+
+在 WhatsApp 这个例子中的价值支点是什么？是产品（业务），连接用户、形成网络。技术本身的价值通过这个产品业务形态支点，在每个活跃用户身上得到了放大。
+
+而另一个价值支点，是借助团队，但这只适合高级别的技术人员，比如：技术管理者或架构师。但团队也需要能创造真正的价值，才能实现利用杠杆放大价值的效果。在商业环境下，任何一种产品业务形态，其最终能实现价值，都会存在一个价值网络。这个网络中覆盖了各种角色，技术只是其一，若要找到最好的价值支点，那么通常会在离价值来源比较近的地方。
+
+技术像是一根棍子，能发挥多大价值，取决于棍子本身的品质和运用的方式。而往高处走的技术人，要跨越这条路径的断层，就是要认识清楚这个价值网络，并找到最适合技术发挥的价值点。
+
+精
+
+精的路线是一条 “专家” 之路。
+
+曾经在前文《定义：阶梯与级别》中定义过 “专家”，我说：专家可能就是某个领域中你绕不过去的人吧。这个定义中包含两个点，一个是领域，另一个是绕不过去。第一点表达了某个范围，第二个则模糊地表达了这个范围的大小，绕不过去其实是一个很大的范围了。
+
+比如，若你处在物理学领域，牛顿就是你绕不过去的人，之后是爱因斯坦。而在计算机领域，图灵定义了计算机的边界，也是这个领域绕不过去的人。但这样的天才人物，百年来才出一个，如果都要达到这个水平才算是专家，可能就太难了，从而失去了指导意义。
+
+如今反思，其实用这两点来定义专家也是可以的，只是需要更清晰地明确领域和量化范围。大至国家、社会、行业，小到公司、团队、小组，都有自己关于专家的定义。
+
+曾经，好些年前，我最早在公司的几个同事组成的小组内研究引入 Java NIO 的技术来编写网络程序，读了一些相关的书和开源框架代码（Mina、Netty），周围的几个同事就戏称我为 Java NIO 的专家。这就是用领域（Java NIO 是一个很细分的技术领域）加范围（局限于周围组内几个同事，他们要解决 NIO 的网络编程问题都绕不过我）定义专家的方式。
+
+因而，像前面说的爱因斯坦、牛顿、图灵，他们既是行业（学科维度）范围内的，也是世界（地理维度）范围内的专家。而公司内的专家职级定义，其范围无非就是与公司经营相关的某个领域，其大小无非就是公司组织架构的某一层级之内。
+
+走向专家之路，就是精确地找到、建立你的领域，并不断推高壁垒和扩大边界的过程。
+
+那么如何建立属于自己的、更大范围内且具备足够识别性的领域？这就是 “精” 的路径中的非连续性断层问题。曾经读过一篇吴军的文章，谈到了工程师成长中的类似问题，他用了一个公式来描述解法：
+
+
+成就 ＝ 成功率 x 事情的量级 x 做事的速度
+
+
+在连续的成长阶段，我们的成长主要体现在不断提升做事的熟练度，也就是上述公式中的速度和成功率，但这两个指标到了一定的熟练度阶段后就会碰到物理极限。实际情况是，一个资深的工程师的速度甚至不会比一个初级工程师快两倍，但可能成功率会高几倍，甚至十倍，这就是传说中的一个顶十个的程序员，但离极限也就差不远了。
+
+而要成为传说中以一敌百的程序员，只有一个可能，他们做的事情和其他人不在一个量级上。现实案例中，就有如 Linus 这样的人。所以，一直做同样的事，都是写代码，也可以跨越断层，但关键是，你写的代码体现在什么量级的事情上。
+
+之前在工程思维中总结过：问题的量级变了，逻辑就不一样了。作为程序员，我们会有直观的感受，用户量级越过了一定的门槛后，我们编写、维护和部署程序系统的方式都会发生本质的变化。而提升量级最难的就在于我们要放下曾经熟悉的方式和习惯，站在更高的维度去看更大量级的事情，并且找到适合这个量级事情的合适解决方案。
+
+面临成长路上的非连续断层，以及角色之间的无形壁障，该如何跨越断层，突破边界？我们着重从成长路线的两个方向：“高” 和 “精”， 提供了分析和解法。
+
+
+高的路线，需要借助技术的杠杆，认清所处的价值网络，找到合适的价值点，撬动更大的价值；
+精的路线，在做事情的成功率和速度接近自己的极限后，只能去提升事情的量级，才能发挥出专家的价值。
+
+
+明晰了不同路线的价值方向，但每个人脚下的路都是具体的、不同的，我们跨越的方式也不会一样。在成长的路上，你碰到了断层没？是如何跨越的？欢迎留言和大家一起分享探讨。
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/63成长蓝图，进化跃迁.md

@@ -0,0 +1,108 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            63 成长蓝图，进化跃迁
+                            回顾过去，我们会清晰地看见走过来的路线，但面向未来我们又该如何走下去？但凡过往，皆为序章，过去不可变，未来才是希望，而如何去规划并管理好未来的成长进化之路，才是我们当下要面临的主要任务。
+
+我们先从一个高度抽象的维度，来看看这条成长之路。
+
+一、成长路线
+
+结合我自己的经历、思考与总结，我对走过的路和未来的路概括成如下这张图：
+
+
+
+图中描述了好几个阶段，从一个阶段到下一个阶段，都会经历一次转折。
+
+1. 开发代码（Develop Code）
+
+从刚走出学校到进入职场成为一名新手程序员，在最初的一两年内，你可能都处在这个阶段。不停地大量写代码，为各类系统的“大厦”添砖加瓦，像块海绵一样，把自己吸得满满的，朝 9 晚 24 地工作与学习，并不时自嘲为 “码农”。
+
+这个阶段，你为生存所需（迫），会强烈地渴望成长。
+
+2. 开发系统（Develop System）
+
+三、五年后，你可能从初级、中级成长到了高级，此时你不再仅仅是写代码搬砖，而是开始负责起或大或小的整个系统。这时，你最关心的是如何用最好的技术方案，去开发、优化和完善系统。
+
+3. 开发产品（Develop Product）
+
+从高级走向资深、专家或架构师，你会发现你的技术执行技能已经优化到了相当的程度，这时往前多走一步，关注你所实现的系统所属的产品，会让你打开新的空间，找到更有效率和效果的实现路径，减少做无用功。
+
+而且在技术的世界里，有很多面向开发者的技术型产品，这个领域中最适合承担起产品经理角色的就应该是各类资深的技术专家和架构师了。
+
+4. 开发团队（Develop Team）
+
+当你选择走上技术主管并转变为一名管理者，那么人和团队将成为你的主要开发对象，而不再是代码了，这是成为管理者的必经之路。
+
+5. 开发梦想（Develop Dream）
+
+梦想这个东西也会随着岁月与你相伴成长，梦想实际永远在前方，它只是不断引领着你往前走。梦想相对而言是一个感觉上很 “虚” 的概念，它可能需要产品作为载体，也需要团队来一起开发创造。如此，梦想的引力就会引发你向一名创新者或领导者的方向进化跃迁。比如说，十多年前，刚毕业时，我的梦想是成为一名架构师，如今已然实现。
+
+以上这张图只是帮你看清从过去到未来的一条路，但如何走好这条路，就需要另一个视角维度的蓝图了。
+
+二、战略蓝图
+
+战略这个词，通常会和组织、公司关联在一起；那假想下，如果个人是一家公司，那么这家 “公司” 的战略该如何确定？
+
+在分析战略之前，我们需要先分析下公司的业务。为了更好地分析清楚公司的主要业务，这里借鉴下咨询公司爱用的商业分析模型：波士顿矩阵。实际有很多不同的分析模型，我只是觉得这个最简单，比较适合像个人这样的小小微 “公司”。
+
+波士顿矩阵模型，把公司业务分成下面四类：
+
+
+现金牛业务
+明星业务
+问题业务
+瘦狗业务
+
+
+现金牛业务，比较形象地表达了就是产生现金的业务。比如谷歌的搜索业务、微软的 Windows 操作系统，都是它们的现金牛业务，有很高的市场占有率，但成长率相对就比较低了。
+
+就个人来说，现金牛业务自然是一份稳定的工作，产生现金，维持个人生活的基本面，当然稳定之外越高薪越好。程序员这个职业就是很好的现金牛业务，行业繁荣，工作也比较稳定，专注于这个业务，不断提升薪资水平，这就是：活在当下。
+
+明星业务，比较形象地表达了很有前景的新兴业务，已经走上了快速发展的轨道。比如：亚马逊的云计算（AWS）就是它的未来之星。而个人呢？如果你的现金牛业务（级别和薪资）已经进入行业正态分布的前 20%，那么再继续提升的难度就比较大了。
+
+个人的明星业务是为未来 5 到 10 年准备的，就是现在还并不能带来稳定的现金流但感觉上了轨道的事。于我而言，是投资理财。人到中年，除了劳动性收入，资产性收益将作为很重要的补充收入来源，而当资本金足够大时，很可能就是未来的主要收入来源。当你开始在考虑未来的明星业务时，这就是：活在未来。
+
+问题业务，比较形象地表达了还有比较多问题的业务领域，面临很多不确定性，也就是还没走上正轨。将来到底是死掉，还是成为新的明星业务，现在还看不清楚。比如谷歌的无人驾驶、机器人等业务领域都属于此类。
+
+就个人而言，可能是一些自身的兴趣探索领域。于我来说，目前就是写作和英语，即使写作已经开了专栏，但并不算是稳定可靠的收入来源，主要还是以兴趣驱动，投入时间，不断探索，开拓新的维度，这就是：活在多维。
+
+瘦狗业务，比较形象地表达了一些食之无味、弃之可惜的业务。瘦狗业务要么无法产生现金流，要么产生的现金流不断萎缩。今日之瘦狗，也许是昨日的明星或现金牛，比如像诺基亚的功能机。
+
+就个人而言，行业在发展，技术也在进化，曾经你赖以为生的 “现金牛” 技能，可能过几年后就会落后，逐渐变成了 “瘦狗”，无法果断地放弃旧技能、开发新技能，可能就如诺基亚一般在新的时代被淘汰。固守瘦狗业务，那就是：活在过去。
+
+业务模型构成了你的蓝图，而对你的各种业务进行与时俱进地布局与取舍，这就是战略。
+
+三、进化跃迁
+
+明晰了路线，掌握了蓝图，该如何完成你的成长进化跃迁呢？
+
+跃迁是量子力学里的概念，指电子吸收能量后，突然跳到更高的能量级，这种不连续、跳跃的突变，我们称之为 “跃迁”。我借用了这个概念来类比成长，从如上定义中有几个关键点：
+
+
+吸收能量
+更高能量级
+非连续跳跃
+
+
+个人成长的跃迁也需要能量，在这里能量就是知识、技能和能力。完成 “能量” 的积累就需要持续地学习和实践行动，而持续行动又靠什么来驱动？内心的自驱力，这是稳定有效的驱动力来源，若没有自我驱动的力量是不太可能带来持续行动的。
+
+学习行动计划、养成行动习惯都是为了提升行动的效率，行动积累了足够的 “能量” 后，就向更高能量级跳跃。这里更高的能量级是对知识和能力的更高维度抽象的比喻，比如：知识模型和技能体系，就比孤立的知识点和技能拥有更高的能量级。
+
+而第三个关键点：非连续跳跃，说明这样的进化有突变的特征。而个人知识的积累与能力的提升，其实都是比较缓慢而连续的，非连续的跳跃其实体现在机会和运气上。合适的机会若没能降临，你就没法完成跃迁。
+
+连续的成长积累是你能掌控的部分，而跃迁的机会、运气则属于概率成分，你的努力可能一定程度上提高了概率，但它并不能导致必然的跃迁结果发生。即使机会没能到临，努力过后也许有无奈，也该当无悔了。
+
+最后，我们总结下：
+
+从开发代码到开发梦想，你可以画出一张你的成长路线图，从而走上进化跃迁的道路；上了路后，接着你可以利用工程师的思维模式和商业工具模型，建立一个你的成长战略蓝图去指导你如何走这条路。剩下的，就让你的努力、选择和运气来帮助你完成不断的跃迁变化吧。
+
+专栏至此，已近尾声，而如今的你，正在向哪个阶段跃迁呢？
+
+
+
+                        
+                        
+                            

专栏/程序员进阶攻略/尾声始于知，终于行.md

@@ -0,0 +1,77 @@
+
+                            
+                            因收到Google相关通知，网站将会择期关闭。相关通知内容
+                            
+                            
+                            尾声 始于知，终于行
+                            专栏历时半年，终于到了尾声。
+
+在写这个专栏之前，我已经写了好些年博客，写过很多关于技术的，也写过更多围绕程序员或者说当时的我自己成长的一些感悟。在回顾曾经写过的一些主题时，发现很多技术的内容可能都随着时间变迁过时了，但关于成长的认知却依旧历久弥新，因此选了这个关于成长的主题。
+
+而成长的本质，就是两个字：知行——始于知，终于行。
+
+知
+
+知，起于阅读；当你决定学习一样东西时，自然就会从阅读开始。从阅读中学习，要么是直接获得知识，要么就是从别人的学习经历或经验中找到值得自身借鉴的参考与启发。
+
+我硕士毕业于广州中山大学，一直让我铭记的是当年学校的校训，那是孙中山先生于 1924 年 11 月 11 日在广东大学（原校名，后为纪念孙中山先生改名）举行成立典礼时亲笔提写的十字训词：
+
+
+博学 审问 慎思 明辨 笃行
+
+
+这十字训词原文出自儒家经典《礼记·中庸》：“博学之，审问之，慎思之，明辨之，笃行之”，但孙中山先生赋予了它新时代的涵义。
+
+“博学” 好理解，在校训牌旁边不远处就是陈寅恪的故居，陈寅恪是中国现代历史学家、古典文学研究家、语言学家、中央研究院院士、中华民国清华大学国学院四大导师之一（其余三人为梁启超、王国维、赵元任），通晓二十余种语言，堪称博学之人。
+
+相比九十多年前孙中山先生的时代，今天是信息爆炸与过载的时代，知识与学问也淹没在这些爆炸的信息中，谁还能轻易堪称博学，我们只能说在信息的洪流中，保持永无止境地学习。如果能坚持学下去，那么今天的自己就比昨天的自己稍微博学一点，今年的自己也比去年的自己要博学一些。
+
+正因为信息过载，我们通过各式各样的大量阅读来接收信息，因此对这些信息进行 “审问、慎思、明辨” 就显得十分重要和关键了。“问、思、辨” 是对信息进行筛选、分析与处理，去其糟粕取其精华。经过降噪、筛选、分析处理后的信息再与我们自身已有的知识和经验结合形成属于自己的独立思考与观点，而这些独立的思考和观点才能用来指导我们的行动，也即 “笃行”。
+
+先有 “知”，方有 “行”。知，只是行的方法；行，才是知的目的。
+
+行
+
+在中大学习的年间，我每天早上去实验室，晚上又回来，多少次要从校训牌前来回经过。十多年后再回想当初在学校习得的那点知识和技能，要么已经过时，要么也遗忘殆尽了。最终留在心里的反倒是校训牌上那无比清晰的十字训词，并一直指导着我未来的学习与成长之路。
+
+十字训词，前 8 字 4 词占了 80% 的文字内容，但我觉着用在上面的时间和精力应该正好反过来：花 20% 时间和精力研究如何更好地 “知”，而 80% 的时间和精力放在持续地 “行” 上。搞错了比例，很可能最终也就无所成就，收获寥寥。
+
+但 “笃行” 往往是最消耗时间的阶段，一旦方向搞错了，可能大量的努力就浪费了。因此，“行” 之前的 “学、问、思、辨” 就很关键了，它们是行之前甚至行程中不断修正方向的指南针。
+
+我的专栏能提供给你的也不过是我的一些经历、经验与思考，供你行路参考。你的阅读会让你更 “博学” 一点，但这只是第一步的信息传递与接收阶段，如果没有后面的 “问、思、辨、行”， 于你又有多大的意义呢？所以，后面的部分只能靠你自己来完成了。
+
+
+纸上得来终觉浅，绝知此事要躬行。
+
+
+在 “行” 的路上，也许一开始都是参照走前人走过的路，虽然我们经常想走自己的路，其实绝大部分人终其一生都是在走前人的路。写到这，想起一个前几年关于我自己的真实 “行路” 的感悟。
+
+几年前，我考了驾照买了车，然后就跑去自驾。从成都出发，经过了红军长征走过的草原，绕过了青海湖边，经古代丝绸之路的路线一路开到了敦煌。丝绸之路从敦煌出去，分出两条，北上经玉门关，南下出阳关，走到那里突然有种诗和远方的感觉。
+
+但无论自驾如何自由，我们也不过是在走前人的路。在敦煌的洞窟里看到了张大千临摹的笔迹，才了解到战争年代大师也曾在这里临摹古人的壁画，走着前人的路。
+
+开着车走在路上，两边是沙漠，偶尔看见前面有车，超过，再前行，两边的沙漠变成戈壁，路看不到头，一望之下再也看不到其他的人和车，走在路上感觉有些心慌然，仅仅是走在前人的路上已有些慌然，那走出这条路的前人又该是怎样的心境？
+
+回程中，入蜀后国道一来一去两条车道，车多起来了后都只能跟着走，大车在路上慢悠悠地挡着道，小车都会借道超车。借道本身是有一定危险的，超大车还好，如果前面是小车，本身开得不慢，跟着走是不是更能在安全和速度之间取得平衡？我试过跟着小车走，不超车，结果跟不了多久就跟丢了。
+
+当你决定跟车时就放弃了超越的心，安稳是安稳些了，但节奏掌握在前车手里，最终只会被远远甩下。开车行路如此尚可，但人生之路终究是无法去跟住别人的，有一颗超越的心，按自己的节奏一直走下去，你终究会慢慢走出一条属于自己的路。
+
+这条路，难不难走？难，感觉走不下去时，不妨读读李白的诗吧。
+
+
+行路难！行路难！多歧路，今安在？-
+
+长风破浪会有时，直挂云帆济沧海。
+
+
+所以，近年啊，我总不时读读唐诗。
+
+感谢你一路同行读到这里，希望这个专栏是你又一次 “知” 的起点，后面该看你的 “行” 了。最后，祝你：前路无碍，挂帆破浪。
+
+末了，专栏虽然结束了，但我的“行”——写作之旅并未停止，在未来，我还会继续在我的公众号（瞬息之间）思考与写作下去，期待你也行动起来，我们一路同行 ^_^。
+
+
+
+                        
+                        
+