文章摘要(AI生成)

这段内容总结了在工作中需要做和不该做的事项，涵盖了代码编写、变更、可维护性、依赖管理、测试、代码评审、软件交付、On-call、架构演进和敏捷计划等方面的建议。在开始工作阶段，建议多试验代码、加入社区学习，不应瞎写烂代码、怕冒险失败。在变更代码阶段，建议慢慢进行重构、选择保守技术，不应为了测试公开变量或方法。在代码可维护性方面，建议在编译时出错而不是运行时出错，不应在程序逻辑中使用异常。此外，还涉及了依赖管理、测试、代码评审、软件交付、On-call、架构演进、敏捷计划和与管理者合作等方面的建议和注意事项。建议遵循这些指导，以提高工作效率和质量。

一、开始工作

该做的事：多试试代码，看看设计文档和别人写的代码，参加聚会、读论文博客，用 “非打扰式” 交流，旁听面试和参与值班轮换。

不该做的事：别瞎写一堆烂代码，别怕冒险和失败，别老参加研讨会，也别不敢提问题。

二、变更代码

该做的事：慢慢进行重构，把新特性提交里的重构部分分出来，小幅度改代码，让经手的代码更整洁，选保守点的技术。

不该做的事：别老说 “技术债”，别为了测试就把变量或方法弄成公共的，别对编程语言有偏见，别不管公司标准和工具，光分叉代码不往上提交修改。

三、代码可维护

该做的事：宁可编译的时候出错，也别运行的时候出错。尽量让东西不变，检查输入输出，学学 OWASP 的十大报告，用查 bug 的工具和有类型提示的功能，出问题后清理资源，用系统指标监控代码，让程序能配置，检查和记录所有配置。

不该做的事：别在程序逻辑里用异常，别在异常处理的时候光返回个错误码，别抓那些处理不了的异常，别写带换行的日志，别在日志里记秘密或敏感信息，别在单台电脑上手动改配置，别在配置文件里存密码等秘密，别写定制的配置格式，能不用动态配置就别用。

四、依赖管理

该做的事：用语义化的版本号，明确指定依赖的版本范围，用工具分析传递依赖，加新依赖的时候要谨慎，精确用依赖范围。

不该做的事：别拿 Git 的哈希值当版本号，没好处的时候别加依赖，别直接用传过来的依赖，别弄循环依赖。

五、测试

该做的事：用测试重现 bug，用模拟工具写单元测试，用代码质量工具检查覆盖率啥的，测试的时候用固定种子的随机数生成器，测完关网络套接字和文件句柄，生成唯一的文件路径和数据库位置，清理测试留下的状态。

不该做的事：别不管加新测试工具的成本，别靠别人写测试用例，别光为了提高覆盖率写测试，别只拿代码覆盖率当质量标准，测试的时候能不用休眠和超时就别用，单元测试别调用远程系统，别依赖测试执行的顺序。

六、代码评审

该做的事：提交评审前保证通过了测试和代码检查，专门留点时间做评审，看到粗鲁没建设性或者不当的言论指出来，提供修改的背景信息，别光揪着代码风格，用工具理解难改的地方，把测试代码也放评审里。

不该做的事：别光为了触发 CI 系统提交评审，别光盖章不细看，别把评审反馈当私人恩怨，不了解改动背景别瞎纠结细节，别太挑剔，别让完美挡着优秀。

七、软件交付

该做的事：用基于主干的分支模式和持续集成，用 VCS 管分支，和发布运维团队合作弄好流程，发布变更日志和发行说明，通知用户新版本，用现成工具自动化部署，用特性开关慢慢推出更新，用熔断器防大问题，用影子流量或摸黑启动做重大变更。

不该做的事：别发布没标版本号的包，别把配置啥的都打包一起，别盲目靠发布经理和运维团队，别用 VCS 分发软件，别改已经发布的软件包，没监控结果别展开，别依赖顺序部署。

八、On-call

该做的事：把呼叫号码加到白名单，用优先级类别确定事故响应优先级，严重事故用特定策略，科学排障，用 5W 追根溯源，确认响应支持请求，明确下次回复时间，确认问题改好再关任务票，重定向支持请求。

不该做的事：别无视警告，分流阶段别排障，问题没好别找根本原因，事后别指责别人，别犹豫关没响应的请求，别光问优先级不问影响，别逞英雄啥都修。

九、构建可演进的架构

该做的事：记住 “你不是真的需要” 原则，用标准类库和开发模型，用 IDL 定义 API，给外部 API 和文档做版本管理，隔离数据库，明确定义 schema，用迁移工具管数据库 schema，保持 schema 兼容性。

不该做的事：别没目的乱建太多抽象模型，别写隐含排序和参数需求的方法，别用奇怪代码吓别人，别对 API 做不兼容变更，别对内部 API 版本控制太教条，别在字符串里乱塞没模式的数据。

十、敏捷计划

该做的事：站会简短点，给用户故事写详细验收标准，承诺能完成的工作，大块工作拆开，用故事点估计工作量，用相对尺度和 T 恤尺码帮忙估算。

不该做的事：别痴迷敏捷的 “正确做法”，别怕改流程，别把常规任务描述硬套给用户故事，别忘了跟踪计划和设计工作，没做完又加活，别盲目跟着流程走。

十一、与管理者合作

该做的事：希望管理者好相处、透明，明确告诉管理者自己要啥，设置一对一谈话议程，留好谈话纪要，按想要的反馈写有操作性的内容并跟踪成果，用 SBI 框架让反馈不那么针对个人，考虑长期职业目标。

不该做的事：有困难别瞒着管理者，别把一对一谈话只当工作状态更新会，别凭记忆总结，别给肤浅反馈，别被 OKR 框死，别把反馈当攻击，别忍受糟糕管理。