笔记一：先想清楚，再动手——读第 3 章《三思而后行：前期准备》

一、这一章讲了什么
McConnell 开篇给出一个反直觉的数据：在典型的软件项目中，真正的「编码」（构建活动）只占 20%—30% 的时间，其余大部分花在需求、设计、测试和维护上。可现实中，我们往往把「写代码」当成全部，一拿到任务就急着敲键盘。作者借用木匠的谚语——「量两次，锯一次」——说明一个朴素的道理：前期多花的一小时，能省下后期返工的十小时。
二、三个我划了线的观点

1. 问题定义先于一切。 在写第一行代码之前，必须能回答「这个程序到底要解决什么问题」。如果连问题都没说清，写得再快也是白写。
2. 需求必须「可验证」。 「界面要友好」不是需求，「点击后 2 秒内响应」才是需求。无法验证的需求，等于没有需求。
3. 架构是「分解 + 决策」。 把系统拆成哪些模块、模块之间怎么通信、用什么技术，这些决定在编码前就该有个雏形。
   三、结合我自己的项目
   做课程里的个人主页（Lab01）时，我一开始想直接写 HTML，结果页面结构改了三遍，CSS 越改越乱。后来我先在纸上画出「导航—基本资料—学习经历—奖励—动态」的分区，再按区块逐个写代码，返工量立刻降下来。这让我真切体会到：所谓「前期准备」，不是拖延，而是给后面的自己省事。
   四、我打算怎么做

• 每个功能动手前，先用 5 分钟写一段「这个功能要解决什么问题、输入什么、输出什么」。
• 复杂页面先画结构草图或写伪代码，再写正式代码。
• 需求写不清时，先问清楚，而不是先猜着写。