想象你想要的未来，对可以拥有的未来充满憧憬，才有动力去创造它。即使是空中楼阁，也要每天为它添砖加瓦。

前言

没有最好的解决方案，无论是工具语言还是操作系统；只有在特定的环境下才有所谓更合适的系统。

在一个项目的整体结构中，总有个性和技艺的空间。但是软件构造的工程成分并不妨碍个体的技艺。

我们，采集的只是石头，却必须始终展望着未来的大教堂。

一、务实的哲学

我活着不是为了满足你的期望，正如你也不是因为我的期望而活着。

你有权选择，只是需要积极主动去掌控这些机遇。

提供选择，别找借口。解释一下要做什么才能挽回这个局面。

不要搁置破窗（糟糕的设计、错误的决定、低劣的代码）不去修理，每发现一个就赶紧修理一个。也可以注释掉，或使用代码桩替代，预防进一步的损害发生，表明一切尽在你的掌握中。

也不要因为一些东西非常危急，就去造成附带伤害。

石头做的汤：使用一个原型作为推动变革的催化剂，人们都觉得，加入一个推进中的项目更容易一些。因为只要一窥未来，大家就能团结在一起。

煮熟的青蛙：不要学寓言里的青蛙，永远留意着大局，持续不断地审视你身边发生的事情，而不要只专注于你个人在做的事情。

许多用户宁愿今天就用上一个毛糙的软件，也不愿意多等上一年再用那个打磨光亮、功能齐备的版本，而且，实际上他们一年后真正需要的东西可能完全不同。今天还不错的软件通常更讨人喜欢，如果你早点给用户一点东西玩，他们的反馈常常能引领你做出更好的最终方案。

持续投资非常重要。一旦你进入了对某个新语言或新技术的舒适期，向前走，再学一个。想法的交叉传授是很重要的，试着把你领悟到的东西应用到你当前的项目中。

了解听众：注意看肢体语言和面部表情。所获对方的反应即沟通的意义，在交流的过程中，不断提高对听众的了解。

通过提供鼓励人们交谈，试着让他们总结你的发言。把会议变成一场对话，你将更有效地表达你的观点。说不定还可以学到一些东西。

越是有效的交流，影响力就越大。

二、务实的方法

优秀的设计比糟糕的设计更容易变更（ETC：Easier To Change）：能适应使用者的就是好的设计。对代码而言，就是要顺应变化。

DRY（邪恶的重复）：在一个系统中，每一处知识都必须单一、明确、权威地表达。

一个模块提供的所有服务都应该通过统一的约定来提供，该约定不应表露出其内部实现是基于存储的还是基于运算的。

让复用变得更容易：你要努力的方向，应该是孕育出一个更容易找到和复用已有事物的环境，而不是自己重新编写。如果复用不容易，人们就不会这么做。如果你未能复用，就有重复知识的风险。

正交性：消除不相关事物之间的影响：我们希望设计的组件自成一体，独立自主，有单一的清晰定义的意图。

正交的系统，可以提高生产力和降低风险：

提高生产力：
- 简单的组件将变更限制在局部，开发和测试都会更容易。
- 系统的耦合越松散，重新配置系统和再加工就越容易。
- 正交组件的组合重叠处更小，能有更大的覆盖。
降低风险：
- 病变的代码被隔离开。
- 系统的修改局限于局部。
- 正交的系统更利于测试。
- 只与第三方的接口相关联，不会被供应商紧紧束缚。

不要依赖那些你无法控制的东西。例如，不要使用外部标识符作为用户 ID。

重构：养成不断质疑代码的习惯。只要有机会就重新组织、改善其结构和正交性。

如果某个想法是你唯一的想法，那就没有比它更危险的东西。

使用曳光弹找到目标：最初的曳光弹就是，创建一个简单的 Hello World，确保其能编译和运行。然后再去找整个应用程序中不确定的部分，添加上让它们跑起来的骨架。

是否选择使用领域语言：领域语言即在某个领域有先天便利的语言，在选择是否使用领域语言的时候，需要比较花费的努力和节省的成本，要确信省下的花销（在可预计的长期）足以抵消领域语言的成本。

估算的单位可以反映想要传达的精确性。约125个工作日和约6个月的精确度是不一样的，有不同的上下浮动范围。

人们在现实世界中所做的估算，除了数字之外，还有一系列的预案。每个预案对应着一个估算的数字。

被要求做一个估算时间时说什么：我等一下答复你。放慢节奏，花点时间完成估算的步骤，你总能得到更好的结果。

三、基础工具

熟悉 Shell 命令。图形工具的好处在于所见即所得，弱势之处在于所见即全部。

