构建之法阅读笔记01

《构建之法》第一章阅读笔记

（阅读范围：第1章 "概论" 结束）

---

一、本章核心内容总结

1. 软件工程的定义与目标：

   • 软件工程是"将系统化的、规范化的、可量化的方法应用于软件的开发、运行和维护"，其核心目标是解决复杂度问题，通过工程化手段控制开发成本、保证质量。
   • 对比"个人程序"与"软件系统"：前者依赖个人能力，后者需要团队协作与流程规范。

2. 软件开发的特殊性：

   • 软件是"逻辑实体"而非物理实体，其复杂性体现在需求多变和不可见性上。
   • 书中以"焦油坑"比喻：缺乏规范的开发会陷入反复修改、无法交付的困境。

3. 初级工程师的误区：

   • 过度关注"写代码"而忽视需求分析、测试、维护等全生命周期环节。
   • 迷信"银弹"（如某种万能工具或方法论），忽略实际问题的复杂性。

---

二、个人感受与反思

1. 我过去是怎么做的：

   • 在做项目中，我曾负责一个简单的Web应用开发。当时我的做法是：
     • 直接开始写代码，没有明确需求细节（例如"用户登录功能"的具体交互流程）；
     • 代码写完后才进行测试，导致后期发现大量接口不兼容的问题；
     • 认为"代码能跑就行"，拒绝写文档，最终出现问题时无法理解模块逻辑。

2. 结合书中观点，为什么这样不好：

   • 缺乏需求分析：书中强调"软件=程序+软件工程"，需求是工程的起点。我跳过需求确认，导致后续频繁返工（例如登录页面的密码规则被反复修改）。
   • 忽视测试的代价：书中提到"缺陷修复成本随阶段指数增长"，我的后期测试发现的问题，实际在设计阶段就能规避。
   • 无文档的团队协作灾难：软件工程的核心是"多人协作"，我的个人主义行为增加了沟通成本，违背了"可维护性"原则。

3. 提出的解决办法：

   • 采用"需求-设计-实现-测试"的迭代流程：
     1. 与利益相关者（队友/用户）书面确认需求（哪怕是一个简单的功能列表）；
     2. 设计阶段输出接口文档或伪代码，确保团队理解一致；
     3. 实现时遵循"测试驱动开发"（TDD），每完成一个小功能立即验证。
   • 强制文档化：用Markdown记录关键设计决策和接口说明，即使项目再小也坚持"代码未动，文档先行"。

---

三、后续行动计划

• 在下一个项目中实践"需求确认清单"（参考书中的NABCD模型）；
• 使用Git版本控制时，要求每次提交关联任务描述或问题编号，避免混乱。

---