构建之法读书笔记

一、核心观点提炼
​​1.1 软件工程的本质（第1章）​​
graph LR
A[程序] --> B(算法+数据结构)
C[软件] --> D{程序+工程化}
D --> E[可维护性]
D --> F[可扩展性]
D --> G[可靠性]

​​振聋发聩的断言​​
“把‘够用就好’的玩具变成可维护的软件产品，需要工程化思维”

​​顿悟点​​：课程大作业中“临时改需求导致代码崩溃”的困境，本质是缺乏工程约束（如未写单元测试）
​​技术≠产品​​四象限
维度 技术突破型 用户需求型
​​成功案例​​ Google Glass 微信红包
​​致命陷阱​​ 解决不存在的问题 过度迎合短期需求
​​1.2 个人开发流程（第2章）​​
​​PSP对比传统编程的降维打击​​
阶段 学生习惯 PSP要求 改进实践案例
需求分析 直接开写代码 耗时占比15%-20% 用PlantUML画状态图
代码复审 无系统方法 每500行≥30分钟 结对编程错字率↓45%
测试报告 手动黑盒测试 自动化覆盖率≥80% Jest替代console.log
二、直击痛点的反思
​​2.1 理论与现实的断层​​
​​书中理想​​：个人开发流程需精确到分钟级的耗时记录
​​实践困境​​：

真实情境的时间损耗因子（课堂项目验证）

time_loss = 环境配置(20%) + 需求变更(35%) + 会议沟通(25%) + 编码(20%)
​​矛盾点​​：严格的PSP是否适用于本科教学场景？（需压缩50%理论时间）
​​2.2 “银弹”迷信的破灭​​
​​反常识洞见​​：
“瀑布模型在航天软件中的缺陷率低于敏捷开发”

​​课堂关联​​：王建民老师强调“电信级系统需DO-178C标准”，呼应书中场景适用性原则
三、关联实践的提问
​​3.1 待解困惑​​
​​度量陷阱​​：
如何平衡PSP的量化要求与创意型任务（如UI设计）的非线性工作特征？

观察：团队成员用Toggl计时，导致为凑数据拆分任务
​​工具链悖论​​：
Jenkins等自动化工具降低人为失误，但维护成本陡增（课程项目CI流水线耗时＞编码），ROI临界点在哪？

​​学生开发者的特殊性​​：
书中微软工程师案例是否适用于学习曲线陡峭的本科生？如何定制“教学版PSP”？

​​3.2 实验建议（验证第2章理论）​​
graph TB
A[对照组] -->|传统开发| B[10人团队]
C[实验组] -->|PSP驱动| D[10人团队]
E[数据采集] --> F[代码Bug率]
E --> G[需求完成度]
E --> H[时间偏差率]

四、金句手账
​​“工程师的荣耀不是写出好代码，而是让垃圾代码能正常工作”​​
—— 第1章结尾注：与王建民老师所讲“软件工程是做取舍的艺术”形成互文

​​“PSP不是紧箍咒，而是显微镜”​​
—— 第2章精髓：用数据透视改进空间（非惩罚工具）

五、明日阅读重点
第3章“结对编程”：验证两人协作的效率损耗边界
探索PSP与学生团队Scrum的兼容性矛盾