（1）这是一本 “课外”书。知道如何编写代码，仅仅是“战斗的一半”。像与资深导师喝咖啡一样，本书将教授你学校里计算机课没有涉及的技能。
（2）这是一本有态度的书。公司之间总有差异，基本原理总是相通。书中构建团队的经验取自那些快速成长的、由风险投资公司资助的或者准上市的硅谷公司。
（3）这是一张进军职场“线路图”。资深之路选择多，请主导你自己的晋升。本书涵盖构建、测试和运行生产软件的现代实践，使团队更强大和使队友更默契的行为和多种方法，供你选择。
（4）作者是Zymergen 的软件工程副总裁和Apache Samza的作者，在 PayPal、LinkedIn、WePay 和 Twitter等主要科技公司拥有十多年的经验。

对于刚刚成为软件工程师的新手来说，知道如何编写代码只是成功了一半。你可能很快就会发现，学校并没有教授在现实世界中至关重要的技能和工作中必要的流程。本书恰恰填补了这一环节，它是作者十多年来在大型公司指导初级工程师工作的教程，涵盖软件工程的基础知识和best实践。本书第1～2章讲解当你在公司开启你的职业生涯时会发生什么；第3～11章会扩展你的工作技能，教你如何使用现有代码库、解决和防止技术债、编写生产级软件、管理依赖关系、有效地测试、评审代码、交付软件、处理On-Call时的事故和构建可演进的架构等；剩余章节涵盖管理能力和职业阶梯的提升等相关内容，例如敏捷计划、与管理者合作以及成长为资深工程师的必经之路。本书中非常重要的一部分内容是教你如何应对糟糕的管理，以及如何调整自己的节奏。本书内容不仅浅显易懂，还覆盖整个软件开发周期，是一本技术主管希望每名新入行的工程师在开始工作之前都能阅读的书。

第1章前面的旅程1
1.1你的目的地1
1.2你的旅程地图2
1.2.1新手营3
1.2.2试炼之河5
1.2.3贡献者之角5
1.2.4运维之海6
1.2.5胜任之湾6
1.3前进！7

第2章步入自觉阶段8
2.1学习如何学习9
2.1.1前置学习9
2.1.2在实践中学习9
2.1.3运行实例代码11
2.1.4阅读11
2.1.5观看讲座13
2.1.6适度地参加会议和聚会14
2.1.7跟班学习并同有经验的工程师结对15
2.1.8用副业项目实践16
2.2提出问题17
2.2.1动手调查一下17
2.2.2设置一个时间17
2.2.3写下全过程18
2.2.4别打扰别人19
2.2.5多用“非打扰式”交流20
2.2.6批量处理你的同步请求20
2.3克服成长的障碍21
2.3.1冒充者综合征21
2.3.2邓宁-克鲁格效应22
2.4行为准则23
2.5升级加油站23

第3章玩转代码25
3.1软件的熵26
3.2技术债26
3.3变更代码29
3.3.1善于利用现有代码30
3.3.2过手的代码要比之前更干净32
3.3.3做渐变式的修改33
3.3.4对重构要务实33
3.3.5善用IDE34
3.3.6请使用VCS的很好实践34
3.4避“坑”指南35
3.4.1保守一些的技术选型36
3.4.2不要特立独行39
3.4.3不要只分叉而不向上游提交修改40
3.4.4克制重构的冲动40
3.5行为准则42
3.6升级加油站42

第4章编写可维护的代码44
4.1防御式编程45
4.1.1避免空值45
4.1.2保持变量不可变46
4.1.3使用类型提示和静态类型检查器46
4.1.4验证输入47
4.1.5善用异常49
4.1.6异常要有准确含义50
4.1.7早抛晚捕51
4.1.8智能重试52
4.1.9构建幂等系统53
4.1.10及时释放资源53
4.2关于日志的使用54
4.2.1给日志分级55
4.2.2日志的原子性56
4.2.3关注日志性能57
4.2.4不要记录敏感数据59
4.3系统监控59
4.3.1使用标准的监控组件60
4.3.2测量一切63
4.4跟踪器64
4.5配置相关注意事项64
4.5.1配置无须新花样65
4.5.2记录并校验所有的配置66
4.5.3提供默认值67
4.5.4给配置分组67
4.5.5将配置视为代码67
4.5.6保持配置文件清爽68
4.5.7不要编辑已经部署的配置68
4.6工具集68
4.7行为准则70
4.8升级加油站71

第5章依赖管理72
5.1依赖管理基础知识73
5.1.1语义化版本74
5.1.2传递依赖75
5.2相依性地狱76
5.3避免相依性地狱80
5.3.1隔离依赖项80
5.3.2按需添加依赖项81
5.3.3指定依赖项的版本82
5.3.4依赖范围最小化84
5.3.5保护自己免受循环依赖的影响84
5.4行为准则85
5.5升级加油站85

