正当我对着空白的IDE发愁“该如何开始”时，这本书的《曳光弹开发》这一章给了我明确的方向。
1. 曳光弹 vs. 原型—— 两种启动策略
这是我第一次接触这两个概念，它们解决的是不同的问题。
原型：用于探索和验证。 书上说原型是“用完即弃”的。这让我想起学C语言时，要验证一个复杂的算法逻辑，我会先写个简单的test.c，只关注核心算法，忽略输入输出和错误处理。这就是一个原型。它的目的是回答特定问题，比如“这个排序算法在我的数据上有效吗？”。在Java里，我可以快速写一个Main类，用硬编码的数据测试一个核心类（比如Book）的行为，而不必关心UI或数据库。
曳光弹：用于构建真实系统。 而“曳光弹”的方法酷毙了！它的目标是最终系统的一部分。想象一下，你要开发一个完整的电商网站（这目标太大了，让人无从下手）。曳光弹方法不是先花半年做数据库设计，再花半年做后端API，而是在第一天就让一个极简但“端到端”可用的系统跑起来。比如，做一个最简单的功能：“显示一件商品的信息”。这个功能需要：
前端
后端
数据库（一张简单的商品表）
当你把这个最细的链路打通，虽然功能简陋，但它是一个真实的、完整的系统骨架。之后增加用户登录、购物车等功能，就像是往这个骨架上添肉。
2. 我的课程设计实践：迷你图书管理系统
我决定用“曳光弹”方法来启动我的Java课程设计。我的“第一发曳光弹”目标是：实现一个通过控制台输入命令，可以“添加”一本图书并“列出”所有图书的程序。
这个目标虽小，但涉及了完整链路：
领域模型： 创建Book实体类。
数据层： 创建BookRepository接口及其内存实现InMemoryBookRepository。
业务逻辑： 创建BookService类，包含addBook和getAllBooks方法。
用户界面： 一个简单的控制台循环，解析用户命令。
花了一个下午，我这个“曳光弹”程序真的跑起来了！虽然它只能做两件事，但带来的信心提升是巨大的。我不再面对一个庞大的、令人焦虑的空白项目，而是有了一个可以运行、可以扩展的基础。接下来，我就可以像打靶一样，沿着这个弹道（即架构），依次实现“删除图书”、“查询图书”、“持久化到文件”等功能。
3. 便签的智慧—— 随时清空大脑
“用便签来策划”这个建议太实用了！我以前习惯把想法和待办事项都记在脑子里，结果经常忘记，或者因为事情太多而无从下手。现在，我开始用Trello这类看板工具（数字便签）来管理我的学习和项目。
我为图书管理系统创建了一个看板，包含“待办”、“进行中”、“测试中”、“完成”等列表。把“实现删除功能”、“为Book类添加ISBN属性”这样的小任务写成卡片。每完成一个，就把它拖到“完成”列，这种视觉化的进度带来了巨大的成就感，也让我能专注于当前最该做的事。
总结与联想：
这一章让我明白，启动项目的能力和编码能力同等重要。“曳光弹”方法完美解决了我的“开端焦虑症”，而“便签”则帮助我管理复杂性和保持专注。联想到多态，我意识到我的InMemoryBookRepository就是一个“曳光弹”，未来我可以很容易地创建一个FileBookRepository，利用多态在不修改业务代码的情况下替换它，这正是正交性和可撤销性的体现。
