一、打破迷思：软件工程≠编程技术
读《构建之法》前，我和大多数计算机专业学生一样，以为软件工程就是"学一门编程语言+做几个项目"。邹欣老师用"软件 = 程序 + 软件工程"这个公式彻底打破了我的认知。
书中提到一个残酷现实：很多毕业生能写出"能跑"的代码，却做不出"可用"的软件。区别在哪里？程序是基本功，但软件工程决定了软件的命运。算法和数据结构固然重要，但如果不能在预计时间内交付、不能应对需求变更、不能保证可维护性，再优雅的代码也是空中楼阁。
这让我想起上学期课程设计的惨痛经历：我花了三周时间"完美"实现了一个功能，却因为没写单元测试，集成时bug成灾，最后不得不推倒重来。书中说的"分析麻痹"和"过早优化"简直就是我的写照——总想弄清所有细节再动手，结果陷入无限延迟。
二、PSP：用数据认识自己
个人软件开发流程（PSP）是我实践最多的工具。我开始记录每个任务的预估时间和实际耗时，结果令人震惊：我的预估误差普遍在50%以上！
表格
复制
任务类型 预估时间 实际时间 误差
界面设计 2小时 4.5小时 +125%
数据库搭建 3小时 2小时 -33%
API开发 4小时 7小时 +75%
这种"用数据说话"的习惯让我从"我感觉快了"的主观臆断，转变为"根据历史数据，这个模块需要X小时"的理性判断。虽然初期记录很繁琐，但三周后，我的预估准确率提升了40%。
三、代码规范：从"我能看懂"到"别人能维护"
书中对代码规范的强调让我汗颜。以前我写代码追求"短平快"，变量名用a、b、c，注释几乎为零，还美其名曰"代码自解释"。直到结对编程时，队友看着我的代码沉默了三分钟，说："你这逻辑，三天后你自己还能看懂吗？"
现在我严格遵守：
命名：studentList 而非 sl
函数：单一职责，不超过30行
注释：解释Why（为什么用这个算法），而非What（这段代码在做什么）
最大的改变是心态：写代码不是给自己看，是给未来的维护者看。这个维护者可能是三个月后的自己，也可能是完全陌生的同事。
四、工程师的"足够好"哲学
最让我释然的是"足够好"的软件这个概念。以前我总追求"零bug"，结果项目无限延期。书中说：Bug是"软件行为与用户期望不符"，而"足够好"是在预计时间内交付符合用户需求、可维护发展的产品。
这不是妥协，而是工程思维的成熟——在资源、时间、质量的三角约束中找到最优解。就像书中说的："完美的敌人是好的"，有时候"先完成，再完美"才是专业态度。
