yan-mika1. 为什么我们需要一场"红蓝对决"？
期末考试前的复习总是让人头疼，尤其是软件工程这种知识点繁杂的学科。传统的死记硬背不仅效率低下，而且容易遗忘。我在大三那年偶然发现了一种独特的复习方法——通过模拟技术对决的方式，把枯燥的知识点变成一场场精彩的攻防战。
这种方法的精髓在于：将每个核心知识点转化为一个具体的"战场"，由两位同学分别扮演红方（攻击方）和蓝方（防御方）。红方负责提出刁钻的问题或设计极端场景，蓝方则需要运用所学知识进行防御和解答。通过这种对抗性思维，知识点的掌握程度会得到全方位的检验。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 需求工程：用户故事 vs 用例图
2.1 红方进攻：用户故事的模糊地带
红方首先发难："用户故事'作为客户，我想快速结账'太过模糊，根本无法指导开发！"这是一个典型的攻击点。用户故事确实存在边界不清的问题，特别是在验收标准不明确的情况下。
蓝方该如何应对？关键在于补充"3C原则"（Card, Conversation, Confirmation）。具体防御策略包括：
- 补充验收标准：明确"快速"的定义（如3步完成支付）
- 添加技术约束：支持至少5种支付方式
- 定义异常流程：网络中断时的降级方案
2.2 蓝方反击：用例图的过度设计陷阱
蓝方转守为攻："用例图把所有可能性都画出来，结果变成了'蜘蛛网'，反而增加了理解成本！"这是需求工程中常见的过度设计问题。
红方需要承认：用例图确实存在滥用风险。有效的防御方案是采用"目标导向"的绘制方法：
- 核心路径不超过5个步骤
- 异常流程单独标注
- 使用«include»和«extend»关系简化结构
实战技巧：在期末考中遇到需求分析题，建议先写2-3个用户故事，再提炼出核心用例图，这种组合打法最容易拿高分。
3. 设计模式：策略模式 vs 工厂模式
3.1 场景设定：电商促销系统
假设我们要实现一个促销系统，支持多种折扣策略（满减、折扣券、秒杀等）。这是设计模式应用的经典场景。
3.2 红方选择策略模式
红方主张使用策略模式：
java复制interface DiscountStrategy {
double applyDiscount(Order order);
}
class FullReduction implements DiscountStrategy {
public double applyDiscount(Order order) {
// 满300减50逻辑
}
}
优势在于：
- 算法可独立变化
- 避免多层if-else
- 符合开闭原则
3.3 蓝方坚持工厂模式
蓝方则认为工厂模式更适合：
java复制class DiscountFactory {
public static Discount create(String type) {
switch(type) {
case "FULL_REDUCTION":
return new FullReduction();
// 其他类型...
}
}
}
理由是：
- 创建逻辑集中管理
- 客户端无需知道具体类
- 更容易添加新类型
3.4 终极解决方案：模式组合
经过激烈辩论，双方达成共识——最佳实践是组合使用两种模式：
- 用策略模式封装算法
- 用工厂模式管理策略创建
- 再用门面模式提供统一接口
这种架构既保持了灵活性，又降低了耦合度。在期末考试中，展示这种模式组合的思维往往能得到额外加分。
4. 软件测试：单元测试的边界之争
4.1 红方极端案例：数据库交互测试
红方抛出一个棘手问题："单元测试要不要测数据库操作？"这是一个极具争议的话题。
激进派认为：
- 涉及数据库就不是"单元"测试
- 运行速度慢
- 容易产生测试污染
保守派则主张：
- 业务逻辑常依赖数据库状态
- 不测数据库可能遗漏严重bug
- 可通过内存数据库加速
4.2 蓝方务实方案：测试金字塔+Mock
蓝方给出的折中方案是：
- 核心逻辑用纯单元测试（完全Mock）
- 数据库操作用集成测试
- 整体流程用端到端测试
具体到代码层面：
python复制# 纯单元测试示例
def test_calculate_discount():
order = Order(items=[...])
strategy = Mock(spec=DiscountStrategy)
strategy.apply_discount.return_value = 100
service = DiscountService(strategy)
assert service.apply(order) == 100
strategy.apply_discount.assert_called_once_with(order)
# 集成测试示例
@pytest.mark.django_db
def test_order_save():
order = Order.objects.create(...)
assert order.id is not None
这种分层策略既能保证测试覆盖率，又能控制执行时间——特别适合期末大作业的测试方案。
5. 敏捷模型：Scrum还是Kanban？
5.1 红方质疑Scrum仪式
红方指出："每日站会变成形式主义，Sprint评审浪费时间！"这是Scrum实施中的常见痛点。
5.2 蓝方改良方案
蓝方建议采用"轻量级Scrum"：
- 站会不超过7分钟
- 用看板替代任务板
- 两周一次的Sprint
- 评审与回顾合并进行
5.3 特殊场景下的Kanban
对于期末小组项目，当：
- 需求变化频繁
- 成员时间碎片化
- 交付压力大时
Kanban可能是更好的选择：
- 可视化所有任务（开发/文档/测试）
- 设置WIP限制（如每人同时不超过2个任务）
- 每日同步阻塞问题
我在三个学期的小组项目中实践发现：前期用Scrum建立节奏，后期用Kanban应对变化，这种混合模式最适合学生项目。
6. 期末应试技巧：从理论到实践
6.1 简答题的"三明治"结构
遇到"简述XXX概念"这类题目，采用：
- 定义（教科书标准说法）
- 举例（自己项目中的实际应用）
- 对比（与相似概念的异同）
例如回答"什么是观察者模式"：
- 定义：一对多的依赖关系...
- 举例：在我们开发的图书馆系统中...
- 对比：与发布-订阅模式相比...
6.2 设计题的分步拆解
面对"设计一个XX系统"的大题：
- 先画上下文图（系统边界）
- 再提取核心用例（不超过3个）
- 选择关键模块详细设计
- 说明使用的设计模式
- 补充非功能需求（性能、安全等）
6.3 代码题的"模式识别"
发现题目隐含的设计模式：
- 大量if-else → 考虑策略/状态模式
- 复杂对象创建 → 工厂/建造者模式
- 组件间通信 → 观察者/中介者模式
我在最后一次期末考试中，通过识别出题目隐含的装饰器模式需求，仅用20行代码就解决了其他同学写80行都没搞定的问题。