想象你想要的未来，对可以拥有的未来充满憧憬，才有动力去创造它。即使是空中楼阁，也要每天为它添砖加瓦。
前言
没有最好的解决方案，无论是工具语言还是操作系统；只有在特定的环境下才有所谓更合适的系统。
在一个项目的整体结构中，总有个性和技艺的空间。但是软件构造的工程成分并不妨碍个体的技艺。
我们，采集的只是石头，却必须始终展望着未来的大教堂。
一、务实的哲学
我活着不是为了满足你的期望，正如你也不是因为我的期望而活着。
你有权选择，只是需要积极主动去掌控这些机遇。
提供选择，别找借口。解释一下要做什么才能挽回这个局面。
不要搁置破窗（糟糕的设计、错误的决定、低劣的代码）不去修理，每发现一个就赶紧修理一个。也可以注释掉，或使用代码桩替代，预防进一步的损害发生，表明一切尽在你的掌握中。
也不要因为一些东西非常危急，就去造成附带伤害。
石头做的汤：使用一个原型作为推动变革的催化剂，人们都觉得，加入一个推进中的项目更容易一些。因为只要一窥未来，大家就能团结在一起。
煮熟的青蛙：不要学寓言里的青蛙，永远留意着大局，持续不断地审视你身边发生的事情，而不要只专注于你个人在做的事情。
许多用户宁愿今天就用上一个毛糙的软件，也不愿意多等上一年再用那个打磨光亮、功能齐备的版本，而且，实际上他们一年后真正需要的东西可能完全不同。今天还不错的软件通常更讨人喜欢，如果你早点给用户一点东西玩，他们的反馈常常能引领你做出更好的最终方案。
持续投资非常重要。一旦你进入了对某个新语言或新技术的舒适期，向前走，再学一个。想法的交叉传授是很重要的，试着把你领悟到的东西应用到你当前的项目中。
了解听众：注意看肢体语言和面部表情。所获对方的反应即沟通的意义，在交流的过程中，不断提高对听众的了解。
通过提供鼓励人们交谈，试着让他们总结你的发言。把会议变成一场对话，你将更有效地表达你的观点。说不定还可以学到一些东西。
越是有效的交流，影响力就越大。
二、务实的方法
优秀的设计比糟糕的设计更容易变更（ETC：Easier To Change）：能适应使用者的就是好的设计。对代码而言，就是要顺应变化。
DRY（邪恶的重复）：在一个系统中，每一处知识都必须单一、明确、权威地表达。
一个模块提供的所有服务都应该通过统一的约定来提供，该约定不应表露出其内部实现是基于存储的还是基于运算的。
让复用变得更容易：你要努力的方向，应该是孕育出一个更容易找到和复用已有事物的环境，而不是自己重新编写。如果复用不容易，人们就不会这么做。如果你未能复用，就有重复知识的风险。
正交性：消除不相关事物之间的影响：我们希望设计的组件自成一体，独立自主，有单一的清晰定义的意图。
正交的系统，可以提高生产力和降低风险：
提高生产力： 简单的组件将变更限制在局部，开发和测试都会更容易。系统的耦合越松散，重新配置系统和再加工就越容易。正交组件的组合重叠处更小，能有更大的覆盖。 降低风险： 病变的代码被隔离开。系统的修改局限于局部。正交的系统更利于测试。只与第三方的接口相关联，不会被供应商紧紧束缚。
不要依赖那些你无法控制的东西。例如，不要使用外部标识符作为用户 ID。
重构：养成不断质疑代码的习惯。只要有机会就重新组织、改善其结构和正交性。
如果某个想法是你唯一的想法，那就没有比它更危险的东西。
使用曳光弹找到目标：最初的曳光弹就是，创建一个简单的 Hello World，确保其能编译和运行。然后再去找整个应用程序中不确定的部分，添加上让它们跑起来的骨架。
是否选择使用领域语言：领域语言即在某个领域有先天便利的语言，在选择是否使用领域语言的时候，需要比较花费的努力和节省的成本，要确信省下的花销（在可预计的长期）足以抵消领域语言的成本。
估算的单位可以反映想要传达的精确性。约125个工作日和约6个月的精确度是不一样的，有不同的上下浮动范围。
人们在现实世界中所做的估算，除了数字之外，还有一系列的预案。每个预案对应着一个估算的数字。
被要求做一个估算时间时说什么：我等一下答复你。放慢节奏，花点时间完成估算的步骤，你总能得到更好的结果。
三、基础工具
熟悉 Shell 命令。图形工具的好处在于所见即所得，弱势之处在于所见即全部。
新手会仔细考虑要做的每个动作，而老司机则是靠本能在开车。
日记本有三大好处：
它比记忆更可靠。它为你提供了一个地方，用来保存与当前任务无关的想法。这样你就可以继续专注于正在做的事情，并知道这个伟大的想法不会被遗忘。它就像一种橡皮鸭。这是一个反思的好机会。
四、务实的偏执
防御型驾驶：在麻烦发生前就做好准备，预料到意料之外的事情，永远不要把自己置于无法自拔的境地。
所有的错误都是信息，不要忽略错误信息。
防御性编程就是在浪费时间，让它崩溃。程序被设计成允许出故障，但是故障会由监控程序掌控。
使用断言去预防不可能的事情。不要自我欺骗，特别是在编程的时候。
断言不止是一种调试设施，当程序交付到生产环境时，也要保持断言常开。即使断言会导致性能问题，也只需要关闭那些真正有影响的断言。
不要冲出前灯范围。小步前进，由始至终。总是采取经过深思熟虑的小步骤，同时检查反馈，并在推进前不断调整。把反馈的频率当作速率限制，永远不要进行太大的步骤或任务。
五、宁弯不折
只管命令不要询问：不应该根据对象的内部状态做出决策，然后更新该对象。这样做完全破坏了封装的优势。
响应式应用程序：
有限状态机 由一系列状态列表由消息进行状态转换 观察者模式 有一个事件源作为被观察对象有一个客户列表作为观察者 发布/订阅（pubsub） 与观察者模式相比，pubsub 是一个通过共享接口（信道）来进行抽象来减少耦合的好例子 响应式编程与流 数据级响应式编程，例如 React 和 Vue
如果你不能将你正在做的事情描述为一个流程，那表示你不知道自己正在做什么。
在变换式模型中，不要把数据看作是遍布整个系统的小数据池，而要把数据看作是一条浩浩荡荡的河流。数据成为与功能对等的东西，管道是一系列的代码->数据->代码……数据不再和特定的函数组绑定在类定义中，而函数将输入转换为输出。
用接口来表达多态，用委托来提供服务。
六、并发
并发性是一种软件机制，而并行性则和硬件有关。
七、当你编码时
巧合式编程：编程需要深思熟虑，你不知道它为什么能工作，就不知道去如何修好。
重构：重组现有代码实体、改变其内部结构而不改变其外部行为的规范式技术。为了保证外部行为没有改变，你需要良好的自动化单元测试来验证代码的行为。
自上而下学派和自下而上学派实际上都没有成功，因为它们都忽略了软件开发中最重要的一个方面：我们不知道开始时在做什么。自上而下学派认为可以提前表达整个需求，然而他们做不到。自下而上学派假设他们能构建出一系列的抽象，这串抽象最终会将他们带到一个单一的顶层解决方案，但是当不知道方向时，如何决定每一层的功能呢？既非自上而下，也不自下而上，基于端到端构建。我们坚信，构建软件的唯一方法是增量式的。构建端到端功能的小块，一边工作一边了解问题。应用学到的只是持续充实代码，让客户参与每一个步骤并让他们指导这个过程。
基于特性测试：基于契约测试：编写测试用例确保指定的单元遵守了契约。测试是否完成了它所承诺的功能。基于不变式测试：测试部分保持为真的状态。
密码的反模式：严格的密码策略实际上会降低安全性。
应该鼓励长的随机的密码，因为它有更高程度的熵。人为的限制局限了信息熵，助长了使用槽糕密码的习惯，让用户的账户更容易被接管。
不要自己做加密，只应依赖可靠的开源框架和库。
命名名称应表达其意图。不能有误导性，或是令人困惑。
八、项目启动之前
需求是从反馈循环中学到的。你的工作是帮助客户理解他们所陈述需求的后果。你通过激发反馈来做到这一点，并让他们利用反馈来完善自己的想法。
注意力分散的人在解决复杂问题时比有意识的人做的更好。如果你就是不愿意让这个问题搁置一段时间，那么最好的办法就是找个人去解释一下这个问题。通常情况下，围绕它的简单谈论就可以让你分心，从而得到启迪。
九、务实的项目
如果团队对改进和创新是认真的，那么就需要将其排入日程表。只要有空闲时间就去做，意味着这件事情永远不会发生。
每个 Bug 只找一次：一个 Bug 一旦被发现，就应该是被发现的最后一次。要立即修改自动化测试，以便这个特定的 Bug 从此往后每次都被检查到。
当你吸引别人的时候，目标不是从他们身上赚钱或者让他们做你想做的事，而是让他们充满快乐。
想象你想要的未来，对可以拥有的未来充满憧憬，才有动力去创造它。即使是空中楼阁，也要每天为它添砖加瓦。
