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

为什么要学习设计模式

• 应对面试中的设计模式相关问题
• 告别写被人吐槽的烂代码
  • 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、基于接口而非实现、里式替换原则等
    • 设计模式可以让我们写出易扩展的代码
    • 持续重构可以时刻保持代码的可维护性

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

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