01为什么称为一名程序员

在工作的前几年有一段快速的自然成长期。因为这时我们就像一张白纸，只要是在认真地做事儿，总是能成长。这段时期，心其实是乱的，但因为忙而充实，也获得了很多成长，但它的问题是：这样的自然成长期有多长取决于你所做事情的天花板，所以才有了后面的落差。

02技术方向的选择

03技能地图

测试驱动开发（TDD）

在写代码的时候，用测试的思维与方式（提供单元测试）去审视和检测代码，也就是说明确要开发某个功能后，先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。

04别了校园初入江湖

那么持续努力的学习还有意义吗？我只是说你很难做到每年加薪20%，但是却可以做到每年比去年的自己多增长20%的知识、见识和能力。

05架构与实现

架构的内容

• 确定边界：划定问题域、系统域的边界。
• 切分协作：切分系统和服务，目的是建立分工与协作，并行以获得效率。
• 连接交互：在切分的各部分之间建立连接交互的原则和机制。
• 组装整合：把切分的各部分按预期定义的规则和方法组装整合为一体，完成系统目标。

架构的维度

• 高维度：指系统、子系统或服务之间的切分与交互结构。
• 中维度：指系统、服务内部模块的切分与交互结构。
• 低维度：指模块组成的代码结构、数据结构、库表结构等。

架构交付的一套决策流，而文档是交付的载体

架构实现的过程中

• 选型评估：选库，框架和API
• 程序设计：逻辑（流程和分支）、控制（串行并行同步异步）、数据（结构，状态，存储）
• 执行效率：运行时间、响应时间、吞吐量
• 稳定健壮：异常处理、边界条件
• 维护运维：维护（易读、易改）、运维（监控、日志、配置、报警、兼容）
• 集成部署：依赖复杂度、易用性、调用管理

关注点为熵

• 系统只要是活跃的，“熵”值就会在生命周期中不断波动。需求的增加和改变，就是在不断增加“熵”值（系统的混乱程度）。但软件系统的“熵”有个临界值，当达到并超过临界值后，软件系统的生命也基本到头了。
• 实现中重构与优化的动作则是在不断进行减“熵”，作出平衡，让系统的“熵”值在安全的范围内波动。

需要把控的为战略性细节。而其他大量的实现细节也许与想象的不同，但只要没有越出顶层宏观结构定义的边界即可

06模式与框架

设计模式，对于初窥门径的程序员，带来的麻烦简直不逊于它所解决的问题

所以需要在一定程度的时候再去看模式就发现很多已经用过，没用过也能很好理解

• 模式是代码层面，解决单个问题的成功方法
• 框架是设计层面，解决一系列问题的成功方法

通用则意味着至少要适用于大于两种或以上的场景，场景越多我们的选择和取舍成本越高。

07多维和视图

三视图

• 组成视图 子系统、服务、组件部分构成
• 交互视图 系统或服务与外部系统或服务的协作关系
• 部署视图 部署结构与环境

还有

• 流程视图 时序图
• 状态视图

08代码和分类

• 功能：业务逻辑的复杂度决定了功能性代码的复杂度，整理需求为第一
• 控制：通信、负载、限流、隔离、熔断、异步、并行、重试、降级
• 运维：用于检测和诊断，日志和监控，运维类代码很多都成了技术债

09粗放和精益

在通往"更好"的路上，总会经过"更多"这条路

好不是完美，好是一个过程，一个不断精益化的过程

10炫技和克制

避免写一些复杂不易理解的代码

11调试，编写和运行

一段代码写出来，基本就该在你头脑中跑过一遍了。等上线进入真实生产环境跑起来，你就可以拿真实的运行数据和头脑中的预期做出对比，如果差距较大，那可能就掩藏着问题，值得你去分析和思考。

12BUG的空间属性

因为程序没有对环境的异常做应对导致的bug的产生

13BUG的周期属性

周期特点，会周期性的复现，这种一般是资源泄漏

14BUG的反复出现

吸取教训避免重蹈覆辙

15计划的愿景

我们最后悔的是没做什么，而不是做过什么

• "理想的自己"就是你想要成为什么人
• "义务的自己"就是你应该干什么

