为什么要学习设计模式?
1. 应对面试中的设计模式相关问题
在求职面试中,设计模式问题是被问得频率比较高的一类问题。特别是一些像 BAT、TMD 这样的大公司,比较重视候选人的基本功,经常会拿算法、设计模式之类的问题来考察候选人。
平时重视设计模式相关知识的积累,只需要在每次面试前花很短的时间,重新温习一下,便可以自信满满地去面试,而不是心里老是担心被问到,影响正常的面试发挥。
2. 告别写被人吐槽的烂代码
代码能力是一个程序员最基础的能力,是基本功,是展示一个程序员基础素养的最直接的衡量标准。你写的代码,实际上就是你名片。
烂代码,比如命名不规范、类设计不合理、分层不清晰、没有模块化概念、代码结构混乱、高度耦合
等等。这样的代码维护起来非常费劲,添加或者修改一个功能,常常会牵一发而动全身,让你无从下手,恨不得将全部的代码删掉重写!
3. 提高复杂代码的设计和开发能力
大部分工程师比较熟悉的都是编程语言、工具、框架这些东西,因为每天的工作就是在框架里根据业务需求,填充代码。实际上,我刚工作的时候,也是做这类事情。相对来说,这样的工作并不需要你具备很强的代码设计能力,只要单纯地能理解业务,翻译成代码就可以了。
但是,有一天,我的 leader 让我开发一个跟业务无关的比较通用的功能模块,面对这样稍微复杂的代码设计和开发,我就发现我有点力不从心,不知从何下手了。因为我知道只是完成功能、代码能用,可能并不复杂,但是要想写出易扩展、易用、易维护的代码,并不容易。
如何分层、分模块?应该怎么划分类?每个类应该具有哪些属性、方法?怎么设计类之间的交互?该用继承还是组合?该使用接口还是抽象类?怎样做到解耦、高内聚低耦合?该用单例模式还是静态方法?用工厂模式创建对象还是直接 new 出来?如何避免引入设计模式提高扩展性的同时带来的降低可读性问题?……各种问题,一下子挤到了我面前。
而我当时并没有对设计模式相关的知识(包括设计模式、设计原则、面向对象设计思想等)有太多的了解和积累,所以一时间搞得我手足无措。好在因此我意识到了这方面知识的重要性,所以在之后很多年的开发中,我都一直刻意锻炼、积累这方面的能力。面对复杂代码、功能、系统的设计和开发,我也越来越得心应手,游刃有余。写出高质量代码已经成为了我的习惯,不经意间写出来的代码,都能作为同事学习、临摹的范例,这也成为了我职场中最引以为豪的亮点之一。
4. 让读源码、学框架事半功倍
对于一个有追求的程序员来说,对技术的积累,既要有广度,也要有深度。很多技术人早早就意识到了这一点,所以在学习框架、中间件的时候,都会抽空去研究研究原理,读一读源码,希望能在深度上有所积累,而不只是略知皮毛,会用而已。从我的经验和同事的反馈来看,有些人看源码的时候,经常会遇到看不懂、看不下去的问题。不知道你有没有遇到过这种情况?实际上,这个问题的原因很简单,那就是你积累的基本功还不够,你的能力还不足以看懂这些代码。为什么我会这么说呢?
优秀的开源项目、框架、中间件,代码量、类的个数都会比较多,类结构、类之间的关系极其复杂,常常调用来调用去。所以,为了保证代码的扩展性、灵活性、可维护性等,代码中会使用到很多设计模式、设计原则或者设计思想
。如果你不懂这些设计模式、原则、思想,在看代码的时候,你可能就会琢磨不透作者的设计思路,对于一些很明显的设计思路,你可能要花费很多时间才能参悟。相反,如果你对设计模式、原则、思想非常了解,一眼就能参透作者的设计思路、设计初衷,很快就可以把脑容量释放出来,重点思考其他问题,代码读起来就会变得轻松了。
实际上,除了看不懂、看不下去的问题,还有一个隐藏的问题,你可能自己都发现不了,那就是你自己觉得看懂了,实际上,里面的精髓你并没有 get 到多少!因为优秀的开源项目、框架、中间件,就像一个集各种高精尖技术在一起的战斗机。如果你想剖析它的原理、学习它的技术,而你没有积累深厚的基本功,就算把这台战斗机摆在你面前,你也不能完全参透它的精髓,只是了解个皮毛,看个热闹而已。因此,学好设计模式相关的知识,不仅能让你更轻松地读懂开源项目,还能更深入地参透里面的技术精髓,做到事半功倍。
5. 为你的职场发展做铺垫
普通的、低级别的开发工程师,只需要把框架、开发工具、编程语言用熟练,再做几个项目练练手,基本上就能应付平时的开发工作了。但是,如果你不想一辈子做一个低级的码农,想成长为技术专家、大牛、技术 leader,希望在职场有更高的成就、更好的发展,那就要重视基本功的训练、基础知识的积累。
你去看大牛写的代码,或者优秀的开源项目,代码写得都非常的优美,质量都很高。如果你只是框架用得很溜,架构聊得头头是道,但写出来的代码很烂,让人一眼就能看出很多不合理的、可以改进的地方,那你永远都成不了别人心目中的“技术大牛”。
再者,在技术这条职场道路上,当成长到一定阶段之后,你势必要承担一些指导培养初级员工、新人,以及 code review 的工作。这个时候,如果你自己都对“什么是好的代码?如何写出好的代码?”不了解,那又该如何指导别人,如何让人家信服呢?
还有,如果你是一个技术 leader,负责一个项目整体的开发工作,你就需要为开发进度、开发效率和项目质量负责。你也不希望团队堆砌垃圾代码,让整个项目无法维护,添加、修改一个功能都要费老大劲,最终拉低整个团队的开发效率吧?
除此之外,代码质量低还会导致线上 bug 频发,排查困难。整个团队都陷在成天修改无意义的低级 bug、在烂代码中添补丁的事情中。而一个设计良好、易维护的系统,可以解放我们的时间,让我们做些更加有意义、更能提高自己和团队能力的事情。
最后,当你成为 leader、或者团队中的资深工程师、技术专家之后,你势必要负责一部分团队的招聘工作。这个时候,如果你要考察候选人的设计能力、代码能力
,那设计模式相关的问题便是一个很好的考察点。
不过,我也了解到,很多面试官实际上对设计模式也并不是很了解,只能拿一些简单的单例模式、工厂模式来考察候选人,而且所出的题目往往都脱离实践,比如,如何设计一个餐厅系统、停车场系统、售票系统等。这些题目都是网上万年不变的老题目,几乎考察不出候选人的能力。在我的专栏中,有 200 多个真实项目开发中的设计模式相关问题,你跟着看下来,足以让你成为设计模式方面的大牛,再来面试候选人的时候,就不用因为题目老套、脱离实践而尴尬了!
目标:写出高质量代码,提高复杂代码的设计和开发能力
数据结构和算法是教你如何写出高效代码,那设计模式讲的是如何写出可扩展、可读、可维护的高质量代码,所以,它们跟平时的编码会有直接的关系,也会直接影响到你的开发能力
写出“能用”代码的人比比皆是,但是,并不是每个人都能写出“好用”的代码。只会写能用的代码,我们永远成长不成大牛,成长不成最优秀的那批人。
设计模式能更直接地提高开发能力。把写高质量代码培养成一种开发习惯,形成一种代码质量意识,把设计原则和设计模式在项目中锻炼运用。
需要用到设计模式的一般是复杂的业务需求;
- 优秀的开源项目、框架、中间件,代码量、类的个数都会比较多,类结构、类之间的关系极其复杂,为了保证代码的扩展性、灵活性、可维护性等,代码中会使用到很多设计模式、设计原则或者设计思想。
- 指导培养初级员工、新人,以及 code review 的工作;如果你是一个技术 leader,负责一个项目整体的开发工作,你就需要为开发进度、开发效率和项目质量负责。你也不希望团队堆砌垃圾代码,让整个项目无法维护;代码质量低还会导致线上 bug 频发,排查困难。;考察候选人的设计能力、代码能力,那设计模式相关的问题便是一个很好的考察点。
步骤:
为什么要有这种设计原则、思想或者模式?它能解决什么编程问题?有哪些应用场景?又该如何权衡、恰当地在项目中应用?
- 总结本质的定义,解决了什么问题?
- 在具体的需求一步步演进过程中,每次演进分析代码缺陷在哪里,如何通过设计原则、思想、模式来优化?(如何进行需求分析、如何落地编码的具体方法论)