「笔记」设计模式之美 - 导读篇

为什么要学习设计模式

  • 应对面试中的设计模式相关问题
  • 告别写被人吐槽的烂代码
    • Talk is cheap,show me the code ;代码能力是一个程序员最基础的能力,是基本功
      • 是展示一个程序员基础素养的最直接的衡量标准,你写的代码,实际上就是你名片
    • 烂代码的情况,比如命名不规范、类设计不合理、分层不清晰、没有模块化概念、代码结构混乱、高度耦合等等
      • 维护起来非常费劲,添加或者修改一个功能,常常会牵一发而动全身
  • 提高复杂代码的设计和开发能力
  • 让读源码、学框架事半功倍
    • 有些人看源码的时候,经常会遇到看不懂、看不下去的问题,是因为积累的基本功还不够
    • 优秀开源代码为了保证代码的扩展性、灵活性、可维护性等,会使用到很多设计模式、设计原则或者设计思想
    • 如果你对设计模式、原则、思想非常了解,一眼就能参透作者的设计思路、设计初衷,就可以把脑容量释放出来
    • 没有积累深厚的基本功,就算把这台战斗机摆在你面前,你也不能完全参透它的精髓,只是了解个皮毛而已
  • 为你的职场发展做铺垫
    • 希望在职场有更高的成就、更好的发展,那就要重视基本功的训练、基础知识的积累
    • 当成长到一定阶段之后,你势必要承担一些指导培养初级员工、新人,以及 code review 的工作
      • 如果你自己都对“什么是好的代码?如何写出好的代码?”不了解,那又该如何指导别人,如何让人家信服呢
    • 如果你是一个技术 leader,负责一个项目整体的开发工作时,就需要为开发进度、开发效率和项目质量负责
      • 不希望团队堆砌垃圾代码,让整个项目无法维护,添加修改功能时特别费劲,影响开发效率
      • 代码质量低还会导致线上 bug 频发,排查困难(导致团队都都陷入成天修改无意义的低级 bug 中
    • 当负责招聘时,如果你要考察候选人的设计能力、代码能力,那设计模式相关的问题便是一个很好的考察点

如何评判代码质量的好坏

  • 代码质量评价的主观性,使得这种主观评价的准确度,跟工程师自身经验有极大的关系
  • 如何评价代码质量的高低
    • 代码质量的评价有很强的主观性,描述代码质量的词汇也有很多,比如可读性、可维护性、灵活、优雅、简洁等
      • 这些词汇是从不同的维度去评价代码质量的
      • 它们之间有互相作用,并不是独立的,比如,代码的可读性好、可扩展性好就意味着代码的可维护性好
    • 代码质量高低是一个综合各种因素得到的结论。我们并不能通过单一的维度去评价一段代码的好坏
  • 最常用的评价标准
    • 可维护性(maintainability)
      • 维护:无外乎就是修改 bug、修改老的代码、添加新的代码之类的工作
      • 代码易维护:在不破坏原有代码设计、不引入新的 bug 的情况下,能够快速地修改或者添加代码
        • 代码的可读性好、简洁、可扩展性好,就会使得代码易维护
        • 代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则等等也使得易维护
        • 项目代码量、业务的复杂程度、利用到的技术的复杂程度、文档是否全面、团队成员水平等有关
      • 代码不易维护:修改或者添加代码需要冒着极大的引入新 bug 的风险,并且需要花费很长的时间才能完成
    • 可读性(readability)
      • 代码的可读性应该是评价代码质量最重要的指标之一
        • 代码被阅读的次数远远超过被编写和执行的次数
        • 代码的可读性在非常大程度上会影响代码的可维护性
      • 如何评价一段代码的可读性
        • 是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模块划分是否清晰、是否符合高内聚低耦合等等
      • code review 是一个很好的测验代码可读性的手段
        • 如果你的同事可以轻松地读懂你写的代码,那说明你的代码可读性很好
    • 可扩展性(extensibility)
      • 可扩展性也是一个评价代码质量非常重要的标准,它表示我们的代码应对未来需求变化的能力
      • 跟可读性一样,代码是否易扩展也很大程度上决定代码是否易维护
      • 可扩展性:在不修改或少量修改原有代码的情况下,通过扩展的方式添加新的功能代码
        • 说直白点就是,代码预留了一些功能扩展点
    • 灵活性(flexibility)
      • 灵活性是一个挺抽象的评价标准,要给灵活性下个定义也是挺难的
      • 如果一段代码易扩展、易复用或者易用,我们都可以称这段代码写得比较灵活
    • 简洁性(simplicity)
      • 尽量保持代码简单。代码简单、逻辑清晰,也就意味着易读、易维护
      • 思从深而行从简,真正的高手能云淡风轻地用最简单的方法解决最复杂的问题
    • 可复用性(reusability)
      • 代码的可复用性可以简单地理解为,尽量减少重复代码的编写,复用已有的代码
        • 在讲到面向对象特性的时候,继承、多态存在的目的之一,就是为了提高代码的可复用性
        • 当讲到设计原则的时候,我们会讲到单一职责原则也跟代码的可复用性相关
        • 当讲到重构技巧的时候,我们会讲到解耦、高内聚、模块化等都能提高代码的可复用性
      • 可复用性也是一个非常重要的代码评价标准,是很多设计原则、思想、模式等所要达到的最终效果
    • 可测试性(testability)
      • 代码可测试性的好坏,能从侧面上非常准确地反应代码质量的好坏
      • 码的可测试性差,比较难写单元测试,那基本上就能说明代码设计得有问题
  • 如何才能写出高质量的代码
    • 要写出高质量代码,我们就需要掌握一些更加细化、更加能落地的编程方法论
      • 面向对象中的继承、多态能让我们写出可复用的代码
      • 编码规范能让我们写出可读性好的代码
      • 设计原则可以让我们写出可复用、灵活、可读性好、易扩展、易维护的代码
        • 例如单一职责、DRY、基于接口而非实现、里式替换原则等
      • 设计模式可以让我们写出易扩展的代码
      • 持续重构可以时刻保持代码的可维护性

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

  • 「笔记」设计模式之美 - 导读篇_第1张图片
  • 五者之间的联系
    • 面向对象编程其具有丰富的特性,可以实现很多复杂的设计思路,是很多设计原则、设计模式等编码实现的基础
    • 设计原则是指导我们代码设计的一些经验总结,对于某些场景下,是否应该应用某种设计模式,具有指导意义
      • 开闭原则 是很多设计模式(策略、模板等)的指导原则
    • 设计模式是针对软件开发中经常遇到的一些设计问题,总结出来的一套解决方案或者设计思路
      • 应用设计模式的主要目的是提高代码的可扩展性
      • 从抽象程度上来讲,设计原则比设计模式更抽象,设计模式更加具体、更加可执行
    • 编程规范主要解决的是代码的可读性问题
      • 编码规范相对于设计原则、设计模式,更加具体、更加偏重代码细节、更加能落地
      • 持续的小重构依赖的理论基础主要就是编程规范
    • 重构作为保持代码质量不下降的有效手段,利用的就是面向对象、设计原则、设计模式、编码规范这些理论
  • 这五者都是保持或者提高代码质量的方法论,本质上都是服务于编写高质量代码这一件事的
    • 在某个场景下,该不该用这个设计模式,那就看能不能提高代码的可扩展性
    • 要不要重构,那就看重代码是否存在可读、可维护问题等

你可能感兴趣的:(「笔记」设计模式之美)