这篇文章告诉你为什么要学好设计模式

1. 设计模式究竟是啥？

相信很多程序员都知道有设计模式这么个概念，也知道很重要，但至于什么这么重要就比较模糊了。没错，其实在很多场景开发中，开发者只需要掌握最基本的框架使用，根据不同的业务逻辑去做CRUD开发就行了。软件也能跑起来，看起来也不错，对吧。但如果你的代码并没有采用合理的设计模式，当我们要改动需求或者增加新的功能或者业务系统过于庞大后，你会发现代码真的乱成了一锅粥，你自己都想赶快甩锅走人了。这时候你问一些大佬，他们通常会告诉你两个字：重构。而重构的核心意义就是改善既有代码的设计，说白了就是应对程序开发中的变动的。说白了，设计模式用得好，你就可以很轻松自如的应对各种变动，反之则越改越痛苦。设计模式是设计代码结构的一种指导，但对于没一些编码经验的人来说看起来的确有点抽象难懂。没错，学设计模式之前的确需要一些编程实践，当有了这些编程实践后在看起来就会有种豁然开朗的感觉。

2. 学好设计模式的意义

其实学好设计模式最直接的意义就是你可以写出很有层次结构高质量代码，避免了在团队开发中被打。此外，无论你打算做什么工程师，无论是前端后端还是客户端面试都会问道设计模式相关的问题，这就足以证明了它的价值与意义。所以如果你不平时不把这块内容给夯实了打好基础很容易在面试的时候漏出马脚。
不知道你有没有阅读源代码的习惯，无论是语言的源代码还是常用框架的源代码，其实内部都蕴含了大量的设计模式，如果你没有相应的知识可能连源代码都看不懂。因为像这些框架基本是中间件，为了满足各种复杂场景的通用性都做到了高内聚低耦合，没有相应的知识很容易出现云里雾里的自己把自己都绕晕了。
我们经常说，“Talk is cheap，show me the code。”实际上，代码能力是一个程序员最基础的能力，是基本功，是展示一个程序员基础素养的最直接的衡量标准。你写的代码，实际上就是你名片。随着日积月累的经验，成为技术大牛，升职加薪还不是早晚的事。

3. 如何评价代码质量的高低?

实际上，我们很难通过其中的某个或者某几个词汇来全面地评价代码质量。因为这些词汇都 是从不同维度来说的。这就好比，对于一个人的评价，我们需要综合各个方面来给出，比如 性格、相貌、能力、财富等等。代码质量高低也是一个综合各种因素得到的结论。我们并不 能通过单一的维度去评价一段代码写的好坏。比如，即使一段代码的可扩展性很好，但可读 性很差，那我们也不能说这段代码质量高。
除此之外，不同的评价维度也并不是完全独立的，有些是具有包含关系、重叠关系或者可以 互相影响的。比如，代码的可读性好、可扩展性好，就意味着代码的可维护性好。而且，各 种评价维度也不是非黑即白的。比如，我们不能简单地将代码分为可读与不可读。如果用数 字来量化代码的可读性的话，它应该是一个连续的区间值，而非 0、1 这样的离散值。
不过，我们真的可以客观地量化一段代码质量的高低吗?答案是否定的。对一段代码的质量 评价，常常有很强的主观性。比如，怎么样的代码才算可读性好，每个人的评判标准都不大 一样。这就好比我们去评价一本小说写得是否精彩，本身就是一个很难量化的、非常主观的 事情。
正是因为代码质量评价的主观性，使得这种主观评价的准确度，跟工程师自身经验有极大的 关系。越是有经验的工程师，给出的评价也就越准确。相反，资历比较浅的工程师就常常会 觉得，没有一个可执行的客观的评价标准作为参考，很难准确地判断一段代码写得好与坏。 有的时候，自己觉得代码写得已经够好了，但实际上并不是。所以，这也导致如果没有人指 导的话，自己一个人闷头写代码，即便写再多的代码，代码能力也可能一直没有太大提高。
仔细看前面罗列的所有代码质量评价标准，你会发现，有些词语过于笼统、抽象，比较偏向 对于整体的描述，比如优雅、好、坏、整洁、清晰等;有些过于细节、偏重方法论，比如模 块化、高内聚低耦合、文档详尽、分层清晰等;有些可能并不仅仅局限于编码，跟架构设计 等也有关系，比如可伸缩性、可用性、稳定性等。其中几个最常用的、最重要的评价标准，来详 细讲解，其中就包括:可维护性、可读性、可扩展性、灵活性、简洁性(简单、复杂)、可 复用性、可测试性。实际上，思从深而行从简，真正的 高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本 质区别之一。

4. 面向对象、设计原则、设计模式、编程规范、重构，这五者有何关系？

简单来说：面向对象是武器，设计模式是招式，设计原则是心法，以心法为基础，以武器运用招式应对复杂的编程问题。总体来说就是为了编写高质量代码而服务的，如下图所示。

好了，相信你看到这里已经明白为什么要学号设计模式了，后续我也会写一些关于设计模式有关的博文，喜欢的敬请关注。

关于我

颜值与BUG并存的程序员👨‍💻‍
请关注👀、点赞👍、评论👯‍♀️
微信公众号：Peachou