相比第一版，书中大约三分之一的主题是全新的，而其余的大部分都被部分或全部重写了。作者再版的目的是，让内容变得更清晰、更贴切，并在某种程度上不受时间的影响。所以可以直接阅读第二版了。
务实的哲学 #
务实的程序员的特质是什么？是他们面临问题时，在解决方案中透出的态度、风格及理念。他们总是越过问题的表面，试着将问题放在更宽泛的上下文中综合考虑，从大局着想。他们的另一个成功点是他们为所做的一切负责。
务实的编程源于务实思考的哲学。
人生是你的 #
软件开发在任何职业列表中，绝对是你自己最能掌控的职业之一。
我们的技能供不应求，我们的知识不限于地域，我们可以远程工作。
我们收入颇丰。我们真的能做我们想做的任何事情。
你有权选择
你的工作环境很糟糕？你的工作很无聊？尝试纠正它。不过不要一直尝试下去，你还可以改变组织，或是让自己换一个组织。
如果你的技术过时了，安排时间学习一些看起来有趣的新东西，这是一种自我投资，只有为此加班才是合理的。
想要远程工作？要求过了吗？如果他们说不行，就去找个说行的人。
我的源码被猫吃了 #
一切行为都要对自己负责，也意味着自己要承担责任。
提供选择，别找借口
给出选择，而不是找借口。不要说搞不定；解释一下要做些什么才能挽回这个局面。
软件的熵 #
不要放任破窗
破窗理论：如果一间房子的一扇窗户破了，运转良好的干净系统会迅速恶化，紧接着，一扇又一扇窗户都会因缺乏维护而破掉，从而使得整个房子变得破败不堪。
不要搁置“破窗”（糟糕的设计、错误的决定、低劣的代码）不去修理。每发现一个就赶紧修一个。如果没有足够的时间完全修好，那么就把它钉起来。也许你可以注释掉那些糟糕的代码，显示一行“尚未实现”的信息，或用假数据先替代一下。采取行动，预防进一步的损害发生，表明一切尽在你的掌握中。
石头做的汤和煮熟的青蛙 #
做推动变革的催化剂
学习士兵。
牢记全景
够好即可的软件 #
将质量要求视为需求问题
知道何时止步。
知识组合 #
对知识组合做定期投资
- 每年学习一门新语言
- 每月读一本技术书
- 还要读非技术书
- 上课
- 加入本地的用户组和交流群
- 尝试不同的环境
- 与时俱进
批判性地分析你读到和听到的东西
问自己几个值得思考的问题：
- ask 5 why
- 谁从中受益
- 有什么背景
- 什么时候在哪里可以工作起来
- 为什么这是个问题
交流 #
英语就是另一门编程语言
说什么和怎么说同样重要
把文档嵌进去，而不要拴在表面
注释源码。
务实的方法 #
优秀设计的精髓 #
优秀的设计比糟糕的设计更容易变更
关注易于变更的能力。
DRY – 邪恶的重复 #
在一个系统中，每一处知识都必须单一、明确、权威地表达。
Don’t repeat yourself
重复的现象有很多：
- 代码中的重复
- 文档中的重复
- 表征的重复
- 内部 API 的重复
- 外部 API 的重复
- 数据源引起的重复
- 开发人员间的重复
让复用变得更容易
正交性 #
“正交性”是从几何学中借用来的术语。若两条直线相交后构成直角，它们就是正交的。在计算科学中，这个术语象征着独立性或解耦性。
排除不相关事物之间的影响
有几种技术可以用来保持正交性：
- 保持代码解藕
- 避免全局数据
- 避免相似的函数
可逆性 #
不设最终决定
放弃追逐时尚
曳光弹 #
你肯定看过那些人们用机关枪射击的电影、电视节目和电子游戏？在这些场景中，会经常看到子弹在空中留下明亮的轨迹线。这些线条来自曳光弹。
和普通弹药间隔着一起被压入弹夹。当曳光弹发射时，上面的磷就会被点燃，在枪和击中物之间留下一道烟火轨迹。如果曳光弹击中了目标，那么之后的常规子弹也会击中。士兵们使用这些曳光弹来调整他们的瞄准：这是一种务实的方法，可以在真实条件下提供实时反馈。
曳光弹式开发和项目不会结束这种理念是一致的：总有东西需要改，总有新功能需要加。这是一个逐步递增的方法。为了在编码中获得相同的效果，我们会找一些东西，能让我们快速、直观、可重复地从需求中得到最终系统的某个方面。
使用曳光弹找到目标
使用曳光弹代码有很多优势：
- 用户可以更早地获得能工作的东西
- 开发者构造了一个可以在其中工作的框架
- 你有了一个集成平台
- 你有可以演示的东西
- 你对进度有更好的感觉
原型与便签 #
使用原型学习
当制作一个原型时，哪些细节可以忽略：
- 正确性：你可以在适当的地方使用替代数据。
- 完整性：原型只需要满足有限的功能，可能只有一个预先选好的输入数据片段及单个菜单选项。
- 健壮性：错误检查可以不完整，甚至完全没有都行。如果你偏离了预定的航线，原型机很可能烧毁在绚丽的烟火中——那又如何！
- 格式：原型代码可能并不需要太多注释和文档（尽管围绕从原型中获取的经验，可能会产生大量文档，但是相对而言，原型系统本身的文档要少得多）。
领域语言 #
靠近问题域编程
估算 #
通过估算来避免意外
根据代码不断迭代进度表
这可能不受管理人员的欢迎，他们通常在项目开始之前就想要一个简单可靠的数字。你必须帮助他们去理解，进度是由团队、团队的生产力和环境综合决定的。明确了这一点，把提炼进度表作为每次迭代的一部分，你就可以估算出能力范围内最精确的进度安排。
基础工具 #
纯文本的威力 #
将知识用纯文本保存
Shell 游戏 #
发挥 shell 命令的威力
加强编辑能力 #
游刃有余地使用编辑器
版本控制 #
共享目录绝非版本控制！
永远使用版本控制
调试 #
去解决问题，而不是责备
最容易欺骗的人就是自己。
Don’t Panic
遇事不要慌。。
修代码前先让代码在测试中失败
读一下那些该死的出错信息
“select” 没出问题
不要假设，要证明
文本处理 #
学习一门文本处理语言
工程日记 #
写日记
务实的偏执 #
你无法写出完美的软件 #
契约式设计 #
通过契约进行设计
契约驱动测试。
死掉的程序不会说谎 #
尽早崩溃
断言式编程 #
使用断言去预防不可能的事情
如何保持资源的平衡 #
有始有终
在局部行动
不要冲出前灯范围 #
我们无法看到遥远的未来，离照射轴越远，就越黑暗。
小步前进 —— 由始至终
避免占卜
很多时候，明天看起来会和今天差不多，但不要指望一定会这样。
宁弯不折 #
如何编写只弯曲却不会折断的代码。
解藕 #
解藕代码让改变更容易
只管命令不要询问
这个原则说的是，不应该根据对象的内部状态做出决策，然后更新该对象。
不要链式调用方法
当你访问某样东西时，尽量不要超过一个“.”。
“一个点”规则有一个很大的例外：如果你链式调用的东西真的不太可能改变，那么这个规则就不适用。
避免全局数据
如果全局唯一非常重要，那么把它包装到 API 中
在现实世界抛球杂耍 #
有限状态机 #
观察者模式 #
发布/订阅 #
响应式编程与流 #
变换式编程 #
所有程序其实都是对数据的一种变换：将输入转换成输出。然而，当我们在构思设计时，很少考虑创建变换过程。相反，我们操心的是类和模块、数据结构和算法、语言和框架。
编程讲的是代码，而程序谈的是数据
不要囤积状态，传递下去
继承税 #
你想要一根香蕉，但得到的却是一只拿着香蕉的大猩猩，甚至还有整个丛林。– 乔·阿姆斯特朗
有点“智商税”的意思。
继承就是耦合。
不要付继承税
更好的替代方案：
- 接口与协议
- 委托
- mixin 与特征
尽量用接口来表达多态
用委托提供服务：“有一个”胜过“是一个”
利用 mixin 共享功能
Django-Rest-Framework 是比较典型的例子。
配置 #
使用外部配置参数化应用程序
并发 #
打破时域耦合 #
时间对我们来说有两个重要的方面：并发性（在同一时刻发生的多件事情）以及次序（事情在时间轴上的相对位置）。
通过分析工作流来提高并发性
共享状态是不正确的状态 #
你坐在最喜欢的餐厅。吃完主菜，问男服务员还有没有苹果派。他回头一看——陈列柜里还有一个，就告诉你“还有”。点到了苹果派，你心满意足地长出了一口气。与此同时，在餐厅的另一边，还有一位顾客也问了女服务员同样的问题。她也看了看，确认有一个，让顾客点了单。
总有一个顾客会失望的。
随机故障通常是并发问题
角色与进程 #
用角色实现并发性时不必共享状态
黑板 #
使用黑板来协调工作流
当你编码时 #
听从蜥蜴脑 #
蜥蜴脑即本能。
倾听你内心的蜥蜴
首先，停止正在做的事情。给自己一点时间和空间，让大脑自我组织。远离键盘，停止对代码的思考，做一些暂时不需要动脑筋的事情——散步、吃午饭、和别人聊天，或是先睡一觉。让想法自己从大脑的各个层面渗透出来：对此不用很刻意。最终这些想法可能会上升到有意识的水平，这样你就能抓住一个“啊哈！”的时刻。
如果这不起作用，就试着把问题外化。把正在写的代码涂画到纸上，或者向你的同事（最好不是程序员）解释一下是怎么回事，向橡皮鸭解释一下也行。
但也许在试过这些方法后，还是无法脱困。那么就该行动了。我们需要告诉大脑：打算要做的事情，并没有那么重要。可以用做原型的方式来干这件事。
巧合式编程 #
不要依赖巧合编程
首先判别什么是巧合，并对此形成识别模式，其次决策依据里不能有巧合和假设。
算法速度 #
评估算法的级别
对估算做测试
重构 #
何时该重构：
- 重复，发现了一处违背 DRY 原则的地方。
- 非正交设计
- 过时的知识
- 使用：当系统在真实的环境中被真实的人使用时，你会意识到，与以前的认识相比，一些特性现在看来更为重要，反而“必须拥有”的特性可能并不重要。
- 性能
- 通过了测试
尽早重构，经常重构
对编码测试 #
测试与找 Bug 无关
测试是代码的第一个用户
既非自上而下，也不自下而上，基于端对端构建
为测试做设计
要对软件做测试，否则只能留给用户去做
基于特性测试 #
使用基于特性的测试来校验假设
出门在外注意安全 #
务实的程序员有相当多的偏执。我们知道自己有缺陷和限制，外部攻击者会抓住每个我们留下的漏洞去破坏系统。特定的开发和部署环境，将有其自己的围绕安全性的需求，但是你应该始终牢记一些基本原则。
将攻击面的面积最小化
系统攻击面的面积指，攻击者可以在其中输入数据、提取数据或调用服务执行的所有访问点的总和。
保持代码简洁，让攻击面最小，代码复杂性滋生攻击载体
输入数据是一种攻击载体
未经身份认证的服务成为攻击载体
经过身份认证的服务成为攻击载体
输出数据成为攻击载体
调试信息成为攻击载体
最小特权原则
在最短的时间内使用最少的特权。换句话说，不要自动获取类似root 或 Administrator 这样的最高级别权限。如果真需要这么高级别的权限，那就去申请，获得权限后只做最少量的工作，然后迅速放弃权限，这样可以降低风险。
安全的默认值
例如，密码输入的默认设置可能是隐藏输入，用星号替换每个字符。
敏感数据要加密
不要将个人身份信息、财务数据、密码或其他凭据，以纯文本的形式保存在数据库或其他外部文件中。如果数据被泄露，加密提供了额外的安全级别。
维护安全更新，尽早打上安全补丁
了解一些密码学常识。
事物命名 #
名字有着深刻的含义。
在计算机科学中只有两件难事：缓存失效和命名。
好好取名；需要时更名
项目启动之前 #
需求之坑 #
无人确切知道自己想要什么
程序员帮助人们理解他们想要什么
需求是从反馈循环中学到的
和用户一起工作以便从用户角度思考
策略即原数据
使用项目术语表
如果用户和开发者使用不同的名称来称呼相同的事物，或者更糟糕的是，使用相同的名称来指代不同的事物，那么项目就很难取得成功。
处理无法解决的难题 #
不要跳出框框思考：找到框框
携手共建 #
康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构。
结对编程
群体编程
不要一个人埋头钻进代码中
敏捷的本质 #
敏捷不是一个名词，敏捷有关于你如何做事。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值。
务实的项目 #
务实的团队 #
维持小而稳定的团队
团队的工作不应仅致力于开发新功能，还可能包括：
- 旧系统的维护
- 流程的反思与精炼
- 实验新技术
- 学习和提升技能
派上日程以待其成
组织全功能的团队
椰子派不上用场 #
人们容易受到诱惑，掉入货物崇拜的陷阱：通过投资去造出神奇的外观，希望吸引来潜在有效的魔法。但与最初发生在美拉尼西亚的货物崇拜一样，用椰子壳制成的赝品是替代不了真机场的。
做能起作用的事，别赶时髦
在用户需要时交付
务实的入门套件 #
使用版本控制来驱动构建、测试和发布
尽早测试，经常测试，自动测试
直到所有的测试都已经运行，编码才算完成
使用破坏者检测你的测试
测试状态覆盖率，而非代码覆盖率
每个 Bug 只找一次
一个 Bug 一旦被人类测试员发现，这就应该是它被该人类测试员发现的最后一次。要立即修改自动化测试，以便这个特定的 Bug，从此往后每次都被检查到 —— 不能有任何例外，无论它多么琐碎，也无论开发者有多少抱怨，或是不停唠叨“哦，永远不会再发生了”。
不要使用手动程序
人不像电脑那样具有可重复性。我们也不应对此抱有期望。shell 脚本或程序将一次又一次地以相同的顺序执行相同的指令。
一切都要依赖自动化。
取悦用户 #
作为开发者，我们的目标是取悦用户。
用户真正要的不是代码，他们只是遇到某个业务问题，需要在目标和预算范围内解决。他们的信念是，通过与你的团队合作，能够做到这一点。
取悦用户，而不是只交付代码
如果你想取悦客户，就和他们建立起某种关系，这样即可积极地帮助他们解决问题。
傲慢与偏见 #
在作品上签名
保持匿名会滋生粗心、错误、懒惰和糟糕的代码，特别是在大型项目中 —— 很容易把自己看成只是大齿轮上的一个小齿，在无休止的工作汇报中制造蹩脚的借口，而不是写出好的代码。
跋 #
先勿伤害
请问自己：我自己愿意成为这个软件的用户吗？我希望分享自己的详细信息吗？我希望自己的行踪被交给零售店吗？我愿意乘坐这辆自动驾驶汽车吗？做这件事我能心安吗？
有一些创造性的想法，开始打道德行为界限的擦边球，如果你参与了这类项目，就和出资者一样负有责任。
不要助纣为虐
你正在为自己和子孙后代建设未来——这是你的职责所在，去创造一个让所有人心向往之的宜居未来。当你做的事情违背了这个理想时，要敢于承认，并有勇气说“不！”对可以拥有的未来充满憧憬，才有动力去创造它。即使是空中楼阁，也要每天为它添砖加瓦。
我们都有精彩的人生。