Appearance
2024年1月初中
快速翻阅过一遍即可，更像是一个checklist和准则集合，用于自省在工作中是否遵循。
摘录
第2章 步入自觉阶段
| 需要做的 | 不应该做的 |
|---|---|
| 多尝试和实验代码 | 这是大量炮制劣质代码 |
| 多阅读设计文档和他人代码 | 害怕承担风险和失败 |
| 参加一些聚会、在线社区、兴趣小组和导师计划 | 过于频繁参加研讨会 |
| 多阅读论文和博客 | 害怕提出问题 |
| 对采用“非打扰式”交流 | |
| 旁听面试以及参与On-Call轮换 |
第3章 玩转代码
行为准则
| 需要做的 | 不应该做的 |
|---|---|
| 进行渐进式的重构 | 过度使用“技术债”这个词 |
| 从新特性的提交中剥离重构的部分 | 为了适应测试而将变量或方法变成公共的 |
| 保持以小规模的方式修改代码 | 成为编程语言上的“势利眼” |
| 将过手的代码整理得比之前干净 | 忽视你公司的标准和工具集 |
| 使用保守的技术选型 | 只分叉而不向上游提交修改 |
第4章 编写可维护的代码
| 需要做的 | 不应该做的 |
|---|---|
| 宁愿编译出错，也不要运行出错 | 在程序逻辑中应用异常 |
| 尽可能使事情不可变 | 在异常处理中只返回错误码 |
| 校验输入和输出 | 捕获你无法处理的异常 |
| 去学习OWASP的十大报告 | 写入带折行的日志 |
| 使用bug检查工具和类型提示的特性 | 在日志中记载秘密或敏感的数据 |
| 在异常之后清理资源（尤其端口、文件指针和内存） | 单独在某台计算机上手动修改配置 |
| 使用系统指标来监控你的代码 | 在配置文件中存储密码或秘密信息 |
| 让你的程序可以配置 | 写定制化的配置格式 |
| 检验和记录所有的配置 | 在可以避免的情况下使用动态配置 |
第5章 依赖管理
| 需要做的 | 不应该做的 |
|---|---|
| 务必使用语义化版本 | 使用Git的哈希值当做版本号 |
| 明确指定依赖版本的范围 | 在收益未超过成本时添加依赖项 |
| 务必使用依赖关系报告工具来分析传递依赖 | 直接使用传递来的依赖项 |
| 添加新的依赖项时，请务必持怀疑态度 | 引入循坏依赖 |
| 精确地使用依赖范围 |
第6章 测试
| 需要做的 | 不应该做的 |
|---|---|
| 使用测试去重现bug | 忽视添加新测试工具时的成本 |
| 使用模拟工具去帮助编写单元测试 | 依赖于他人为你编写测试用例 |
| 使用代码质量工具去检查覆盖率、格式和复杂度 | 仅仅为了提高覆盖率而编写测试 |
| 在测试中使用常数种子的随机生成器 | 仅仅将代码覆盖率作为代码质量的衡量标准 |
| 在测试后关闭网络套接字和文件句柄 | 在测试中使用可以避免的休眠和超时 |
| 在测试中生成唯一的文件路径和数据库位置 | 在单元测试中调用远程系统 |
| 在测试执行的间隙清理掉遗留的测试状态 | 依赖于测试执行顺序 |
第7章 代码评审
| 需要做的 | 不应该做的 |
|---|---|
| 在提交评审请求之前保证通过了测试和代码检测工具的检查 | 仅仅为了触发CI系统而提交评审请求 |
| 为代码评审预留出专门的时间，像对待其他工作一样对待评审工作 | 只做橡皮图章 |
| 当评审意见很粗鲁、没有建设性或者不当言论的时候，请明确指出 | 和代码“坠入爱河”或者把评审的反馈意见当作私人恩怨 |
| 通过适当提供相应修改的背景信息来帮助评审者 | 在不了解整改的大背景下直接纠缠代码细节 |
| 在进行代码评审时，超越肤浅的对待代码风格的指摘 | 过度的挑剔 |
| 用尽一切工具去理解棘手的代码改动，不要只依赖评审工具自身的界面 | 让“完美”成为“优秀”的敌人 |
| 将测试代码纳入评审范围 |
第8章 软件教父
| 需要做的 | 不应该做的 |
|---|---|
| 使用基于主干的分支模式并在可能得条件下持续集成 | 发布未部署版本号的包 |
| 使用VCS工具来管理分支 | 把配置、模式、图片和语言包一并打包在一起 |
| 与发布和运维团队合作为你的应用建立正确的流程 | 盲目地依赖发布经理和运维团队 |
| 一并发布变更日志和发行说明 | 使用VCS来分发软件 |
| 在新版发布时通知用户 | 更改已经发布的软件包 |
| 使用现成的工具来自动化部署 | 在没有监控结果的情况下执行展开步骤 |
| 使用特性开关逐步推出更新 | 依赖于顺序部署 |
| 使用熔断器防止应用造成重大的破坏 | |
| 使用影子流量或摸黑启动来进行重大变更 |
第9章 ON-Call
| 需要做的 | 不应该做的 |
|---|---|
第10章
| 需要做的 | 不应该做的 |
|---|---|
| 将呼叫你的号码添加到电话联系人的白名单中 | 无视警告 |
| 使用优先级类别、SLI、SLO和SLA来确定事故响应的优先级 | 在分流阶段就尝试排除故障 |
| 针对严重的事故采取分流、协同、应急方案、解决方案、后续行动的策略 | 在问题尚未缓解的情况下就去做根本原因分析 |
| 使用科学的方式区排除故障 | 在时候回顾总结的时候职责别人 |
| 在事故的后续行动环节使用5W的方式来追根溯源 | 对关闭那些无响应的支持请求犹豫 |
| 确认响应支持类的请求 | 询问支持的请求者他们的优先级是什么，不询问问题的影响 |
| 针对下一次回复给予明确的时间预期 | 逞英雄修复所有的事情 |
| 在关闭请求类的任务票之前确认问题都已经修改好了 | |
| 将支持请求重定向到适当的沟通渠道 |
第11章 构建可演进的架构
| 需要做的 | 不应该做的 |
|---|---|
| 牢记YAGNI原则：你不是真的需要 | 无目的地构建过多的抽象模型 |
| 使用标准类库和开发模型 | 编写隐含排序需求和参数需求的方法 |
| 使用IDL来定义你的API | 使用怪异代码让其他开发者感到惊讶 |
| 对外部API和文档进行版本管理 | 对API进行不兼容的变更 |
| 隔离不同应用程序的数据库 | 对内部API的版本控制持教条态度 |
| 对所有的数据定义显式的schema | 在字符串或字节字段中嵌入无模式的数据 |
| 使用迁移工具来进行数据库shema的自动化管理 | |
| 如果下游数据消费者使用到了你的数据，保持schema兼容 |
第12章 敏捷计划
| 需要做的 | 不应该做的 |
|---|---|
| 保持站会简短 | 痴迷于敏捷开发的正确性 |
| 为用户故事写下详细的验收标准 | 害怕改变敏捷流程 |
| 承诺可以在冲刺迭代中实际完成的工作 | 将常规任务描述强加给用户故事 |
| 如果你无法再冲刺迭代中完成大块工作，请将其分解 | 忘记跟踪计划和设计工作 |
| 使用故事点来预估工作量 | 尚未完成已提交的工作时又在冲刺开始后追加工作 |
第13章 与管理者合作
| 需要做的 | 不应该做的 |
|---|---|
| 期望管理者能够平易近人且具有透明度 | 向管理者隐瞒困难 |
| 明确告知你的管理者你需要什么 | 仅仅把一对一面谈当作更新工作状态的会议 |
| 为一对一面谈设置议程 | 仅凭记忆进行自我总结 |
| 保有一对一面谈的纪要 | 给予他人肤浅的反馈 |
| 按照你希望收到的反馈来撰写具有可操作性地反馈 | 被OKR框柱 |
| 跟踪工作成果，这样在自我评价时会更容易 | 将反馈视为攻击 |
| 采用SBI框架来减少反馈对个人的针对性 | 忍受糟糕的管理 |