《胡峰·程序员进阶攻略 - 极客时间》
开篇词 | 程序行知：走在同样的路上，遇见自己的风景
学习“技能性知识”，让你成为“解答题高手”。
路径选择和自我认知，有时选择对了合适的路，比光顾着赶路要重要得多。
-
建立技术学习的体系框架与思维模型
-
梳理清晰的成长与进阶路线
-
扫清成长路上的迷茫与障碍
-
形成明确的自我定位与认知
01 | 初心：为什么成为一名程序员？
心明行远。
做“复盘”，一方面审视过去的自己，另外一方面思索未来的方向。
02 | 初惑：技术方向的选择
人生的选择，从投资的出发点而非终点来选择一条路径。
信息或者想法的预期寿命，和它的现有寿命成正比。如果你想预测一门语言还会存在多久，就看看它已经存在了多久。
先在这个行业里立稳脚跟。在此基础上，再去关注新潮流、新方向或新技术，观察它们的可持续性。
选语言，就是选职业，而选职业首先选行业。
03 | 初程：带上一份技能地图
熟练是硬功夫，了解是知其然，知其所以然。
image.png
04 | 初感：别了校园，入了江湖
image
05 | 架构与实现：它们的连接与分界？
架构是一种结构设计，但它同时可能存在于不同的维度和层次上：
-
高维度：指系统、子系统或服务之间的切分与交互结构。
-
中维度：指系统、服务内部模块的切分与交互结构。
-
低维度：指模块组成的代码结构、数据结构、库表结构等。
架构师的共同点：
-
确定边界：划定问题域、系统域的边界。
-
切分协作：切分系统和服务，目的是建立分工与协作，并行以获得效率。
-
连接交互：在切分的各部分之间建立连接交互的原则和机制。
-
组装整合：把切分的各部分按预期定义的规则和方法组装整合为一体，完成系统目标。
架构师的交付成果是一整套决策流，文档仅仅是交付载体。
06 | 模式与框架：它们的关系与误区？
框架是代码复用，模式是设计复用。
框架和模式的共同点在于，它们都提供了一种问题的重用解决方案。
当你解决了一个前人从没有解决的问题，并把解决套路抽象成模式，你就创造了一招新的 “武功”。
07 | 多维与视图：系统设计的思考维度与展现视图
划分微服务2个原则，是微服务的组成：
-
单一化：每个服务提供单一内聚的功能集。
-
正交化：任何一个功能仅由一个服务提供，无提供多个类似功能的服务。
微服务之间的关系与交互：关系也即依赖于被依赖。
08 | 代码与分类：工业级编程的代码分类与特征
三类代码：功能、控制、运维。
搞清楚功能背后的需求并得到正确的理解。之后的编码活动，就仅是一个“翻译”工作了：把需求“翻译”为代码。所以，要努力去理解业务及其背后用户的真实需求。实际上，程序存在的意义就在于实现功能，满足需求。
控制是为了系统运行正常、稳定。
运维代码，就是方便程序检测、诊断和运行时处理的代码。
少了后两类代码，将来都会是负债，甚至是灾难。而一个满足工业级强度的程序系统，这三类代码，一个也不能少。
有足够的边界与距离才能避免耦合与混乱，优雅有时就是边界与距离。
缺失就是欠债，迟早要还，欠多了以后就会面临破产。
我发现，我最近写代码更注重逻辑和思路，理清之后，翻译工作往往是简单快速的。
翻译，就是创造。把想法、思路落实执行，得到结果，这或是创造。
09 | 粗放与精益：编程的两种思路与方式
一上午只修复了一个 Bug，而且只改了一行代码，到底发生了什么？时间都去哪里了？以前觉得自己写代码很快，怎么后来越来越慢了？我认真地思考了这个问题，开始认识到我的编程方式和习惯在那几年已经慢慢发生了变化，形成了明显的两个阶段的转变。这两个阶段是：
-
写得粗放，写得多
-
写得精益，写得好
修bug的时间主要花在了构建重现 Bug 的测试案例场景中。而想要进步需要不断学习、实践、改进、学习。
精益生产（Lean Production），简言之，就是一种以满足用户需求为目标、力求降低成本、提高产品的质量、不断创新的资源节约型生产方式。
如果一开始就像 “品质” 组同学那样去追求完美，也许你就会被定义 “完美” 的品质所绊住，而忽视了制作的成本与效率。
10 | 炫技与克制：代码的两种味道与态度
虽然你代码可能已经写得不少了，但要真正提高代码水平，其实还需要多读代码。就像写作，写得再多，不多读书，思维和认知水平其实是很难提高的。
技术人就容易倾向性地关注项目或工程中的技术含量与难点，过度设计和实现，导致人为制造技术含量，即炫技。
扩展性也应当来自真实的需求，而非假设将来的某天可能需要扩展，因为扩展性的反面就是带来设计抽象的复杂性以及代码量的增加。
克制的编程方式：
-
克制的编码，是每次写完代码，需要去反思和提炼它，代码应当是直观的，可读的，高效的。
-
克制的代码，是即使站在远远的地方去看屏幕上的代码，甚至看不清代码的具体内容时，也能感受到它的结构是干净整齐的，而非 “意大利面条” 似的混乱无序。
-
克制的重构，是每次看到 “坏” 代码不是立刻就动手去改，而是先标记圈定它，然后通读代码，掌握全局，重新设计，最后再等待一个合适的时机，来一气呵成地完成重构。
11 | 三阶段进化：调试，编写与运行代码
多沟通，深入理解别人的代码思路和风格，不要轻易盲目地修改。
从嵌套变成了顺序逻辑，这样可以为未来的程序员留下更优雅地编程惯性方向。
文字能让人读懂，读爽就够了；但代码写出来还需要运行，才能产生最终的价值。
编程，要运行以产生价值；而文字，让人读爽、读懂就行了，不在乎实用性、真实、对错。
12 | Bug的空间属性：环境依赖与过敏反应
经常被测试或产品经理要求修改和返工的 Bug。这类 Bug 都来自于对需求理解的误差，其实属于沟通理解问题，我并不将其归类为真正的技术性 Bug。
13 | Bug的时间属性：周期特点与非规律性
在编程路上你遇到得最多的 Bug 是哪类？
这类 Bug 都来自于对需求理解的误差，其实属于沟通理解问题，我并不将其归类为真正的技术性 Bug。
环境即生活和依赖空间，由跟自己息息相关的东西组成。
14 | Bug的反复出现：重蹈覆辙与吸取教训
“当你在书写的时候，你试图传达想法，这是非常高级的任务。而在做高级任务时，大脑将简单、零碎的部分（拼词和造句）概化，这样就可以更专注于更复杂的任务，比如将句子变成复杂的观点。”
认知偏差，是重蹈覆辙类错误的最大来源。
粗心大意，可以通过开发规范、代码风格、流程约束，代码评审和工具检查等工程手段来加以避免。
软件缺陷分为三类：
-
非常业余的结构设计
-
不符合软件开发规范
-
对关键变量缺乏保护
第一类属于熵增问题，导致系统规模不断变大、变复杂，结果驾驭不了而失控；第二类属于开发过程的认知与管理问题；第三类才是程序员实现上的水平与粗心大意问题。
一个飞机上有正副两个机长，副机长的作用是帮助发现、提醒和纠正机长在飞行过程中可能发生的一些人为小错误。
大韩航空的问题正在于副机长是否敢于以及如何提醒纠正机长的错误。
权力距离是指人们对待比自己更高等级阶层的态度，特别是指对权威的重视和尊重程度。
建立和维护有利于程序员及时暴露并修正错误，挑战权威和主动改善系统的低权力距离文化氛围，这其实就是推崇扁平化管理和 “工程师文化” 的关键所在。
规则、流程或评价体系的制定所造成的文化氛围，对于错误是否以及何时被暴露，如何被修正有着决定性的影响。
世界上不存在不犯错误的学习或行事方式，只是我们可以通过学习，比其他人少犯一些错误，也能够在犯了错误之后，更快地纠正错误。但既要过上富足的生活又不犯很多错误是不可能的。实际上，生活之所以如此，是为了让你们能够处理错误。
人固有缺陷，程序固有 Bug；吸取教训避免重蹈覆辙，除了不断提升方法，也要创造环境。
15 | 根源：计划的愿景——仰望星空
我们做系统应用服务时总是需要考虑各种意外和异常事件发生。
16 | 方式：计划的方法——脚踏实地
我回顾了我工作以来的成长发展阶段，根据目标的清晰度，大概可以划分为如下三个阶段：
1. 目标缺乏，随波逐流
2. 目标模糊，走走停停
3. 目标清晰，步履坚定
我开始问自己想要成为一个怎样的程序员，想要在什么行业，什么公司，写怎样的程序？
做计划就是为了应对变化。
17 | 检视：计划的可行——时间与承诺
承诺让计划得以完成，将目标排在优先级最高。
18 | 评估：计划的收获——成本与收益
读书本是好事，但读书的数量并不是关键点，关键是计划今年读哪些书。因为只有明确了读哪些书，才能评估是否值得和适合在这阶段去读。
计划即选择，而但凡选择就有成本，机会成本。
前期，我都是从网上去扒各种免费的电子书，看免费的博客，读开源的代码；但今天我几乎不会再去网上找免费的学习材料了，而是直接付费购买。
要获得好的结果，你就要自己给自己施加约束，保持自律，对自己有更高的期望，需要有自驱力。
19 | 障碍：从计划到坚持，再到坚持不下去的时候
故事的价值不在于真实准确，而在于提供人生的意义。
20 | 执行：从坚持到持续，再到形成自己的节奏
21 | 信息：过载与有效
没有目的的学习是徒劳的，它仅仅是在我们的头脑中流过一遍，流过的痕迹很快又会被新的信息冲刷干净。不管我们拥有怎样的 “最强大脑”，在面对这股信息与知识洪流时，都几乎可忽略不计。
消耗率示意图：
image
你得挑选那些真正值得做和学的东西去让大脑满负荷运转，但凡投入决心去做的事情，就需要百分百投入。这就是专注于少而精的东西，深入了解这些东西，进入到更深的层次上。深可以无止境，那到底多深才合适？我的答案是：让你的内心对取得的效果感受到满意的深度层次上。它的反面是：但凡心存疑虑，不是那么确定要全力投入的事情，干脆就不做了。
22 | 领域：知识与体系
成长最重要的，就是知识体系的构建。
红色的部分是目前还属于我 “掌握” 与 “了解” 的领域，其他灰色的部分则是要么被时代淘汰了，要么已经被我放弃了维持与更新。
image
成长 “T 线图”，它串联了如今我沉淀下来的和一些新发展的 “点”。
image
在相对传统的行业，做偏业务的开发，技术栈相对固定且老化，难度和深度都不高，看不到发展方向，期望找到突破口。若你也出现这样的情况，那就说明你从事的业务开发，其单个技术点的价值上限较低，而选择更新、更流行的技术，你就是期望提升单个技术点的价值，但单个技术点的价值是相对有限的。
23 | 转化：能力与输出
要想产生更大的成果，取得更大的成功，我们需要找到放大个体或团队能力的杠杆支点。好产品或好结果并不能成为支点，不断产出好结果或好产品的 “体系流水线” 才是。
24 | 并行：工作与学习
初期的代码属性，只能勉强满足业务需要，虽看不出明显的 Bug，但一遇到特殊情况就容易宕机。整个系统虽然勉强能支撑公司运营，但其中欠下了大量的技术债；先活下来，未来再来慢慢还 但有些公司根本没有意识到，也没有采取行动 。
学习还是要聚焦和主动选择，毕竟你的精力和时间都是有限的。
-
成长潜能：按需开发新能力，显示出高于当前层级要求的其他技能，如：专业、管理、领导。
-
转型潜能：持续有规律地开发新能力，追求跨层级的挑战和机会，展现雄心壮志。
25 | 时间：塑造基石习惯（上）——感知与测量
26 | 时间：塑造基石习惯（下）——切割与构建
27 | 试试：一种“坏”习惯，需要有更清晰的终点
28 | 提问：从技术到人生的习惯
第一个原则：提供足够的信息，让人能够回答。更有意义的提问是把解答题变成选择题，提供你的选项，展现你探索了哪些路径，省去了可能产生的反问。
第二个原则：提供更多的选项，让人方便回答。
第三个原则：提供交换价值，建立讨论基础，表达感谢态度，让人乐于回答。
29 | 偏好：个人习惯的局限与反思
30 | 写作：写字如编码
程序员群体有个共同的弱点，那就是写得了代码，解决得了问题，但却不能很好地展现自己的能力。
写作主题的来源：身边的工作和生活中的事件引发的感触；阅读过程中突然产生的启发与领悟；一直困惑的问题突然碰到或找到了答案。
美国作家库尔特·冯内古特说：
想一个你关心，其他人也会关心的话题来写。要记住，不论你用多么发自肺腑的情感表达，对于读者来说，除非是他们真正关心的主题，不然怎么都不会太关心，而只有主题才是读者最真切的关注点。所以，关注你的主题，而不是想办法去显摆自己的文字。
人们都喜欢读故事，而非说教，那故事又该如何切入与布局？这也是需要考虑的点。
大部分作者的源动力都来自于一颗想要表达的心；再配合一部分外部的激励机制，和相应的自律约束，才有可能持续地写下去。
31 | 画图：一图胜千言
32 | 演讲：表达的技术
写作的展现，是一种广度路线，产生间接、长尾效应；演讲的展现，...
33 | 定义：阶梯与级别
不同级别的判断维度：
-
具备什么能力？
-
解决什么问题？
-
产生多大影响？
初级
具备基本的专业技能和素养，能快速学习公司要求的常用开发技术、工具和框架，能理解所在的业务和产品领域，并按照设计要求来实现功能。
如果从这个阶段你就开始定期归纳总结这些局部的工作经验，不断优化工作内容，并能在团队小组内部做出分享，甚至帮助其他同学解决问题，那就说明你已经走上了一条快速成长的通道。
中级
对实现各种业务功能、开发规范流程都很熟练了，摆脱了对基本指导的依赖性。
能够独立承担开发任务，设计实现他们负责的系统模块，以及通过搜集有效信息、资料和汲取过往经验来解决自己工作范围内遇到的问题。
基本要求：完成动作、达成品质和优化效率。需要反思、沉淀、迭代并改进。
高级
独立完成工作，独立负责一个大系统中的子系统或服务，并成为团队骨干或最重要的个人贡献者。
用户体验（品质提升）和性能优化（优化效率）更全面的考量。
资深
深度和资历（即广度）
-
基础研发、算法和特定技术复杂领域，会向 “资深工程师” 方向发展，属于深度优先
-
在面向业务开发的领域，业务复杂度高于技术复杂度，则会向 “架构师” 方向发展，属于广度优先
经验分享和方法论沉淀除了经验分享和方法论沉淀，还有产品和团队两个考虑维度。前者可能资深方向侧重多一些，后者则是架构师方向需要侧重思考实践的。
专家
专家可能就是“这个领域内你绕不过去的人”吧。
专家，表明了某种领域的明确建立，有公认的影响力。“大家”和“小家”的区别，就在于影响建立的范围大小。
积累多年，建立体系，形成领域，他们需要解决的最重要的问题是：面向未来不确定的战略问题。这就像机器学习用过去长期积累的数据，建立起一个模型，用来预测和判断未来。
34 | 晋升：评定与博弈
制定标准的初衷也是为了给评定过程增加客观性，将人的主观判断约束在一定的客观范围内。
编程和解决问题能力很强的人，在这样的形式下就会吃亏，这就有失公平性。
35 | 关系：学徒与导师
我们都知道编程这门手艺，你读的书再多、再好也不如真正动手去做。
为什么他们要牺牲自己的工作时间，甚至私人时间来无私地指导你？
他有什么样的利益或情感驱动要去更积极地做这件事呢？
其实最直接的，还是由对方的态度和行动来驱动的。
而在没有这些更实质的驱动因素时，有人如果愿意去积极地做这件事，那一定是在更高的维度看这件事。
取得领先的方法，就是提携你身边的人。你对待别人的态度始终会伴随你，人们会忘记你所说和所做的一切，但永远不会忘记他们对你的感觉。帮助别人就是影响别人，如果你能帮很多人，你本身就是高手，你的影响力就很大，你就能做更大的事。
这是一个气度问题。
给人当学徒，就给你提供了这个机会。你现在把自己和一个高手连接在了一起，你可以从内部了解第一手的经验。这就是学徒工作的协议：用礼敬和服务，换取机会——而这个机会还不是立功露脸的机会，而是学习实践的机会。
机会，就是得到更快的成长与发展。从导师多年积累的经验中获益，能够缩短获得这些知识经验的时间，并且避免重复错误。但这里面可能还有个障碍，就是自尊心的问题，态度不够谦虚，那么也许是性格还需磨练。
从学徒方面来说，必要的、简单的、低技术含量或重复性的工作也是必须的，不应该被认为是一种浪费或牺牲。当你在免费获得大量的知识和帮助的同时，却抱怨时间投入太多，或者时间不够，其实是短视的。因为：
当你给人铺路的时候，你实际上也在左右他的前进方向。
付出，这就是我从一堆孩子中识别出那些只是随便说说，还是真正认真严肃地想干点事的人的办法。
带好了徒弟，接手并取代了你当前正在做的事情，你才有可能解放出来去做更高层次和更大维度的事情。
而作为学徒，你需要吸取德里克的经验：学习和成长是自己的事，严肃待之，行动起来，自助者，人亦助之。
36 | 核心：安全与效率——工程技术的两个核心维度
37 | 过程：规模与协作——规模化的过程方法
正因为需求的来源多，表达形式也多，因而真实情况是 “需求” 似乎总是源源不绝，但是真正的需求往往隐藏在这些诉求、请求与要求的表象之下。这是关于 “需求” 的第一个困难点。如果我们总是能找出真正的需求，那么也许需求也就没那么多了。但现实往往是我们不能，那么需求过载的场景就会常常发生。
调度策略：
- 先来先执行
- 执行起来最快的先执行
- 占用资源最少的先执行
- 释放资源最多的先执行
- 高优先级的先执行
当资源充足，只用策略 1 就足够了，但更多情形下需要综合后 4 种策略。比如：老板的要求天生自带高优先级，需要先执行；而一些小需求，优先级不高，但执行快，占用资源少，随着它们排队的等待时间延长，优先级可以逐步提升，以免消耗完用户的等待耐心，形成负面评价。
顶层设计主要做两件事：
- 一是去建立系统的边界。系统提供什么？不提供什么？以怎样的形式提供？
- 二是去划定系统的区域。也就是系统的层次与划分，以及它们之间的通信路径。
按文中所说，足球的科学踢法是：“球员必须建立 ‘区域（zone）’ 的观念，每个球员都有一个自己的专属区域”，通过区域的跑位来形成多样化的传球路线配合。
38 | 思维：科学与系统——两类问题的两种思维解法
写了多年代码，做了好多的工程，不停地完成项目，但如果你一直仅仅停留在重复这个过程，那么就不会得到真正的成长与提高。你得从这些重复做工程的过程中，抽象提炼出真正解决问题的工程思维，用来指导未来的工程实践。
什么是工程思维？我从自己过往经验中提炼出的理解是：一种具备科学理论支撑，并成体系的系统化思维。
吴军老师也曾在一篇文章《计算机科学与工程的区别》里指出：
科学常常指出正确的方向，而工程则是沿着科学指出的方向建设道路；在工程中必须首先使用在科学上最好的方法，然后再作细节的改进。
所以，理论的意义不在于充当蓝图，而在于为工程设计实践提供有约束力的原理；而工程设计则依循一切有约束力的理论，为实践作切实可行的筹划。
简言之，科学理论确定了上限，工程实践画出了路线。
系统思维洞察问题本质，科学思维发现最优解法。
39 | 职业倦怠：如何面对？
短期的应对的办法：休个年假，脱离当前的环境，换换节奏，重新补充 “燃料”，恢复精力。
关键就是要找到什么在真正驱动你前进。
40 | 局部最优：如何逃离？
局部最优点：技术无法再快速进步了，业务领域也已经熟得不能再熟了。
所有的局部最优点，都意味着我们爬到了一定阶段，在这个位置徘徊不去，恋恋不舍。
审视下你的当下，再回顾下你的职业生涯，你花了多少时间和功夫来看清自己正在攀爬的 “山”，它的高点能让你去到你想去的地方吗？能让你看到你想看的风景吗？有时，我们大部分的努力，都没有什么进展和结果，仅仅是让我们能勉强呆在同一个地方。
看清了自己目标的高山，发现自己爬错了山，要舍得离开；停留在低矮的山上，无论再努力，看到的风景也有限。
走出徘徊的第一步，总是从下山开始，而这样的选择并不容易。
41 | 沟通之痛：如何改变？
沟通清楚了，能让我们避免一些无谓的需求，少写不少无效的代码。
沉默有时是因为不想说。
《计算机程序的结构与解释》有云：“程序写出来是给人看的，附带能在机器上运行。”
其实，写代码本身也是一种沟通，一种书面沟通。沟通从来都是个问题，书面沟通也同样困难。
千万不要让两个都自我感觉很牛的程序员去同时设计一个技术方案，让他们拿各自的方案去 PK。
- 先确定分歧点是否值得你去拼命维护。
- 分歧进入用 “理” 都无法搞定时，那就是应了那句古词：“剪不断，理还乱”。
这时继续“理”下去，不过都是互相耍混罢了。“理” 是一个需要双方去客观认可的存在，而越“理”越乱则说明双方至少没有这种客观一致性的基础，那就找一个主观的人来做裁决吧。 - 权力来裁决
非关键利益之争实在没有必要走到这一步了。
Stack Overflow 的创始人和乔尔·斯波尔斯基（Joel Spolsky）
真正关键的是，他们能不能把他们的想法表达清楚，杰出的程序员通过说服别人来达成协作。
通过清晰的注释和技术文档，他们让其他程序员能够读懂他们的代码，这也意味着其他程序员能够重用他们的代码，而不必重新写过。
要不然，他们代码的价值就大打折扣了。
程序员解决技术问题的习惯，就是把一个大问题拆解为多个部分的小问题。
当你要向其他人详细解释某样东西的时候，你经常会惊讶地发现你有多无知，于是，你不得不开始一个全新的探索过程。
沟通改变的第一步就是从考虑接收方开始的，看看接收方能吸收和理解多少，而非发送了多少。
现实并不要求程序员成为所谓的沟通达人，只是需要主动认识到身边的沟通问题，去进行理性和逻辑地分析、拆解并做出适当的调整。
沟通问题的本质是要方便接收，达成共识，保持换位思考和同理心，改变自会发生。
42 | 技术停滞：如何更新？
技能是那些你以为你知道，但如果你没做过，就永远不会真的知道的事情。
学习技能，完全低估了需要重复练习的次数和强度。
重复，是有针对性的强化练习，其本身是练习过程，而非练习内容。每一次的重复过程中都需要根据反馈进行有针对性的调整，以取得练习效果的进步。
而重复的刻意练习总是辛苦的，辛苦就是我们付出的技能保养成本。
技能不仅仅会停滞，还有可能会过时。
技术也许会停滞，技能也可能会过时，但其中的能力却可以沉淀下来。
技能对应的词是 Skill，而能力对应的是 Ability。技能是你习得的一种工具，那么能力就是你运用工具的思考和行为方式，它是你做成一件事并取得成果的品质。
代码能力的识别，最简单的方式就是维护一份公开可跟踪的记录，比如参与开源项目贡献，在 GitHub 上留下你的代码简历。
个人很多综合能力的差别，有时就是要靠作品来体现的。完成作品需要有一些产品思维，需要自我规划与管理能力，而推广作品需要运营和传播能力。这些相关的能力，最终都会成为你核心能力体现——作品——的放大器。
43 | 无法实现：困扰与反思
“技术上无法实现”时，仅仅是因为当时的我并不知道如何去实现。
因为不知和不解而心怀畏惧。因为畏惧，所以我用了这句口头禅来回避了这个问题，甚至没有去调研一下技术可行性，就由此固步自封，在这片知识领地留下了一片空白，也不能为客户创造更进一步的价值。
事实上，我发现大部分的用户需求，技术上总是可以实现的。这些需求的真正限制，要么是时间，要么是资源。
关于评估，可以保守一些，因为一般来说现实总是比理想的路径曲折一些的。
我们恐怕不能够再轻易说出 “技术上无法实现” 了。即使真的是无法实现的需求，也有可能通过变通需求的方式来找到一条可实现的路径。“技术上无法实现” 的口头禅仅仅是我们阻挡需求的快捷方式，但这样的思维也阻碍了我们进一步去找到真正的实现路径和优化方案。
44 | 完成作品：理想与现实
维基百科上对“作品”的定义是：
作品，亦称创作、创意、著作，是具有创作性，并且可以通过某种形式复制的成品。
作品最重要的特质是：创作与创意。
从网上复制来一段代码，解决一个问题，这不是创作，也不会成为你的作品。
打磨代码作品的方式，应该是定期对自己写完的代码进行沉淀、梳理和规整，提取可复用的功能，同样的功能只写一次，形成自己专属的编码脚手架和代码库。在以后的学习实践中定期反思，不断优化其效率和品质。
当你再碰到类似功能的实现时，能直接复用库就复用库，不能直接复用的就在脚手架代码上进行扩展，后续的重心就放在了优化实现思路上。
《黑客与画家》一书里所说：
优秀作品的秘诀就是：非常严格的品味，再加上实现这种品味的能力。
大多数做出优美成果的人好像只是为了修正他们眼中丑陋的东西。
当你给别人介绍自己时，只需要介绍自己的作品，而不再需要介绍自己的技能。
作品要实现直接的经济收益，必须还要走完从作品到产品之路。
用一段新算法实现的函数取代了旧函数，那么多余的旧函数就变成了负债而非资产，是需要去清理的。
45 | 代码评审：寄望与哀伤
知道一定会有同事将检查你的代码，那么你编程的姿势和心态就会完全不同。
底层技术产品或中间件的需求较稳定，且生命周期长；而业务项目，特别是尝试性的创新业务，需求不稳定，时间要求紧迫，并且其生命周期还可能是昙花一现。
强制推行，如何保障其效果？团队出于应付，每次走个过场，那么也就失去了评审的初衷和意义。
要么遵守规则，要么离开组织。
剑是好剑，但还需要配合好剑客与好剑法。
46 | 人到中年：失业与恐惧
假如你在一份工作中，对丢掉工作本身产生了恐惧，那你做工作的形式很可能会走向谨小慎微。
这时工作让你产生了恐惧感，你就将会被工作绊住，只想兢兢业业、如履薄冰地做好份内工作，以保护好自己的位置。但为了保护位置所做的所有努力都会是徒劳的，因为恐惧感绊住了你，这样的工作状态，自己也是缺乏信心的，而一个对自己信心不足人，也很难让别人对你产生信心。最终，几乎没有任何办法阻止别人占有你当前的位置。
普通劳动者和专业人士的区别在于，普通劳动者主要被动接受指令去执行任务，而专业人士则在其领域内自己生成指令，同时在领域外还会向同事或上级提供来自该领域的输出：专业建议。
普通劳动者是一种劳动力资源，他们保证执行，而专业人士则是保证选择的执行方向是有意义的，执行路径是优化的。作为专业人士，我们需要去坚持和持续地打磨专业力，守住这块阵地。
安全感，是渴望稳定、安全的心理需求，是应对事情和环境表现出的确定感与可控感。
年轻时，拼的是体力、学习力和适应能力，是做解答题的效率与能力；中年了，拼的是脑力、心力和决策能力，是做对选择题的概率。
年轻时，我们打的是突击站，左冲右突；中年了，我们打的是阵地战，稳步推进。
47 | 该不该去创业公司？
去创业公司可能综合能力更强，但在特定的专业领域又不够精深。
在成熟的大公司工作，无论工资还是配股的收益都有很高的确定性。而创业公司即使给你开出同等的工资加上对应的期权，相比大公司的稳定性和持续性，也依然处于劣势。更可能的情况是，创业公司给你的工资加上按目前融资轮次估值的期权价值一起，才勉强和你在大公司每年的确定收益相持平。
将期权更多的看作彩票，如果期权让你发了财，这非常好，但是你应当确保自己的工资报酬至少可以接受，也就是说即使你的合同中没有期权，你也仍然会选择加入这家创业公司。这中间相对你在大公司的确定性收益的差距便是追求梦想的直接经济成本，也可以理解为你选择创业的风险投入资本。
48 | 该不该接外包？
面临当初的外包项目我的选择是：拒绝。因为，它带来的收入是一次性的，不具备积累效应，而且相比我的全职工作收入还有差距，短期也许能增加点收入，但也没有其他任何意义了。
长期来看，价格总是要回归价值。
选择做赚钱的事，还是值钱的事？
赚钱的事，核心是当下的利差，现金现货，将本求利。
值钱的事，核心是结构性价值，兑现时间，在某个未来。
前十年不妨把关注的焦点放在个人价值的增值上。
外包项目的成果具有可复制、可重用性，这样就可以通过大量复制和重用来降低一次性开发成本；而成本和比较优势才是外包模式的核心竞争力所在啊。
49 | 技术干货那么多，如何选？
通过分析别人走过的路径，来拨开自己技术道路探索上的迷雾。
我们去阅读技术干货文章，想从别人的分享中获得对自己技术方案的一个印证。这就是一种行业的实践证据，毕竟想通过听取分享去印证的，通常都是走过了一条与自己类似的道路。
同一个技术方案在不同的时期，面临不同的环境，就会带来不同的成本，并做出不同的选择与取舍。虽然看起来是在走类似的路，但不同的人，不同的时代，不同的技术背景，这些都导致了终究是在走不同的路。
你不能看见别人的功夫套路好，破解难题手到擒来，就轻易决定改练别人的功夫。表面的招式相同，内功可能完全不同。
切磋，主要是带给你不同的思维方式，用自己的功夫寻求破解之道。
50 | 技术分歧，如何决策？
“康威定律”任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。其本质是最大化团队的核心能力，最小化沟通成本。
51 | 技术债务，有意或无意的选择？
在程序设计与开发过程中，有意或无意做出的错误或不理想的技术决策，由此带来的后果，逐步累积，就像债务一样。
架构升级除了还债，还是为未来铺路。
52 | 选择从众，还是唯一？
本杰明·富兰克林是这么说的：要么写点值得读的东西，要么做点值得写的事情。
独一无二的路，要么是没有竞争的，要么是别人没法竞争的。
54 | 侠客行：一技压身，天下行走
技能模型才是区分不同专业人才特点和价值的核心关键点。
文艺复兴时期的达芬奇是一位多才多艺的人，但一个人如果像达芬奇一样对什么东西都感兴趣，但又没有和达芬奇匹敌的才华，很可能尝试了很多，最终却一事无成，这就中了 “达芬奇诅咒”。
