You are here

DID原则

Blog Terms: 

1 换个思路理解 DID

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

DID:

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

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

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

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

2 过度设计

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

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

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

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

3 精简精简在精简,拆分拆分在拆分。

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

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

 

Refer:

http://younghz.github.io/DID