16计划的方法

目标+拆解

脚踏实地

17计划的可行

一年52周，会有一些法定的长假和个人的休假安排，我们先扣除两周用于休假。那么一天业余8小时，一年算350天，那么一年总共有2800小时的业余时间。但实际这2800小时里还包括了你全部的周末和一些零星的假期，再预扣除每周8小时用于休闲娱乐、处理各种社会关系事务等等，那么你还剩下2400小时

兴趣让计划更容易启动，而承诺让计划得以完成

18计划的收获

量并不代表质

时间是有成本的，随着成长的过程，早期的成本低而选项多，后期的成本高且选项少

计划本质是对时间的分配

19计划到坚持，再到坚持不下去

没有那么多大起大落，我们大部分人的生活只是在经历一些平平凡凡的琐事。 也许其中有些会让你感到高兴与兴奋，有些又让你感到烦躁与郁闷。 但这些琐事都不会沉淀进历史中，被人们传诵上千年，它仅仅对你自己有意义。

20执行

每个人都会有自己不同的节奏

21信息过载与有效

信息是过载的，现在每48小时所产生的数据量，相当于从人类文明开始到2003年累计的数据总量

面对大量信息改如何应对

• 信息和知识本身的价值
• 我需要怎么的信息和知识

22知识和体系

• 点 详细的知识点
• 线 路径，对点的连接
• 面 知识体系
• 体 行业或者经济体，体到告诉增长形成趋势，获得发展

23能力和输出

对于个体，建立起一个初步的知识体系，到能真正充分发挥出这个体系的力量

对于团队

• 流程规则，建立其运行轨道
• 工具系统，支撑其高效运行
• 规范共识，形成了协调合奏

24工作和学习

即使再忙，也会抽空看书夯实基础。成长是自己的事情，不能怪没有时间！

遇到瓶颈，详细需要面对哪些问题，都有答案吗？

25感知与测量

感知时间

很多别过都是后会无期的

为何人随着年龄的增大觉得时间过得越来越快？

有共性的回忆趋向粘合在一起，标志性的回忆倾向于鹤立鸡群

26切割和构建

27试试坏习惯

一门新技术很少是凭空冒出来的，了解它们的前世今生，会更有效地知道

• 哪些方面已经有了成熟的方案
• 哪些地方还在青涩的探索期

再结合它当前的边界，就知道

• 如何定义清楚需要
• 形成合理的技术方案
• 不会产生过度的妄想

28提问

• 如何问
• 问什么
• 为何问

如何问

别人的提问会交代解决场景，描述思路，问题约束，然后有一个障碍，问怎么解决障碍，而不是说我的目的是什么

• 提供足够的信息，让人能够回答

展现你探索了那些路径，省去可能产生的反问

• 提供更多的选项，让人方便回答
• 提供交换价值，建立讨论基础，表达感谢态度，让人乐于回答

问什么

29偏好

30写作

需求、设计、实现、测试和交付

需求随时记录

设计分为

• 概要设计
• 详细设计

31画图

着重记录

32演讲

框架

演讲的框架和程序的架构有点类似，一般从下面几个方面来设计：

• 目标：本次演讲需要达成的目标是什么？
• 听众：本次演讲的受众是哪些人？
• 重点：本次演讲要传递的关键点有哪些？

一场技术分享的框架线，可能有如下：

• 引出主题：结合目标与听众来确定
• 自我介绍：让听众了解你，证明你有资格讲这个主题
• 重点结构：每一个关键点的分析、讲解，可以从以下方面来拆解
• 问题：这个点上存在什么问题？
• 历史：这个问题的历史由来是什么？
• 方法：你是用什么方法解决这个问题的？
• 原因：为什么要用这个方法，要在这个阶段，以及这样解决问题？
• 细节深入：有一定细节深入，更有说服力
• 总结回顾：结束前的再次总结和提炼，以加深印象

材料

• PPT
• 演讲稿
• 故事，慈善募捐组织早就学会了，再大比例的穷困数据，也比不上一张衣不蔽体的小女孩照片来得有效

节奏

• 开场
• 峰终，如果峰终体验是好的，整体的体验也是好的

33