规则一 避免过度设计
内容:在设计中要警惕复杂的解决方案
场景:适用于任何项目,而且应在所有大型或者复杂系统或项目的设计过程中使用
用法:通过测试同事是否能够轻松地理解解决方案,来验证是否存在过度设计
原因:复杂的解决方案实施成本过高,而且长期的维护费用昂贵
要点:过于复杂的系统限制了可扩展性。简单的系统易维护、易扩展且成本低
过度设计有两大类:
第一类：产品的设计和实施超过了实际的需求
第二类：完成的产品过于复杂
我们一般情况下，更关心的是，第二类，因为，第二类严重的影响了产品的可扩展性
对于第一类
我们要解释下“实际”的意思：
假设，要设计一个空调，结果，你设计了一个，可以把温度从-50摄氏度，增温到100摄氏度的一个高性能的产品，这，就是超过了实际需求的过度设计！你设计的这个产品牛不牛逼，牛逼！ 但是，没有卵用！因为他它已经违背了人类工程学和人类社会了！
而且，这中过度设计，会造成很多问题：
- 研发周期过长
- 开发成本过大
- 浪费的资源过多
- 很大的功能几乎不会被用到
其实，这个东西，就是要考虑到实际的生活，不要过度的设计，浪费不必要的成本！
其实，这个东西，在很多的地方都有体现：你操作的东西，多出了你的需要
再举一个例子：select * from table1;
这种sql语句就是典型的例子了～，你并不需要全部的东西，你应该只拿出自己想要的东西就行了，例如，select name from table1；这样，就不会存在无所谓的第一类过度设计了！
对于第二类
最典型的就是：工程师把产品的设计搞得很复杂，把代码写得很复杂！
我们都应该努力把代码写得通俗易懂
对一个工程师的度量是：看他能多快简化一个复杂的问题，然后构一个易于理解并可以维护的解决方案
浅显易懂的方案的好处：
- 初级工程师快速上手
- 在系统纠错过程中以很快地查出问题,确保系统可以更快地恢复正常
- 能够增强组织和平台的可扩展性
有一个非常好的验证办法可以用来确定方案是否过于复杂,就是负责解决该复杂问题的工程师把自己的解决方案展现给公司内的同技术团队
如果每个技术团队都应该能轻松地理解方案,并可以在无人协助的情下,向其他不知情的人描述该方案，那么，这个技术方案，就是不那么复杂的，是适度的，非过度的设计的！
如果有任何一个技术团队对方案表示不理解,那么就应该针对该方案是否过于复杂进行深入
辩论了，并可能的保持技术方案的简单易懂性，使，技术方案符合人类思维学！
过度设计是可扩展性的大敌之一，设计一个超过实际需要的方案就是在浪费金钱和时间，浪费处理资源,增加系统扩展的成本,限制系统的整体可用性，复杂性的过度，还会：
- 影响扩展
- 难以后续理解【工程师离职之类的】
- 扼杀生产力【太过于复杂，谁都不想碰，像一坨屎，大家都想避开】
- 越来越难以维护
- 出现问题，将很难进行查错