构建之法阅读笔记01

阅读内容
《构建之法》第二版 第1章～第3章（软件工程概论、个人技术和流程、软件工程师的成长）

核心概念摘要
软件工程不仅仅是"写代码"，而是一套系统化的方法论，包括需求分析、设计、编码、测试、维护和项目管理。书中强调，一个程序和一个软件产品的区别在于：程序只需要在作者的机器上跑通，而软件产品需要面对真实的用户、多变的运行环境、后续的维护迭代和团队的协作。

个人开发流程（PSP）要求工程师在编码之前先做估算，编码过程中记录实际耗时，之后对比分析偏差。单元测试不是"写完代码顺手点一下看看对不对"，而是有方法论支撑的质量保障手段。

个人感受
1、我过去是怎么做的

在大学课程设计和之前的小项目中，我的典型做法是：拿到需求大致看一遍，觉得"懂了"，然后直接打开 IDE 开始写代码。写到一半发现有些地方理解有偏差，就回头边改边写。功能基本跑通之后，手动在浏览器或终端里点几个按钮，看起来没问题就认为做完了。测试？从来没正经写过。时间估算？从来没准过——每次都以为"这个功能两天能做完"，结果往往拖了一周。

2、结合书中所讲，说明为什么这样不好

书中明确指出，这种做法混淆了"程序"和"软件产品"的边界。我的代码只在我的机器、我的环境、我的操作习惯下跑通了，换个浏览器版本、换组数据、换个操作顺序就可能崩溃。没有单元测试意味着每次改代码都是"盲改"——我不知道这次修改是否破坏了已有功能。不做事前估算和事后复盘，导致我对自己的开发效率完全没有客观认知，时间上永远在"凭感觉"承诺，最后不断延期。书中提到，软件工程师的能力成熟度，恰恰体现在对自己的估算偏差能从 50% 以上压缩到 20% 以内这个过程中。

3、解决办法

从下一个项目开始，强制自己执行以下流程：

先写用例再写代码：在动手编码之前，花 30 分钟把功能的使用场景和边界条件列出来，用文字描述清楚"输入什么、输出什么、异常情况怎么处理"。
估算—记录—对比：每个功能模块开始前写一个预估时间，开发过程中用 Toggl 或简单表格记录实际耗时，周末花 10 分钟做一次偏差对比。连续记录 6 周后，对估算偏差率做一次统计分析。
单元测试先于实现：核心逻辑函数采用 TDD 方式——先写测试用例（红），再写实现代码让测试通过（绿），最后重构优化（重构）。非核心模块至少做到实现后立刻补齐测试，不允许"手动点两下就算过了"。