入职一年后再读到这本书其实有些晚了，每一章节几乎都是在这一年的工作中所经历和摸索过后才建立的认知，每一章外延为单独的一本书大概才能成体系地深入学习，作者也确实每一章的末尾都做了相关阅读推荐。

按「道法术器」的角度看，这本书讲的应该更多是「法」和「术」的东西，虽然也可以被理解为是叭叭一堆“正确的废话”，但只要是正确的就是值得输入的，哪怕最终对自己的帮助和影响只有分毫。

此外不得不提的是，本书的翻译实在是过于“简单直接”，和Google机翻也大致无二了，尽可能还是阅读英文原版吧。

书名：程序员的README

作者：克里斯·里科米尼 德米特里·里亚博伊

译者：付裕

出版社：人民邮电出版社有限公司

出版时间：2023-07-01

ISBN：9787115599438

品牌方：人民邮电出版社有限公司

1. 技术知识

2. 执行力

3. 沟通能力

4. 领导力

坎宁安定律 (Cunningham’s Law）：The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer. 在谈话中，我们也能利用“说错话”来激发更多的对话。

自行车棚效应 (Bike-shed Effect) / 帕金森琐碎定律（Parkinson's Law of Triviality）：A common phenomenon in group decision-making where people give disproportionate weight to trivial issues. 一个被指派到发电厂对该发电厂的设计方案进行评审的委员会，因为发电厂的设计方案过于复杂，以至于无法讨论出什么实际的内容，所以他们花了几分钟就批准了这些计划。然后，他们又花了45分钟来讨论发电厂旁边的自行车棚的材料问题。

1. 前置学习：入职后学习开发流程和项目知识，参与设计讨论、On-Call轮换、解决运维问题和评审代码。
2. 在实践中学习：上手编写并发布代码，适当谨慎，不要过于害怕造成问题。
3. 执行代码：在生产环境外运行项目，多调试，多打日志。
4. 阅读：团队文档、设计文档、代码、积压的tickets、书籍、论文和技术网站。
5. 观看讲座：观看教程、技术讲座和阅读会议简报。
6. 适度地参加会议和聚会：学术会议、草根兴趣小组聚会和科技展览会，偶尔参加。
7. 跟班学习并同有经验的工程师结对：在另一个人执行任务时跟着他，他做笔记并提出问题；结对编程(pair programming)，两名工程师一起写代码，轮流编程。
8. 用副业项目实践：贡献导向，参与开源项目；兴趣导向，找到有兴趣解决的问题，用想学习的工具来解决。

1. 尝试自己寻找答案：不要直接请教同事，可以尝试互联网、文档、内部论坛、聊天记录、源代码等地方。
2. 设置时间限制：设定好研究一个问题预期花费的时间，防止收益递减。
3. 记录全过程：向别人提出问题时，要描述背景、自己的尝试和发现。
4. 别打扰：注意提问的时机，不要打扰别人工作的专心状态。
5. 多用“非打扰式”交流：组播(multicast)是指将消息发送到一个组而不是个人目标；异步(asynchronous)是指可以稍后处理消息，而不需要立即响应。即多使用群聊，邮件或论坛。
6. 批量处理你的同步请求：面对面的交流是“高带宽”和“低延迟”的，所以在聊天和邮件外，预约时间或安排会议集中处理问题更好，但事前要做好功课，事中要多记录，事后要有反馈。

1. 冒充者综合征：觉知（awareness），意识到是自己主动在寻找“冒充”的证据，而自己是真真切切取得了成就；重塑（awareness），把悲观的、消极的自我暗示转化为乐观的、积极的自我鼓励；反馈（feedback），与导师、敬重的同事交流，明确自己做得怎么样。
2. 邓宁-克鲁格效应：有意识地培养好奇心；对犯错持开放态度；向受人尊敬的工程师取经；讨论设计决策并倾听建议；培养一种权衡利弊而不是非黑即白的心态。

推荐阅读：

1. 《软件开发者路线图：从学徒到高手》（Apprenticeship Patterns: Guidance for theAspiring Software Craftsman）
2. 《你要做的全部就是提问：如何掌握成功最重要的技能》（All You Have toDo Is Ask:How to Master the Most Important Skill forSuccess）
3. 《解析极限编程——拥抱变化》（ExtremeProgramming Explained: Embrace Change）
4. 《高能量姿势：肢体语言打造个人影响力》（Presence: Bringing Your Boldest Self to Your BiggestChallenges）

马丁·M.布罗德威尔在其文章《为学而教》(“Teaching forLearning”)中定义了能力的4个阶段：“无意识的无能力”(unconscious incompetence)、“有意识的无能力”(consciousincompetence)，“有意识的有能力”(conscious competence)和“无意识的有能力”(unconscious competence)。具体说来，无意识的无能力意味着你无法胜任某项任务，并且没有意识到这种差距。有意识的无能力意味着你虽然无法胜任某项任务，但其实已经意识到了其中的差距。有意识的有能力意味着你有能力通过努力完成某项任务。最后，无意识的有能力意味着你可以很轻松地胜任某项任务。

冒充者综合征（冒名顶替症候群，Impostor syndrome）：a behavioral health phenomenon described as self-doubt of intellect, skills, or accomplishments among high-achieving individuals.

邓宁-克鲁格效应（Dunning-Kruger effect）：a cognitive bias in which people with limited competence in a particular domain overestimate their abilities.

1. 定义：为了修复现有的代码不足而欠下的未来工作，是造成软件的熵的主要原因之一。与金融债务一样，技术债也有“本金”和“利息”，本金是那些需要修复的原始不足，利息是随着代码的发展没有解决的潜在不足。因为实施了越来越复杂的变通方法，随着变通办法的复制和巩固，利息就会增加，复杂性蔓延开来，就会造成bug。
2. 技术债矩阵：

• 谨慎的、有意的：在代码的已知不足和交付速度之间进行务实的取舍，团队要有规划地解决。

• 鲁莽的、有意的：在团队面临交付压力的情况下产生的，“就...”，“只是...”这样的形容就是鲁莽债务。

• 鲁莽的、无意的：不知道自己不知道，需要通过做方案评审、代码评审和持续学习来最大限度减少。

• 谨慎的、无意的：成长经验积累的自然结果，有些教训只有在事后才会被吸取。

• 不要等到世界都停转一个月了才去解决问题，要边做边解决，着手去做小幅的重构。
• 有时增量重构还不够，需要大型的重构。短期看，偿还技术债会拖慢交付特性的速度，而承担更多的技术债会加速交付，但长期看情况则相反，平衡点在很大程度上取决于环境。如果有大规模重构或重写某些模块的建议，可以向团队说明情况：按事实陈述情况，描述技术债的风险和成本，提出解决方案，讨论备选方案（不采取行动也是备选之一），权衡利弊。要注意的是以书面形式提出建议，不要把呼吁建立在价值判断上（“这段代码又老又难看”），要足够具体，将重点放在技术债的成本和修复它带来的好处上。

1. 善于利用现有代码：定位需要改变的代码即变更点并阅读，然后找到测试点即修改代码的入口，这也是测试用例需要调用和注入的区域。有时候不得不打破现有依赖结构，比如拆分方法、引入接口，这可以更方便地编写测试用例。
2. 过手的代码要比之前更干净：在不影响整个项目持续运转的情况下要持续地重构工程，这样重构的成本就会平摊在多次的版本更迭中。
3. 做渐变式的修改：不要一次提交就“翻天覆地”，保持每次重构代码的体量很小，要尽量将重构代码的提交和新特性的提交分开。
4. 对重构要务实：团队的工作有优先事项和交付时效，重构需要花费时间，成本也可能超过其价值。正在被替换的旧的、废弃的代码，低风险或很少被触及的代码，都是不需要重构的。
5. 善用IDE：重构时多使用IDE的功能，比如抽取方法和字段、更新方法签名等。
6. 善用Git：尽早并频繁地commit，但一定要规范自己的commit message，要压缩但清晰。

1. 保守一些的技术选型：新技术的问题是它不太成熟，缺乏成熟的稳定性、兼容性、框架、文档、社区。只有新技术的收益超过其成本时，才值得考虑。
2. 不要特立独行：不要因为个人喜好就忽视公司或行业标准，自定义的方案必然会付出代价。
3. 不要只fork而不pr：没有及时贡献到上游代码库的小变更也会随着时间的推移而变得复杂。
4. 克制重构的冲动：把重构看作最后的手段，因为其成本和风险都巨大，但又很难评估价值。

推荐阅读：

1. 《修改代码的艺术》（Working Effectively with Legacy Code）
2. 《处理遗留代码的工具箱：软件专业人员处理遗留代码的专业技能》（The Legacy Code Programmer’sToolbox: Practical Skills for Software Professionals Workingwith Legacy Code）
3. 《重构：改善既有代码的设计》（Refactoring: Improving the Design of Existing Code）
4. 《人月神话》（The Mythical Man-Month）

本·霍洛维茨在他的《创业维艰：如何完成比难更难的事》（TheHard Thing About Hard Things）一书中说：任何技术创业公司必须做的主要的事情是建立一个产品，这个产品在做某件事情时至少要比目前流行的方式好十倍。两倍或三倍的改进不足以让人们快速或大量地转向新事物。

丹·麦金利在他的演讲“选择保守的技术”中指出“在保守技术上出现的故障模式很好理解”。所有的技术都会发生故障，但旧的东西以可预测的方式发生故障，新东西往往会以令人惊讶的方式发生故障。

弗雷德里克·布鲁克斯在他的名作《人月神话》（The Mythical Man-Month）中创造了“第二系统综合征”这一短语，描述了简单系统如何被复杂系统所取代。第一个系统的范围是有限的，因为它的创造者并不了解可能会出问题的地方。这个系统完成了它的工作，但它是笨拙的和有限的。现在有经验的开发者清楚地看到了他们的问题所在，他们开始用他们的一切聪明才智来开发第二个系统。新系统是为灵活性而设计的，所有东西都是可配置和可注入的。可悲的是，第二个系统通常是一个臃肿的烂摊子。

1. 避免空值：使用空对象模式(null object pattern)或可选类型(option type)来避免空指针异常；使用@NotNull注解替代手动空值检查让代码更干净。
2. 保持变量不可变：将变量声明为不可变可以防止意外修改，比如Java的final。
3. 使用类型提示和静态类型检查器：限制变量可以被赋的值。
4. 验证输入：永远不要相信你的代码接收的输入，一定要进行校验。
5. 善用异常：不要使用特殊的返回值来标识错误类型（如null、0、−1等），尽量使用异常，它可以被命名，有堆栈跟踪和错误信息。
6. 异常要有精确含义：尽可能地使用内置的异常，避免创建通用的异常。使用异常处理来应对故障，而不是控制应用程序的运行逻辑。
7. 早抛晚捕：“早抛”意味着在尽可能接近错误的地方引发异常，这样开发人员就能迅速地定位相关的代码。“晚捕”意味着在调用的堆栈上传播这个异常，直到你到达能够处理异常的程序的层级。
8. 智能重试：单纯的重试方法是捕捉到一个异常马上就进行重试，但可能会影响系统性能；谨慎的做法是backoff，非线性地增加休眠时间（通常使用指数如(retry number)^2）；不要盲目地重试所有失败的调用，最好是让应用程序在遇到其在设计时没有预想到的错误时崩溃，即fail-fast。
9. 构建幂等系统：处理重试的最好方法是构建幂等系统，一个幂等的操作是可以被进行多次并且仍然产生相同结果的操作，比如往一个Set里添加一个值，客户端单独为每个请求提供一个唯一ID。

1. 给日志分级：通过全局配置和对包或类级别的覆写来控制，设置后所有处于该级别或高于该级别的日志都会被发出来，常见分级有TRACE、DEBUG、INFO、WARN、ERROR、FATAL。
2. 日志的原子性：原子日志就是指在一行消息中包含所有相关的信息，不能原子化输出时考虑在每一条日志中加上Trace ID。
3. 关注日志性能：用参数化的日志输入及异步附加器避免日志对性能的损害。
4. 不要记录敏感数据：日志信息不应该包括任何私人数据，如密码、安全令牌、信用卡号码或电子邮件地址。

1. 常见系统指标形式：计数器、仪表盘和直方图（百分比），汇总到一个集中式可视化系统，在聚合指标之上提供面板和监控工具，跟踪SLO（service level objective，服务等级目标），根据指标值触发警告，或扩容缩容。
2. 使用标准的监控组件：不要推出你自己的系统指标库，非标准库是“维护噩梦”，而标准库可以与其他一切“开箱即用”的东西集成。
3. 测量一切：监测的性能开销很低，要尽可能地监测各种数据结构、操作和行为，比如资源池（线程池、连接池）的大小、缓存的命中数和失误数、数据结构的大小、CPU密集型操作的性能开销、I/O密集型操作的处理时间、异常和错误的数量、远程请求和响应的数量和耗时。

1. 堆栈跟踪：异常。
2. 分布式调用跟踪：Trace ID。

1. 配置的形式和方式：形式有JSON或YAML文件，环境变量，命令行参数，领域特定语言(DSL)，应用程序所使用的语言；方式可以是静态配置或动态配置。
2. 记录并校验所有的配置：在程序启动时立即记录所有（非秘密的）配置，并加载配置的值时立即对其进行类型和逻辑意义的校验。
3. 不要玩花活：配置方案越聪明，bug就越奇怪，尽量使用最简单、有效的方法，理想状态应该是单一标准格式的静态配置文件；如果不得不使用变量替换、条件配置或动态配置，也要日志跟踪配置的变化和记录实际生效的配置值。
4. 提供默认值：提供良好的默认值能让应用开箱即用，避免用户上手就配置大量参数。
5. 给配置分组：可以使用YAML的嵌套将相关属性分组。
6. 配置即代码（configuration as code，CAC）：配置应该受到与代码同样严格的要求，要进行版本控制、评审、测试、构建和发布。
7. 保持配置文件清爽：删除不使用的配置，使用标准的格式和间距，不要盲目地从其他文件中复制配置。
8. 不要编辑已经部署的配置：避免在生产环境中手动编辑某台特定机器上的配置文件。

1. 多了解并尽量使用公司或团队的通用运维工具。
2. 如果是自己编写的脚本，一定要注意规范和测试，有价值的工具可以尝试抽象为共享库或服务。

推荐阅读：

1. 《代码大全：软件构造之实践指南》（CodeComplete: A Practical Handbook of Software Construction）
2. 《代码整洁之道》（Clean Code: A Handbook of Agile Software Craftsmanship）
3. 《Google系统架构解密：构建安全可靠的系统》（BuildingSecure & Reliable Systems：Best Practices for Designing, Implementing, and Maintaining Systems）
4. 《SRE：Google运维解密》（Site Reliability Engineering: How Google Runs ProductionSystems）

1. 相依性是指你的代码所依赖的代码，依赖关系是在软件包管理或构建文件中声明的。
2. 好的版本管理方案要有唯一性（版本不应该被重复使用），可比性（推断版本的优先顺序），信息性（区分预发布和正式发布）。
3. 语义版本管理(semantic versioning，SemVer)：主版本号.次版本号.补丁版本号，还可以添加一个-来定义预发布版本。
4. 传递依赖：软件包管理或构建文件揭示了项目的直接依赖关系，直接依赖又依赖于其他类库，形成依赖传递。

1. 循环依赖：A依赖B，B依赖C，C依赖A。一个库间接性地依赖它自己
2. 钻石依赖：A依赖B和C，B和C依赖D。一个底层库被多个路径依赖。
3. 版本冲突：A直接或间接依赖了B的2个版本。一个项目中存在同一个库的多个版本。

1. 隔离依赖项：不必把依赖管理交给构建和打包系统，直接复制依赖相关的必要代码，Java还可以使用包路径的区分来遮蔽依赖。
2. 按需添加依赖项：将你使用的所有类库显式声明为依赖项，不要使用来自横向依赖的方法和类。
3. 指定依赖项的版本：明确设定每个依赖项的版本号。
4. 依赖范围最小化：依赖范围指在构建生命周期的编译、运行、测试阶段何时使用某个依赖，对每个依赖项指定尽可能精确的依赖范围。
5. 保护自己免受循环依赖的影响：使用构建工具检测，不要引入循环依赖。

推荐阅读：

1. SemVer的官方主页
2. Python官方主页的版本管理说明

帕累托法则（Pareto principle）：也被称为二八定律，由意大利经济学家维尔弗雷多·帕累托在20世纪初提出，他发现意大利约有80％的土地由20％的人口所有。在编程领域，80%的软件缺陷来源于代码中的20%部分；80%的性能提升可以通过优化20%的代码来实现；80%的开发时间被用来完成项目中20%的功能点。

1. 检查代码是否正常工作，验证软件的行为是否符合预期。
2. 编写测试迫使开发人员思考他们程序的接口和实现过程，尽早地暴露出笨拙的接口设计和混乱的实现过程。
3. 测试代码可以是另一种形式的文档，是开始阅读并了解一个新的代码库的入口。

1. 单元测试：测试某个单一的方法或行为。
2. 集成测试：验证多个组件集成在一起之后是否还能正常工作。
3. 系统测试：验证整个系统的整体运行情况。
4. 性能测试：负载测试和压力测试并监控系统性能。
5. 验收测试：验证交付的软件是否符合验收标准。

1. 模拟库：用于单元测试，特别是面向对象的代码中，可以模拟外部依赖的系统、类库或对象。
2. 测试框架：管理测试的setup和teardown，管理测试执行和编排，提供工具，生成结果报告和代码覆盖率。
3. 代码质量工具：运行静态分析并执行代码风格检查，报告复杂度和测试覆盖率等指标。

1. 编写干净的测试：测试代码也要注意质量，专注于测试基本功能而不是实现细节，将测试的依赖项与常规代码的依赖项分开。
2. 避免过度测试：编写有意义的、对代码影响最大风险点的测试，不要为了覆盖率而去写无效测试。

推荐阅读：

1. 《单元测试：原则、实践与模式》（Unit Testing: Principles, Practices, and Patterns）
2. 《测试驱动开发：实战与模式解析》（Test-DrivenDevelopment: By Example）
3. 《程序员修炼之道——从小工到专家》（The Pragmatic Programmer: From Journeyman to Master）
4. 《探索吧！深入理解探索式软件测试》（Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing）

1. 捕捉bug并保持代码整洁。
2. 团队的教学和学习工具。
3. 评审的comments也是一种文档。
4. 保证安全和合规。

1. 准备工作：保持单个代码的小幅改动，将特性和重构工作分到不同的评审中，并写出描述性的commit message，务必将注释和测试包括在内。
2. 用评审草案降低风险：在真正进行代码的编写和评审之前，进行代码草案即大致设计和改造点的评审。
3. 提交评审请勿触发测试：通过提交代码评审来触发持续集成的测试是一种浪费，CI环境应该只用于要发布的代码。
4. 预排大体量的代码修改：大体量代码修改的评审要提前做好预排，提前让同事们了解设计文档和熟悉代码，演示时按照运行步骤来讲解代码。
5. 不要太在意：批评性的评论可能让你很难接受，切记应该保持一些情感上的距离——这些评审意见是针对代码的，而不是针对你个人的，而且这甚至都不算是你的代码，这是整个团队会拥有的代码。
6. 保持同理心，但不要容忍粗鲁：允许评审者怀疑，但如果他们的评论偏离了中心或粗暴无礼，要明确沟通，扫清障碍。
7. 保持主动：不要羞于要求别人评审你的代码，收到评论时要有所回应。

推荐阅读：

1. 《开发者代码评审指南》(“Code Review Developer Guide”)
2. 《高难度谈话Ⅱ：感恩反馈》（Thanks for the Feedback:The Science and Art of Receiving Feedback Well）

1. 并没有行业标准定义。
2. 作者讲解使用的流程：构建(build)、发布(release)、部署(deploy)和展开(rollout)。

1. 基于主分支的开发模式（Trunk-Based Development）：主分支包含整个代码库的主版本，并有修改的历史记录。分支是从主分支上“切”下来的，以进行代码修改，多个分支允许开发人员并行工作，然后将修改过的内容合并回主分支上。只有当各分支可以快速合并到主分支时，基于主分支的开发模式的效果才是最好的，即持续集成（CI）。
2. 基于特性分支的开发模式（Feature Branch Workflow）：开发人员同时在长期存续的特性分支上工作，每个特性分支与产品中的一个特性相关联，特性分支存续时间都较长，开发人员需要经常从主分支中合并代码，使特性分支不偏离主干太远。发布时特性分支会被拉入发布分支进行测试，而特性分支可能会继续开发，最终发布的软件包是建立在稳定的发布分支上的，如果有问题就拉hotfix分支进行热修复。

1. 软件包：为每个发布版本而构建，内容和结构各不相同。
2. 打包的注意事项：带版本号，将不同的资源单独打包。

1. 发布步骤：内部发布可能只需要将软件包发行到共享仓库，面向用户的发布则需要发布构建、文档更新、发行说明和用户透传。
2. 不要只想着发布：发布不是工作的结束，你需要对发布负责，确保适当的部署和良好的运转，并及时解决在生产环境产生的问题。
3. 将包发布到仓库：用于发布的软件包要持久化到一个存储资源库。
4. 保持版本不变性：一旦发布了，就永远不要改变或覆盖这个已发布的包。
5. 频繁发布：快速频繁的发布会让每个版本的风险都较小，产生更稳定的软件，当发现bug时也更容易修复。
6. 对发布计划保持透明：发布时间表一定要明确和公开。
7. 撰写变更日志和发行说明：可以帮助你的用户和支持团队了解一个版本中包含的具体内容。

1. 自动部署：使用脚本而不是手动步骤来部署软件。
2. 部署的原子性：脚本通常涉及多个步骤，每一步都可能失败，要保证部署要么全部完成要么什么都没做（即原子性）。简单方法之一是在与旧版本不同的位置上安装软件，不要覆盖任何东西，让回滚也变得容易。
3. 独立地部署应用：顺序部署会降低部署效率，还可能导致冲突，最好保证每个应用可以独立部署，做好向前和向后的兼容。

1. 系统监控：新代码被激活后，监测健康指标，诸如错误率、响应时间和资源消耗。
2. 特性开关（feature flag）：代码被包裹在一个if语句中，该语句检查一个flag（动态配置）以确定应该运行哪个分支的代码。flag可以是布尔值，列表，灰度百分比等。需要注意的是数据库通常不受开关控制，新旧代码会处理相同的表，因此一定要注意兼容。
3. 熔断器：一种特殊的特性开关，由运维事件（性能阈值、异常日志）控制，熔断器的特点是二进制的（开/关）、永久性的、自动化的。
4. 并行的服务版本梯队：

• 金丝雀部署（Canary Deployment）：用于处理高流量、部署到大量实例的服务。一个新的应用程序版本被首先部署到一组少量机器上，用户的一个子集被路由到这个金丝雀版本，进行监控和评估，决定继续扩大覆盖范围，或快速回滚切回老版本。
• 蓝绿部署（Blue-Green Deployment）：两个相同的生产环境但部署不同的应用版本。蓝色环境是当前活跃的生产环境，承载用户流量，绿色环境初始化为蓝色环境的镜像，但不承载实时用户流量，用于部署新的软件版本，就绪并测试后，切换路由让所有新的用户流量打向绿色环境，此时绿色环境变为新的生产环境，旧的蓝色环境空闲，新版本有问题可以迅速切回。当流量不容易划分的时候可以考虑蓝绿部署，但要注意每个环境都必须能够处理100%的用户流量。

推荐阅读：

1. 《Git团队协作：掌握Git精髓，解决版本控制、工作流问题，实现高效开发》（Git for Teams：A User-CenteredApproach to Creating Efficient Workflows in Git）
2. 《持续交付：发布可靠软件的系统方法》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation）
3. 《发布！设计与部署稳定的分布式系统（第2版）》（Release It! Design and Deploy Production-Ready Software 2nd）

1. 开发人员根据时间表进行轮换。有些时间表会安排一名主要责任人和一名辅助的On-Call人员。
2. On-Call人员的大部分时间用来处理临时性的支持，如bug报告、软件如何运行以及使用的问题，当然也可能遇到运维事故，响应电话或消息告警。

1. 随时响应。

2. 保持专注

3. 确定工作优先级。

4. 清晰的沟通。

5. 记录跟踪工作。

事故处理：

1. 分流(triage)：工程师必须找到问题，确定其严重性，并确定谁能修复它。
2. 协同(coordination)：团队（以及潜在的用户）必须得到这个问题的通知，如果On-Call人员自己不能解决这个问题，他们必须提醒那些能解决的人。
3. 应急方案(mitigation)：工程师必须尽快让事情稳定下来。缓解并不是长期的修复，你只是在试图“止血”，通过回滚一个版本、将故障转移到另一个环境、关闭有问题的特性或增加硬件资源来缓解。
4. 解决方案(resolution)：在问题得到缓解后，工程师有一些时间来喘口气、深入思考，继续调查问题，以确定和解决潜在的问题。
5. 后续行动(follow-up)：对事故的根本原因——为什么会发生，进行调查。如果事故很严重更要进行正式的事后调查或回顾性调查，建立后续任务，以防止重复的根本原因的再次出现。

1. On-Call工程师也得花时间处理支持类请求，来自组织内部或外部用户，支持请求必须遵循一个相当标准的流程。
2. 由于你“真正的”工作是编程，参与到支持工作中可能会让你分心。把支持工作看成一次学习机会，了解你的应用实际的使用方式，接触你不熟悉的代码，发现总结问题，帮助别人，建立良好的关系和影响力。

1. 不要“做得太多”，“救火”工程师、团队“万金油”都会让团队形成依赖，从而变成长期On-Call人员，长时间和高风险将导致倦怠，这种单点模式也是不健康的。
2. 如果你觉得你正在成为“救火”工程师，与你的管理者或技术负责人讨论如何找到更好的平衡，让更多的人接受培训并可以介入“救火”；如果你的团队中有一名英雄，看看你是否可以向他学习，挑起一些重担。

推荐阅读：

1. 《当寻呼机响起时，会发生什么？》(“What Happens When the Pager GoesOff ?”)

1. 软件设计并不是一种将研究和头脑风暴的结论落到文档上并获得批准的线性过程。它更像是在独立工作和相互合作之间交替进行的螺旋式上升的过程。
2. 从问题空间的了解开始，在独立工作和讨论脑暴中进行设计文档的迭代，完成设计。

1. 定义问题：技术设计的首要任务是定义和理解你要解决的那个（或那些）问题。了解问题的边界，以便知道如何解决，判断什么问题亟待解决，什么问题甚至不值得解决。
2. 技术选型：不要从问题定义直接就过渡到“最终”设计。考虑相关的研究、替代的解决方案，以及权衡各方案的利弊。你提出的设计不应该是你的第一个想法，而应该是你若干想法中最好的那个。
3. 进行实验：写代码草稿、运行测试来对你的想法进行实验，编写API草案和部分实现、运行性能测试、甚至A/B用户测试，以了解系统和用户的行为。
4. 给些时间：好的设计需要创造力和深入思考，不要指望坐下来一次就能完成一份设计，要给自己大块的时间，休息一下，换换环境，耐心一点儿，然后深度工作。

1. 判断是否需要设计文档：并非每一项变更都需要设计文档或设计评审，按照团队的指导方针来决定。
2. 了解撰写文档的目的：从表面上看，设计文档是告诉别人某个软件或模块是如何开发、工作的。但设计文档也是一种工具，可以帮助你思考、获得反馈，让你的团队了解情况、培养新的工程师，并推动项目规划。
3. 学会写作：写作作为一项技能，就像其他技能一样，是通过实践来进步的，充分利用写作的机会——设计文档、电子邮件、代码评审意见——努力写得清晰。
4. 保证文档是最新的：设计文档是活的，必须要随着方案的迭代和实现过程中的变更而更新，最好还要进行版本控制。

1. 概要；

2. 现状与背景；

3. 变更的目的；

4. 需求；

5. 潜在的解决方案；

6. 建议的解决方案；

7. 设计与架构；

• 系统构成图；

• UI/UX变更点；

• 代码变更点；

• API变更点；

• 持久层变更点；

1. 理解你的团队的设计评审流程。
2. 随时让团队和技术负责人了解设计进展。
3. 可以使用团队内的设计讨论来脑暴。
4. 除了自己负责的项目，也要为团队的技术设计贡献力量。

推荐阅读：

1. 大型开源项目的文档
2. 《吊床驱动开发》（“HammockDriven Development”）
3. 《有效的软件设计文档》(“Effective Software Design Documents”)
4. 《英语写作手册：风格的要素》（TheElements of Style）
   
   
   
   
   
   

   请到「今天看啥」查看全文