# 简单设计 Simple design


## 定义
一个采用“简单设计”实践的团队将其软件设计策略基于以下原则：

- 设计是一个持续的活动，其中包括重构和启发式方法，例如YAGNI
- 根据代码简单性规则评估设计质量
- 所有设计元素（例如“设计模式”，基于插件的体系结构等）都被视为具有成本和收益，因此必须证明设计成本是合理的；
- 设计决策应该推迟到“最后一个负责任时刻”，以便在产生选择成本之前，尽可能多地收集有关所选选择的好处的信息。

## 也称为
- 这种做法通常被缩写为YAGNI，因为“您根本不需要它”；当程序员试图仅根据其未来利益提出昂贵的设计元素时，这暗示了通常的反论点（“我们迟早需要这个工厂，我们不妨现在就把它放进去。” ，您将不需要它。”）
- 另一个通用术语是“紧急设计”，它强调良好的全局设计可以源于对代码结构的本地质量的持续关注（与复杂性理论家研究的过程类似，纯粹的本地规则可靠地产生了一致的全局属性）

## 常见陷阱
- 第一个（也是致命的）错误是轻描淡写，例如在为团队配备人员时，基于“设计将出现”的基础，团队中重要的设计技能的重要性；出现并不是魔术，这种技能仍然至关重要
- 简单设计”仅指“软件”设计；使用简单的设计实践来证明与客户或产品所有者的要求或可用性考虑有关的决策是合理的，这具有误导性
- 当设计实践不太可能保持一致时（例如，如果开发小组规模较大且地理位置分散），这种实践可能不明智

## 使用迹象
- 团队维护特定设计任务的“积压”：
	- 设计缺陷，需要通过重构进行显式补救
	- 简化现有代码的机会
	- 推迟进行潜在的设计决策，直到获得更多信息
- 这个积压不会停滞不前，或者仅仅是从未解决过的投诉清单；团队留出了足够的生产时间来定期解决问题（或决定与他们共处）
- 团队定期使用一种或多种辅助实践，这为讨论设计提供了明确的机会
- 任何相对简单的功能更改都需要付出大量努力才能实现的印象是“警告信号”，表明该实践可能未得到有效利用

## 预期收益
- 减轻过度设计（“镀金”）的常见风险
- 据称可以“降低变更曲线的成本” –即，使软件易于更改，因为所有设计决策均与预期的特定更改无关

## 起源
短语YAGNI 从最早开始就与极限编程相关联。

## 技能水平
作为个人贡献者：

- 初学者：能够识别不会“减轻重量”的设计元素（不足以证明其复杂性），并进行重构以简化代码结构
- 中级：可以推迟将来的需求可能需要的设计决策，并且可以确定仲裁该决策的条件
- 进阶：能够确定合适的时机来引入深远的设计决策，例如在桌面应用程序中基于插件的体系结构
在团队一级，试金石是团队是否能够“共享”设计决策，因此这些决策不是基于架构师或首席程序员的个人法令，而是团队中所有开发人员的理解和执行。

## 进一步阅读
- 设计死了吗？Martin Fowler撰写的，仍然是关于敏捷团队如何进行设计的最敏锐的讨论之一






  

点击看敏捷名词地铁线路全图