前言
本书阅读完毕，将该书所列的要点进行记录，便于自己进行回顾（自检）。
第1章 前面的旅程
所要达到的
技术知识
你知道计算机科学的基础知识。你知道如何使用集成开发环境(IDE)、构建系统、调试代码和测试框架。你熟悉持续集成、系统指标和监控、配置和打包系统。你积极主动地创建和改进测试代码。在做架构决策时，你会考虑到长期运维。
执行力
你通过用代码解决问题来创造价值，并且你了解你的工作和业务之间的联系。你已经可以构建并部署中小型的特性。你会编写、测试和评审代码。你分担On-Call的职责，调试运维问题。你是积极主动并且可靠的。你参加技术讲座、阅读小组、面谈和路演。
沟通能力
你能同时以书面和口头的形式进行清晰的沟通。你能够有效地给予和接受反馈。在模棱两可的情况下，你会主动寻求帮助并得到明确的结果。你能以建设性的方式提出问题和定义课题。你在可能的情况下可以提供帮助，并开始影响同事。你会文档化你的工作。你撰写清晰的设计文档并征求反馈意见。在与他人打交道时，你富有耐心和同理心。
领导力
你能在指定的工作范围内独立地完成工作。你能迅速地从错误中学习。你能很好地处理变动和模糊的问题。你积极参与到项目和季度的规划中。你能帮助新的成员融入团队。你可以向你的管理者提供有意义的反馈。
如何到达
通过学习本书提到的各个章节并进行运用。
第2章 步入自觉阶段
需要做的
- 多尝试和实验代码
- 多阅读设计文档和他人的代码
- 参加一些聚会、在线社区、兴趣小组和导师计划
- 多读论文和博客
- 多采用“非打扰式”交流
- 旁听面议以及参与 On-Call 轮换
不应该做的
- 只是大量炮制劣质代码
- 害怕承担风险和失败
- 过于频繁地参加研讨会
- 害怕提出问题
书籍推荐
- 在新的环境中起步，从中寻求指导，深入地学习技能，并克服常见的障碍：戴夫·胡佛和阿德瓦莱·奥希尼亚《软件开发者路线图：从学徒到高手》（Apprenticeship Patterns: Guidance for the AspiringSoftware Craftsman，已由机械工业出版社于2010年引进出版）
- 如何提问：韦恩·贝克《你要做的全部就是提问：如何掌握成功最重要的技能》（All You Have to DoIs Ask:How to Master the Most Important Skill for Success，由Currency出版社于2020年出版）
- 结对编程：肯特·贝克和辛西娅·安德烈斯《解析极限编程——拥抱变化》（Extreme Programming Explained: Embrace Change，已由机械工业出版社于2011年引进出版）
- 结对编程：比吉塔·贝克勒和尼娜·西塞格《论结对编程》(“On Pair Programming”)
- 冒充者综合征或邓宁-克鲁格效应：埃米·卡迪《高能量姿势：肢体语言打造个人影响力》（Presence: Bringing Your Boldest Self to Your Biggest Challenges，已由中信出版集团于2019年引进出版）
第3章 玩转代码
需要做的
- 进行渐进式的重构
- 从新特性的提交中剥离重构的部分
- 保持以小规模的方式修改代码
- 将过手的代码整理得比之前更干净
- 使用保守的技术选型
不应该做的
- 过度使用“技术债”这个词
- 为了适应测试而将变量或方法变成公共的
- 成为编程语言上的“势利眼”
- 忽视你公司的标准和工具集
- 只分叉而不向上游提交修改
书籍推荐
- 迈克尔·C.费瑟斯《修改代码的艺术》
- 处理庞大而混乱的代码库：乔纳森·博卡拉《处理遗留代码的工具箱：软件专业人员处理遗留代码的专业技能》（The Legacy Code Programmer’s Toolbox: Practical Skills for Software Professionals Working with Legacy Code，由LeanPub于2019年出版）
- 重构：马丁·福勒《重构：改善既有代码的设计》（Refactoring: Improving the Design of Existing Code，已由人民邮电出版社于2010年引进出版）
- 软件项目在实践中如何运转：弗雷德里克·布鲁克斯《人月神话》
第4章 编写可维护的代码
需要做的
- 宁愿编译出错，也不要运行出错
- 尽可能使事情不可变
- 校验输入和输出
- 去学习 OWASP 的十大报告
- 使用 bug 检查工具和类型提示的特性
- 在异常之后清理资源（尤其是端口、文件指针和内存）
- 使用系统指标来监控你的代码
- 让你的程序可以配置
- 检验和记录所有的配置
不应该做的
- 在程序逻辑中应用异常
- 在异常处理中只返回错误码
- 捕获你无法处理的异常
- 写入带折行的日志
- 在日志中记载秘密或敏感的数据
- 单独在某台计算机上手动修改配置
- 在配置文件中存储密码或秘密信息
- 写定制化的配置格式
- 在可以避免的情况下使用动态配置
书籍推荐
- 史蒂夫·麦康奈尔《代码大全：软件构造之实践指南》（Code Complete: A Practical Handbook of Software Construction，已由电子工业出版社于2006年引进出版）第8章涉及防御性编程
- 罗伯特·C.马丁《代码整洁之道》（Clean Code: A Handbook of Agile Software Craftsmanship，已由人民邮电出版社于2020年引进出版）第7章和第8章涉及错误处理和边界
- 亚马逊构建者库
- 谷歌SRE小组《Google系统架构解密：构建安全可靠的系统》（Building Secure & Reliable Systems：Best Practices for Designing, Implementing, and Maintaining Systems，已由人民邮电出版社于2021年引进出版）
- 网站可靠性：谷歌《SRE：Google运维解密》（Site Reliability Engineering: How Google Runs Production Systems，已由电子工业出版社于2016年引进出版）
第5章 依赖管理
需要做的
- 务必使用语义化版本
- 明确指定依赖版本的范围
- 务必使用依赖关系报告工具来分析传递依赖
- 添加新的依赖项时，请务必持怀疑态度
- 精确地使用依赖范围
不应该做的
- 使用 Git 的哈希值当作版本号
- 在收益未超过成本时添加依赖项
- 直接使用传递来的依赖项
- 引入循环依赖
书籍推荐
- 自行搜索一些关于相依性地狱的文章和参考资料
- 语义化版本管理的紧凑而可读的规范：SemVer的官方主页和Python官方主页
- 语义化版本管理的紧凑而可读的规范：遵循帕累托法则，我们不建议你在刚开始的时候就对语义化版本进行过深的研究，除非这是你工作范畴中明确的一环，或者你需要更多的信息来解决某个具体的问题。
第6章 测试
需要做的
- 使用测试去重现 bug
- 使用模拟工具去帮助编写单元测试
- 使用代码质量工具去检查覆盖率、格式和复杂度
- 在测试中使用常数种子的随机数生成器
- 在测试后关闭网络套接字和文件句柄
- 在测试中生成唯一的文件路径和数据库位置
- 在测试执行的间隙清理掉遗留的测试状态
不应该做的
- 忽视添加新测试工具时的成本
- 依赖于他人为你编写测试用例
- 仅仅为了提高覆盖率而编写测试
- 仅仅将代码覆盖率作为代码质量的衡量标准
- 在测试中使用可以避免的休眠和超时
- 在单元测试中调用远程系统
- 依赖于测试执行顺序
书籍推荐
- 我们建议可以针对具体的测试技术去阅读，而不是阅读详尽的测试教科书。
- 测试的最佳实践：弗拉基米尔·霍里科夫《单元测试：原则、实践与模式》（Unit Testing: Principles,Practices, and Patterns，由Manning出版社于2020年出版）
- TDD：肯特·贝克《测试驱动开发：实战与模式解析》（Test-Driven Development: By Example，已由机械工业出版社于2013年引进出版）
- 属性测试：安德鲁·亨特和戴维·托马斯《程序员修炼之道——从小工到专家》（The Pragmatic Programmer: From Journeyman to Master，已由电子工业出版社于2011年引进出版）中关于基于属性的测试的部分
- 探索性测试来学习代码：伊丽莎白·亨德里克森《探索吧！深入理解探索式软件测试》（Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing，已由机械工业出版社于2014年引进出版）
第7章 代码评审
需要做的
- 在提交评审请求之前保证通过了测试和代码检测工具的检查
- 为代码评审预留出专门的时间，像对待其他工作一样对待评审工作
- 当评审意见很粗鲁、没有建设性或者有不当言论的时候，请明确指出来
- 通过适当提供相应修改的背景信息来帮助评审者
- 在进行代码评审时，超越肤浅的对代码风格的指摘
- 用尽一切工具去理解棘手的代码改动，不要只依赖评审工具自身的界面
- 将测试代码纳入评审范围
不应该做的
- 仅仅为了触发 CI 系统而提交评审请求
- 只做橡皮图章
- 和代码“坠入爱河”或者把评审的反馈意见当作私人恩怨
- 在不了解整项改动的大背景的情况下就直接纠缠代码细节
- 过度地挑剔
- 让“完美”成为“优秀”的敌人
书籍推荐
- 谷歌公司《开发者代码评审指南》(“Code Review Developer Guide”)
- 成为更好的评审者和被评审者：道格拉斯·斯通与希拉·汉《高难度谈话Ⅱ：感恩反馈》（Thanks for the Feedback: The Science and Art of Receiving Feedback Well，已由光明日报出版社于2017年引进出版）
第8章 软件交付
需要做的
- 使用基于主干的分支模式并在可能的条件下持续集成
- 使用 VCS 工具来管理分支
- 与发布和运维团队合作为你的应用建立正确的流程
- 一并发布变更日志和发行说明
- 在新版本发布时通知用户
- 使用现成的工具来自动化部署
- 使用特性开关逐步推出更新
- 使用熔断器防止应用造成重大的破坏
- 使用影子流量或暗启动（launch in dark mode）来进行重大变更
不应该做的
- 发布未部署版本号的包
- 把配置、模式、图片和语言包一并打包在一起
- 盲目地依赖发布经理和运维团队
- 使用 VCS 来分发软件
- 更改已经发布的软件包
- 在没有监控结果的情况下执行展开步骤
- 依赖于顺序部署
书籍推荐
- 分支策略：艾玛·简·霍格宾·韦斯特比《Git团队协作：掌握Git精髓，解决版本控制、工作流问题，实现高效开发》（Git for Teams：A User-Centered Approach to Creating Efficient Workflows in Git，已由人民邮电出版社于2017年引进出版）
- 发布工程：耶斯·亨布尔和戴维·法利《持续交付：发布可靠软件的系统方法》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation，已由人民邮电出版社于2011年引进出版）
- 发布工程：谷歌《SRE：Google运维解密》在第8章涵盖了发布工程
- 迈克尔·尼加德《发布！设计与部署稳定的分布式系统（第2版）》（Release It! Design and Deploy Production-Ready Software 2nd，已由人民邮电出版社于2020年引进出版）
- 亚马逊的构建者库，关于持续交付、自动部署和回滚的帖子
第9章 On-Call
需要做的
- 将呼叫你的号码添加到电话联系人的白名单中
- 使用优先级类别、SLI、SLO和SLA 来确定事故响应的优先级
- 针对严重的事故采取分流、协同、应急方案、解决方案、后续行动的策略
- 使用科学的方式去排除故障
- 在事故的后续行动环节使用 5W 的方式来追根溯源
- 确认响应支持类的请求
- 针对下一次回复给予明确的时间预期
- 在关闭请求类的任务票之前确认问题都已经修改好了
- 将支持请求重定向到适当的沟通渠道
不应该做的
- 无视警告
- 在分流阶段就尝试排除故障
- 在问题尚未缓解的情况下就去做根本原因分析
- 在事后回顾总结的时候指责别人
- 对关闭那些无响应的支持请求犹豫
- 询问支持的请求者他们的优先级是什么，不询问问题的影响
- 逞英雄修复所有的事情
书籍推荐
- 《当寻呼机响起时，会发生什么？》(“What Happens When the Pager Goes Off ?”)
- SLI和SLO：谷歌《SRE：Google运维解密》一书的第4章
- On-Call、应急响应、事故处理和事后分析：《SRE：Google运维解密》的第11、13、14和15章
第10章 技术设计流程
需要做的
- 使用设计文档模板
- 阅读博客、论文和一些演讲文稿来获取灵感
- 对于你看到的一切保持批判性思考
- 在设计阶段就编写实验性的代码
- 学会清晰地写作，并经常练习
- 对设计文档进行版本控制
- 对队友的设计提出问题
不应该做的
- 在意早晚会变的实验性的代码
- 只讨论一项解决方案
- 让非母语阻止你写作
- 在具体实施方案和计划有些偏离时忘记更新设计文档
- 消极地参与团队设计讨论
书籍推荐
- 理查德·希基的演讲“吊床驱动开发”（“Hammock Driven Development”，可以在一些视频网站中找到）中给出了一份关于软件设计的“现场报告”
- 使用大型开源项目来查看正在进行的真实世界的设计：Python增强建议书、Kafka优化提案和Rust征求修正意见书
- 内部设计流程：WePay公司工程博客的一篇文章《有效的软件设计文档》(“Effective Software Design Documents”)
- 提高写作的表意清晰度：威廉·斯特伦克《英语写作手册：风格的要素》（TheElements of Style，已由外语教学与研究出版社于2016年引进出版）
- 提高写作的表意清晰度：威廉·津瑟《写作法宝：非虚构写作指南》（On Writing Well: The Classic Guide to Writing Nonfiction，已由中国人民大学出版社于2013年引进出版）
- Y Combinator公司的保罗·格雷厄姆有两篇关于写作的文章：《如何有用地写作》(“How to Write Usefully”)和《像说话一样写作》(“Write Like You Talk”)
第11章 构建可演进的架构
需要做的
- 牢记 YAGNI 原则：“你不是真的需要”
- 使用标准类库和开发模型
- 使用 IDL 来定义你的 API
- 对外部 API 和 文档进行版本管理
- 隔离不同应用程序的数据库
- 对所有的数据定义显式的 schema
- 使用迁移工具来进行数据库 schema 的自动化管理
- 如果下游数据消费者使用到了你的数据，保持 schema 的兼容性
不应该做的
- 无目的地构建过多的抽象模型
- 编写隐含排序需求和参数需求的方法
- 使用怪异代码让其他开发者感到惊讶
- 对 API 进行不兼容的变更
- 对内部 API 的版本控制持教条态度
- 在字符串或字节字段中嵌入无模式数据
书籍推荐
- 可演进架构：尼尔·福特、丽贝卡·帕森斯和帕特里克·柯撰《演进式架构》（Building Evolutionary Architectures，已由人民邮电出版社于2019年引进出版）
- DDD：沃恩·弗农《实现领域驱动设计》（Implementing Domain-Driven Design，已由电子工业出版社于2014年引进出版）
- 复杂性的内容以及如何管理复杂性：约翰·奥斯特霍特《软件设计的哲学》（A Philosophy of Software Design，由Yaknyam出版社于2018年出版）
- 助于你构建可演进的架构：扎克·特尔曼的《Clojure的要素》（Elements of Clojure，可以在其官方网站上找到）
- 简单性、复杂性、易用性以及如何构建优秀的软件：理查德·希基有一场精彩的演讲，叫作“简单造就易用”(“Simple Made Easy”)
- 数据产品：扎马克·德加尼《数据网格：规模化地提供数据驱动的价值》（Data Mesh: Delivering Data-Driven Value at Scale，由O’Reilly Media出版社于2022年出版）
- 数据演进、数据schema、IDL和变化数据捕获等：马丁·科勒普曼《数据密集型应用系统设计》（Designing Data-Intensive Applications，已由中国电力出版社于2018年引进出版）
第12章 敏捷计划
需要做的
- 保持站会简短
- 为用户故事写下详细的验收标准
- 承诺可以在冲刺迭代中实际完成的工作
- 如果你无法在冲刺迭代中完成大块工作，请将其分解
- 使用故事点来预估工作量
- 务必使用相对尺度和T恤尺码来帮助估算
不应该做的
- 痴迷于敏捷开发的“正确做法”
- 害怕改变敏捷流程
- 将常规任务描述强加给“用户故事”
- 忘记跟踪计划和设计工作
- 尚未完成已提交的工作时又在冲刺开始后追加工作
- 盲目地遵循流程
书籍推荐
- 《〈敏捷宣言〉背后的原则》（“Principles Behind the Agile Manifesto”，可以在其官方网页找到全文）
- Atlassian网站的文章（可以在其主页的敏捷相关分类中找到）
第13章 与管理者合作
需要做的
- 期望管理者能够平易近人且具有透明度
- 明确告知你的管理者你需要什么
- 为一对一面谈设置议程
- 保有一对一面谈的纪要
- 按照你希望收到的反馈来撰写具有可操作性的反馈
- 跟踪工作成果，这样在自我评价时会更容易
- 采用 SBI 框架来减少反馈对个人的针对性
- 考虑长期的职业目标
不应该做的
- 向管理者隐瞒困难
- 仅仅把一对一面谈当作更新工作状态的会议
- 仅凭记忆进行自我总结
- 给予他人肤浅的反馈
- 被 OKR 框住
- 将反馈视为攻击
- 忍受糟糕的管理
书籍推荐
- 每个级别的管理者是如何具体工作的，并给出了关于管理流程如一对一面谈的更多细节、规划自己的职业道路：卡米尔·富尼耶《技术管理之路：技术领导者应对增长和变化的指南》（The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change，由O’Reilly Media出版社于2017年出版）
- 对一名管理者所面临的诸多问题以及他们用来应对这些问题的框架进行了深入分析：威尔·拉森《优雅谜题：工程管理的系统》（An Elegant Puzzle:Systems of Engineering Management，由Stripe Press出版社于2019年出版）
- 帮助你处理评审反馈：道格拉斯·斯通与希拉·汉《高难度谈话Ⅱ：感恩反馈》
- 玛丽·阿巴杰《向上管理：如何晋升，如何在工作中获胜以及如何与不同类型的上司一同获取成功》（Managing Up: How to Move up, Win at Work, and Succeed with Any Type of Boss，由Wiley出版社于2018年出版）
- 工程管理：安迪·格鲁夫《格鲁夫给经理人的第一课：英特尔创始人自述》（High Output Management，已由中信出版集团于2017年引进出版）
第14章 职业生涯规划
迈向资深之路
职业生涯的重大转变通常有两个过渡：
- 从初级工程师到资深工程师
- 从资深工程师到主任工程师或首席工程师
三个层级
- 初级工程师
- 资深工程师
- 主任工程师
资深工程师的能力
- 处理不确定性和模糊性
- 确定工作内容
- 应对更大或更关键的项目
- 需要更少的指导
主任工程师的职责
- 承担更广泛的职责
- 理解大局，做出深远影响的决策
- 两条轨道：管理者和“个人贡献者”
职业生涯建议
T 型人才
- 在大多数领域内有效工作
- 至少是某一个领域的专家
- 构建基本盘，接触不同子领域，找到自己的激情所在
参与工程师训练营
- 参与公司组织的招聘、面试、午餐会、研讨会等活动
- 如果公司没有训练营，主动创建一个
- 建立关系，提高知名度，学习新技能，影响公司文化
主导你自己的晋升
- 了解晋升流程，确保工作有价值且可见
- 进行自我评估，获得他人反馈
- 制订计划填补差距
- 影响力是晋升的关键
- 提前开始晋升谈话，协调并解决差距问题
换工作需谨慎
- 利用过去经验指导决策
- 避免频繁更换工作，积累长期经验
- 对特殊机会持开放态度
- 如果当前工作有适当的薪酬、成长和学习机会，尽量坚持
- 如果当前工作阻碍成长，考虑更换公司
自我调节
- 休息，避免过度劳累
- 长时间工作和睡眠不足不可持续
- 保持健康的工作习惯