第6章测试87
6.1测试的多种用途87
6.2测试类型88
6.3测试工具91
6.3.1模拟库91
6.3.2测试框架92
6.3.3代码质量工具93
6.4自己动手编写测试95
6.4.1编写干净的测试95
6.4.2避免过度测试96
6.5测试中的确定性98
6.5.1种子随机数生成器99
6.5.2不要在单元测试中调用远程系统99
6.5.3采用注入式时间戳99
6.5.4避免使用休眠和超时102
6.5.5记得关闭网络套接字和文件句柄102
6.5.6绑定到0端口103
6.5.7生成专享的文件路径和数据库位置103
6.5.8隔离并清理剩余的测试状态103
6.5.9不要依赖测试顺序104
6.6行为准则105
6.7升级加油站105

第7章代码评审107
7.1为什么需要评审代码107
7.2当你的代码被评审时109
7.2.1准备工作109
7.2.2用评审草案降低风险110
7.2.3提交评审请勿触发测试111
7.2.4预排大体量的代码修改111
7.2.5不要太在意112
7.2.6保持同理心，但不要容忍粗鲁113
7.2.7保持主动113
7.3评审别人的代码时114
7.3.1分流评审请求114
7.3.2给评审预留时间114
7.3.3理解修改的意图115
7.3.4提供全面的反馈115
7.3.5要承认优点116
7.3.6区分问题、建议和挑剔116
7.3.7不要只做橡皮图章117
7.3.8不要只局限于使用网页版的评审工具118
7.3.9不要忘记评审测试代码118
7.3.10推动决断118
7.4行为准则119
7.5升级加油站120

第8章软件交付121
8.1软件交付流程121
8.2分支策略122
8.3构建环节125
8.3.1打包需要带版本号126
8.3.2将不同的资源单独打包127
8.4发布环节129
8.4.1请勿只想着发布129
8.4.2将包发布到仓库130
8.4.3保持版本不变性131
8.4.4频繁发布131
8.4.5对发布计划保持透明132
8.4.6撰写变更日志和发行说明132
8.5部署环节133
8.5.1自动部署133
8.5.2部署的原子性134
8.5.3独立地部署应用134
8.6展开环节136
8.6.1系统监控137
8.6.2特性开关137
8.6.3熔断器138
8.6.4并行的服务版本梯队139
8.6.5摸黑启动141
8.7行为准则143
8.8升级加油站144

第9章On-Call146
9.1On-Call的工作方式147
9.2On-Call技能包148
9.2.1随时响应148
9.2.2保持专注148
9.2.3确定工作优先级149
9.2.4清晰的沟通150
9.2.5跟踪你的工作151
9.3事故处理152
9.3.1分流153
9.3.2协同154
9.3.3应急方案155
9.3.4解决方案157
9.3.5后续行动159
9.4提供支持162
9.5不要逞英雄164
9.6行为准则165
9.7升级加油站165

第10章技术设计流程167
10.1技术设计的V形结构168
10.2关于设计的思考169
10.2.1定义问题170
10.2.2着手调查171
10.2.3进行实验172
10.2.4给些时间173
10.3撰写设计文档174
10.3.1文档持续变更174
10.3.2了解撰写文档的目的175
10.3.3学会写作176
10.3.4保证文档是近期新的176
10.4使用设计文档模板177
10.4.1概要178
10.4.2现状与背景178
10.4.3变更的目的178
10.4.4需求179
10.4.5潜在的解决方案179
10.4.6建议的解决方案180
10.4.7设计与架构180
10.4.8测试计划181
10.4.9发布计划181
10.4.10遗留的问题181
10.4.11附录181
10.5协作设计182
10.5.1理解你的团队的设计评审流程182
10.5.2不要让人惊讶183
10.5.3用设计讨论来进行头脑风暴183
10.5.4为设计出力184
10.6行为准则185
10.7升级加油站185

第11章构建可演进的架构187
11.1理解复杂性188
11.2可演进的设计189
11.2.1你不是真的需要189
11.2.2最小惊讶原则191
11.2.3封装专业领域知识193
11.3可演进的API193
11.3.1保持API小巧194
11.3.2公开定义良好的服务端API194
11.3.3保持API变更的兼容性195
11.3.4API版本化198
11.4可持续的数据管理199
11.4.1数据库隔离199
11.4.2使用schema201
11.4.3schema自动化迁移203
11.4.4保持schema的兼容性206
11.5行为准则207
11.6升级加油站208