新手会仔细考虑要做的每个动作，而老司机则是靠本能在开车。

日记本有三大好处：

它比记忆更可靠。
它为你提供了一个地方，用来保存与当前任务无关的想法。这样你就可以继续专注于正在做的事情，并知道这个伟大的想法不会被遗忘。
它就像一种橡皮鸭。这是一个反思的好机会。

四、务实的偏执

防御型驾驶：在麻烦发生前就做好准备，预料到意料之外的事情，永远不要把自己置于无法自拔的境地。

所有的错误都是信息，不要忽略错误信息。

防御性编程就是在浪费时间，让它崩溃。程序被设计成允许出故障，但是故障会由监控程序掌控。

使用断言去预防不可能的事情。不要自我欺骗，特别是在编程的时候。

断言不止是一种调试设施，当程序交付到生产环境时，也要保持断言常开。即使断言会导致性能问题，也只需要关闭那些真正有影响的断言。

不要冲出前灯范围。小步前进，由始至终。总是采取经过深思熟虑的小步骤，同时检查反馈，并在推进前不断调整。把反馈的频率当作速率限制，永远不要进行太大的步骤或任务。

五、宁弯不折

只管命令不要询问：不应该根据对象的内部状态做出决策，然后更新该对象。这样做完全破坏了封装的优势。

响应式应用程序：

有限状态机
- 由一系列状态列表
- 由消息进行状态转换
观察者模式
- 有一个事件源作为被观察对象
- 有一个客户列表作为观察者
发布/订阅（pubsub）
- 与观察者模式相比，pubsub 是一个通过共享接口（信道）来进行抽象来减少耦合的好例子
响应式编程与流
- 数据级响应式编程，例如 React 和 Vue

如果你不能将你正在做的事情描述为一个流程，那表示你不知道自己正在做什么。

在变换式模型中，不要把数据看作是遍布整个系统的小数据池，而要把数据看作是一条浩浩荡荡的河流。数据成为与功能对等的东西，管道是一系列的代码->数据->代码……数据不再和特定的函数组绑定在类定义中，而函数将输入转换为输出。

用接口来表达多态，用委托来提供服务。

六、并发

并发性是一种软件机制，而并行性则和硬件有关。

七、当你编码时

巧合式编程：编程需要深思熟虑，你不知道它为什么能工作，就不知道去如何修好。

重构：重组现有代码实体、改变其内部结构而不改变其外部行为的规范式技术。为了保证外部行为没有改变，你需要良好的自动化单元测试来验证代码的行为。

自上而下学派和自下而上学派实际上都没有成功，因为它们都忽略了软件开发中最重要的一个方面：我们不知道开始时在做什么。自上而下学派认为可以提前表达整个需求，然而他们做不到。自下而上学派假设他们能构建出一系列的抽象，这串抽象最终会将他们带到一个单一的顶层解决方案，但是当不知道方向时，如何决定每一层的功能呢？既非自上而下，也不自下而上，基于端到端构建。我们坚信，构建软件的唯一方法是增量式的。构建端到端功能的小块，一边工作一边了解问题。应用学到的只是持续充实代码，让客户参与每一个步骤并让他们指导这个过程。

基于特性测试：
- 基于契约测试：编写测试用例确保指定的单元遵守了契约。测试是否完成了它所承诺的功能。
- 基于不变式测试：测试部分保持为真的状态。

密码的反模式：严格的密码策略实际上会降低安全性。

应该鼓励长的随机的密码，因为它有更高程度的熵。人为的限制局限了信息熵，助长了使用槽糕密码的习惯，让用户的账户更容易被接管。

不要自己做加密，只应依赖可靠的开源框架和库。

命名名称应表达其意图。不能有误导性，或是令人困惑。

八、项目启动之前

需求是从反馈循环中学到的。你的工作是帮助客户理解他们所陈述需求的后果。你通过激发反馈来做到这一点，并让他们利用反馈来完善自己的想法。

注意力分散的人在解决复杂问题时比有意识的人做的更好。如果你就是不愿意让这个问题搁置一段时间，那么最好的办法就是找个人去解释一下这个问题。通常情况下，围绕它的简单谈论就可以让你分心，从而得到启迪。

九、务实的项目

如果团队对改进和创新是认真的，那么就需要将其排入日程表。只要有空闲时间就去做，意味着这件事情永远不会发生。

每个 Bug 只找一次：一个 Bug 一旦被发现，就应该是被发现的最后一次。要立即修改自动化测试，以便这个特定的 Bug 从此往后每次都被检查到。

当你吸引别人的时候，目标不是从他们身上赚钱或者让他们做你想做的事，而是让他们充满快乐。