梦断代码阅读笔记01

在《软件工程》课程设计中，我作为组长承诺开发"智能选课助手"，包含课程推荐、课表冲突检测、成绩预测三大核心功能。团队基于初期调研的20个需求点制定开发计划，未预留需求变更空间。这与书中第2章微软团队的"承诺文化"如出一辙——为追求高分盲目扩展功能。当指导老师要求增加"教师评价查询"功能时，团队陷入被动，最终因代码质量低下导致核心功能无法运行。这种"需求蔓延"（Feature Creep）现象，根源在于缺乏需求优先级管理。应用书中"最小可行产品（MVP）"理念。将项目拆解为3个迭代周期：

1. 基础版：实现课程查询与课表生成
2. 优化版：增加冲突检测与收藏功能
3. 增强版：探索推荐算法与成绩预测。
   在开发"校园迎新系统"时，我坚持采用刚学的Spring Cloud微服务架构。团队花费2周搭建分布式系统，最终因服务器资源不足导致注册功能崩溃。这与书中第4章微软NT内核开发的"技术浪漫主义"高度相似——过度追求技术新颖性忽视可行性。书中强调"技术选型应匹配项目规模"，而我忽略了校园服务器仅支持单体应用的限制，导致系统部署失败。
   实施"技术栈分级验证"：
4. 评估阶段：用Docker容器测试微服务可行性，发现内存溢出问题
5. 降级方案：采用Spring Boot单体架构+Redis缓存
6. 优化路径：后续迭代逐步拆分支付、通知等独立模块
   在《移动应用开发》课程小组中，我独自负责核心代码编写，其他成员仅完成界面设计。由于缺乏文档规范，代码合并时出现严重冲突，最终项目演示时崩溃。
   这与书中第5章微软开发小组的"筒仓效应"如出一辙——知识私有导致协作失效。书中强调"代码所有权"（Code Ownership）的危害，我的集权式开发模式使团队无法形成持续集成能力。
   推行"结对编程+每日站会"制度：
7. 任务拆分：将核心功能分解为用户登录、课程展示等8个任务
8. 结对开发：强制要求两人一组完成任务，实时同步代码到Git仓库
9. 每日同步：15分钟站会汇报进度，用Trello看板跟踪任务状态