软件工程推荐阅读：遇到问题再找对应资料

第一次学习不需要同时读完所有经典书。先沿课程完成一个小功能，卡在某一步时再查资料，通常更容易知道自己在找什么。本页按问题提供入口，并说明哪些资料适合入门、哪些更适合做过项目后回看。

软件工程 2026/10/54 分钟阅读

软件工程推荐阅读：遇到问题再找对应资料

1. 还不理解工程与编程的关系

先读 Software Engineering at Google 第一章。它讨论软件随时间和规模变化带来的问题。不要把大组织的所有流程直接搬到个人项目，先抓住“未来还要维护”这个视角，再回到自己的功能卡。

读完做一个动作：为收藏功能写出未来最可能出现的两个变化。例如文章改名、同一用户换设备。看看当前设计是否能承受，再考虑需要多少流程。

Cucumber 的 BDD 介绍适合认识如何用具体例子讨论行为；Gherkin 参考解释常见场景表达。先练习前提、操作、结果，暂时不必安装工具。

把“保存应该正常”改成两个人能重复执行的步骤，再让对方指出遗漏。沟通有了共同例子以后，自动化才有稳定目标。

先读简短的敏捷宣言，再按需看 Scrum Guide。前者提供价值取向，后者定义具体框架，不能互相替代。

资料中出现的流程并非唯一答案。对个人小项目，先做到小步完成、尽早试用和定期反思就很有价值。评估方法是否有效，要看它是否帮助解决真实协作问题。

Software Carpentry Git 入门是面向学习者的逐步练习；Pro Git 中文版适合系统学习与查阅。先在独立目录练习提交、分支和合并，不要直接在生产仓库试破坏性命令。

Google Engineering Practices说明评审者与作者分别应关注什么。阅读时可以拿自己的一份小改动做对照：是否解释了问题、结果、测试和限制？把格式交给工具，把人的讨论留给行为和设计。

C4 model帮助用不同层次画清系统，ADR 社区提供决策记录思路。先画系统边界和一次请求，再记录一个真实取舍，例如为什么收藏需要服务端保存。

Refactoring适合在代码开始难改时阅读。把一种小调整实际做出来，确认外部行为不变，比一次背完全部重构名称更有效。网站可阅读并不意味着所有书籍或材料采用相同开放许可证，转载前仍需查看各自许可。

Node.js 24 测试文档对应本课可运行示例。Google SRE 的测试章节则帮助理解不同检查层次，以及为什么测试不能代替运行时观察。

进一步阅读持续集成和故障复盘。先落实一个短反馈循环：改动、检查、交付、观察，再逐步完善基础设施。

每次阅读先写一个问题，读后留下一个例子和一条适用边界。例如“重构保持外部行为，但新增收藏规则属于行为变更”。遇到互相矛盾的说法，核对版本、场景和术语定义，不按作者名气直接投票。

本页核对于 2026-10-05，外部资料可能更新。课程中的案例、练习与答案是围绕本知识库重新组织的教学内容；引用链接用于追溯概念，不能把“有链接”当作全部结论已经被自动证明。