《构建之法》读书笔记3

《构建之法》读书笔记：从个人经验到科学实践的转变

一、之前我是怎么做的

在阅读《构建之法》之前，我的软件开发和学习方式更多是“野蛮生长”式的：

1. 编程实践：以完成任务为导向，注重代码能否运行，而非代码的可维护性、可扩展性。比如，写代码时很少写注释，变量命名随意，模块化设计意识薄弱。
2. 团队协作：缺乏规范的流程，依赖口头沟通，版本管理混乱（比如直接传代码压缩包，而非使用Git）。
3. 测试与质量保障：基本不写单元测试，认为“手动测试没问题就等于代码没问题”。
4. 学习方式：倾向于直接写代码，而非系统学习软件工程理论，认为“理论无用，实践至上”。

二、和书中的做法有什么不同

《构建之法》从软件工程的角度，系统性地提出了科学的方法论，与我的旧习惯形成鲜明对比：

1. 个人开发与团队协作
   • 书中强调代码规范（如命名规则、注释标准）、模块化设计，而我过去更关注“快速实现功能”。
   • 书中提倡版本控制（如Git）、代码审查，而我过去认为这些是“浪费时间”。
2. 开发流程
   • 书中介绍敏捷开发（Scrum、每日站会）、需求分析（用户故事、原型设计），而我过去是“接到需求直接开写”。
   • 书中强调持续集成（CI/CD），而我过去是“全部写完再手动部署”。
3. 测试与质量
   • 书中详细讲解单元测试、自动化测试的重要性，而我过去认为“测试是测试工程师的事”。
4. 职业成长
   • 书中提出效能分析（如PSP个人软件过程）、技术债管理，而我过去很少反思效率问题。

三、从中得到的启示

1. 工程化思维优于“游击队”模式
   • 过去的做法虽然短期见效快，但长期来看会导致维护成本高、团队协作低效。书中提到的规范、工具和流程，能显著提升代码质量和开发效率。
2. 测试是质量的保障，而非负担
   • 单元测试和自动化测试并非“额外工作”，而是减少后期调试时间的有效手段。
3. 团队协作需要流程和工具
   • Git、代码审查、敏捷会议等实践，能减少沟通成本，避免“最后一刻才发现问题”的窘境。
4. 理论指导实践，而非脱离实践
   • 过去轻视软件工程理论，但书中案例证明，科学的方法论（如需求分析、效能优化）能避免很多低级错误。

四、行动计划

1. 在个人项目中实践代码规范和单元测试。
2. 学习使用Git进行版本管理，尝试参与开源项目以练习协作。
3. 在团队中推动每日站会和代码审查，逐步引入敏捷实践。
4. 定期复盘个人效能，用PSP方法记录时间分配，优化工作流程。

《构建之法》让我意识到，软件工程不仅是“写代码”，而是一套系统的科学方法。从“能跑就行”到“优雅高效”，需要持续学习和改进。