目标:防止设计中涌现庞杂的解决计划。

实用情况:实用于任何项目，所有年夜型的或庞杂的体系和项目都应当采取该原则。

运用方法:让同同业来检讨解决计划是否好懂得，抵制过度设计的强烈愿望。

运用来由:庞杂的解决计划实行成本高，并且会发生年夜量历久成本。要点:过度庞杂的体系会限制扩大才能。简略的体系更轻易保护和扩大，且成本更低。

维基百科说明说，过度设计分为两年夜类。一类是指设计与实现超越了有效需求的产物。出于完全性的斟酌，我们只简略地评论辩论一下这个问题。相对于第二类问题来说，这类问题对可扩大性的影响较小。过度设计的另一类问题指过于庞杂的产物。如前所述，我们最关怀的是第二类问题对可扩大性的影响。不外，照样先来懂得一下第一个问题吧。

要说明过度设计的第一类问题，即超越产物有效需求的问题，就要先搞清晰楚“有效的”这个术语的寄义，这个术语在这里表现的只是“可以或许伸用”。例如。为家庭住房设计一种空调，可以或许在室外温度为0开时把全部房子的温度加热到300华氏度，这毫无意义，纯属糟蹋，我们只须要一个可以或许在室外温度为-20华氏度时把房子加热到舒适温度的产物。这种过度设计会发生过度的成本，个中开辟的成本会更高，实行该计划的硬件和软件成本也会更高。假如研发这种过度设计体系的时光比研发有效体系的时光更长，还可能迁延产物的宣布，对公司造成进一步的影响。成本高，利润就低。研发时光长，收入或收益就会被延迟，所有这些成本都邑影响到好处相干者。规模舒展，或者最初的产物界说和最初的产物宣布之间的规模差别，是过度设计的一种表示。

说个更接近我们工作的例子，是开辟一个员工打卡体系，这个体系可以或许处置的员工数目是全部地球上人数的100倍。在这个软件的应用刻日内，地球上的生齿升至100倍的可能性是微乎其微的，而所有人都为一家公司工作的可能性则更小。我们当然想让构建的体系知足客户需求但也不想糟蹋时光来实现和安排远远超越需求的体系。

过度设计的第二类表示是使体系过度庞杂，或者用庞杂的方法来实现它。简而言之，就是要消费过年夜的力量去完成一项工作，或者是让用户消费过年夜的力量去完成一项义务，或者是让法式员消费过年夜的力量去懂得一个功效。让我们来一一剖析过度庞杂的体系的这三种情形。

什么是消费过年夜的力量去完成一项工作呢?实际世界有最简略的例子。假设你让或人去杂货店买器械，你告知他，店里面的所有商品都拿一个，列队结账时给你打德律风。等他打德律风给你时，你再告知他到底想要哪几个，让他从所拿的无数篮商品中选出来，然后把其他商品都倒在地上。你必定会说:“别开顽笑了。”可是，你在本身的代码顶用过select(年夜)schema_nane.tab1e_name如许的SQL语句，只是为了从返回的聚集中找出本身想要的成果吗?我们这个杂货店的例子，和上述的se1ect(*)恰是异曲同工。在你的代码中，有几个前提语句是处置个体情形的，它们是依照什么次序履行的?是不是最可能产生的情形最先履行?你是不是经常刚查询完一个成果，又反复查询一次?是不是经常刚显示了HML面，这种情形到处可见，却又经常被疏忽。

什么是让一位用户消费过年夜的力量去完成一项义务呢?谜底异常简略。在很多情形下，少就是多。为寻求体系的灵巧性，我们老是想给它硬加上尽可能多的奇异功效。但生涯的情趣并不总在于多种多样。很多时刻，用户只是想无干扰地尽可能快地从A达到B。假如你的市场中有99%的用户不须要把日记文件存成pdf文件，那么就不要构建一个提醒框讯问他们是否想把日记文件保留成pdf文件。假如你的用户想把.wav文件转换成MP3文件，那么他们已经不在乎丧失精度了，所以不必再提醒他们转换成无损紧缩的FLAC文件，那样只会干扰他们。

最后一种情形，就是软件庞杂得让其他法式员难以懂得。创立庞杂的代码让他人难以懂得曾经异常风行(还有过竞赛)。有时，代码写得庞杂，是为了让它比一般法式员所开辟的代码运行更快。而更多的情形是代码的庞杂度(就其懂得的难度而言)成了法式员才干的象征，或者说是工夫高下的象征。那些开辟的代码能让做代码检讨的高等开辟人员欲苦无泪的人反而颇受推重。庞杂度成了聪明的樊笼，编程极客们会在公司内部争强好胜。对于乐此不疲的人来说，这是很好的竞赛，但对于公司和股东来说，则要为一场无人关怀的樊笼年夜赛买单。对于那些仍然沉浸于这场极客盛宴的人，假如不想伤害好处相干者的好处，又想真刀真枪地拼一场，那建议你加入国际混杂C代码比赛。

我们都应当尽力去写让每小我都能懂得的代码。权衡一个巨大法式员的真正尺度，是他可以或许多快把一个庞杂的问题简化，多快能开辟出一个既轻易懂得，又轻易保护的解决计划。轻易履行的解决计划意味着一般法式员就可以快速地控制体系，为它供给支撑。轻易懂得的解决计划则意味着在查找问题时可以或许甲

方法把体系恢复到正常工作状况。轻易履行的解决计划可以进步公司息争决计划的可扩大性。

要测试体系是否太庞杂，一个很好的办法是让负责解决庞杂问题的法式员把他的解决计划陈说给公司内的一组法式员。这组法式员应当代表公司内分歧的编码程度，分歧的工作年限(参加这一条，是因为可能有些有经验的法式员在公司的工作经验不多)。要经由过程这一测试，须要这组法式员中的每一位都可以或许轻松懂得该解决计划，可以或许在无赞助的情形下向他人描写它，而不只是知道它。假如这组法式员中的任何一位不克不及懂得该解决计划，那么就要小组评论辩论该体系是不是过度庞杂了。

过度的网站设计是可扩大性的一个仇敌。开辟一个超越有效需求的解决计划，既糟蹋金钱又糟蹋时光。此外，还可能进一步步糟蹋处置资本，增长扩大成本，限制体系的整体扩大才能(即体系能被扩大到什么水平)。构建过度庞杂的解决计划会造成相似的效果。运行吃力的体系会增长成本，限制最终成长范围。让用户用起来吃力的体系，会放慢吸引客户的速度，从而限制营业增加的速度。太庞杂以至于难以懂得的体系，则会扼制司的临盆力，让你无从增长法式员，或者难以给体系增长功效。