也谈DID与过度设计

• 1 换个思路理解 DID
• 2 过度设计
• 3 精简精简在精简，拆分拆分在拆分。

最近一个月陷入了不断的开发-推翻-开发的不确定循环中，总结一下。

1 换个思路理解 DID

在软件建构领域，有一个原则叫DID, 通常用来保证资源和时间的最小化。

DID:

• 设计（Design）20倍的容量。
• 实现（Implement）3倍的容量。
• 部署（Deploy）1.5倍的容量。

这个DID一般是从资源成本的更小消耗来出发，希望将更低成本的设计发挥更大的作用，对更高成本的部署更谨慎的使用。

换个思路，在需求开发与系统设计层面出发，也应该遵循这种规律，即在前期设计层面下足功夫，用更周到的设计来实现 方案，以便在部署上线后的改动最小。

但是，往往在实际开发中这个过程都是本末倒置的，从 ‘拍脑袋就做’ 到 ‘开发中发现行不通’ 到 ‘返工’，或者更严重的上线 之后才发现问题，导致更大的返工成本。

2 过度设计

通常意义的过度设计包含两方面：

• 超出了需求的本意，比如我要一个一公里的代步工具你给我设计了一架飞机。
• 导致系统过度复杂。

我认为，还有一种也应该称之为过度设计，即设计出了合理的但是没人感兴趣的产品。比如所有人都买了一款可用但是有瑕疵的手机v1， 不到一个月，一款同款产品v2出现，虽然更完美，价格更低，但是基于成本没人会买单。

但是v2一定是推广不了的吗？也不一定，怎么推广？顺势而为。比如运营商推出5G, 只有v2支持，这叫顺势而为；国家规定，只有支持5G的手机才能使用，这也叫顺势而为。晚上做班车下班，遇到一个之前的领导，他说为什么当时order-platform可以推广，那是因为借着海外的大势…

3 精简精简在精简，拆分拆分在拆分。

这个，和过度设计想对应。和成就感相挂钩。

帕累托法则：80%的成果源于20%的时间。如果时间有限，那么尽量把时间放在容易产生成果的事情上，有成果便有产出，才有成就感。