程序员的进阶攻略
2024-10-12 11:07:32 0 举报AI智能生成
《程序员的进阶攻略》是一本关于如何提高编程技能和职业发展的实用指南。本书涵盖了从初级到高级程序员的各个阶段，提供了系统化的学习路径和实践建议。同时，本书还介绍了一些流行的编程语言和技术栈，如Python、Java、C++等，以及它们在实际项目中的应用。此外，书中还阐述了软件工程原理、代码重构、算法设计等核心概念，帮助读者深入理解编程的本质。对于想要在编程领域不断精进的读者来说，这本书是不可或缺的参考资源。
作者其他创作
大纲/内容
一方面审视过去的自己，另外一方面思索未来的方向。
复盘
成长阶段
01讲初心：为什么成为一名程序员
选择那些展现出蓬勃生命力的语言。
越是新的语言或技术，升级换代越快，也越容易被取代。
换句话说就是，如果你想预测一门语言还会存在多久，就看看它已经存在了多久
存活时间足够长的语言，可以预期，它未来也还可能存活这么长时间。
信息或者想法的预期寿命，和它的现有寿命成正比。
选择语言
不妨投入到一些可能在长期被低估的基础技术上，而不是被技术潮流的短期波动所左右
技术的选择，都是赚取长期回报，短期的波动放在长期来看终将被抵消掉，成为时代的一朵小浪花。
选择回报
选语言，就是选职业，而选职业首先选行业。
先想想自己想从事哪个行业的软件开发；
然后，再看看：这个行业的现状如何？行业的平均增速如何？和其他行业相比如何？这个行业里最好的公司相比行业平均增速又如何？
最后，再看看这些最好的公司都用些什么样的技术栈和语言。如果你想进入这样的公司，那就很简单了，就选择学这样的技术和语言。
思路
选择行业
02讲初惑：技术方向的选择
开发平台，它包括一种编程语言、附带的平台生态及相关的技术
语言的选择基本决定了开发平台的性质，但有些语言可能例外，如：C++、JS、C# 等，这些语言都可以跨多个平台
编程语言
与语言平台关联的还有其技术生态以及各种技术框架的繁荣程度
这些平台技术生态的存在让使用这门语言编程完成特定的任务变得容易和简单得多。
Java 的生命力除了 JDK 的强大支撑，实际还有其平台生态的繁荣，也起了决定性的作用。
例子
平台生态
主流的技术框架
解决方案
1.开发平台
算法，表达的是一个计算的动态过程，它引入了一个度量标准：时空复杂度。
但结合工作实际的业务场景，我们需要去设计更贴合需求的算法，而只要是算法它都受到时空复杂度的约束，而我们只是在其中进行平衡与折衷。
2.常用算法
数据结构通常都和算法一起出现，但算法表达的是动态特性，而数据结构表达的是一种静态的结构特性
数组 Array链表 Linked List队列 Queues堆栈 Stacks散列 Hashes集合 Sets
基础结构
树 Trees图 Graphs
不属于基础结构，但在现实中有非常广泛的直接映射场景
3.数据结构
掌握
SQL 关系型数据库（如：MySQL、Oracle）
NoSQL 非关系型数据库（如：HBase、MongoDB）
Cache 缓存（如：Redis、Memcached）
广泛流行的数据存储系统有下面三类：
如何用？在什么场景下，用什么数据存储的什么特性？
它们是如何工作的？
如何优化你的使用方式？
它们的量化指标，并能够进行量化分析？
按了解的深度需要依次知道如下几点：
1.数据存储
开发与测试这两种相反视角的切入维度，能真正长期地提高你写代码的效率和水平。
2.测试方法
像 Java 这么多年下来，逐渐形成了一种基于 Maven 的代码组织结构规范，这种约定俗成的代码结构规范省却了很多没必要的沟通
代码结构
相对没那么标准化。但为了写出更清晰、易读的代码，我们至少要坚持自己写的代码具有某种一致性的风格
另外，除了风格问题，也可以借助静态代码检查工具来规避一些新手爱犯的低级错误，而老手也可以通过这些工具来找到自己的认知与习惯盲点。
代码风格
3.工程规范
每个实践敏捷的开发团队，估计都会根据自己的理解和摸索建立一整套逐渐约定成型的开发流程规范。
而为了和团队其他成员更好地协作，估计每个新加入团队的成员都需要了解团队演进形成的开发流程规范。
先了解，再优化。
4.开发流程
源码管理工具经历了从 CVS 到 SVN 再到 Git 的变迁
并行：以支持多特性，多人的并行开发
协作：以协调多人对同一份代码的编写
版本：以支持不同历史的代码版本切换
管理的最基本的诉求
5.源码管理
了解
红色区域相对更小而聚焦，是需要掌握的部分，要求深度；
蓝色区域的部分更广而泛，需要广度。
解释
如图所示
03讲初程：带上一份技能地图
知识、见识和能力的积累与相应价值的变现，理论与现实的对比可能如下图
无论怎样，要想获得拐点出现的机遇，可能你也只能持续努力地积累下去。
04讲初感：别了校园，入了江湖
把一种想法、一个需求变成代码，这叫 “实现”，而在此之前，技术上有一个过程称为设计，设计中有个特别的阶段叫 “架构”。
概念
软件系统的结构与行为设计
架构
而实现就是围绕这种已定义的宏观结构去开发程序的过程。
实现
是什么
高维度：指系统、子系统或服务之间的切分与交互结构。
中维度：指系统、服务内部模块的切分与交互结构。
低维度：指模块组成的代码结构、数据结构、库表结构等。
从定义上，你已知道架构是一种结构设计，但它同时可能存在于不同的维度和层次上：
1.确定边界：划定问题域、系统域的边界。
2.切分协作：切分系统和服务，目的是建立分工与协作，并行以获得效率。
3.连接交互：在切分的各部分之间建立连接交互的原则和机制。
4.组装整合：把切分的各部分按预期定义的规则和方法组装整合为一体，完成系统目标。
在不同规模的团队中，存在不同维度的架构师，但不论工作在哪个维度的架构师，他们工作的共同点包括下面4个方面：
架构师的交付成果是一整套决策流，文档仅仅是交付载体
选型评估
程序设计
执行效率
稳定健壮
维护运维
集成部署
这个过程考虑的6个方面
实现一个功能，可能全部自己徒手做，也可能选择一些合适的库或框架，再从中找到需要的API。
逻辑，即功能的业务逻辑，反映了真实业务场景流程与分支，包含大量业务领域知识。
控制，即考虑业务逻辑的执行策略，哪些可以并行执行，哪些可以异步执行，哪些地方又必须同步等待结果并串行执行？
数据，包括数据结构、数据状态变化和存取方式。
确定了合适的选型后，需要从逻辑、控制与数据这三个方面进一步考虑程序设计：
需要运行多长时间？要求的最大等待响应时间能否满足？并发吞吐能力如何？
运行的稳定性和各种边界条件、异常处理是否考虑到了？
上线后，出现 Bug，相关的监控、日志能否帮助快速定位？
是否有动态线上配置和变更能力，可以快速修复一些问题？新上线版本时，你的程序是否考虑了兼容老版本的问题等？
开始编码实现时，你进一步要考虑代码的执行效率
如果是提供一个程序库，则需要考虑相关的依赖复杂度和使用便利性，以及未来的升级管理
如果是提供服务，就需要考虑服务调用的管理、服务使用的统计监控，以及相关的 SLA 服务保障承诺。
最后你开发的代码是以什么形态交付？
实现功能为例子
而完成的每一行代码，都包含了上面这些方面的考虑，而这些方面的所有判断也是一整套决策流，然后固化在了一块块的代码中。
“实现”作为一个过程，就是不断地在交付代码流
实现的最终交付物是程序代码
因为实现是围绕架构来进行的，所以架构的决策流在先
一定程度上决定了实现决策流的方向与复杂度，而架构决策的失误，后续会成倍地放大实现的成本。
实现和架构的关系
做什么
表达系统的混乱程度。
软件系统或架构，不像建筑物会因为时间的流逝而自然损耗腐坏，它只会因为变化而腐坏。
一开始清晰整洁的架构与实现随着需求的变化而不断变得浑浊、混乱。这也就意味着系统的“熵”在不断增高。
系统只要是活跃的，“熵”值就会在生命周期中不断波动。
需求的增加和改变，就是在不断增加“熵”值（系统的混乱程度）
但软件系统的“熵”有个临界值，当达到并超过临界值后，软件系统的生命也基本到头了
这时，你可能将迫不得已采取一种行动：重写或对系统做架构升级。
熵值的生命周期
而实现中重构与优化的动作则是在不断进行减“熵”，作出平衡，让系统的“熵”值在安全的范围内波动。
架构的核心关注点:熵
是简单、简洁、简明、简化，都是在做减法，但不是简陋
架构关注复杂度的变化，自然就会带来简化，而实现则应当顺着把“简”做到极致。
实现的核心关注点:简
关注点
架构与实现之间，存在一条鸿沟，这是它们之间的断裂带。
当系统规模足够大了，没有任何架构师能够把控住全部的细节
但在我发现和掌握的所有细节中，我需要做一个判断，哪些细节上的问题会是战略性的，而我有限的时间和注意力，必须放在这样的战略性细节上
而其他大量的实现细节也许和我想的不同，但只要没有越出顶层宏观结构定义的边界即可。
系统是活的，控制演化的方向是可行的，而妄图掌控演化过程的每一步是不现实的。
关注与把控边界，这就比掌控整个领地的范围小了很多，再确认领地中的战略要地，那么掌控的能力也就有了支撑。
架构与实现的鸿沟会始终存在，在这条鸿沟上选择合适的地方建设桥梁，建设桥梁的地方必是战略要地。
方法
断裂带
任何架构的可实现性，是完全等效的，但实现本身却不是等效的，对不同的人或不同的团队可实现性的可能、成本、效率是绝对不等效的。
架构升级，仅仅是一次系统的重新布局与规划，成本和效率的重新计算与设计，“熵”的重新分布与管理
等效性
架构是关注系统结构与行为的决策流，而实现是围绕架构的程序开发过程
架构核心关注系统的“熵”，而实现则顺应“简”
架构注重把控系统的边界与 “要塞”，而实现则去建立 “领地”
所有架构的可实现性都是等效的，但实现的成本、效率绝不会相同。
沟通问题：如信息传递障碍。
水平问题：如技术能力不足。
态度问题：如偷懒走捷径。
现实问题：如无法变更的截止日期（Deadline）。
架构和实现之间有一条断裂带，而让架构与实现分道扬镳的原因有
总结
05讲架构与实现：它们的连接与分界
在具体的实践中抽象出模式的思维。
从具体到抽象之间切换的思维模式
设计模式描述了抽象的概念，也就在代码层面引入了抽象，它会导致代码量和复杂度的增加。
而衡量应用设计模式付出的代价和带来的益处是否值得，这也是程序员 “火候” 能力另一层面的体现。
注意
当你解决了一个前人从没有解决的问题，并把解决套路抽象成模式，你就创造了一招新的 “武功”，后来的追随者也许会给它起个新名字叫：某某模式
设计模式
现在的编程活动中，已是大量应用框架，而框架就像是给程序员定制的开发脚手架
一个框架是一个可复用的设计组件，它统一定义了高层设计和接口，使得从框架构建应用程序变得非常容易
因此，框架可以算是打开“快速开发”与“代码复用”这两扇门的钥匙。
依赖的jar包多
如今，框架带来的束缚在于，同一个问题，会有很多不同框架可供选择。如何了解、评估、选择与取舍框架，成了新的束缚。
通用则意味着至少要适用于大于两种或以上的场景，场景越多我们的选择和取舍成本越高
通用意味着抽象度更高，而现实是越高的抽象度，越不容易被理解
缺点
框架，既是钥匙，也是枷锁，既解放了我们，也束缚着我们。
开发框架
，它们都提供了一种问题的重用解决方案。其中，框架是代码复用，模式是设计复用。
共同点
软件开发是一种知识与智力的活动，知识的积累很关键。
框架采用了一种结构化的方式来对特定的编程领域进行了规范化，在框架中直接就会包含很多模式的应用、模式的设计概念、领域的优化实践等，都被固化在了框架之中
框架是程序代码
框架
而模式是关于这些程序代码的知识
模式
区别
两者关系
程序员就像是圣斗士，框架是“圣衣”，模式是“流星拳“，但最重要的还是自身的“小宇宙”啊。
06讲模式与框架：它们的关系与误区
组成、交互和部署图更多是表达系统的宏观视图：关注系统组合、协作和依存的关系
还缺乏关于系统设计或实现本身的表达，这就引出了流程和状态两类视图。
组成视图，表达了系统由哪些子系统、服务、组件部分构成。
单一化：每个服务提供单一内聚的功能集。
正交化：任何一个功能仅由一个服务提供，无提供多个类似功能的服务。
每一类服务提供逻辑概念上比较相关的功能，而每一个微服务又按照如下两大原则进行了更细的划分：
分析
用于帮助团队理解整体系统的宏观组成，以及个人的具体工作内容在整个系统中的位置。
作用
组成视图
表达了系统或服务与外部系统或服务的协作关系，也即：依赖与被依赖。
如果我们把目光聚焦在一个服务上，以其为中心的表达方式，就体现了该服务的依赖协作关系
所以，可以从不同服务为中心点出发，得到关注点和细节更明确的局部交互细节图，而这样的细节图一般掌握在每个服务开发者的脑中。
当我们需要写关于某个服务的设计文档时，这样的局部细节交互图也应该是必不可少的。
思路分析
在逻辑的层面了解了服务间的协作与交互后，则需要更进一步了解这些服务的部署环境与物理结构。
扩展
交互视图
表达系统的部署结构与环境。
部署视图，从不同的人员角色出发，关注点其实不一样
部署视图本身也可以从不同的视角来画，这取决于你想强调什么元素。
上面这张示例图，强调的是应用部署的 IDC 及其之间的网络关系，和一些关键的网络通讯延时指标。因为这些内容可能影响系统的架构设计和开发实现方式。
视角分析
部署视图
组成部分
宏观试图
表达系统内部实现的功能和控制逻辑流程。
可能有人喜欢用常见的流程图来表达系统设计与实现的流程，但我更偏好使用 UML 的序列图，个人感觉更清晰些。
实现方式
流程视图
表达系统内部管理了哪些状态以及状态的变迁转移路径。
所有的业务系统都一定会有状态，因为那就是业务的核心价值，并且这个系统只要有用户使用，用户就会产生行为，行为导致系统状态的变迁
比如，IM 中用户发出的消息，用户的上下线等等都是行为引发的状态变化
原因
但无状态服务相比有状态的服务和系统要简单很多，一个系统中不是所有的服务都有状态，只会有部分服务需要状态
我们的设计仅仅是围绕在，如何尽可能地把状态限制在系统的有限范围内，控制其复杂性的区域边界。
无状态服务
状态试图
07讲多维与视图：系统设计的思考维度与展现视图
是实现需求的业务逻辑代码，反映真实业务场景，包含大量领域知识。
把功能代码写好，最难的不是编码本身，而是搞清楚功能背后的需求并得到正确的理解。
用户心理诉求 -> 用户表达需求 -> 产品定义需求 -> 开发实现 -> 测试验证 -> 上线发布 -> 用户验收
为什么搞清楚用户需求很困难？
困难
微信里有个功能叫：消息删除
消息发错了，不想对方收到。
消息发了后，不想留下发过的痕迹，但期望对方收到。
消息已发了，对于已经收到的用户就算了，未收到的最好就别收到了，控制其传播范围。
功能
是控制业务功能逻辑代码执行的代码，即业务逻辑的执行策略。
控制代码，都是与业务功能逻辑不直接相关的，但它们和程序运行的性能、稳定性、可用性直接相关
编程领域熟悉的各类设计模式，都是在讲关于控制代码的逻辑。
现今分布式领域流行的微服务架构，各种架构模式和最佳实践也开始出现在各类开源组件中
比如微服务架构模式下关注的控制领域，包括：通信、负载、限流、隔离、熔断、异步、并行、重试、降级。
通用控制型代码由各种开源框架来提供，程序员就被解放出来专注写好功能业务逻辑
应用场景
以上每个领域都有相应的开源组件代码解决方案，而进一步将控制和功能分离的 “服务网格（Service Mesh）” 架构模式则做到了极致
控制和功能代码甚至运行在了不同的进程中。
案例
提供一项服务，功能代码满足了服务的功能需求，而控制代码则保障了服务的稳定可靠。
有了控制和功能代码，程序系统终于能正常且稳定可靠地运行了，但难保不出现异常，这时最后一类 “运维” 型代码便要登场了。
控制
就是方便程序检测、诊断和运行时处理的代码。它们的存在，才让系统具备了真正工业级的可运维性。
最常见的检测诊断性代码，应该就是日志了，打日志太过简单，因此我们通常也就疏于考虑。
运维
功能、控制、运维，三类代码，在现实的开发场景中优先级这样依次排序
span style=\
而一个满足工业级强度的程序系统，这三类代码，一个也不能少。
三者的关系
08讲代码与分类：工业级编程的代码分类与特征
按 “数量” 组的评定标准，他们似乎应该忙于粗制滥造大量的陶器呀
但实际情况是他们每做出一个垃圾作品，都会吸取上一次制作的错误教训，然后在做下一个作品时得到改进。
数量
一开始就追求完美的作品，他们花费了大量的时间从理论上不断论证如何才能做出一个完美的作品
而到了最后拿出来的东西，似乎只是一堆建立在宏大理论上的陶土。
品质
很显然，“品质” 组的同学一开始就在追求理想上的 “好与精益” ，而 “数量” 组同学的完成方式则似我早期堆砌代码时的“多与粗放”
但他们正是通过做得多，不断尝试，快速迭代 ，最后取得到了更好的结果。
多与粗放
编程，其实一开始哪有什么完美，只有不断变得更好。
好不是完美，好是一个过程，一个不断精益化的过程。
好与精益
09讲粗放与精益：编程的两种思路与方式
增加不必要的复杂性外，炫技的代码，也可能更容易出 Bug。
炫技
其实对于新技术，即使从我知道、我了解到我熟悉、我深谙，这时也还需要克制，要等待合适的时机。
克制的编码，是每次写完代码，需要去反思和提炼它，代码应当是直观的，可读的，高效的。
克制的代码，是即使站在远远的地方去看屏幕上的代码，甚至看不清代码的具体内容时，也能感受到它的结构是干净整齐的，而非 “意大利面条” 似的混乱无序。
克制的重构，是每次看到 “坏” 代码不是立刻就动手去改，而是先标记圈定它，然后通读代码，掌握全局，重新设计，最后再等待一个合适的时机，来一气呵成地完成重构。
编程方式
克制
克制是不要留下多余的想象，是不炫技、不追新，且恰到好处地满足需要，是一种平实、清晰、易懂的表达
句话是这么说的：“看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水。”
转了一圈回来，机锋尽敛，大巧若拙，深在深处，浅在浅处。
克制与炫技，匹配与适度，代码的技术深度未必体现在技巧上
10讲炫技与克制：代码的两种味道与态度
编程，是把用自然语言描述的现实问题，转变为用程序语言来描述并解决问题的过程；
背景
刚开始写代码，对语法掌握得不熟，对各种库和 API 不知道，不了解，也不熟悉
一路写代码，翻翻书，查查 Google，搜搜 API 文档，好不容易写完一段代码，却又不知道能否执行，执行能否正确等等
现状
如果出错了，是在哪一步开始或哪个变量出错的？
一段不到一屏的代码，足足单步走了半小时，反复改了好几次，终于顺利执行完毕，按预期输出了执行结果。
小心翼翼地点击 Debug 按钮开始了单步调试之旅，一步步验证所有的变量或执行结果是否符合预期。
阶段一：调试代码 Debugging
翻译讲究 “信、达、雅”，编码亦如此。
指不违背原文，不偏离原文，不篡改，不增不减，要求准确可信地表达原文描述的事实。
虽然需求很多时候来自于需求（产品）文档，但需求（产品）文档上写的并不一定真正体现了用户的原始需求
只有真正挖掘并理解了用户的原始需求，最后通过编程实现的程序系统才是符合 “信” 的标准的。
因为要做到 “信” 的标准，编写行业软件程序的程序员需要在一个行业长期沉淀，才能慢慢搞明白用户的真实需求。
这条应用在编程上就是：程序员需要深刻地理解用户的原始需求
信
指不拘泥于原文的形式，表达通顺明白，让读者对所述内容明达。
这条应用在编程上就是在说程序的可读性、可理解性和可维护性。
只满足 “信” 这一条的程序虽然能准确地满足用户的需要
但没有 “达” 则很难维护下去。
所有关于代码规范和风格的编程约束都是在约定 “达” 的标准。
一些流行建议的解决方案是：多沟通，深入理解别人的代码思路和风格，不要轻易盲目地修改
但这些年实践下来，这个方法在现实中走得并不顺畅。
解决方案一
每个服务对应一个唯一的负责人（Owner）
长期由一个人来维护的代码，就不会那么容易腐烂，因为一个人不存在沟通问题
而一个人所能 “达” 到的层次，完全由个人的经验水平和追求来决定。
解决方案二
做法
达
指选用的词语要得体，追求文章本身的古雅，简明优雅。
雅的标准，应用在编程上已经从技艺上升到了艺术的追求，这当然是很高的要求与自我追求了，难以强求
而只有先满足于 “信” 和 “达” 的要求，你才有余力来追求 “雅” 。
雅
同一个方法，实现完全一样的功能，都符合 “信” 的要求
而方法很短小，命名也完全符合规范，可理解性和维护性都没问题，符合 “达” 的要求；
差别就在对 “雅” 的追求上。
该方法的目标是生成一个字符串 key 值，传入两个参数：服务名和方法名
然后返回 key 值，key 的长度受外部条件约束不能超过 50 个字符
先 key 由固定的头（head）+ service（全类名）+ method（方法）组成，若小于 50 字符，直接返回。
若超过 50 字符限制，则去掉包名，保留类名，再判断一次，若此时小于 50 字符则返回。
若还是超过 50 字符限制，则连类名一起去掉，保留头和方法再判断一次，若小于 50 字符则返回。
最后如果有个变态长的方法名（46+ 个字符），没办法，只好暴力截断到 50 字符返回。
具体逻辑
流程
代码示例
这个业务规则只有 4 个判断，实现进行了三次 if 语句嵌套，还好这个方法比较短，可读性还不成问题。
问题
优化方法
从嵌套变成了顺序逻辑，这样可以为未来的程序员留下更优雅地编程惯性方向。
阶段二：编写代码 Coding
编程相对翻译，其超越 “信、达、雅” 的部分在于：翻译出来的文字能让人读懂，读爽就够了；但代码写出来还需要运行，才能产生最终的价值。
并且写出来的代码要符合 “信、达、雅” 的标准
但清晰定义 “多快多好” 则是指运行时的效率和效果
代码的运行效率和效果
写程序又快又好
延迟数字
只有深刻记住并理解了程序运行各环节的效率数据，你才有可能接近准确地评估程序运行的最终效果
当然，上面这张图只是最基础的程序运行效率数据，实际的生产运行环节会需要更多的基准效率数据才可能做出更准确的预估。
曾经我所在团队的一个高级程序员和我讨论要在所有的微服务中引入一个限流开源工具
这对于他和我们团队都是一个新东西，如何进行引入后线上运行效果的评估呢？
需求
第一步，他去阅读资料和代码搞懂该工具的实现原理与机制并能清晰地描述出来
第二步，去对该工具进行效果测试，又称功能可用性验证
第三步，进行基准性能测试，或者又叫基准效率测试（Benchmark），以确定符合预期的标准。
分析步骤
上图中有个红色字体部分，当阀值设置为 100 万而请求数超过 100 万时，发生了很大偏差
这是一个很奇怪的测试结果，但如果心里对各种基准效率数据有谱的话，会知道这实际绝不会影响线上服务的运行。
因为我们的服务主要由两部分组成：RPC 和业务逻辑
而 RPC 又由网络通信加上编解码序列化组成。服务都是 Java 实现的，而目前 Java 中最高效且吞吐最大的网络通信方式是基于 NIO 的方式
而我们服务使用的 RPC 框架正是基于 Netty（一个基于 Java NIO 的开源网络通信框架）的。
做完上述三步，他拿出一个该工具的原理性描述说明文档，一份样例使用代码和一份基准效率测试结果，如下：
测试人员做的性能测试都是针对真实业务综合场景的模拟，测试的是整体系统的运行；
而基准测试是开发人员自己做来帮助准确理解程序运行效率和效果的方式，当测试人员在性能测试发现了系统的性能问题时开发人员才可能一步步拆解根据基准测试的标尺效果找到真正的瓶颈点，否则大部分的性能优化都是在靠猜测。
基准测试和测试人员做的性能测试的区别
阶段三：运行代码 Running
11讲三阶段进化：调试，编写与运行代码
技术性 Bug 可以从很多维度分类，而我则习惯于从 Bug 出现的 “时空” 特征角度来分类。
环境，即程序运行时的空间与依赖。
人有时换了环境，会产生一些从生理到心理的过敏反应，程序亦然
运行环境发生变化，程序就出现异常的现象，我称其为 “程序过敏反应”。
程序编写缺乏对环境问题的考虑，引发了故障。
环境过敏
应对环境过敏，自然要先从了解环境开始。
比如，服务端运行的环境，一般都在数据中心（IDC）机房内网中，相对受控
而客户端运行的环境是在用户的设备上，存在不同的品牌、不同的操作系统、不同的浏览器等等，多种多样，不可控。
不同的程序部署和运行的环境千差万别，有的受控，有的不受控
环境那么复杂，你需要了解到何种程度呢？
至少必须关心与程序运行直接相关联的那一层环境
而 JVM 可能是运行在 Linux 操作系统或者是像 Docker 这样的虚拟化容器中
那么 Linux 或 Docker 这一层，理论上你的关心程度就没太多要求，当然，学有余力去了解到这一层次，自是更好的。
以后端 Java 程序的运行为例，Java 是运行在 JVM 中，那么 JVM 提供的运行时配置和特性就是你必须要关心的一层环境了
但网络本身也有很多层次，而对于在网络上面开发应用程序的你我来说，可以把网络模糊抽象为一个层次
只用关心网络距离延时，以及应用程序依赖的具体平台相关网络库的 I/O 特性。
同理，现今从互联网到移动互联网时代，几乎所有的程序系统都和网络有关，所以网络环境也必须是你关心的
应对之道
不仅仅局限于相关直接依赖环境的配置和参数，也包括用户输入的一些数据
在收集了足够的信息后，你才能编写这样的代码，因为现实中，程序最终会运行在一些一开始你可能没考虑到的环境中
收集到了这样的环境信息，你才能写出针对这种环境的 “抗过敏代码”。
这样的场景针对客户端编程特别常见，比如客户端针对运行环境进行的自检测和自适应代码。
检测和适应范围包括：CPU、网络、存储、屏幕、操作系统、权限、安全等各方面，这些都属于环境抗过敏类代码。
收集信息
空间即环境，包括了程序的运行和依赖环境；环境是多维度、多层次的，你对环境的理解越全面、越深入，那么出现空间类 Bug 的几率也就越低
对环境的掌控有广度和深度两个方向，更有效的方法是先广度全面了解，再同步与程序直接相连的一层去深度理解，最后逐层深入，“各个击破”。
空间维度
12讲Bug的空间属性：环境依赖与过敏反应
Bug 有了时间属性，Bug 的出现就是一个概率性问题了，它体现出如下特征。
周期性的 Bug，虽然乍一看很难解决的样子，但它总会重复出现，就像可以重新倒带的 “案发现场”，找到真凶也就简单了。
案例中这个 Bug 隐藏的时间很长，但它所暴露出的周期特点很明显，解决起来也就没那么困难。
其实主要麻烦的是那种这次出现了，但不知道下次会在什么时候出现的 Bug。
难点
周期特点
没有规律性的 Bug，才是让人抓狂的。
而更好的办法就应该是采用工具，直接引入代码 Profiler 等性能剖析工具，就可以准确地找到有性能问题的代码段，从而避免了看似有理却无效的猜测。
面对非规律性的 Bug，最困难的是不知道它的出现时机，但一旦找到它重现的条件，解决起来也没那么困难了。
非规律性
能称得上神出鬼没的 Bug 只有一种：海森堡 Bug（Heisenbug）。
海森堡 Bug 的出现场景通常都是和分布式的并发编程有关
一方面很少有机会碰到，另一方面随着你编程经验的增加，掌握了很多编码的优化实践方法，也会大大降低撞上海森堡 Bug 的几率。
神出鬼没
每一个 Bug 都是具体的，每一个具体的 Bug 都有具体的解法。但所有 Bug 的解决之道只有两类：事后和事前。
事后，就是指 Bug 出现后容易捕捉现场并定位解决的，比如第一类周期特点的 Bug
事后
但对于没有明显重现规律，甚至神出鬼没的海森堡 Bug，靠抓现场重现的事后方法就比较困难了。
针对这类 Bug，更通用和有效的方法就是在事前预防与埋伏。
事前
运维代码，它们提供的一种能力就像人体血液中的白细胞，可以帮助发现、诊断、甚至抵御 Bug 的 “入侵”
而为了得到一个更健康、更健壮的程序，运维类代码需要写到何种程度，这又是编程的 “智慧” 领域了，充满了权衡选择。
运维代码
13讲Bug的时间属性：周期特点与非规律性
写程序时，我们是在进行一项高级的复杂任务：将复杂的需求或产品逻辑翻译为程序逻辑，并且还要补充上程序固有的非业务类控制逻辑
因而，一旦我们完成了程序，再来复审写好的代码，这时我们预期的逻辑含义都预先存在于脑中，同样也就容易忽略掉某些视觉感官表达上的问题。
从进化角度看，粗心写错别字，还看不出来，不是因为我们太笨，而恰恰还是进化上的权衡优化选择。
1.1 粗心大意
认知盲区，我以为的和真正的现象之间的差异一度让我困惑不解。
1.2 认知偏差
熵增，是借用了物理热力学的比喻，表达更复杂混乱的现象
程序规模变大，复杂度变高之后，再去修改程序或添加功能就更容易引发未知的 Bug。
后端系统的高度复杂性和耦合作用导致即使增加一些小功能特性，也可能带来巨大的牵连影响，所以一个小改动才需要数月时间。
我们不断进行架构升级的本质，就在于随着业务和场景功能的增加，去控制住程序系统整体 “熵” 的增加
而复杂且耦合度高（熵很高）的系统，正是容易滋生 Bug 的温床。
1.3 熵增问题
1. 重蹈覆辙
可以通过开发规范、代码风格、流程约束，代码评审和工具检查等工程手段来加以避免。
甚至相对写错别字，代码更进一步，通过补充单元测试在运行时做一个正确性后验，反过来去发现这类我们视而不见的低级错误。
粗心大意
一般没什么太好的自我发现机制，但可以依赖团队和技术手段来纠偏。
每次掉坑里爬出来后的经验教训总结和团队内部分享，另外就是像一些静态代码扫描工具也提供了内置的优化实践，通过它们的提示来发现与你的认知产生碰撞纠偏。
认知偏差
业界不断迭代更新流行的架构模式就是在解决这个问题
比如，微服务架构相对曾经的单体应用架构模式，就是通过增加开发协作，部署测试和运维上的复杂度来换取系统开发的敏捷性
在协作方式、部署运维等方面付出的代价都可以通过提升自动化水平来降低成本，但只有编程活动是没法自动化的，依赖程序员来完成，而每个程序员对复杂度的驾驭能力是有不同上限的
微服务本质上就是将一个大系统的熵增问题，局部化在一个又一个的小服务中
而每个微服务都有一个熵增的极限值，而这个极限值一般是要低于该服务负责人的驾驭能力上限的。
对于一个熵增接近极限附近的微服务，服务负责人就需要及时重构优化，降低熵的水平
而高水平和低水平程序员负责的服务本质差别在于熵的大小。
而熵增问题若不及时重构优化，最后可能会付出巨大的代价。
丰田曾陷入的 “刹车门” 事件，就是因为其汽车动力控制系统软件存在缺陷
非常业余的结构设计
不符合软件开发规范
对关键变量缺乏保护
缺陷
第一类属于熵增问题，导致系统规模不断变大、变复杂，结果驾驭不了而失控
第二类属于开发过程的认知与管理问题
第三类才是程序员实现上的水平与粗心大意问题
问题原因
熵增问题
2.1 优化方法
建立和维护有利于程序员及时暴露并修正错误
挑战权威和主动改善系统的低权力距离文化氛围，这其实就是推崇扁平化管理和 “工程师文化” 的关键所在
一旦系统出了故障非技术背景的管理者通常喜欢用流程、制度甚至价值观来应对问题
而技术背景的管理者则喜欢从技术本身的角度去解决当下的问题
我觉着两者需要结合，站在更高的维度去考虑问题
规则、流程或评价体系的制定所造成的文化氛围，对于错误是否以及何时被暴露，如何被修正有着决定性的影响。
2.2 塑造环境
2. 吸取教训
世界上不存在不犯错误的学习或行事方式，只是我们可以通过学习，比其他人少犯一些错误，也能够在犯了错误之后，更快地纠正错误
但既要过上富足的生活又不犯很多错误是不可能的。实际上，生活之所以如此，是为了让你们能够处理错误
真理
14讲Bug的反复出现：重蹈覆辙与吸取教训
马斯洛的经典金字塔图：需求层次模型
在人生的早期，我们努力学习，考一个好大学，拥有一技之长，找一份好工作，带来更高薪的收入
这很大程度都是为了满足图中最底层的生存需求，让生活变得更舒适美好。
第一层次
成长拼搏数年，事业小成，工作稳定，有房，有车，有娃后，第二层次，也就是安全的需求开始凸显。
有人在这阶段开始给自己、父母、老婆、孩子都买人寿保险，开始考虑理财，投资甚至强身健体
然而处在这个阶段时，我却有一种强烈的不安全感，这也许和长年的程序员职业经历养成的习惯也有关系。
我们做系统应用服务时总是需要考虑各种意外和异常事件发生，一般至少提供主备方案
主，指当前支撑生活的工作
备，是通过持续学习，同步成长，保持核心能力的不断积累与时间的付出来获得一份备份保障
以避免 “主” 出现意外时，“备” 的能力已被时代淘汰。
于人生而言，保持持续学习，与时俱进，追求成长，这其实也是一种主备方案：
第二层次
需求金字塔底部两层属于物质层次的 “经济基础”，而再往上则进入了更高精神层次的 “上层建筑”
就个体而言，高层次需求要比低层次需求具有更大的价值。
在 “生存” 和 “安全” 基本满足的保障基础之上，我们才会更从容地向内求，更多地探求内心，进而向外索，对外去探索、发现和建立不同的圈层关系，以满足上层的社交 “归属”、获得 “尊重” 与 “自我实现” 的需求。
第三层次
马斯洛把底层的四类需求：生存、安全、归属、尊重归类为 “缺失性” 需求，它们的满足需要从外部环境去获得。
而最顶层的“自我实现” 则属于 “成长性” 需求。成长就是自我实现的过程，成长的动机也来自于 “自我实现” 的吸引
就像很多植物具有天生的向阳性，而对于人，我感觉也有天生的 “自我实现” 趋向性。
第四层次
在人生的不同阶段，会产生不同层次的目标需求。
需求模型
背后的价值观是影响与权力。
代表性关键词有：追逐竞争、改变世界。
高度：
背后的价值观是卓越与智慧
代表性关键词有：专业主义、工匠精神。
深度：
背后的价值观是博爱与和谐。
代表性关键词有：多种角色、丰富平衡。
宽度
背后的价值观是自由与快乐
代表性关键词有：自我认同、精彩程度。
温度
生涯提出了四个维度
个人的人生发展路线都会有这四个维度，只是不同人的偏好、愿望和阶段不同导致了在四个维度分布重心的差异
在不同维度的选择，都代表了不一样的 “生涯”，每一种 “生涯” 都需要一定程度的计划与努力。
虽有四种维度，四个方向，但不代表只能选其一。虽然我们不太可能同时去追求这四个维度，但可以在特定的人生不同阶段，在其中一个维度上，给自己一个去尝试和探索的周期
所以，这就有了选择，有了计划。而计划会有开始，也会有结束，我们需要计划在人生的不同阶段，重点开始哪个维度的追求，以及大概需要持续的周期。
过程
生涯发展
计划，就是做选择，你在为未来的你做出选择，你在选择未来变成 “谁”
如果你还在为今天的自己而后悔，那就该为明天的自己做出计划了。
人生的征程中，先是恐惧驱动，地狱震颤了你，想要逃离黑暗深渊；后来才是愿望驱动，星空吸引了你，想要征服星辰大海。
回首无悔
15讲根源：计划的愿景——仰望星空
富有成效的计划的第一步，便是确定目标。
HARD 目标中的 H 体现了你的兴趣、偏好与心灵深处的内核
就拿写作这个事情来说吧，于我而言，兴趣只是驱动它的一种燃料，而另一种燃料是内心深处的表达欲望。
写作本身不是目标，通过写作去完成一部作品才是目标，就像通过写代码去实现一个系统，它们都是作品，其驱动内核就是一种 “创造者之心”。
Heartfelt 衷心的，源自内心的
而 A 是你对这个目标形成的愿景是否足够清晰，在头脑中是否直接就能视觉化、具象化
就拿我个人来说，我非常喜欢读书，常在夜深人静的时候，默默潜读，掩卷而思，和作者产生一种无声的交流。
这样一种画面，慢慢烙在脑海中，渐渐就激发起了想要拥有一部作品的目标。
Animated 活生生，有画面感的
R 则是由上一篇文章中的马斯洛需求模型层次决定的。
写作一方面本是自带属于第三层次的社交属性，但另一方面更多是一种成长性的自我实现需求在激发。
完成一部作品，需要明确一个主题，持续地写作，一开始我从每月写，到每周写，再到写这个专栏，作品也就渐渐成型。
Required 必须的，需求明确的
而最后的 D 是其难度，决定了目标的挑战门槛。
太容易的目标不值得设定，太难或离你现实太远的目标也不合适。基于现实的边界，选择舒适圈外的一两步，可能就是合适的目标。
于我，从写代码到写作，其实也真就只有那么一两步的距离。
具体分析
Difficult 困难的，有难度的
首字母组成
如其解释，这是一种强调内心愿望驱动的方法
按这个标准，一种源自内心的强烈需求在你头脑中形成很具体的画面感，其难度和挑战会让你感到既颤栗又激动，那么这也许就是一个好目标。
HARD方法
第一个阶段，属于工作的前三、四年，虽然每天都很忙，感觉也充实，一直在低头做事
但突然某一天一抬头，就迷茫了，发现不知道自己要去向哪里，
原来在过去的几年里，虽然充实，但却没有形成自己明确的目标，一直在随波逐流。
1.目标缺乏，随波逐流
在那时，人生的浪花把我推到了彼时彼地，我停在岸边，花了半年的时间重新开始思考方向
当然这样的思考依然逃不脱现实的引力，它顶多是我当时工作与生活的延伸
想要在什么行业，什么公司，写怎样的程序
就这样，渐渐确立了一个模糊的目标。
我知道我还会继续走在程序这条路上，但我开始问自己想要成为一个怎样的程序员
2.目标模糊，走走停停
重新上路，比之前好了不少，虽然当时定的目标不够清晰，但至少有了大致方向，一路也越走越清晰。
模糊到清晰的过程中，难免走走停停，但停下迷茫与徘徊的时间相对以前要少了很多，模糊的目标就像一张绘画的草图，逐渐变得清晰、丰富、立体起来
当目标变得越来越清晰时，步履自然也就变得越发坚定。
3.目标清晰，步履坚定
根据目标的清晰度，大概可以划分为如下三个阶段：
目标
目标是愿望层面的，计划是执行层面的，而计划的方式也有不同的认识维度。
短期：拟定一年内的几个主要事项、行动周期和检查标准。
中期：近 2～3 年内的规划，对一年内不足以取得最终成果的事项，可以分成每年的阶段性结果。
长期：我的长期一般也就在 5～7 年周期，属于我的 “一辈子” 的概念范围了，而 “一辈子” 当有一个愿景。
短期一年可以完成几件事或任务，中期两三年可以掌握精熟一门技能，长期的 “一辈子” 达成一个愿景，实现一个成长的里程碑。
从时间维度，可以拟定 “短、中、长” 三阶段的计划：
Specific 具体的
Measurable 可衡量的
Achievable 可实现的
Relevant 相关的
Time-bound 有时限的
SMART 也是 5 个英文词的首字母缩写：
按 SMART 原则方法使用计划跟踪表的优点是：简单、直接、清晰。
优点
但缺点也明显：即使百分百完成了所有的计划，也都是预期内的，会缺乏一些惊喜感。
从路径维度，订计划可以用一种 SMART 方法，该方法是百年老店通用电气创造的
最后，找到属于你的 HARD 目标，开始有计划且 SMART 的每一天；这样的每一天，走的每一步也许会更重些、累些，但留下的脚印却很深、很长。
16讲方式：计划的方法——脚踏实地
计划的第一个影响因素是和时间有关。
在过去的人类社会生活中，人们已经习惯了以年为单位来进行时间分界，所以我们都会习惯于做年度计划
在个人的时间感觉中，一年，似乎也算是挺长一段时间了，但在过去这么些年的计划与实践中
做计划不能靠模糊的感觉，而是需要精确理性的计算。
经验
其中的 1/3（约 8 小时）会被睡过去了，这里假设一个正常人的生理睡眠需求大约 8 小时。
另一个 1/3 你会贡献到和你的工作有关的各种事项中，虽然国家法律规定了每周只用上 5 天班，每天 8 小时，似乎用不了 1/3 的时间
最后的 1/3 就是我们常说的决定人生的业余 8 小时。
一年，我们到底有多少时间？一个正常参与社会工作的人，时间大约会被平均分成三份
一年 52 周，会有一些法定的长假和个人的休假安排，我们先扣除两周用于休假。
那么一天业余 8 小时，一年算 350 天，那么一年总共有 2800 小时的业余时间
但实际这 2800 小时里还包括了你全部的周末和一些零星的假期，再预扣除每周 8 小时用于休闲娱乐、处理各种社会关系事务等等，那么你还剩下 2400 小时。
这样看来，一年实际能用来计划的时间并不多，需要仔细挑选合理的事项，放进计划表，并真正地执行
而实际，一年中你还需要把时间合理地分配在 “短、中、长” 三种不同周期的计划上。
这2400 小时就是你可以比较自由地用来安排的全部业余时间了，这就是理性计算的结果
计算
短期：完成事项，获取结果，得到即时反馈与成就感（比如：写这个专栏）。
中期：学习技能，实践经验，积累能力（比如：学一门语言）。
长期：建立信念，达成愿景（比如：成长为一名架构师）。
计划
你可以从时间的维度，看看你计划的时间安排是否合理分配在了不同周期的计划事项上。
如果计划的事项和周期匹配错了，计划的执行就容易产生挫败感从而导致半途而废，曾经的我就犯过这样的错误。
判断
要让计划可行，就是选择合适的事项，匹配正确的周期，建立合理的预期，得到不断进步的反馈。
时间与周期
既然时间有限，那该如何选择有限的事项，才可能更有效地被执行下去呢？
有的人兴趣可能广泛些，有的人兴趣可能少一些，但每个人多多少少都会有些个人的兴趣爱好。
其中有一个很重要的因素：兴趣。
兴趣让计划更容易启动，而承诺让计划得以完成。
兴趣与承诺
以为一年之内自己有足够多的自由支配时间；
对计划的事情误判了其开发与成长的周期；
兴趣很多，一直在尝试，却不见有结果。
让计划不可行或半途而废的常见错误有：
放进计划表的事项是你精心识别、选择并做出的承诺
而承诺也是一种负担，若承诺太多，负担可能就太重，会让你感觉自己不堪重负
最后就可能放弃了，到头来又是一场空。
其实，一年下来，重要的不是开启了多少计划，而是完成了几个计划。
有限的时间，适合的周期，兴趣的选择，郑重的承诺
可行的计划应该是：
17讲检视：计划的可行——时间与承诺
计划即选择，而但凡选择就有成本。
从经济学思维的角度，做计划就是做选择，选择了某些事情
而选择了这些事情，就意味着放弃了另外可能做的事情，这里面的成本就是机会成本
机会成本是放弃的代价，选择这些事情从而放弃的其他可能选项中拥有最高价值的事情。
你要敏感地去感知自己时间的成本，去提升时间的价值，根据时间的价值再去调整自己的计划和行动
成长过程中，早期的成本低而选项多，后期的成本高且选项少
而计划，就是对你的时间做分配。时间在不同的阶段，价值不同，那么成本也就不同
计划才能给你真正的自由，你对计划的控制力越强，离自由也就更近了。
成本与机会
计划得到了执行，产生了预期的结果，才会有期望的收益。
第一类人，自己给自己施加约束，保持自律并建立期望；
第二类人，需要外部环境给予其约束和期望。
要获得好的结果，你就要做第一类人，需要对自己有更高的期望，需要有自驱力。
在获得结果的路上，这个世界上似乎有两类人：
专业，自然是指程序专业技能，通过出售自己的时间和人力资源来获取一份相对稳定的工资收入来源。
专业
写作，到今天这个专栏出品后，终于可以通过作品的形式产生直接收益，它只需一次性投入时间来完成作品
而写作，英语给我提供了另外一个更广阔世界的写作素材和看待世界的角度。
写作
而理财属于资产性收益，就是任何等价于钱的家庭动产或不动产，能产生利息、分红或租金的收入，它需要长期的收入结余积累。
至于理财，英语让我更直接高效地接收中文世界以外的信息，从某种角度来说，具备了更多元化的视角和思维结构。
而思维和视角是投资理财的核心能力，在这个领域全是选择题，只有做对选择的概率高于做错的概率，才可能获得正收益。
理财
收益结构
学好英语从我的角度来说，赚取的不是直接的经济收益，而是间接的结构性收益，增强直接收益结构价值。
结果与收益
18讲评估：计划的收获——成本与收益
酝酿期，是计划的早期雏形阶段；这阶段最大的障碍来自内心：理性与感性的冲突。
酝酿
启动期，是计划从静止到运动的早期阶段；这阶段的最大障碍是所谓的“最大静摩擦力”。
启动
执行期，是计划实现过程中最漫长的阶段；这阶段的最大障碍就是容易困倦与乏味。
漫长的坚持过程期，大部分时候都是很无聊、乏味的，因为真实的人生就是这样，并没有那么多戏剧性的故事
真实的生活如图所示
而获得目标与意义的最好方式是讲好一个故事
你看，成功的企业家会把未来的愿景包进一个美好的故事里，让自己深信不疑
然后再把这个故事传播出去，把所有相信这个故事的人聚在一起去追寻这个故事
最后，这个关于未来的故事就这样在现实中发生了。
坚持，特别是长期的坚持，是需要动力的，而动力来自目标和意义
执行
挫败，不是一个阶段，而是坚持路上的一些点；正是在这些点上你遭遇了巨大的挫败感。
为什么会产生挫败感？
一开始你就不知道这件事有多难，直到走了一段后才发现这太难了
一开始就评估清楚一个计划的难度，需要投入大量的时间、经历和金钱，甚或有更高的技能与能力要求，这本身就是一件不容易的事。
原因
遭遇挫败，你会进入一种心情与情绪的低谷，这个时候有很高的概率做出放弃的决策
一般的做法
不要在挫败的情绪低谷期进行任何的选择与决策。可以暂时放下这件事，等待情绪回归到正常，再重新理性地评估计划还是否该坚持。
每经历一次挫败之后，你还选择坚持，那么就已经收获了成长。
建议
挫败
计划的生命周期的各个阶段
19讲障碍：从计划到坚持，再到坚持不下去的时候
一个计划被制定出来后，我们通常会根据它的周期设定一个执行的节奏。
就像长跑，跑五千米是长跑，跑马拉松（四万多米）也是长跑，但我们知道跑五千米和跑拉松肯定是用不同的节奏在跑。
长期的目标
也许是一年。比如，计划用一年时间写一本书，假如一本书 20 万字，那每周大约需要完成 4000 字，再细化到每天就是800 字左右。
这就是我们做一年计划的方式，计划成型后，相应做出分解，分解到周这个级别后，基本的计划节奏就出来了
中期的目标
可能是几个月。比如，我这个 “极客时间” 专栏，计划就是几个月内完成的事情。
短期的目标
所以，你要从心理上接受它，并从行为上合理地应对它。
计划更多是给予预期和方向，去锚定现实的走向，但在行进的过程中，“意外” 难免会出现
计划的节奏
这说明每个人的节奏是不同的，即便同一人在不同阶段的节奏也是不一样。
跑马拉松的时候，一大群人一起出发，最后到达终点时却是稀稀拉拉
他人的节奏
找到并控制好自己的节奏，才能长期匀速地奔跑，才能更高效地利用好自己的时间和注意力。
对于每日计划的执行节奏，我自己的经验是：把自己的时间安排成一段一段的，高度集中和高度分心交叉分布。
自己的节奏
20讲执行：从坚持到持续，再到形成自己的节奏
我们没办法掌握这一切。别说“一切”，其实更符合实际的情况是，我们仅仅掌握了已有信息和知识领域中非常微小的一部分。
在信息大爆炸的时代，我们对信息越发敏锐，信息就越会主动吸引我们，让我们产生一种过载的感觉。
现状：信息过载
在面对这股信息与知识的洪流时，有时我们会不自觉地就进入到了 “疲于奔命”模式中。
而大脑的工作模式就有点像 CPU，而人只要活着，大脑会一直工作，从不停止。
人脑毕竟不是 CPU，它需要休息，持续的过载与奔命，并不能让我们学会更多，但却会减少我们创造新的可能。
状态：疲于奔命
第一点，信息和知识的价值是一个主观的判断，有一个客观点的因子是获取门槛。
如果一个信息或知识随处可得，大家都能接触到，甚至变得很热门，那么其价值可能就不大
吴军老师有一篇文章讲了个道理叫：“众利勿为，众争勿往”，这在对信息和知识价值的主观判断上也是通用的。
信息和知识本身的价值
就提出了一个关于如何筛选信息和知识的问题。心理学上有一个 “心智模型” ：
“心智模型” 是用于解释个体对现实世界中某事所运作的内在认知历程，它在有限的领域知识和有限的信息处理能力上，产生合理的解释。
不过只有少部分人会更理性地认知到这个模型的存在，而且不断通过吸收相关信息和知识来完善这个模型；
更多的众人依赖的是所谓的 “感觉” 和 “直觉”
但实际上 “感觉” 和 “直觉” 也是 “心智模型” 产生的一种快捷方式，只是他们没有理性地认知到这一点。
每个人都有这样的 “心智模型”，用来处理信息，解释行为，做出决策。
我需要怎样的信息和知识
面对大量的信息和知识，我们该如何应对？这可以从两个角度来考虑：
“心” 是你对需要的选择，从心出发；
“智” 是对价值的判断，智力的匹配。
“心智” 这两个字合在一起是一个意思，分开为 “心” 和 “智” 两个字又可以分别解释为
筛选：心智模型
储备了信息，建立了知识，最终都是为了应用。
囤积信息，学习知识，如果不能被应用在改变自己上，那还有什么意义？
没有目的的学习是徒劳的，它仅仅是在我们的头脑中流过一遍，流过的痕迹很快又会被新的信息冲刷干净
长短期记忆，类似 CPU 的多级缓存
它还有一个计算单元，用于任务处理与决策
大脑确实和计算机的 CPU 有很多类似之处，比如它也有一个缓存单元
注意力是一种有限的资源，你要是不擅长不集中注意力，你就不擅长集中注意力。
这就是专注于少而精的东西，深入了解这些东西，进入到更深的层次上
深可以无止境，那到底多深才合适？我的答案是：让你的内心对取得的效果感受到满意的深度层次上。
它的反面是：但凡心存疑虑，不是那么确定要全力投入的事情，干脆就不做了。
你得挑选那些真正值得做和学的东西去让大脑满负荷运转，但凡投入决心去做的事情，就需要百分百投入
应用：一击中的
信息过载是现实；
疲于奔命是陷阱；
心智模型是方法；
一击中的是策略。
最后，总结下在信息爆炸的时代，我们该如何有效处理、吸收和消化信息：
21讲信息：过载与有效
进入任何一个知识领域，都是从一个点开始的。
如下图，是我从大学进入软件开发领域所接触的一系列的点，我将其从左到右按时间顺序排列
在你入行后，我想你可能也会因为时代、公司或项目的原因，有很大的随机性去接触很多不同的技术点
但如果你总是这样被客观的原因驱动去随机点亮不同的 “点”，那么你终究会感到有点疲于奔命，永远追不上技术的浪潮。
点
当形成的点足够多了后，一部分点开始形成线，而另一些点则在技术趋势的演进中被自然淘汰或自己主动战略放弃。
子主题
先自然地要向下至少走一层，接触 Java 的运行平台 JVM
而又因为早期做了几年电信项目，要和很多网络设备（包括各类网元和交换机等）通信，接触网络协议编程；
后来又做了即时消息（IM）领域的工作，网络这一块就又继续增强了
而网络编程依赖于操作系统提供的 I/O 模型和 API，自然绕不过 OS 这一块
在这条 “T线” 上，先向下走，专注于解决业务需求碰到的技术问题
而再从程序员到架构师，就开始往上走，进入更纯粹的 “架构与设计” 领域
在更宽的范围和更高的维度评估技术方案，做出技术决策与权衡，设定技术演进路线。
成长的T形图
再好的技术方案，再完美的架构，如果没有承载更有意义的业务与产品形态，它们的价值和作用就体现不了。
所以不可避免，再往上走时就会去了解并评估 “业务与产品”，关注目标的价值、路径的有效性与合理性。
在整个纵向的技术线上，最终汇总到顶点，会形成一种新的能力，也就是我对这条纵向线的 “掌控力”
到了这个 “点” 后，在这里可以横向发展，如图中，也就有了新的能力域：领导力和组织力。
线
线的交织，将形成面。
六年多在电商客服和即时通讯领域的工作画出来后，
再上升到用户的接入触达，考虑产品的场景、形态和人群是如何去为这些用户提供的服务、产生的价值。
如果很难跳脱出自身环境的局限，那么也可以不局限于技术，去考虑这些传统的业务价值，从技术到业务
面
你的 “面” 附着在什么 “体” 上决定了它的价值上限
如果 “体” 在高速增长并形成趋势，你就可能获得更快的发展。
体是经济体或其中的单元。
从电力时代到信息时代再到智能时代，互联网、电商、移动互联网，这些都是 “体” 的变化
体
在领域知识体系中，“点” 是利器，“线” 是路径，“面” 是地图
而就我们个体而言，“点” 是孤立知识点的学习掌握，而 “线” 是对这些点的连接，“面” 则构成了完整的知识体系网。
22讲领域：知识与体系
我们从学会一个知识，到能够熟练应用其去输出能力，大概会经历如下过程：
所以，对于个体而言，刚建立起一个初步的知识体系，到能真正充分发挥出这个体系的力量，才仅仅是刚开始。
个体
如果说个体的能力输出像出拳，那么团队的输出就像战争了。
一是团队中所有个体形成的体系力量之和
二是由流程规则、工具系统和规范共识共同决定的转化效率。
那么团队的强弱就由两方面决定，
团队能力输出就是这样一个 “机器” 体系运行的过程。
团队
从个体到团队，都是通过搭建体系来积蓄力量，再通过体系的运转来输出能力
这里的共同思维方式是：体系化、工具化。
个体和团队的强弱，一方面取决于我们在体系中积蓄的力量的总量，另一方面在于体系运作的转化输出率
体系决定了力量的总量，而转化决定了拳拳到肉的痛感。
转化
23讲转化：能力与输出
程序员的主要工作是：编程，产出代码，完成需求，交付程序系统。
如：达成品质、优化效率。而在不断晋级的路上，跨越的门槛就在于此，很多人比较容易被卡在不断地在完成工作
但却没有去反思、沉淀、迭代并改进，导致一直停留在了不断重复的怪圈之中。
从初、中级走向高级程序员，就不仅仅是交付代码，完成工作，还要有后续的更高要求。
而从完成到追求品质和完美的路上，不仅仅是靠工作实践的经验积累，还需要有意识地持续学习。
程序员，工作以产出代码为主，从初级到高级，代码的负债属性逐步降低，资产属性不断提升，最终成为高品质的个人贡献者。
工作
持续学习，是让你突破不断循环怪圈的不二法门。
国内: 小时候努力，到大学后就不努力了。
国外: 到大学后才开始努力，很快就超过国内学生。
聚焦于一个技术领域并讲得透彻清晰。
比如，对于 Java 就是《Java 核心技术》或《Java 编程思想》
第一维度的书
聚焦于领域的思想和思路。
比如：《Effective Java》《UNIX 编程艺术》等，这些是聚焦于特定领域经验总结型的书
第二维度的书
不同维度的书
Tutorial（指南） 和 API Reference（应用编程接口参考） 层次的信息资料能帮助你快速上手开发
而 Spec（技术规范）和 Code（源代码）会帮助你深刻地理解这门技术
而其他相关的技术书籍和文章其实是作为一种补充阅读，好的技术书籍和文章应该有官方资料中未涵盖的特定经验或实践才算值得一读。
每一项开源框架或技术相关的学习资料可以组织成下面这张金字塔形的结构图
每当我们接触一项新技术的时候，都要把手头的资料按照类似这样的一个金字塔结构进行分类。如果我们阅读了一些技术博客和技术书籍，那么也要清楚地知道它们涉及到的是金字塔中的哪些部分。
张铁蕾在文中如是说：
关于技术学习我们不能简单地蜻蜓点水、复制粘贴、拿来主义，应是去建立你的知识 “金字塔”，形成体系结构，而每次的学习实践都是在不断完善你的 “金字塔”。
技术的正宗与野路子
学习
保持学习，不断成长，工作也许还在重复，但成长却在迭代上升，然后才会有机会面临更多可选择的路径。
程序员在攀登职场阶梯的道路上，走过了高级，后面还会有好些分叉路线。
比如，转到脱离技术的纯管理岗或者技术管理岗。技术主管或架构师某种意义上都属于技术管理岗，不懂技术是做不了这两个角色的
或者继续沿着深度领域走，成为细分领域专家
面对怎么选路的问题，我近些年学习的收获是这样的：选择走最适合实现个人价值的路
对数增长也意味着更容易退步，因为起步阶段是如此陡峭（见对数曲线示例图）
比如，学习一门新的技能，不持续去应用，很快就忘了，退回原点
那你应该如何应对这种“窘况”呢？
我建议你在起初的高增长阶段，学习和工作的关注点需放在养成长期习惯上，因为虽然开始增长很快
但需要小心一旦停止努力它可能会向下滑落，所以一定要慎之又慎，坚持形成自己的习惯和节奏。
对数增长形态：这种类型在初期增长很快，但随后进展就越发困难；
而指数增长则意味着存在一个拐点的 “突变” 时刻
很多人期望线性增长，但实际却是按指数增长的，这让许多人在拐点发生前就放弃了
比如，写作，在呈指数增长的领域内，到处都是半途而废者。所以，做本质是指数增长曲线的事情时，柔韧且持久的思维模式是关键。
指数增长形态：这种类型在初期增长很慢，但存在积累的复利效应。
任何一个你所尝试提升的事情都有一个增长曲线，这个曲线有两种形态：
关注当前专业领域且十分熟练，但没有显示出在开发新能力上的努力，竭力维持现有技能。
熟练潜能
按需开发新能力，显示出高于当前层级要求的其他技能，如：专业、管理、领导
成长潜能
持续有规律地开发新能力，追求跨层级的挑战和机会，展现雄心壮志。
转型潜能
拉姆·查兰有本书叫《领导梯队》，书里把人才潜能分成三种
成长这条路从来都不是笔直的，你的“奔跑速度”也不会一直是匀速的。在每一个拐弯处，都应减速，思考，学习，然后再加速，进步。
路径
程序员的工作形式是编程产出代码，本质是完成需求，交付系统
但在工作中容易陷入不断完成的循环怪圈，要打破它，就需要你持续学习并有意识地关注交付代码的品质和属性，一方面提升了交付质量，另一方面也获得了个人成长。
而学习的路在时间上是永远持续的，在空间上也是有路径的
有效的学习需要你关注学习曲线的变化，遵循有体系的技术学习框架，匹配适合当前阶段的学习资源。
24讲并行：工作与学习
有时，我们觉得时间过得很慢，慢如从周一到周五；有时，又会觉得时间飞逝，快到十年间一恍惚就过去了。
感知时间
正因为我们对时间的感知非常模糊而不精确，若想更有效率地用好时间，就需要更精确地测量它。
我会记下一年来经历的所有有意义的事件（除去每日的例行工作），我称之为 “时间日志”。
而基于 “事件-时间日志” 的记录可以调整你对时间的感觉。在估算任何工作时，都更容易确定 “真正现实可行的目标”。
是的，这就是关于时间的第一个 “基石” 习惯，在精确地感知与测量时间之后，你才可能更准确地“预知” 未来。
测量时间
25讲时间：塑造基石习惯（上）——感知与测量
为了更有效地利用好你每天有限的时间，就需要你重新审视并调整你的时间切割与构建方式。
转换一下你看待时间的方式，有人把它看作流水，任其从指间溜走，你却可以把它看作石头，用它去塑造什么
将时间切割成建造你心中“大教堂”的合适“石材”。
切割时间
切割了时间，得到了合适的“石材”，你还需要确定适当的构建方式。
比如，好些年前开始，我会从每周的时间里切出来一块，专用于写作，慢慢就形成了写作的习惯。
而适当的构建方式，是指在时间的 “基石” 习惯之上，建立其他的习惯。
第一种，是行动本身固有需要的努力，如跑步，跑一公里和跑十公里固有需要的努力是不等量的
第二种，指决策是否执行这种行动的努力，决定跑一公里还是跑十公里的决策意志力消耗，我想也不会一样。
任何行动的发生，都需要两种努力才有可能
构建习惯的目的，以及它们能起作用的原因在于：它能消除行动中第二种努力的决策消耗。
如果一项行动通过习惯慢慢变成了能力范围之内的事，那么你以后再去做类似的事，其实就不需要再付出什么决策努力了，也就不再需要习惯来帮忙了
所以，在时间 “基石” 习惯之上构建的习惯应该是你能力范围之外的行动。
习惯，它的表象和形式给人的感觉是在重复一件事，但它的内在与核心其实是不断产生交付，持续的交付。
如果你要构建一个习惯，就要运用好基因中本已存在的关于 “采集和狩猎” 的本能：高度专注，跨出边界，持续交付。
习惯
构建方式
要形成时间习惯，要通过有意识的感知和测量来发现时间是怎么流失的。
要完成建设你心中 “大教堂”，要通过切割 “时间原石” 来完成 “时间石材” 的准备。
在养成了时间的基石习惯之上，挑选和构建其他习惯来完成 “大教堂” 的持续建设与交付。
26讲时间：塑造基石习惯（下）——切割与构建
“试一试” 的初衷本来就该是好的，它表达了一种好奇心，以及尝试走出舒适区的勇气。
程序员这个职业，会带来一些职业习惯。比如，可能会经常性地去尝试一些新东西，然后看看它是否如预期般那样被应用或实现。
好的出发点
这里，“试一试”的“坏”习惯的“坏”字之所以加上双引号，就在于它的出发点本是好的，但如果终点是模糊的，那就“坏”了。
它的原理与应用场景；
它的前世今生；
它如今已抵达的边界。
因为，现实中我需要判断一些真实的业务场景该如何结合这样的技术，这就需要了解它们的应用场景和一些原理。
搞清楚这三件事，虽不会让我成为机器学习的专家，但会提升我对于这个热门技术的判断力
另外，一门新技术很少是凭空冒出来的，了解它们的前世今生，会更有效地知道，哪些方面已经有了成熟的方案，哪些地方还在青涩的探索期
再结合它当前的边界，就知道如何定义清楚需要，形成合理的技术方案，而不会产生过度的妄想。
这个部分程序员就很熟悉了，因为编程中的调试其实最重要的目的就是验证猜想
引入一种新技术或框架，验证 API 的调用结果或运行输出是否如你所想，即使最终否决了，那你也获得了判断的依据与知识。
1.验证猜想
定义清楚你尝试的这件事，到底能收获怎样具体的结果。比如：考试，尝试的收获就是要通过。
2.收获结果
有时候结果并不确定，比如，创业的结果未必就一定是成功，那么这样的尝试难道就没有意义了吗？
有的，因为创业的超低成功率，所以，体验过程恐怕多于收获最终结果。
3.体验过程
你尝试一个新东西或学习一个新知识，有时未必真是为了将来有朝一日能用上它，而主要是为了完善你的知识与认知体系，然后再去理解现实为什么是这样的。
4.理解现实
试一试，需要有更清晰的终点。关于终点，你也可以从下面一些方面来考虑：
模糊的终点
“试一试” 的路径是有限的，毕竟终究离不开现实的约束。
从理解的角度，这类技术切换的尝试事实上扩大了你的知识边界，尝试的也许是孤点，但你可以进一步找到它们的连接处，形成体系
因为很多现实的原因，每个人的起点和路径都不会一样，但我们都是从某一点开始去慢慢摸索、尝试，最终走出一个属于自己的体系来的。
最后，当你有了自己的体系，也可能有了更多的尝试选择权，就可以体系为中心，去有选择地尝试对你更有意义或价值的事了。
现实的路径
试一试，是走出舒适区的一次行动，这本是一个好的出发点，但若只有一个模糊的终点，那么它带来的更可能就是无谓的浪费。
验证猜想、收获结果、体验过程、理解现实
而在起点和终点之间，你需要选择一条更现实的路径，通过不断地尝试，走出自己的体系。
试一试，不仅要有一个好的出发点，还需要一个清晰的终点，在这个终点你可能
试一试，本该是个好习惯，可别把它用坏了。
27\b讲试试：一种“坏”习惯
1.如何问？
2.问什么？
3.为何问？
提问这个习惯，我有三个层面的理解：
大部分情况，我们碰到的都是已经有了问题，但却问不好，从而得不到答案或得不到好的答案。
有同学常拿着一个具体的问题跑来，向我发问，他大概会交代一下想解决的场景
然后就会接着描述他的思路，以及解决这个问题的思路的一些其他约束，但这中间会有一个障碍，然后就问我该怎么解决这个障碍
一种是，问题的业务背景交代得太泛化，所以我只好跟着他的思路，感觉解决这个问题似乎只能有这一条路可走；
另一种则正好相反，问题的业务背景描述得过于细致，让人最后陷入对复杂业务领域的理解中，迷失在细节的讨论里
这样的发问一般都会让我陷入两种困扰之中
即使是同一个场景，其实不同人还会产生不同的思路
比如：你想去一个十公里外的地方，对方也许会问你怎么套马鞍的问题，这时你就很困扰，因为你的思路是坐车或开车。
这就是一个针对技术人员面对同一场景问题，所选取的不同技术方案可能处在不同的时代背景下的类比。
案例一
某某出错了，怎么办？
如何针对某某封装一个库？
再看看国内网上技术问答社区的情况，我有时会去看看，发现上面的问题大部分类似下面两种模式：
某某可以是一种具体的技术或框架，这两种提问模式代表了两个方向，都让人无法回答。第一种太模糊而无法回答，而第二种太庞大则不愿回答。
案例二
就具体问题提问，除了问及手段，还最好跟上你的目的和你就此目的是怎样提出的手段，然后才走到了这一步的障碍，让你不得不在此提问的。
如何问
一个能够回答的具体问题，一般都是解答题形式，表达清楚你的解答目的，也许你的困扰在高手那里根本就不存在
你只是走了一个弯路而已，这样不仅绕过了障碍，还获得了一条近（先进的）路，这就是有意义的提问。
提供足够的信息，让人能够回答。
提问的第一个原则
草率的问题是懒惰的问题，通过搜索引擎就能简单获得
草率的问题是模糊的问题，让人没法回答。
而更有意义的提问是把解答题变成选择题，提供你的选项，展现你探索了哪些路径，省去了可能产生的反问。
也许你的某条路径已经非常接近答案了，只是卡在了某个点上，知道答案的人一看就明白了，也很容易回答。
提供更多的选项，让人方便回答。
这就是提问的第二个原则：
即使你的问题能够回答，也方便回答，但也可能得不到回答。因为，回答问题需要有驱动力
提问本是一种索取，要让人有更多的回答动力，还需要付出。付出一种态度，表达感谢；付出一份可供交换的视角，建立讨论的基础。
提供交换价值，建立讨论基础，表达感谢态度，让人乐于回答。
这就是提问的第三个原则
原则
提让人能够回答的问题：草率的问题，只能得到一个草率的答案。
提让人方便回答的问题：你得到的答案的好坏取决于提问的方式和开发答案的难度。
提让人乐于回答的问题：只索取而不愿思考和付出的提问者，要么什么也得不到，要么只会得到 RTFM（Read The Fucking Manual） 或 STFW（Search The Fucking Web）。
最后，我归纳下关于提问之术的三个方面
如何问？提问之术
有时一个好问题，比如何问更有价值和意义。
当遇到暂时没有答案的问题时，先记录下来
问题的上、下文；
问题的具体描述；
问题的解决思考和思路；
问题的解决方案和具体技术或办法；
问题解决后留下的思考或其他延伸的疑问。
把暂时这阶段还没法回答的问题按一种模式记录下来，比如下面这样：
保持积累，持续给予，终有所获。
问什么？求解之惑
选择决定命运，什么来决定选择？价值观。
这就是第三个习惯：为何而问？获得答案，认清自我，选择自己的价值之道。
为何问？价值之道
如何问，是关于提问的 “术”，考虑让人能够回答，方便回答和乐于回答；
问什么，是关于成长的 “惑”，去积累问题，寻找答案，并分享出来，从而完成了价值的积累、传递与交换；
为何问，是关于选择的 “道”，价值观的选择决定了不同的道。
28讲提问：从技术到人生的习惯
因为强加于人，总是容易带来分歧和争论，最终可能好习惯还没机会带来收益，却因为分歧争论直接带来了损失。
习惯最后也许真的变成了大家认同的好方法，一开始也不该以个人的方式直接去强加于人。
但编程中总结出来的一些方法和原则，很多可能就是始于个人习惯，最后逐渐传播并演化形成了普遍共识。
习惯形成
如今，很多约定俗成的代码规范，基本就是从早期一些人的习惯中加以提炼总结出来的，然后形成了大家共同认可的好方法，并在组织层面形成了规范
形成了规范的东西，就不再是从个人习惯的角度去强加于人了，而是大家的共识达成。
遵守设计模式总是能让你少踩坑的，但如何灵活地采用合适的模式又是另一种智慧了。
1.设计模式
约定了术语，总是能让口头的概念和落在代码上的东西保持一致，减少沟通歧义，从而更高效。
2.术语约定
这比任何的代码评审都来得可靠，哪里该写多少测试用例，哪里可以不写，这又是智慧了。
但不要刻意为了追求覆盖率而去写，覆盖率的技术统计方法其实是很唬人的，有些覆盖率很高的项目，该有的 Bug 还是有的。
3.单元测试
对于技术债务，每个月付点“利息”，比好几年后“连本带息”去还要感觉轻松得多
这条的特殊点在于，这可能是大部分程序员都认可的好方法，但却不是大部分人的习惯
因为技术上的债，实在自己还不起，总是可以推脱出去给下个“倒霉的家伙”，但从长远角度看，这样的推脱不会让你获得成长，甚至还会阻碍你的发展。
4.随时重构
一些好的编程规范建议
共识达成
编程中除了好方法，还有些确实只是个人习惯的东西，如果我们不去留心区分，很容易模糊了两者的界限。
比如程序员都不爱写文档，很多人也没有这个习惯，但大家几乎都认同提供规范的设计和接口文档是个好方法，只是因为文档的优先级长期低于完成代码功能从而被搁置了。
分辨反思
在你从程序新人成长起来的过程中，要学会区分，哪些确实是值得学习与推广的好方法，哪些仅仅是自己的个人习惯，特别是在你成长到开始成为技术管理者之后。
但你依然需要去对这些流行的共识进行分辨和反思，看看哪些才是适合你的好方法。若真是好方法，也可以进一步将其培养成自己的习惯。
反过来看，程序行业，编程实践中，存在大量流行的概念、模式、原则，甚至哲学，它们的产生都有其历史背景和过程，并在一定范围内形成了共识
总结来说：
29讲偏好：个人习惯的局限与反思
程序的需求，对应于写作的主题。
你之所以写程序，是因为有人给你提需求；
但你业余的写作，通常就不会有人给你提相关的写作需求或主题了
所以，就需要你自己去主动寻找和发掘你自己的写作需求或主题。
一个好的主题很可能是一篇好文字的开端，毕竟如果一开始产品方向错了，实现得再好又能有多大意义呢？
核心
一、需求
确定了本次写作的主题（需求），接下来就该进入到设计阶段了。
在软件程序系统的设计中，这部分内容主要是架构设计，系统或子系统的拆分、交互逻辑、边界等等
而对于写作而言，这部分对应的就是设计本篇文字的逻辑结构，换言之，即在主题确定的基础上，采用怎样的逻辑去展开主题，形成合适的衔接
1. 概要设计
有了逻辑骨架后，就需要补充真正有血有肉的文字了。
围绕主题想表达的观点，考虑需要添加哪些支撑观点的素材，以及设计整理、引出和排布这些素材的方式。
而为了让文字更有阅读的趣味，还需要有适当的故事，因为人们都喜欢读故事，而非说教，那故事又该如何切入与布局？这也是需要考虑的点。
经过了编程强大且反复的逻辑训练后，对于你、我写作而言，逻辑结构的设计就不该有障碍了，其实最大的差异与障碍可能是在 “实现” 上。
2. 详细设计
程序开发的设计一般分为两个层面
二、设计
写文字和编码在实现层面最大的差异是：实现过程的技能和要求不同。
在实现技能层面，程序是用计算机语言来表达的，文字是用自然语言来表达的。
计算机语言的逻辑性和精确表达能力要比自然语言强得多，自然语言是模糊的、混沌的、不精确的
因此写得一手好程序的人，不一定能写得一手好文字，因为他们需要驾驭的语言的特性完全不同。
而 “招式” 的积累与应用，无论写程序还是写文字，都没有什么捷径可走，只能多看、多写、多练。
写程序和写文章，本是两种不同的 “武功”，“心法” 可以类似，但 “招式” 自不相同。
三、实现
每次写完一篇文章后，就感觉自己好像是被清空了，甚至不再想去读一遍，这时我就会把它“扔”在一边。
而对写完的文字再读一遍，进行再编辑和优化，这就像软件开发中的测试过程
但我需要在一个冷却的状态下进行，站在一个读者或编者的视角去重新审视这篇文章
所以，这个过程通常发生在写作完成后的一天或几天之后。这中间的间隔，我称之为写作后的冷却时间
只有在冷却的状态下，我才能更客观地检视自己写的文字，同时进行合适地编辑和修改，这个过程就是对文字的测试。
时机
文词使用：进一步发现有时作者自己很难发现的错别字和用词的适当性、理解性问题；
逻辑结构：整体文字内容的逻辑结构，衔接过渡是否自然等；
读者感受：站在读者的角度，去考虑其感受以及能够得到的收获；
和 “极客时间” 合作写专栏就给配备了专业的编辑，编辑主要会从下面几个方面进行测试或检查。
四、测试
完成了必要的编辑测试工作后，就到了最终的交付（发布）阶段。
写作本身是一个不断积累压力的过程，而交付之后则完成了一种压力的释放与转换
写作与文字的价值实现分两部分，写完后就完成了对自我的价值实现，而交付后才算完成了对他人的价值实现。
五、交付
30讲写作：写字如编码
对于写作这种展现形式，有一种最好的补充手段就是画图。有时文字描述了半天还不如一张图来得清晰，正所谓：一图胜千言
这对于程序员特别需要的技术性文档或文章写作，都是最好的补充注解，有时甚至起到了画龙点睛的效果。
程序员不是主要写代码的么，为什么需要画图？
“用更系统化的视图去观察和思考，想必也会让你得到更成体系化的系统设计
既然具象化了设计，那么再基于此去沟通交流自是事半功倍
成为架构师之后，你自己明白还不是主要的，要让别人明白才更重要。
而画图对于能力模型中的 “抽象思维” 就起到了一种锻炼，其作用就是帮助你在不同的层次上去思考系统设计，并具象化这个设计
一、为何？
画一个清晰易懂的技术架构或交互流程的说明图例需要什么专门的绘图知识与技巧么？
问题一
另外为了画好图会花费大量的时间么？
问题二
比如：矩形、圆、三角、菱形、气泡、箭头，这些最基本的图形几乎所有的画图软件都会自带的
所以工具的依赖性很低，但真正画时的操作效率却又很高。
画技术图例时只会使用一些最基础的图形
如果有时为了表达和这些著名外部系统间的交互，也会直接使用它们的 Logo 图标
。如下面图示，就是我常用的一些画图图形元素。
一些著名外部系统可能都有各自知名的 Logo 图标
1. 图形
有时系统的组成比较复杂，只用基本图形不足以表达所有不同的系统组成部件，这时就需要用颜色来区分了。
使用饱和度、亮度以及色相区分颜色，确保颜色的高反差，因为人的视觉是为边缘反差而优化的。
使用独特的颜色，因为人最容易区分的颜色包括：红、绿、黄、蓝、白和黑。
避免使用色盲无法区分的颜色对，比如：深红－黑，深红－深绿，蓝色－紫色，浅绿－白色。
使用颜色之外的其他提示，对有颜色视觉障碍的人友好，而且也增强了可理解性。
避免强烈的对抗色，比如：红黑，黄黑。
色彩使用准则
2. 颜色
除了基本的图形和颜色选择之外，另外一个关注点是审美。
我们画的是系统设计图，不是美术设计稿，审美方面的追求就适可而止了。
3. 审美
组成元素
二、如何？
学会使用一种简单的软件，使用简单的图形和配色，在最有效率的情况下画出一幅效果还不错的图例，也是很有价值的。
mac的key note画的
三、几何？
31讲画图：一图胜千言
过去几年，我读过很多的文章、书，但还能记得住只言片语的都非常少
即使当时一些给我非常多启发与触动的文字，如今也只能记得当时触动的感觉，却忘了触动的内容。
写作的展现，是一种广度路线，产生间接、长尾效应
但好些年前，我参加过几次行业大会，有那么几场演讲，现在回想起来，不仅记得当时深受启发的触动感，甚至还能记得当时的内容。
这就是演讲带来的深度效应，它的现场感更立体，有助于留下更深刻的记忆，持续发挥影响的时间也超过了文字。
演讲的展现，是一种深度路线，产生直接、深度连接。
一、价值与效果
成长路上，终究会遇上演讲；从没遇上演讲的程序员，可能天花板就会比较低。
后来再有技术分享的机会时，我已经开始写作了一段时间，发现写作实际对演讲是有帮助的
内容、观点、信息传递的目标都是要考虑的，只是最终的表达形式不同。
而且因为写了不少东西，也反而获得了更多的技术分享机会。
作和演讲的共通处在于：
而不同时长的演讲，准备的方式也不太一样。时间长的演讲，准备的内容就多，要精确地讲好这么多内容是一个挑战
而时间短的演讲，内容不多，但就需要合适地挑选和裁剪，并且精确地传递，这又是另外一种挑战。
二、经历与感悟
一场演讲，包括前期准备和现场发挥两个阶段，而前期充分的准备是现场良好发挥的基础。
世界上有一个著名的演讲论坛 TED，它上面的演讲，即使仅仅是视频，很多都给人留下了深刻的印象，而且传播范围也很广
它的演讲者通常是一些知名人士或至少是业内影响力比较大的人物。
目标：本次演讲需要达成的目标是什么？
听众：本次演讲的受众是哪些人？
重点：本次演讲要传递的关键点有哪些？
演讲的框架和程序的架构有点类似，一般我都从下面几个方面来设计：
引出主题：结合目标与听众来确定。
自我介绍：让听众了解你，证明你有资格讲这个主题。
问题：这个点上存在什么问题？
历史：这个问题的历史由来是什么？
方法：你是用什么方法解决这个问题的？
原因：为什么要用这个方法，要在这个阶段，以及这样解决问题？
重点结构：每一个关键点的分析、讲解，可以从以下方面来拆解。
细节深入：有一定细节深入，更有说服力。
总结回顾：结束前的再次总结和提炼，以加深印象。
那么一场技术分享的框架线，可能有如下：
1. 框架
到底要准备多少页的幻灯片？这个取决于框架线和演讲时长。但这里幻灯片的最大作用在于：
辅助演讲者的结构记忆与信息表达；
辅助听众的信息吸收、理解与消化。
第一类是幻灯片。
讲之前你可以先写下来你所要讲的内容，这样会有助于组织信息、梳理逻辑和提炼语言。
人是情感动物，故事的影响效应远高于数据和逻辑，即使是在做技术分享时。
第三类是小故事
在框架线清晰后，就进入了演讲材料的准备阶段。其中的材料包括三类：
h3 style=\
一段持续时间的演讲中，有没有一些关键的时间点呢？当然是有的。
据研究统计，一场演讲给人留下的印象和评价，开场的数秒至关重要。这可能和一开始是否能抓住听众的注意力有关。
一个是开场
管理界有一个 “峰终定律（Peak-End Rule）”：在 “峰” 和 “终” 时的体验，主宰了对一段体验好或者不好的感受，而在过程中好或不好体验的比重、时间长短，对记忆的感觉差不多没有影响
也就是说，如果在一段体验的高峰和结尾，你的体验是愉悦的，那么你对整个体验的感受就是愉悦的，即使这次体验总体来看，更多是无聊和乏味的时刻。
3. 节奏
演讲，包括讲和演，因而还有最后一个准备环节：演。
4. 表演
那前期可以准备的内容有哪些？我梳理了有如下维度：
三、准备与发挥
32讲演讲：表达的技术
具备什么能力？
解决什么问题？
产生多大影响？
至于对不同级别的定义，我选择了三个相对容易判断的维度：
他们通常都工作在系统中局部某个区域内，能独立或在有限指导下实现功能并解决该模块碰到的具体问题。
初级，多属于刚入职场的新人。
初级
初级同学经过两三年工作历练，对实现各种业务功能、开发规范流程都很熟练了，摆脱了对基本指导的依赖性，这时就进入了中级阶段。
中级工程师已经能够独立承担开发任务，设计实现他们负责的系统模块，以及通过搜集有效信息、资料和汲取过往经验来解决自己工作范围内遇到的问题。
中级，相对初级最大的质变在于：独立性。
中级这个层面的基本要求就是：完成动作、达成品质和优化效率，属于公司 “动作执行” 层面的中坚力量
中级
高级，不仅要能独立完成工作，还要能独立负责
他们能独立负责一个大系统中的子系统或服务，并成为团队骨干或最重要的个人贡献者。
高级
在偏基础研发、算法和特定技术复杂领域，会向 “资深工程师” 方向发展，属于深度优先
资深工程师
而在面向业务开发的领域，业务复杂度高于技术复杂度，则会向 “架构师” 方向发展，属于广度优先。
架构师
资深，有深度和资历（即广度）两个层面，对应到职业生涯路线上，也有两个方向。
即使是做纯技术的东西，最终的影响也是通过技术产品来完成的
而另一方面则是团队的梯队建设、结构调整与协作优化，决定了团队外在表现。
这两个维度，前者可能资深方向侧重多一些，后者则是架构师方向需要侧重思考实践的。
这个层次的影响方面，除了经验分享和方法论沉淀，还有产品和团队两个考虑维度
资深
也许架构师和资深工程师也具备在特定细分技术领域的深厚积累，说明他们和专家一样也有属于自己的领域，但这个领域还不算明确建立，它还需要有公认的影响力。
公认影响力实际指一个范围，如果是公司的技术专家，那么范围就是公司或行业。
专家，表明了某种领域的明确建立。
面向未来不确定的战略问题。这就像机器学习用过去长期积累的数据，建立起一个模型，用来预测和判断未来
未来不可测，但建立好了一个领域体系后，当未来到来时，就可以很快地将新出现的信息加入到现有的领域体系中去，从而修正模型，做出快速地调整与决策。
积累多年，建立体系，形成领域，他们需要解决的最重要的问题是
专家
33讲定义：阶梯与级别
通用能力，包括学习能力、沟通能力和领导能力等；
业务能力，包括业务理解和领域建模等；
技术能力，包括深度、广度和技能应用等；
影响力，如知识总结、知识传承和人才培养。
标准维度
晋升识别过程是一条链路，而技术标准评定只是其中的一个环节。
HR 部门的责任是对提报候选人进行晋升资格确认，比如是否满足上一级别或岗位要求的工作年限，是否存在公司行政处分导致失去资格等；
第一个环节
部门从满足资格的员工中进行提报，部门的作用是对提报员工过去一年在本部门工作绩效的认可
第二个环节
就进入了技术委员会组织的专业线技术评定，而通过技术标准评定后，是对其专业综合能力的认可。
最后，就进入到管理层复议环节，这个环节会有一个冲突点存在。
第三个环节
责任域，就是你负责什么，这个相对容易识别。而能力域则过于抽象，很难清晰识别，在述职这样的形式中，最容易判断的仅仅是表达和沟通能力
至于业务和技术能力，虽不那么容易判断，但好在其有最好的展现形式：作品。
对于程序员，作品可以是一个完整的系统，但其展现不应该是一系列的技术点，而是先有整体（面），再深入局部（点），应该是一个画龙点睛的过程。
从这样的展现过程中就能很好地体现出晋升者的业务与技术能力。
过程识别
晋升过程因为涉及太多个人的利益，所以评定过程的公平性是所有参与方都关心的问题。
晋升的本质是承担更大的责任，而责任和能力是需要匹配的，晋升就是完成这样一种匹配关系的过程
一个公司中的责任域是有限的、发展的、变化的，那你当下具备的能力域是否匹配相应的责任域
你正在学习和开发的新能力域，是否能在组织中匹配上合适的责任域？这才是看待职场阶梯与晋升的正确方式。
保持不断学习和提升能力，找到并承担起合适的责任域，那么后续的晋升并贴上一个相应的职级标签，就是一件自然而然的事情了。
晋升、职场阶梯和级别，更多是一种形式和标签，其实最后更重要的还是自己的成长，你说呢？
博弈权衡
34讲晋升：评定与博弈
起源
导师
学徒
关系
学徒视角
带好了徒弟，接手并取代了你当前正在做的事情，你才有可能解放出来去做更高层次和更大维度的事情。
学习和成长是自己的事，严肃待之，行动起来，自助者，人亦助之。
导师视角
35讲关系：学徒与导师
在“修行：由术入道”模块的最后一个主题，我们聊聊工程，不是具体的工程的技术，而是抽象的工程之道。
做了很多年的工程，开发了各种各样的系统，写了无数的代码，说起这一切，我们都在谈些什么？
从需求工程到开发流程，从编码规范到同行评审，从持续集成到自动部署，从敏捷开发到极限编程
谈过程
从企业级到互联网，从面向服务架构（SOA）到微服务架构（Microservice）
谈架构
从高并发到高性能，从高可用到高可靠，从大数据到大容量。
谈复杂性
那么对于这一切，你感觉这里面的核心是什么？
核心，意味着最重要的，一切复杂的工程技术方案都是围绕着它来运转。
安全与效率的平衡，是所有工程技术的核心。”
就是为了保障交付的程序代码是高质量、低 Bug 率、无漏洞的。
从开发流程、编码规范到代码评审、单元测试等，都是为了保障开发过程中的 “安全”。
安全开发
就是为了保障程序系统在线上的变化过程中不出意外，无故障。
但无故障是个理想状态，现实中总会有故障产生，当其发生时最好是对用户无感知或影响范围有限的。
通过自动部署来避免人为的粗心大意，资源隔离保障程序故障影响的局部化
当一定要有人参与操作时，操作规范和日志保证了操作的标准化和可追溯性
线上程序的版本化管理与灰度发布机制，保障了若有代码 Bug 出现时的影响局部化与快速恢复能力。
安全运维
就是为了应对 “峰值” 等极端或异常运行状态，提供高可靠和高可用的服务能力。
安全运行
在程序技术上的 “广义” 安全范畴，我划分了三个方面：
安全
效率，从程序系统的角度看，同样也是从 “开发”“运维” 和 “运行” 三个方面来考虑
就是程序员个人了，其开发效率除了受自身代码设计与编写能力的影响，同时还要看其利用工具的水平
更好的源码管理工具与技巧可以避免无谓的冲突与混乱
代码模板与开发框架能大幅度提升代码产出效率
而持续集成工具体系则能有助于快速推进代码进入可测试状态。
就是一个团队，其开发效率最大的限制经常是架构导致的
如果你在一个工程项目上写过几年代码后，多半会碰到这样一种场景，代码库越来越大，而功能越改越困难。
明明感觉是一个小功能变化，也要改上好几天，再测上好几天，这通常都是架构的问题，导致了团队群体开发效率的下降。
但部署效率可以通过自动化的手段来得到弥补，而开发则没法自动化
微服务化一方面提升了整体的开发效率，但因为服务多了，部署就变复杂了，所以降低了部署的效率。
另一方面，每个微服务都是一个独立的进程，从而在应用进程层面隔离了资源冲突，提升了程序运行的 “安全” 性。
群体
可以从 “个体” 和 “群体” 两个方面来看
开发效率
一个运行的系统，是一个有生命力的系统，并有其生命周期。
在其生命周期内，我们需要定期去做检查，以得到系统的 “生命体征” 的多维度信息数据汇总，以供后续的诊断分析。
检查
运行系统的 “体征” 数据是在实时变化的，而且数据来源是多层次的，从底层的网络、操作系统、容器到运行平台（如：JVM）、服务框架与应用服务。
当异常 “体征” 指标出现时，很难简单地判断到底哪里才是根本原因，这就需要关联的因果性分析来得出结论，最后智能地发出告警，而不是被告警所淹没。
准确地诊断之后，才能进行合适地处理
诊断
恢复：重启或隔离来清除故障、恢复服务；
变更：修改配置或回滚程序版本；
限制：故障断路或过载限流。
处理
可以从 “检查”“诊断” 和 “处理” 三个方面来看。
运维效率
关键就是提高程序的 “响应性”，若是服务还包括其 “吞吐量”。
负载均衡器让更多的机器或进程参与服务，并行算法策略让更多的线程同步执行
更多
异步化、无锁化和非阻塞的算法策略让程序执行得更快，缓存与缓冲让数据的读写更快。
更快
程序运行的高效率，也即高响应、高吞吐能力，所有的优化手段都可以从下面两个维度来分类：
响应性
吞吐量
运行效率
三个方面
效率
36讲核心：安全与效率——工程技术的两个核心维度
工业级规模化的程序系统开发包括了一系列的过程，而这一系列过程的起点是：需求。
需求，有时会有很多不同的表达形式，包括：客户的诉求、用户的请求、老板的要求，但这些不同的表达形式，不一定是真正的需求
形式
正因为需求的来源多，表达形式也多，因而真实情况是 “需求” 似乎总是源源不绝，但是真正的需求往往隐藏在这些诉求、请求与要求的表象之下
如果我们总是能找出真正的需求，那么也许需求也就没那么多了
但现实往往是我们不能，那么需求过载的场景就会常常发生。
难点一
这时，你就会面临第二个困难，如何对过多的需求进行排序？
最大化用户、客户和老板的整体满意度；
最大化价值与产出，让最多的资源投入到最有价值的需求上。
为什么需要排序？我们进行需求排序的原因是，在有限的资源下我们想要达到如下目标：
先来先执行
执行起来最快的先执行
占用资源最少的先执行
释放资源最多的先执行
高优先级的先执行
思路:参考操作系统的调度
难点二
需求与调度
成为程序员后，你一开始可能会习惯于一个人完成系统开发，自己做架构设计、技术选型、代码调测，最后发布上线，但这只适合代码量在一定范围内的系统开发模式
在一定范围内，你可以实现从头到尾“一条龙”做完，并对系统的每一处细节都了如指掌，但当系统规模变大后，需要更多的人共同参与时，整个设计和开发的模式就完全不一样了。
单兵作战过程
一是去建立系统的边界。系统提供什么？不提供什么？以怎样的形式提供？
二是去划定系统的区域。也就是系统的层次与划分，以及它们之间的通信路径。
规模化的设计思路，一方面是自顶向下去完成顶层设计.顶层设计主要做两件事
自顶向下的设计是前瞻性的设计，但没有人能做到完美的前瞻性设计；
规模化设计思路的另一面，就是要让系统具备自底向上的演化机能
所以，一个规模化的系统既要靠前瞻的设计视野，也依赖后验的演化机能，这样才可能将前瞻蓝图变成美好现实。
设计与开发
完成了设计与开发之后，系统将进入测试，最后发布上线进入运行与维护阶段。
从开发提测，机器自动下载提测版本分支代码，进行构建编译打包，实施代码规范性检查测试，通过后发布测试环境，进行分层次的各类自动化专项测试。
如：用户终端层、通信协议层、服务接口层、数据存储层的各项测试，全部通过后，生成相应的测试报告，进入下一步发布流程
这就是测试体系的“流程”，而“规则”就是其中定义的各种测试项检查约束。
流程规则
上述流程中涉及的“工具系统”包括：代码规范检查工具、终端 UI 的自动化测试工具、通信协议与服务端接口调用的模拟工具、数据一致性校验工具、测试报告生成工具、测试 Bug 统计分析与收敛趋势等可视化展现工具，等等。
工具系统
最后，“规范共识” 是整个团队对这个流程环节、里面具体规则的定义以及 Bug 分类等方面达成的共识，这决定了这台 “测试机器” 运转的协调性与效率。
规范共识
以测试为例进行规模化的最佳方式，就是打造一条 “测试机器” 流水线
测试通过后，发布到线上就进入了运维阶段，行业里已经有大量的关于 DevOps 的分享内容，而它的本质也就是打造了一台 “运维机器” 流水线，这和我上面描述的 “测试机器” 运转类同，只是有不同的规范共识、流程规则和工具系统，便不再赘述了。
测试与运维
37讲过程：规模与协作——规模化的过程方法
什么是工程思维？
一种具备科学理论支撑，并成体系的系统化思维
答案
可以简单归因的问题：属于直接简单的因果关系；
难以简单归因的问题：属于间接复杂的因果关系。
做了多年的软件开发工程，碰到和解决了数不清的问题，最终这些问题，我发现稍微抽象一下，可以归为以下两类
第一类问题，现象清晰，归因明确，那么它唯一的难处就是为这个问题找到最优的解决方案
求解最优化问题，就需要科学与理论的支持，也即：科学思维。
这就是用科学思维来指导工程实践，科学理论指出方向，探明边界，工程实践在边界的约束范围内修通道路，达成目标
第一类 问题 思路:科学思维
第二类问题，结果明确，但归因很难，那么找到真正的原因就是第一个需要解决的难点
所谓系统，就是一个由很多部分组成的整体，各个部分互相之间有联系，作为整体又有一个共同的目的
一个系统中可以有若干个正反馈和若干个负反馈回路，正反馈回路让系统或者增长、或者崩溃，是要偏离平衡，负反馈回路则尽力保持系统的平衡。
对你想要解决的这个问题而言，可能就有一个回路，正在起主导的作用！如果你能发现在系统里起主导作用的回路是什么，你就抓住了系统的主要矛盾，你就找到了问题的关键所在。
这时，我们就需要用另一种思维方式：系统思维。
第二类问题思路:系统 思维
一个优秀的工程师应该同时具备科学思维和系统思维，它们是工程思维的两种不同表现形态：系统思维洞察问题本质，科学思维发现最优解法。
38讲思维：科学与系统——两类问题的两种思维解法
人面对过度工作时产生的身体和情绪的极度疲劳。
它出现的状态，可以用两个英文单词来形象地表达：Burnout（燃尽，精疲力尽）和 Overwhelm（难以承受）。
一种是短期的倦怠感。
它与你对当前工作的感受有关。
另一种更可怕的倦怠感是长期的
一般将可以明显感知到的分为两种。
倦怠感
当倦怠感出现时，“工作态” 就隐退了；而为了消除倦怠感，我们就需要找回 “工作态”。
工作态，如其名，是一种工作的状态，一种让我们在工作中感觉到美好的状态（beautiful state）；是做我们喜欢的工作时表现出来的一种状态。
工作态
关于工作区，我想借用下面一张图来展示。
这是工作的终极之问。它决定了你的很多选择，以及你接受什么、拒绝什么，是工作愿景背后的灵魂所在
每个人工作都会有自己的目的与意义，而且还会随着工作过程发生变化（或者说进化更合适些）。
追寻目的与意义，这可能是你、我一生的工作。
目的意义 Purpose
是个人一生职业愿望的追寻过程。它由长期目标驱动，是追寻 “目的意义” 的一条你所期望的路径
而这条路径并不唯一，它因人而异，因你的 “目的意义” 而异。
它构建在你工作过程中的所有经历、经验、决策、知识、技能与时运的基础之上
职业生涯 Career
这不过是你现在上班的地方，包括了位置、角色、关系、职责与薪酬的总和。
工作岗位 Job
工作区
当职业倦怠时，自然是远离了工作区，这时很容易产生的一个决策是：换一份工作。我曾经就做过这样的决策
换一份工作没有对错好坏之分，它能改变你的工作岗位，甚至也能改变你的职业生涯路径，但它唯一不能改变的就是你对 “目的意义” 的思考与认识
h1 data-v-87ffcada=\"\" class=\"article-title pd\" style=\
机器学习建模也是一个最优化问题，基于一组已知的数据去构建一个模型，让这个模型去适配未来未知的数据达到最优，然后求解关于这个模型的参数
参数的选择尝试收敛到了一小块范围内，无论再怎么尝试变化都没法取得更优的结果。
而从全局来看，这并不是最优的选择，但算法此时就进入了一种尝试的徘徊状态，这就是局部最优点，但算法并不知道这到底是不是全局最优的。
局部最优点
对于我们这些自诩智能的人，在成长的路上，其实也经常陷入这样的成长局部最优点。
关于成长最形象的类比便是爬山，但爬到山顶的路并不总是向上的。
有时你很幸运地爬上了一个高点，你并不知道这个高点是否就是山顶了，因为再往前走，无论哪个方向的路都是向下的，你会心下疑惑
这是要下山了吗？
不同的是，成长的路上并没有清晰的路标告诉你山顶在哪里。
一方面可能是 “山形” 所致，要继续上山的路需要先向下走，而向下的疑虑又会让我们徘徊不前。
另一方面，可能是此 “山” 只有这么高了，就像青城山，你想看云海，可能就得换一座山了。
我们在成长（爬山）的路上，会进入局部最优点
爬山
所有的局部最优点，都意味着我们爬到了一定阶段，在这个位置徘徊不去，恋恋不舍。
看清了自己目标的高山，发现自己爬错了山，要舍得离开；停留在低矮的山上，无论再努力，看到的风景也有限。
徘徊
如何知道你正站在局部最优点上徘徊呢？当你知道自己做得很好，但却没有感觉到成长与进步时，那么也许你就正在徘徊了。
在我的故事中，我一次次逃离，是为了什么？因为失去了成长的感觉。
当然，逃离，不一定都是换一座 “山”，也有可能是换一种爬山的方式，找到一条新的路。
这就需要你有意识地试图在一些你已经知道如何做的事情上，再去做得更好
如果没有这种有意识的尝试与努力，很可能你就还在原地依赖过往的经验和技能自动化地完成同样的事情。
在日常工作中，你可以尝试问问自己，对于十年后而言，现在的工作和事情，哪些会是很重要的？哪些会让你的技能变得更好？
进入局部最优，徘徊于局部最优，逃离局部最优，都是你的选择。而站在局部的最优点，走出徘徊的第一步，总是从下山开始，而这样的选择并不容易。
逃离
40讲局部最优：如何逃离？
需求没沟通清楚，写出来的代码，即使没 Bug 将来也可能是负债。
一、木讷与沉默
程序员最容易产生沟通争论的地方：沟通需求和沟通技术方案。
首先，把握一个度，对事不对人，切勿意气用事。
1. 以理服人
分歧进入用 “理” 都无法搞定时，那就是应了那句古词：“剪不断，理还乱”。
2. 以德服人
最差的状况就会走到这一步，特别在跨大部门的沟通中。
3. 以力服人
既然分歧已经产生了，为了避免无谓的争论，该怎么解决呢？
二、争论与无奈
从内容上看，虽说你想沟通的本质是同一样东西或事情，但针对不同的人，你就需要准备不同的内容
内容
从形式上看，沟通其实不局限于面对面的谈话。面对面交谈是一种形式，书面写作又是另外一种形式，连写代码本身都是在和未来的自己或某个你尚未谋面的程序员沟通
不同方式和场景的沟通可以有不同的风格。比如面对面沟通，有一对一的私下沟通，风格就可以更随性柔和些
也有一对多的场景，比如演讲、汇报和会议，风格就要正式一些，语言的风格可能就需要更清晰、准确和锐利一些。
你只需要尝试写点你自认为已经熟悉掌握的技术，并交给读者去阅读与评价。
每过一段时间（比如，一个季度或半年）尝试去总结，然后给同事分享下你工作的核心内容，再观察同事们的反应和听取他们的反馈，你就能体会到这一点了。
沟通之难就在于清晰地传递内容和观点
风格
三、认识与改变
41讲沟通之痛：如何改变？
每天的工作可能就是编程写代码，在早期还不够熟练时，你还能感觉到进步，这种进步就是从不熟练到熟练。
进入熟练期以后，你可能感觉这项技能就提升得很慢，甚至一度停滞了。
程序员，最重要的就是编程技能
只在 “学习区” 练习，练习时注意力必须高度集中。
把训练的内容分成有针对性的小块，对每一个小块进行重复练习。
在整个练习过程中，随时能获得有效的反馈。
刻意练习
在程序员足够熟练了之后，每天的这种编程实战型工作就不会再是处于 “学习区” 的练习了，而是进入了 “舒适区” 的自动完成
真正的职业竞技体育运动员每天的日常训练都是在 “学习区” 的刻意练习，到了上场比赛则是进入 “舒适区” 的自动完成。
然而很多熟练程序员的日常工作则是在 “舒适区” 的自动完成，工作之外则是另一种 “舒适区” 的娱乐休闲。
停滞，就是这样发生的。
技术停滞
感觉停滞的技能，如果工作依然需要它，其大的技术方向发展趋势依然明朗，那么这样的技能是值得好好保养，并继续提高的
关于 “刻意练习”，有时我们即使一直保持在 “学习区” 的重复练习，却也可能感觉不到进步，这有可能是因为重复的次数和强度还不够
但即使每日都能保障一小时的时间，一年下来也不过区区 300 多小时，更别提分散在听说读写四个分支上了
最后的结果可想而知，就是那一年结束后，并没有哪一项在让我感觉到一点点的进步。
第一年，仅仅在每日的工作之余，我会花上大约一小时来进行听说读写的练习
每一次的重复过程中都需要根据反馈进行有针对性的调整，以取得练习效果的进步。
而重复的刻意练习总是辛苦的，辛苦就是我们付出的技能保养成本。
重复，是有针对性的强化练习，其本身是练习过程，而非练习内容。
而保养和提升技能的方法，“刻意练习” 依然是不二之选。
技能保养
技能不仅仅会停滞，还有可能会过时。
一般技术书籍的组织方式都是按主题的相关性来编排的，系统体系性很强，但却不是按你解决问题需要知道的内容来组织的
完整地读技术书籍能增长你的知识，但却无法快速习得技能，并解决你的问题。
所以，技术书籍更适合于在你解决问题的过程中用来参考
了解全局
确定范围
定义目标
寻找资源
学习计划
筛选资源
开始学习，浅尝辄止
动手操作，边玩边学
全面掌握，学以致用
乐为人师，融汇贯通
对如何开发一门新技能，《软技能》一书的作者曾在书中分享过他的一个十步学习法：
在深度路线学习中，对全局、范围、目标的定向更聚焦，因此寻找、筛选的资源会更窄，学习计划的迭代期更短，很快就走完了前 6 步，并进入动手实践、反复迭代的过程中，直到把问题解决。
而在广度路线的学习中，前 6 步会花去大量的时间，因为这时你面临的问题其实是对新技术领域边界的探索
这就像以前玩《魔兽争霸》游戏中，先去把地图全开了，看清楚了全貌，后面再进军时就能选择最优路径，避免了瞎摸索。
这个方法和我自己在实践中养成的习惯基本一致
技能开发
技术也许会停滞，技能也可能会过时，但其中的能力却可以沉淀下来，应用于下一代的技能之上。
技能是你习得的一种工具，那么能力就是你运用工具的思考和行为方式，它是你做成一件事并取得成果的品质。
能够写程序，只能算是技能过关吧，而能写好程序，才算具备了程序员的基本代码能力
代码能力的识别，最简单的方式就是维护一份公开可跟踪的记录，比如参与开源项目贡献，在 GitHub 上留下你的代码简历。
作为程序员最基本的自然是代码能力
架构师也许不像在工程师阶段需要写大量代码，但实际没有代码能力是做不了架构的。
代码能力是架构能力的底层能力要求。但仅此一项能力却也远远不足，这里就先不展开了，后面会专门有一篇文章谈架构师能力模型这个主题。
从程序员到架构师，“架构”显然不是一种技能，而是综合应用多种技能的能力
一方面，技术能力的提升总会到达平台期，增长变得缓慢
而了解学习一下其他方面的全新能力，可能会让你找到新的成长点，重新找回快速成长的感觉。
除了技术能力，如果有可能可以适当跨出技术的边界，去了解下产品、管理、运营和传播等方面的能力。
完成作品需要有一些产品思维，需要自我规划与管理能力，而推广作品需要运营和传播能力。
这些相关的能力，最终都会成为你核心能力体现——作品——的放大器。
另一方面，个人很多综合能力的差别，有时就是要靠作品来体现的。
那么程序员需要去沉淀哪些能力？
春去秋来，时过境迁，技能过时，落叶归根
沉淀下来的能力，将如春风吹又生，新的技能自会发芽。
而这一切的能力与技能之母，又叫元能力，自当是学习能力。
当时代发展，某些技能会过时，但能力矩阵不会过时，它当与时俱进
永不会有停滞的时候，它总是在进化。而对于过时的技能，除了既往不恋，我们还能做什么呢？
持续保养主要的生存技能，合理开发辅助技能，形成自己独有的技能组合，沉淀能力模型，发展能力矩阵。
如果你是一棵树，能力是根，技能是叶
沉淀能力
42讲技术停滞：如何更新
因为畏惧，所以我用了这句口头禅来回避了这个问题，甚至没有去调研一下技术可行性
就由此固步自封，在这片知识领地留下了一片空白，也不能为客户创造更进一步的价值
当时我说出的那句“技术上无法实现”，仅仅是因为不知和不解而心怀畏惧
“技术上无法实现” 的口头禅，此时成为了遮挡我们因不知而畏惧的面具。
1. 不知
当时我说出的那句“技术上无法实现”，只是因为觉得很麻烦，不愿意而已
“技术上无法实现” 的口头禅，此时成为了我们推脱的借口。
2. 不愿
一、困扰
不论是 “不知” 还是 “不愿”，“技术上无法实现” 的口头禅看来都不会给我们带来什么帮助
它反而阻碍了我们进一步做出更好的产品，从而给客户留下遗憾。
这些需求的真正限制，要么是时间，要么是资源。
这个需求背后涉及的技术实现，要么可能你现在未知
要么你至少知道一个方案，只是觉得过于复杂，而且会带来很多“副作用”，所以不愿意这样去做罢了
所以，面对一个紧迫的或不合理的客户需求，甚至诉求时，不应该再以如此苍白的一句话去应对了。
事实上，我发现大部分的用户需求，技术上总是可以实现的。
这一步的目的并不是要找到并确定实现方案，只是对这一问题涉及主题的相关内容有一个全局性的了解。
移动弱网络，消息投递失败率高；
应用切后台就被系统杀掉，所以收不到；
第三方推送渠道，比如：某一类用户完全没有这种渠道可达；
应用本身的问题，比如：Bug，版本碎片导致的兼容性问题。
而用户碰到这样的问题可能的原因有：
1. 全局背景
对上面列出的全局背景问题分析分类后，会发现没有一个是轻松容易就能解决的。
而且这时还必然面临资源和时间的问题，也就是在特定的资源和时间下，我应该优先解决哪类？
所以，这一步的本质就是从上面的全局分类中，聚焦一个范围，然后集中深入调研评估
2. 聚焦范围
前面说了用户仅仅反馈了一个说法，站在用户的角度，他们总是希望没有任何问题的
但站在我的角度，我知道我只聚焦了一部分问题，所以我需要清晰定义这部分问题解决的成功标准。
3. 定义标准
有了范围和标准，剩下的就是深度评估方案路径问题
4. 深度评估
二、反思
43讲无法实现：困扰与反思
继续停留在通往“罗马”的循环往复中，已无法让你继续成长为专家。
而要想跳出这循环往复的路，无非就是不再去走那熟悉的条条通往“罗马”的大道，而是选择一条离开“罗马”的路，走出去，走向未知与未来。
困境：代码与罗马
作品，亦称创作、创意、著作，是具有创作性，并且可以通过某种形式复制的成品。
从这个定义来看，作品最重要的特质是：创作与创意。所以，只有包含了创意和创作性质的事物才能叫作品。
你从网上复制来一段代码，解决一个问题，这不是创作，也不会成为你的作品。
代码作品，可以小到一段函数、一个类，大到一个库或框架、一个服务，甚至一个系统
但打磨代码作品的方式，应该是定期对自己写完的代码进行沉淀、梳理和规整，提取可复用的功能，同样的功能只写一次，形成自己专属的编码脚手架和代码库。
当你给别人介绍自己时，只需要介绍自己的作品，而不再需要介绍自己的技能。
作品
理想：作品与创作
作品要实现直接的经济收益，必须还要走完从作品到产品之路。
产品，是指能够供给市场，被人们使用和消费，并能满足人们某种需求的任何东西，包括有形的物品，无形的服务、组织、观念或它们的组合
现实情况是，大部分时候我们的代码作品，都是存在于产品之中的，所以你需要关注包含了你的代码作品的更大范围的产品及其特性。
如果产品无法获得市场的价值认同，技术作品自然也就埋没其中了。
技术需要懂的是产品提供的核心服务和流程，并清晰地将其映射到技术的支撑能力与成本上。
显性
用一段新算法实现的函数取代了旧函数，那么多余的旧函数就变成了负债而非资产，是需要去清理的
重构代码变得更简洁和优雅，可读性增强，节省了未来的维护成本
一个能同时服务一万人的程序实例，你知道你没法加十个实例就能简单变成能同时服务十万人的系统。
显性的错误会有测试、产品甚至最终用户来帮你纠正，但隐性的错误却很难有人能及时帮你发现并纠正。
隐性
有个说法是：要做好技术需要懂业务和产品
技术从特性到作品，去支撑产品的体验与服务，这是一条更现实的技术作品实现价值的路。
从反复写代码实现需求的重复困境中，到打磨作品实现价值的理想，再回归产品化的现实之路。
现实：产品与特性
44讲完成作品：理想与现实
代码评审的初衷是提高代码质量，在代码进入生产环境前经过同行评审来发现缺陷，降低损失概率
感性认识
从如上的实验分析结论来看，代码评审对于发现潜在缺陷很有用，相比测试能发现的缺陷率高一倍，但也需要投入巨大的时间成本
一小时审查 150 行代码，再快就不利于发现潜在缺陷了，而且更适用于长生命周期的产品。
理性分析
项目期限 Deadline 已定，时间紧迫，天天加班忙成狗了，谁还愿意搞代码评审？
这是一个最常见的客观阻碍因素，因为 Deadline 很多时候都不是我们自己能确定和改变的。
困境一
即使强制推行下去，如何保障其效果？团队出于应付，每次走个过场，那么也就失去了评审的初衷和意义。
困境二
团队人员结构搭配不合理，新人没经验的多，有经验的少。新人交叉评审可能效果不好，而老是安排经验多的少数人帮助 Review 多数新人的代码，新人或有收获，但对高级或资深程序员又有多大裨益
一个好的规则或制度，总是需要既符合多方参与者的个体利益又能满足组织或团队的共同利益，这样的规则或制度才能更顺畅、有效地实施和运转。
困境三
人就是不喜欢别人 Review 他的代码，他会感觉是在找茬
比如，团队中存在一些自信超强大的程序员，觉得自己写的代码绝对没问题，不需要别人来给他Review。
困境四
多种困境
在国内，我并没有看到或听闻哪家把代码评审作为一项研发制度或规则强制要求，并落地得很好的公司。
参考路径
以前尝试过要在团队内部做代码评审，听说兄弟团队搞得不错，然后就一起交流经验
交流开始不久就跑偏了，重心就落在了应该选个什么好用的代码评审工具来做，如今想来这完全是舍本逐末了。
给自己 Review 是一种自省，自我的成长总是从自省开始的。
现实选择
45讲代码评审：寄望与哀伤
当你感到害怕丢掉工作时，说明已经不再年轻了，一种为了谋生的恐惧感油然而生。
中年，每个月比年轻那会儿挣得更多了，职位也更高了，生活变得更安适和稳定
这时真正潜伏着的威胁开始出现：技能的上升曲线可能越过了高点，走入平缓区，甚至也许在以缓慢而不易觉察的方式下降，而我们却安之若素。
但中年，悄然而生的恐惧感，并不是阻止我们再进一步的 “鸣枪示警”，而像是中场的哨声，提醒我们人生的上半场快结束了，短暂的休整之后，就该提起精神开始下半场了。
恐惧感：谋生
假如你在一份工作中，对丢掉工作本身产生了恐惧，那你做工作的形式很可能会走向谨小慎微。
而偏偏是要对工作的无惧感才能真正释放你的潜力，发挥你的能力，让你能够留在原地甚或更进一步。
无惧感：舍生
安全感，是渴望稳定、安全的心理需求，是应对事情和环境表现出的确定感与可控感。
年轻时，拼的是体力、学习力和适应能力，是做解答题的效率与能力；
中年了，拼的是脑力、心力和决策能力，是做对选择题的概率。
中年人和年轻人本应在不同的战场上
环境和人都处在长期持续的变化中，变化总是不确定的，我们没法消除变化，只能把变化纳入考虑，承认变化是永恒的，不确定是长期的
简言之，人到中年，转换了战场，重新定位自己的优势，转变核心竞争力，浴火重生，开启人生的下半场。
这场战事从谋生的恐惧感开始，给予我们警示；到舍生的无惧感，让我们摆脱束缚，整装待发；最后经过重生的安全感，推动我们再次上升。
安全感：重生
46讲人到中年：失业与恐惧
1. 自由成长
2. 变身土豪
3. 追求梦想
一、期望
搞清楚了自身的期望与需要付出的成本和代价，再来理性地看看其他方面的因素。
创业毕竟是一段长期的旅程，大家的目的、价值观、期望差距太大，必然走不长远，身边就目睹过这样的例子。
1、创始人创业的目的是什么？期望是什么？
有信用污点的人并不值得合作与跟随，而且前面说的创业公司期权，最终能否兑现？
就国内的创业环境而言，这一点也很是关键。
2、创始人以前的口碑和信用如何？
看看之前都有些什么样的人，你对这个团队的感觉契合么？价值观对味么？
这个团队是合作融洽，还是各怀鬼胎？有些小公司，人虽不多，办公室政治比大公司还厉害。
3、公司的核心团队成员如何？
创业公司在发展初期容易遇到技术瓶颈，会以招 CTO 的名义，来找一个能解决当前技术瓶颈的专业人才
也许你会被名头（Title）吸引，解决完问题，渡过了这个瓶颈，但这之后老板会觉得你的价值还足够大么？
有句话是这么说的：“技术总是短期被高估，长期被低估”。而你自身还能跟得上公司的发展需要么？
4、对你的定位是什么？
5、公司是否有明确的业务方向？业务的天花板多高？有哪些对手？相对竞争的核心优势是什么？
二、条件
决策之前，期望是内省，条件是外因；决策就是将客观的外因与主观的内省进行匹配判断选择的过程。
如今在创业公司的你，当初是如何选择的呢？或者你是怎么看待这件事的呢？
三、决策
47讲该不该去创业公司？
外包的直接诱惑，就是能立刻增加工资之外的收入，赚点外快。
咨询/培训。
演讲/分享
投稿/翻译
写书
写博客/公众号
课程/专栏
兼职/外包
赚钱方式
赚钱与诱惑
不要让债务的增长速度超过收入。
不要让收入的增长速度超过生产率。
尽一切努力提高生产率。
但长期来看，价格总是要回归价值的，这是经济规律，宏观如国家，微观如个人。
成本与比较
赚钱的事，核心是当下的利差，现金现货，将本求利。
值钱的事，核心是结构性价值，兑现时间，在某个未来。
从值钱的角度看，前面分析的所有赚钱方式，在以个人价值增值为出发点的前提下，是值得尝试的。
选择做赚钱的事，还是值钱的事？
值钱与选择
如果外包项目对你的技术积累有好处，那么收点钱去实践提升下正好一举两得；其实参与开源项目，本质上不就是不收钱的外包项目？它的收益就是让你更值钱。
包项目的成果具有可复制、可重用性，这样就可以通过大量复制和重用来降低一次性开发成本；而成本和比较优势才是外包模式的核心竞争力所在啊。
从赚钱的角度看，前面分析的所有赚钱方式的赚钱性价比都很低，完全不值得做。你可能会反驳说，外包项目的收入可能也不低，甚至比你的全职工资还高，怎么会认为赚钱性价比很低呢
外包项目不是临时一次性的，而是需要长期维护的，而这种维护的边际成本可以依靠技术工具手段不断降低，那这样的外包项目就是一个长期赚钱的 “机器” 了。
值得接的外包，它包括下面一些特性：
所有以上特性都反映了一个本质：去做值钱的事，打造值钱的结构，从知识结构、技能结构到作品结构与产品结构，然后等待某个未来的兑现时间。
48讲该不该接外包？
循证与决策路径
连结与知识体系
49讲技术干货那么多，如何选？
50讲技术分歧，如何决策？
程序员的进阶攻略
职业：暂无
0 条评论
回复 删除
下一页
