阅读笔记（二）

本章一上来就提醒读者：用户提出来的往往不是真正的问题，而是他想象出来的解决方案。比如同学说"这个系统查询太慢，给我加个索引"，真正的问题可能是SQL写法不合理、数据量大，或者表结构设计有冗余。务实程序员要先追问"为什么"，把表象挖到根因，避免在错误的方向上拼命优化。作者提倡"分析优先于编码"，动手之前先把问题描述清楚、把边界条件想明白，必要时在纸上、白板上或者用小脚本做原型验证。
"曳光弹"是这一章最经典的比喻：机枪在夜间射击时先打出发光曳光弹，照亮弹道，后面的子弹沿着这条光路跟进。软件开发也可以这样——先选出一条贯穿整体架构的最小功能链路，从界面、业务逻辑到数据库全部打通，让它在真实环境里跑起来；之后再围绕这条骨架填充各个模块。这种方式比"先在脑子里把所有细节设计完美，最后再拼接"更可靠，因为它让系统尽早暴露真实的接口问题和环境问题。作者还讨论了"知其所以然"：工具和语言会不断更换，但底层的原理、建模方法、架构思想是相通的，学会通用的思维模型比记住某个框架的API更重要。
我自己在做课程设计和网页项目时，反复体会到"想清楚再动手"的重要性。"先分析、后建模、再编码"。读完"曳光弹"这一节后，我意识到下次应该先选一个最简单的登录或者列表页面，把前端请求、Servlet后端、MySQL数据库整条链路打通跑通，哪怕功能很简陋，先让骨架动起来，再逐步扩展。这种"先贯通、再丰富"的做法，比封闭开发到最后才集成风险小很多。本章提醒我要反过来去理解：面向对象为什么这样设计、集合框架底层用了什么数据结构、异常机制解决了什么问题，把通用原理吃透，换一门语言也能快速上手。
编程能力的差距，很大程度上在写代码之前就拉开了。能不能准确理解问题、能不能把复杂问题拆解成可建模的小部分、能不能先用一条曳光链路验证整体思路，决定了后续工作是否顺利。作为学生，我需要刻意训练自己"先想后写"的习惯，遇到需求先追问、先画图、先做最小验证，而不是打开 IDE 就开始堆代码。