务实的方法

优秀设计的精髓

ETC 原则（Easier To Change）：

• 解耦：隔离关注焦点，可以更容易地进行修改。
• 单一职责原则：一个需求的变化只会影响一个模块。
• 命名：良好的命名可以使代码更容易阅读。

DRY——邪恶的重复

DRY（Don't Repeat Yourself）原则：

• 代码中的重复。
• 文档中的重复。
• 数据中的重复。

正交性

对于两个或多个事物，如果它们的行为不会相互影响，那么它们就是正交的。

象征着独立性和解耦。

• 保持代码解耦。
• 避免全局数据。
• 避免相似的函数，每个函数都有不同的中心算法，可以使用「策略模式」进行优化。
• 编写单元测试。

可逆性

• 将第三方的 API 隐藏在自己的抽象层之后。
• 将代码分解为多个组件。

曳光弹

先实现最小可行产品（MVP）。

原型与便签

你可以为下列事物做原型：

• 架构
• 已存在的系统中的新功能
• 数据结构或外部数据的内容
• 第三方工具或组件
• 性能问题
• 用户界面设计

当制作一个原型时，下面几个方面可以忽略：

• 正确性：你可以在适当的地方使用替代数据。
• 完整性：原型只需要满足有限的功能，可能只有一个预先选好的输入数据片段及单个菜单选项。
• 健壮性：错误检查可以不完整，甚至完全没有都行。如果你偏离了预定的航线，原型机很可能烧毁在绚丽的烟火中——那又如何！
• 格式：原型代码可能并不需要太多注释和文档（尽管围绕从原型中获取的经验，可能会产生大量文档，但是相对而言，原型系统本身的文档要少得多）。

制作架构原型：

• 主要组件的职责是否恰当，有没有定义清晰？
• 主要组件之间的协作是否定义清晰？
• 耦合度最小化了吗？
• 你能确定重复的潜在来源吗？
• 接口的定义和约束能否接受？
• 在执行过程中是否每个模块都有访问所需数据的途径？在需要数据的时候，能访问到吗？

领域语言

计算机的语言会影响你怎样思考问题，影响你怎样看待信息的传播。

每一门语言都有一个特性列表——比如这些时髦的术语：静态类型还是动态类型，早期绑定还是晚期绑定，函数式还是面向对象，继承模型，mixin，宏机制——所有这些对问题的解决方案，既可能提供建议也可能扰乱视听。

同样是设计解决方案，用 C++ 的方式和用 Haskell 的思想，得到的结果会大为不同，反之亦然。

估算

通过估算来避免意外。

估算项目进度，根据代码不断迭代项目进度表。（TODO 看板？）