洋蔥

贪婪,找不到比这更好的词了,是件好事。

软件开发的难度无外乎两点,一是技术难,意思是说,代码量不一定多,但要解决的问题比较难,需要用到一些比较深的技术解决方案或者算法,不是靠“堆人”就能搞定的,比如自动驾驶、图像识别、高性能消息队列等;二是复杂度,意思是说,技术不难,但项目很庞大,业务复杂,代码量多,参与开发的人多,比如物流系统、财务系统等。第一点涉及细分专业的领域知识,跟我们专栏要讲的设计、编码无关,所以我们重点来讲第二点,如何应对软件开发的复杂度。

简单的“hello world”程序,谁都能写得出来。几千行的代码谁都能维护得了。但是,当代码超过几万行、十几万,甚至几十万行、上百万行的时候,软件的复杂度就会呈指数级增长。这种情况下,我们不仅仅要求程序运行得了,运行得正确,还要求代码看得懂、维护得了。实际上,复杂度不仅仅体现在代码本身,还体现在协作研发上,如何管理庞大的团队,来进行有条不紊地协作开发,也是一个很复杂的难题。

如何应对复杂软件开发?Unix开源项目就是一个值得学习的例子。

Unix从1969年诞生,一直演进至今,代码量有几百万行,如此庞大的项目开发,能够如此完美的协作开发,并且长期维护,保持足够的代码质量,这里面有很多成功的经验可以借鉴。所以,接下来,我们就以Unix开源项目的开发为引子,分三节课的时间,通过下面三个话题,详细地讲讲应对复杂软件开发的方法论。希望这些经验能为你所用,在今后面对复杂项目开发的时候,能让你有条不紊、有章可循地从容应对。

  • 从设计原则和思想的角度来看,如何应对庞大而复杂的项目开发?
  • 从研发管理和开发技巧的角度来看,如何应对庞大而复杂的项目开发?
  • 聚焦在Code Review上来看,如何通过Code Reviwe保持项目的代码质量?

话不多说,让我们正式开始今天的学习吧!

阅读全文 »

上一节课,我们讲解了工厂模式、建造者模式、装饰器模式、适配器模式在Java JDK中的应用,其中,Calendar类用到了工厂模式和建造者模式,Collections类用到了装饰器模式、适配器模式。学习的重点是让你了解,在真实的项目中模式的实现和应用更加灵活、多变,会根据具体的场景做实现或者设计上的调整。

今天,我们继续延续这个话题,再重点讲一下模板模式、观察者模式这两个模式在JDK中的应用。除此之外,我还会对在理论部分已经讲过的一些模式在JDK中的应用做一个汇总,带你一块回忆复习一下。

话不多说,让我们正式开始今天的学习吧!

阅读全文 »

从今天开始,我们就正式地进入到实战环节。实战环节包括两部分,一部分是开源项目实战,另一部分是项目实战。

在开源项目实战部分,我会带你剖析几个经典的开源项目中用到的设计原则、思想和模式,这其中就包括对Java JDK、Unix、Google Guava、Spring、MyBatis这样五个开源项目的分析。在项目实战部分,我们精心挑选了几个实战项目,手把手地带你利用之前学过的设计原则、思想、模式,来对它们进行分析、设计和代码实现,这其中就包括鉴权限流、幂等重试、灰度发布这样三个项目。

接下来的两节课,我们重点剖析Java JDK中用到的几种常见的设计模式。学习的目的是让你体会,在真实的项目开发中,要学会活学活用,切不可过于死板,生搬硬套设计模式的设计与实现。除此之外,针对每个模式,我们不可能像前面学习理论知识那样,分析得细致入微,很多都是点到为止。在已经具备之前理论知识的前提下,我想你可以跟着我的指引自己去研究,有哪里不懂的话,也可以再回过头去看下之前的理论讲解。

话不多说,让我们正式开始今天的学习吧!

阅读全文 »

设计模式的理论部分已经全部学习完了。现在,你可能已经蠢蠢欲动,想要赶紧实践一把,把这些理论应用到自己的项目中。不过,这里我要给你提个醒了,千万别手里拿着锤子就看什么都是钉子啊。

在我过往的项目经历中,经常遇到两种同事。

一种同事会过度设计。在开始编写代码之前,他会花很长时间做代码设计,在开发过程中应用各种设计模式,美其名曰未雨绸缪,希望代码更加灵活,为未来的扩展打好基础,实则过度设计,未来的需求并不一定会实现,实际上是增加了代码的复杂度,以后的所有开发都要在这套复杂的设计基础之上来完成。

除此之外,还有一种是设计不足。怎么简单怎么来,写出来的代码能跑就可以,顶多算是demo,看似在实践KISS、YAGNI原则,实则忽略了设计环节,代码毫无扩展性、灵活性可言,添加、修改一个很小的功能就要改动很多代码。

