1、一场关于"大括号放哪"的战争团队里两个人吵了半天：大括号是 if (x) { 还是 if (x)\n{。争论消耗的时间、产生的情绪，远超这件事本身的价值。风格问题不该由人吵，该由工具定。 这就是编码规范（Coding Standard）与静态检查（Static Analysis）要解决的问题。本课解决三件事：编码规范到底规范什么？（不只是风格）怎么用自动化工具强制执行，而不是靠自觉？静态检 …

1、"集成地狱"：一个经典的团队噩梦一个五人团队，各自在自己的分支上开发了近一个月，谁都没合过。到"集成日"才发现：小王和小李都"新增"了 UserService，重名冲突。小张升级了依赖 A，和主力升级的依赖 B 版本冲突，编译不过。每个人的代码单看都能跑，合到一起一下冒出 200 个错误。这就是 集成地狱（Integration Hell）：把"集成"攒到最后一次性做，等于把几十个问题堆在 …

1、代码托管 ≠ 项目管理第 12、13 课我们把 Git 和分支策略讲透了。但一个真实的团队项目，仓库里跑的不只是代码，还有一堆"管理问题"：「这个 Bug 谁认领了？修到哪一步了？」「下个版本到底要做什么？做完了吗？」「这个需求当时为什么这么定？谁拍的板？」这些如果靠聊天群和脑子记，很快就是一团乱麻：消息刷屏、责任不清、进度靠猜。协作平台（Collaboration Platform）的价 …

1、三个人的团队，为什么会互相踩脚第 12 课我们学会了"个人的 Git"。但团队一上来就遇到新问题：小王在 main 上直接提交，把大家跑不起来的代码推了上去，全员停工半小时。小李的 PR 挂了 3 天没人看，等他合进去时，main 已经变了 200 个文件，冲突解到怀疑人生。团队没有约定分支怎么命名，仓库里躺着 test、dev2、new-new、老王分支……这些都不是技术问题，是协作流程 …

1、为什么"没有版本控制"是灾难先看一个真实场景。一个三人小组做课程设计，共享文件夹放在网盘上。两周后，文件夹里是这些文件名：main.py main_最终版.py main_最终版2.py main_最终版_真的最终.py main_别动这个_能跑.py最后谁能跑通、改了什么、为什么改，没人说得清。这就是没有版本控制的代价。版本控制（Version Control）解决三件事：历史：每次改动 …

1、技术选型翻车的三种典型第一种：被"新技术光环"带走。看到一个博主说某框架"又快又酷"，团队一拍脑袋就上了。三个月后发现：文档稀烂、生态缺失、招不到人、出了 bug 只能自己啃源码。第二种：用最熟的工具硬套所有问题。"我就只会 MySQL"，于是把时序数据、全文检索、图关系全塞进 MySQL。能跑，但代价是性能和可维护性。第三种：决策只存在某个人脑子里。半年后他离职了，新来的问"为什么用了两 …

1、数据是最后才改得动的东西代码可以重构，架构可以演进，数据最难改——因为数据里存着历史、连着上下游、动一次就可能丢东西。所以数据设计的原则是：宁愿多花一天想清楚，也不要上线后迁数据。本课回答四个问题：数据该用哪类数据库？表格怎么设计才合理（范式与反范式）？索引和事务要注意什么？上线后表结构怎么演进？2、数据设计的四问选型前先回答四个问题（这就是第 9 课"质量属性驱动"在数据上的落地）：问题 …

1、架构不是画图，是"最难改的决策"写错一个函数，改它 10 分钟；选错一个架构，改它 3 个月。架构（Architecture）是系统的骨架与规则：分哪些模块、谁依赖谁、数据怎么流、外部怎么接入。它的本质特征是——决定一旦定下，后续所有代码都要绕着它写，改起来的代价极高。所以架构设计的目标不是"看起来高级"，而是：满足当前的质量属性要求（性能、可维护、安全、可扩展）让未来的改动尽量便宜（可演 …

1、为什么"先画再写"第 7 课我们得到了文字规格。但文字有天然的歧义：你写"任务列表"，有人脑子里是表格，有人想的是卡片流。改一行原型，成本是 5 分钟；改一个已上线的界面，成本是数天。 原型就是最便宜的试错工具：让用户在还没写代码的时候就说"这个不对"。本课回答四个问题：需求怎么变成界面与流程？低保真、高保真原型分别用在什么时候？怎么判断"好不好用"，而不是"我觉得挺好看"？设计怎么落到可 …

1、需求拿到手 ≠ 需求清楚第 6 课结束，你手里是一堆用户故事。但如果直接开工，结局通常是：开发做完了，用户说"这不是我要的"。问题出在"用户故事只是个标题"。一条"作为管理员，我想要能管理用户，以便控制权限"——里面至少藏着 20 个没回答的问题：谁能加？能删吗？删了数据怎么办？批量吗？要审批吗？本课解决四件事：怎么把模糊故事变成可验证的需求？一堆需求，怎么排优先级？需求会变，怎么管理变更 …