概述
设计模式的理论部分已经学完了。我想你一定蠢蠢欲动，想要赶紧实践一下，把这些理论知识应用到自己的项目中。不过，要注意下面两点：
- 一种是过度设计。在开始编写代码之前，花很长的时间做代码设计，在开发过程中应用各种设计模式，希望代码更加灵活，为未来的扩展打好基础。这其实是过度设计，未来的需求并不一定会实现，变相地增加了代码的复杂度。
- 还有一种是设计不足。怎么简单怎么来，写出来的代码能跑就可以，顶多算式 demo，看似在实践 KISS、YAGNI 原则，实则忽略了设计环节，代码毫无扩展性、灵活性可言，添加、修改一个很小的功能就要改动很多代码。
所以，本章和你聊聊，在实际的项目开发中，如何避免过度设计，以及如何避免设计不足。
设计的初衷是提高代码质量
应用设计模式只是方法，最终的目的是 “初心”，是提高代码的质量。具体点说，提高代码的可读性、可扩展性、可维护性等。所有的设计都是围绕着这个初心来做的。
所以，在做代码设计的时候，你一定要先问下自己，为什么要这样设计，为什么要应用这种设计模式，这样做是否能真正地提高代码质量，能提高代码质量的哪些方面。如果自己很难讲清楚，或者给出的理由比较牵强，没有压倒性优势，那基本上就可以断定这是一种过度设计，是为了设计而设计。
实际上**，设计原则和思想是心法，设计模式只是招式**。掌握心法，以不变应万变，无招胜有招。所以，设计原则和设计思想更加普适、重要。掌握了设计原则和思想，我们能更加清楚的了解为什么要用这种设计模式，就能恰到好处的应用设计模式，甚至我们还可以自己创造出来新的设计模式。
设计的过程是先有问题后有方案
如果我们把写出的代码看作作品，那做产品时，我们先要思考痛点在哪里，用户的真正需求在哪里，然后再看要开发哪些功能去满足，而不是先拍脑袋相处一个花哨的功能，再去东搬西凑编出一个需求来。
代码设计也是类似。我们要先去分析代码存在的痛点，比如可读性不好、可扩展性不好等等，然后再针对性地利用设计模式去改善，而不是看到某个应用场景后，觉得跟之前在某本书中看到的某个设计模式的应用场景很相似，就套用上去，也不考虑是否合适，最后如果有人问起了，就再找几个不痛不痒、很不具体的伪需求来搪塞，比如提高了代码的可扩展性、满足了开闭原则。
实际上，很多没有太多开发经验的新手，往往在学完设计模式之后会非常 “学生气”，那原理当真理，不懂得具体问题具体分析，手里拿着锤子看哪都是钉子，不分青红皂白，上来就是套用某个设计模式。写完之后，看着自己写的很复杂的代码，还沾沾自喜，甚至到处炫耀。这完全是无知地炫技，半瓶子不满大抵就是这样子的。等你慢慢成长之后，回过头来在看自己当年写的代码，我相信你应该会感到脸红。这里主要是告诉你，要防止过度设计。
所以，在之前的文章中，一直都是从问题讲起，一步一步的给你剖析为什么要用设计模式，而不是一开始就告诉你最终的设计。实际上，最重要的是想培养你分析问题、解决问题的能力。这样，看到某段代码之后，你就能自己分析得头头是道，说出它好的地方、不好的地方，为什么好、为什么不好，不好的如何改善，可以应用哪种设计模式，应该之后有哪些副作用要控制等等。
相反，如果你只是掌握了理论知识，即便是把 23 种设计模式的原理和实现都背的滚瓜烂熟，不具备具体问题具体分析的能力，在面对真实项目的千变万化的代码时，很容易就会滥用设计模式，过度设计。
设计的应用场景是复杂代码
很多设计模式的教程都会举一些简单的例子，这些例子仅仅只有教学意义，只是为了奖设计模式的原理和实现，力求在有限的篇幅内给你讲明白。而很多人误以为这些简单的例子就是这些设计模式的经典应用场景，常常照葫芦画瓢地应用到自己的项目中，用复杂的设计模式去解决简单的问题，还振振有词地说某某书中就是这么写的。这是很多初学者因为缺乏经验，在学完设计模式之后，在项目中过度设计的首要原因。
前面我们讲到，设计模式要干的事情就是解耦，也就是利用更好的代码结构将一大堆代码拆分成职责更单一的小类，让其满足高内聚低耦合等特性。
- 创建型模式是将创建和使用解耦
- 结构型模式是将不同的功能代码解耦
- 行为型模式是将不同的行为代码解耦
而解耦的主要模式是应对代码的复杂性，设计模式就是为了解决复杂代码问题而产生的。
因此，对于复杂代码，比如项目代码量多、开发周期长、参与开发人员多，我们前期要多花时间在设计上，越是复杂代码，花在设计上的时间就要越多。
不仅如此，每次提交的代码，都要保证代码质量，都要经过足够的思考和精心的设计，这样才能避免烂代码效应（每次提交的代码质量都不是太好，最终积累起来整个项目的质量就变得很差）。
相反，如果你参与的只是一个简单的项目，代码量不多，开发人员也不多，那简单的问题用简单的解决方案就好，不要引入过于负责的设计模式，将简单问题复杂化。
持续重构能有效避免过度设计
我们知道，应用设计模式会提高代码的可扩展性，但同时也会带来代码的可读性的降低，复杂度的升高。一旦我们引入某个复杂的设计，之后即便在很长一段时间都没有扩展的需求，我们也不可能将这个复杂的设计删除，整个团队都要一直背负着这个复杂的设计前行。
为了避免错误的需求预判导致的过度设计，我非常推崇持续重构的开发方法。持续重构不仅仅是保证代码质量的重要手段，也是避免过度设计的有效方法。在真正有痛点的时候，我们再去考虑用设计模式来解决，而不是一开始就为不一定实现的未来需求而应用设计模式。
当对要不要应用某种设计模式感到模棱两可的时候，你可以思考下，如果暂时不用这种设计模式，随着代码的演进，当某一天不得不去使用它时，重构的代码是否很大。如果不是，那能不用就不用，怎么简单怎么来。说句实话，对于 10 万行以内的代码，团队成员稳定，对代码涉及的业务比较熟悉的情况下，即便所有的代码都推到重写，也不会花太多的时间，因此也不必为代码的扩展性太多担忧。
避免设计不足的 3 个必要条件
前面讲的都是如何避免过度设计，下面再稍微讲讲如何避免设计不足。
首先，你要有一定的理论知识储备。
比如你熟练掌握各种设计原则、思想、编码规范、设计模式。理论知识是解决问题的工具，时前任只会的结晶。没有理论知识，就相当于游戏中没有厉害的装备，虽然可以靠身手徒手打怪，但肯定会影响你最高水平的发挥。
其次，你还要有一定的刻意训练。
很多同学很苦恼，说理论知识都学过，但是很容易忘记，遇到问题也想不到对应的知识点。实际上，就是缺乏理论结合实际的刻意训练。没有经过刻意训练，知识积累不了，能力也锻炼不了，等于白学。
最后，你一定要有代码质量意识、设计意识。
在写代码之前，要多想想未来会有哪些扩展的需求，哪部分是会变的，哪部分是不会变的，这样写会不会导致之后添加新的功能比较困难，代码的可读性好不好等代码质量问题。有了这样的意识，你就里写出高质量的代码不远了。
不脱离具体场景去谈设计
设计是一个非常主观的事情，不夸张地讲，可以称之为一门 “艺术”。相应的，好坏就很难评判了。如果真的要评判，我们就要放到具体的场景中。脱离具体的场景去谈论设计是否合理，都是空谈。
比如，一个手游项目能否被市场接收，往往非常不确定。很多手游项目开发出来之后，市场反馈很差，立马就放弃了。此外，尽快上市占领市场也是一款手游致胜的关键。所以，对于手游项目的开发来说，往往前期不会花太多的时间在代码设计、代码质量上。
相反，如果你开发的是大型端游，一般都要投资上亿资金，几百号人开发好几年，推倒重来的成本很大。这个时候，代码质量就非常关键了。前期就要多花点时间在设计上，否则，代码质量太差，bug 太多，后期无法维护，也会导致很多用户弃用而选择同类型的其他家的游戏。
再比如，开发的是偏底层、框架类、通用的代码，那代码质量就比较重要，因为一旦出现问题或者代码改动，影响面就比较大。相反，如果我们开发的是业务系统或者不需要长期维护的项目，那稍微放低点代码质量的要求，也是没有问题的，而且，自己的代码跟其他项目没有太多耦合，即便出了问题，影响也不大。
