不要过分设计你的网站

目的:防止设计中泛起庞大的解决计划。
合用情景:合用于任何项目，一切大型的或庞大的零碎和项目都应该采用该准则。
应用体式格局:让同偕行来检查解决计划是否好理解，抵制过分设计的猛烈愿望。
应用理由:庞大的解决计划施行本钱高，并且会发生大量恒久本钱。要点:过分庞大的零碎会限定扩展威力。简略的零碎更易维护和扩展，且本钱更低。
维基百科注释说，过分设计分为两大类。一类是指设计与实现超越了有效需求的商品。出于完整性的思索，咱们只简略地接头一下这个问题。相对于付只知其一，不知其二类问题来讲，这类问题对可扩展性的影响较小。过分设计的另外一类问题指过于庞大的商品。如前所述，咱们最关怀的是只知其一，不知其二类问题对可扩展性的影响。不外，仍是先来理解一下第一个问题吧。

要注释过分设计的第一类问题，即超越商品有效需求的问题，就要先搞分明楚“有效的”这个术语的寄义，这个术语在这里暗示的只是“能够伸用”。比方。为家庭住房设计一种空调，能够在室外温度为0开时把整个屋子的温度加热到300华氏度，这毫无心义，纯属挥霍，咱们只需求一个能够在室外温度为-20华氏度时把屋子加热到温馨温度的商品。这类过分设计会发生过分的本钱，此中开发的本钱会更高，施行该计划的硬件和软件本钱也会更高。若是研发这类过分设计零碎的时间比研发有效零碎的时间更长，还能够迁延商品的发布，对公司形成进一步的影响。本钱高，利润就低。研发时间长，收入或收益就会被延迟，一切这些本钱城市影响到利益相干者。范畴伸张，或者最初的商品界说和最初的商品发布之间的范畴差距，是过分设计的一种浮现。
说个更濒临咱们事情的例子，是开发一个员工打卡零碎，这个零碎能够处置的员工数目是整个地球上人数的100倍。在这个软件的运用限期内，地球上的人口升至100倍的能够性是微不足道的，而一切人都为一家公司事情的能够性则更小。咱们当然想让构建的零碎知足客户需求但也不想挥霍时间来实现和部署远远超越需求的零碎。
过分设计的只知其一，不知其二类浮现是使零碎过分庞大，或者用庞大的体式格局来实现它。简而言之，就是要破费过大的力量去完成一项事情，或者是让用户破费过大的力量去完成一项任务，或者是让程序员破费过大的力量去理解一个功用。让咱们来逐一阐明过分庞大的零碎的这三种情况。
甚么是破费过大的力量去完成一项事情呢?现实世界有最简略的例子。假如你让或人去杂货店买东西，你通知他，店内里的一切商品都拿一个，列队结账时给你打电话。等他打电话给你时，你再通知他到底想要哪多少，让他从所拿的有数篮商品当选出来，而后把其余商品都倒在地上。你必然会说:“别开打趣了。”但是，你在本身的代码顶用过select(大)schema_nane.tab1e_name如许的sql语句，只是为了从返回的汇合中找出本身想要的结果吗?咱们这个杂货店的例子，和上述的se1ect(*)恰是异曲同工。在你的代码中，有多少前提语句是处置个别情况的，它们是根据甚么递次执行的?是否是最能够发生的情况最早执行?你是否是常常刚查询完一个结果，又反复查询一次?是否是常常刚显示了hml面，这类情况随处可见，却又常常被无视。
甚么是让一名用户破费过大的力量去完成一项任务呢?谜底十分简略。在许多情况下，少就是多。为谋求零碎的灵活性，咱们老是想给它硬加之尽能够多的新鲜功用。但糊口的情味其实不总在于多种多样。许多时辰，用户只是想无烦扰地尽能够快地从a达到b。若是你的市场中有99%的用户不需求把日记文件存成pdf文件，那末就不要构建一个提示框扣问他们是否想把日记文件保留成pdf文件。若是你的用户想把.wav文件转换成mp3文件，那末他们已经不在意损失精度了，以是没必要再提示他们转换成无损压缩的flac文件，那样只会烦扰他们。
末了一种情况，就是软件庞大得让其余程序员难以理解。创立庞大的代码让别人难以理解已经十分风行(另有过角逐)。有时，代码写得庞大，是为了让它比普通程序员所开发的代码运转更快。而更多的情况是代码的庞大度(就其理解的难度而言)成为了程序员才调的意味，或者说是功夫上下的意味。那些开发的代码能让做代码检查的高档开发职员欲苦无泪的人反而颇受推许。庞大度成为了聪明的樊笼，编程极客们会在公司内部争强好胜。对付乐此不疲的人来讲，这是很好的角逐，但对付公司和股东来讲，则要为一场无人关怀的樊笼大赛买单。对付那些依然沉醉于这场极客盛宴的人，若是不想损害利益相干者的利益，又想真刀真枪地拼一场，那倡议你参与国际混合c代码竞赛。
咱们都应该勤奋去写让每一个人都能理解的代码。掂量一个巨大程序员的真正标准，是他能够多快把一个庞大的问题简化，多快能开发出一个既容易理解，又容易维护的解决计划。容易执行的解决计划意味着普通程序员就能够疾速地把握零碎，为它提供支持。容易理解的解决计划则意味着在查找问题时能够甲
体式格局把零碎恢复到正常事景况态。容易执行的解决计划可以普及公司息争决计划的可扩展性。
要测试零碎是否太庞大，一个很好的要领是让卖力解决庞大问题的程序员把他的解决计划报告给公司内的一组程序员。这组程序员应该代表公司内差别的编码水平，差别的事情年限(插手这一条，是由于能够有些有教训的程序员在公司的事情教训未几)。要经由过程这一测试，需求这组程序员中的每回位都能够轻松理解该解决计划，能够在无协助的情况下向别人形容它，而不仅是知道它。若是这组程序员中的任何一名不克不及理解该解决计划，那末就要小组接头该零碎是否是过分庞大了。
过分的网页设计是可扩展性的一个敌人。开发一个超越有效需求的解决计划，既挥霍款项又挥霍时间。别的，还能够进一步步挥霍处置，添加扩展本钱，限定零碎的总体扩展威力(即零碎能被扩展到甚么水平)。构建过分庞大的解决计划会形成雷同的结果。运转费劲的零碎会添加本钱，限定终极发展规模。让用户用起来费劲的零碎，会放慢吸引客户的速率，从而限定营业增进的速率。太庞大甚至于难以理解的零碎，则会扼制司的出产力，让你无从添加程序员，或者难以给零碎添加功用。