所以,今天我想和你聊一下,在实际的项目开发中,如何避免过度设计,以及如何避免设计不足。话不多说,让我们正式开始今天的内容吧!

阅读全文 »

到今天为止,23种经典的设计模式已经全部讲完了。咱们整个专栏也完成了3/4,马上就要进入实战环节了。在进入新模块的学习之前,我照例带你做一下总结回顾。23种经典设计模式共分为3种类型,分别是创建型、结构型和行为型。今天,我们把这3种类型分成3个对应的小模块,逐一带你回顾一下每一种设计模式的原理、实现、设计意图和应用场景。

和之前的总结文一样,今天的内容比较多,有近万字,但都是咱们之前学过的,看起来应该不会太费劲,但却能检验你是否真的掌握了这些内容。

还是那句话,如果你看了之后,感觉都有印象,那就说明学得还不错;如果还能在脑子里形成自己的知识架构,闭上眼睛都能回忆上来,那说明你学得很好;如果能有自己的理解,并且在项目开发中,开始思考代码质量问题,开始用已经学过的设计模式来解决代码问题,那说明你已经掌握这些内容的精髓。

阅读全文 »

今天,我们来学习23种经典设计模式中的最后一个,中介模式。跟前面刚刚讲过的命令模式、解释器模式类似,中介模式也属于不怎么常用的模式,应用场景比较特殊、有限,但是,跟它俩不同的是,中介模式理解起来并不难,代码实现也非常简单,学习难度要小很多。

如果你对中介模式有所了解,你可能会知道,中介模式跟之前讲过的观察者模式有点相似,所以,今天我们还会详细讨论下这两种模式的区别。

话不多说,让我们正式开始今天的学习吧!

阅读全文 »

上一节课,我们学习了命令模式。命令模式将请求封装成对象,方便作为函数参数传递和赋值给变量。它主要的应用场景是给命令的执行附加功能,换句话说,就是控制命令的执行,比如,排队、异步、延迟执行命令、给命令执行记录日志、撤销重做命令等等。总体上来讲,命令模式的应用范围并不广。

今天,我们来学习解释器模式,它用来描述如何构建一个简单的“语言”解释器。比起命令模式,解释器模式更加小众,只在一些特定的领域会被用到,比如编译器、规则引擎、正则表达式。所以,解释器模式也不是我们学习的重点,你稍微了解一下就可以了。

话不多说,让我们正式开始今天的学习吧!

阅读全文 »

设计模式模块已经接近尾声了,现在我们只剩下3个模式还没有学习,它们分别是:命令模式、解释器模式、中介模式。这3个模式使用频率低、理解难度大,只在非常特定的应用场景下才会用到,所以,不是我们学习的重点,你只需要稍微了解,见了能认识就可以了。

今天呢,我们来学习其中的命令模式。在学习这个模式的过程中,你可能会遇到的最大的疑惑是,感觉命令模式没啥用,是一种过度设计,有更加简单的设计思路可以替代。所以,我今天讲解的重点是这个模式的设计意图,带你搞清楚到底什么情况下才真正需要使用它。

话不多说,让我们正式开始今天的学习吧!

阅读全文 »

上两节课,我们学习了访问者模式。在23种设计模式中,访问者模式的原理和实现可以说是最难理解的了,特别是它的代码实现。其中,用Single Dispatch来模拟Double Dispatch的实现思路尤其不好理解。不知道你有没有将它拿下呢?如果还没有弄得很清楚,那就要多看几遍、多自己动脑经琢磨一下。

今天,我们学习另外一种行为型模式,备忘录模式。这个模式理解、掌握起来不难,代码实现比较灵活,应用场景也比较明确和有限,主要是用来防丢失、撤销、恢复等。所以,相对于上两节课,今天的内容学起来相对会比较轻松些。

话不多说,让我们正式开始今天的学习吧!

阅读全文 »

上一节课中,我们学习了访问者模式的原理和实现,并且还原了访问者模式诞生的思维过程。总体上来讲,这个模式的代码实现比较难,所以应用场景并不多。从应用开发的角度来说,它的确不是我们学习的重点。

不过,我们前面反复说过,学习我的专栏,并不只是让你掌握知识,更重要的是锻炼你分析、解决问题的能力,锻炼你的逻辑思维能力,所以,今天我们继续把访问者模式作为引子,一块讨论一下这样两个问题,希望能激发你的深度思考:

  • 为什么支持双分派的语言不需要访问者模式呢?
  • 除了访问者模式,上一节课中的例子还有其他实现方案吗?

话不多说,让我们正式开始今天的学习吧!

阅读全文 »
0%