第12章敏捷计划210
12.1敏捷宣言210
12.2敏捷计划的框架211
12.3Scrum框架212
12.3.1用户故事213
12.3.2任务分解214
12.3.3故事点214
12.3.4消化积压216
12.3.5冲刺计划216
12.4站会217
12.5评审机制218
12.6回顾会219
12.7路线图220
12.8行为准则221
12.9升级加油站222

第13章与管理者合作223
13.1管理者是做什么的223
13.2沟通、目标与成长224
13.2.1一对一面谈225
13.2.2PPP227
13.2.3OKR229
13.2.4绩效考核230
13.3向上管理232
13.3.1接收反馈232
13.3.2给予反馈233
13.3.3讨论你的目标235
13.3.4事情不顺时要采取行动236
13.4行为准则238
13.5升级加油站239

第14章职业生涯规划241
14.1迈向资深之路241
14.2职业生涯建议242
14.2.1T型人才242
14.2.2参加工程师训练营243
14.2.3主导你自己的晋升244
14.2.4换工作需谨慎246
14.2.5自我调节247
14.3结尾寄语248

【摘自推荐序】
在本书的前几章中，“提问”就被高度重视，这让我感到非常高兴。向同事提问和学习是快速成长和习得新技能的有效方式。为你的工作成果感到自豪通常是件好事，但当自己在持续改进和交付中比以前做得更好时，你应该优先感到自豪。
这本书针对如何改进、如何学习、如何推进职业生涯发展，以及如何成为一名更好的开发者提供不同的方法和步骤。这本书包含适应团队的工作流程、处理会议、如期交付、善用学习工具和技术领域的best实践，并指导人们如何成为团队中有价值的成员。
向资深工程师寻求帮助可能会让人感到一丝畏惧，因为打断他们的工作通常是不妥的。资深工程师往往在聚精会神工作时会因为被打扰而失去在脑海中已构建的系统的短期记忆，但大多数资深工程师都很愿意提供帮助，优秀的资深工程师更是以指导和协助他人为荣。如果你在寻求帮助时感受到了敌意，大可不必心烦意乱，因为这在每个人身上都可能发生。不要让某一次糟糕的遭遇阻断了你再次寻求帮助的欲望。但总是打断他人的工作并非是合适的，这时就可以使用这本书中涵盖的其他策略和原则，它们都可以指导你将职业生涯提升到新的阶段。
无论你处于职业生涯的哪个阶段，这本书都非常实用。请保持开放的心态，好学深思，渴望提高，不惧破旧习，不惧提问题。
——雅克·奥洛夫松（Jerker Olofsson），索尼移动公司前核心架构师
【摘自译者序】
本书的两位作者在最后一章中说：“你可以为任何行业做出贡献，从科学到农业、健康、娱乐，甚至是太空探索。”我一直都认为软件工程师的工作带来的成就感并不亚于小说家、建筑师或音乐家。软件开发本身带来的欣喜是一种“尤里卡时刻”的幸福体验，尤其是在无数个面对调试器“狂按”F10 键的夜晚，自己提交的特性成功上线时的喜悦，抑或是眼看着自己设计的技术架构方案从纸面上的框图到代码实现再到最终交付的满足感。
当然在软件行业工作也有艰辛，变动的需求、阻滞的沟通、糟糕的管理和紧迫的工期，总有些时刻会令人产生倦怠。毕竟真实世界中并不存在只和机器进行沟通的工作，更多的还是人与人之间的交流。本书能够很好地帮助刚刚踏入这个行业的工程师去认识真实世界。似乎从来都是程序员为他人撰写README，从来没有人为程序员撰写过README。
由于工作的关系，我个人不仅参与过采用瀑布流模型的传统项目，也参与过靠前灵活多变的研发项目，以及采用改良后的Scrum 框架的敏捷项目。虽然各自采用的开发模型不尽相同，但是遇到的问题都很相似。在实际的工作中，成功地交付软件并不是只有专享的路径可走。如何衡量与之匹配的需求、成本和风险才是考验团队的地方。本书中，两位作者提到了软件开发过程中的诸多困境，在我曾经的工作中也遇到过类似的情况。至今我还记得曾经有一次由于共享的数据层竞合而引发的生产环境故障，整个团队高负荷地工作了一周才最终解决。而在应对这起故障的过程中，团队明明在非常积极地处理，却引起了客户的极大不满。让客户不满的并不是故障本身，而是出了故障之后得不到应急方案导致了长时间的服务器宕机。如果那个时候能采用本书中提到的事故处理的标准流程（分流、协同、应急方案、解决方案和后续行动），那么很多弯路就可以避免了。
——付裕，本书译者