代码最佳实践 - Coding Best Practice

面向对象设计 - OO Design

函数是一段业务逻辑的封装，类是一块相关业务逻辑的封装。一个类可以是：

• 一个主体，比如书-Book，电脑-Computer
• 一个行为，比如过滤-Filter，拦截-Interceptor
• 一个数据结构，比如List，Map 等等。

SOLID Principles

• S - 单一职责 - Single Responsibility：划分清楚业务责任，不同的责任封装在不同的类中，实现高内聚低耦合。
• O - 开闭原则 - Open-Close Principle：对扩展开放，对修改封闭。设计时考虑变化，考虑改动，采用易扩展的设计模式。
• L - 替换原则 - Liskov Substitution：子类可完全替换父类，即子类的实现在语义和责任上要与父类的定义保持一致。
• I - 接口隔离 - Interface Segregation：不同模块、不同服务之间的对接使用接口来定义，隔离具体的实现。
• D - 依赖倒置 - Dependency Inversion：依赖于抽象，不依赖于具体。

函数式编程 - Functional Programming

• 不可变性 - Immutability：传递不可变的对象，不用担心通过引用更改了对象的状态。线程安全。
• 纯函数 - Pure Function：无副作用的函数，易于测试。

领域驱动设计 - Domain Driven Design

• 围绕业务领域建模，不断加深对业务知识的理解，同时把这种理解反映在代码中。
• 理清边界：类的边界、业务域的边界，高内聚低耦合。
• 把隐式概念转换成显式概念 - Making implicit concepts explicit：在日常沟通中经常用到的一些词汇，在代码中没有对应的封装，发现这些概念隐藏或混合在了某些函数或类中，可以显式地把这些概念提取出来做好封装。
• 声明式设计 - Declarative Design：声明列出你想要的结果，再添加一个规则引擎处理声明得到结果。也类似于用配置化的思路解决业务问题和代码结构问题。
  • DSL - Domain Specific Language：DSL是声明式设计的典范，比方说使用Gradle用户只需声明服务的包依赖，Gradle负责解析包依赖、下载包等问题。

一些最佳实践 - Best Pratices

• 代码首先是写给人看的，其次才是写给机器的 （可理解性 - Understandability）
  • 阅读代码的次数要远远多于修改代码的次数，容易理解的代码才能容易修改，降低改动风险。
  • （变量、函数、类、包等）命名达意
  • 控制一个函数的行数，长了就拆
  • 放弃一些看似的性能优化，真正的性能优化建立在对业务的深入理解和基准测试（Benchmark Test）的数据之上
• 写易于测试的代码 （可测试性 - Testability）
  • 写程序时考虑测试会带来很多好处，比如自然而然我们会考虑到
    • 优先使用纯函数，减少全局变量的依赖
    • 因为要着重于测试功能需求，而不是测试具体的代码实现细节，所以需要考虑如何定义更好的抽象 —— 依赖倒置原则。
    • 修改业务代码时如何适应性、扩展性的改动测试，这就要求业务程序设计上的适应性和扩展性 —— 开闭原则。
• Don't Repeat Yourself：不要重复，不要重复，不要重复
  • 重复即重构
• 隔离变化 - 易变的和不易变的隔离开来
• 清理掉被废弃的代码
• 没有放之四海而皆准的法则

测试 - Testing

测试是一份可执行的规格说明书（Executable Specification）。

• 测试步骤：1.设置前置条件（given-when-then） 2.执行被测试代码 3.检查预期（expectation）。
• 执行速度快。跑得快才能频繁跑，负担小而且快速得到检查的反馈，开发者才愿意多去使用测试、多维护测试，形成良性循环。
• 可重复执行。相同的前置条件，产生相同的结果。
• 测试要关注业务功能，而不是实现细节。
• 部署流中添加测试任务，作为部署的前置检查。
• 测试覆盖率是反映测试状况的指标（Metric），不是形式主义上的覆盖 —— 没有预期、没有检查的测试毫无意义。
• 开发的时间包含了两部分：业务功能开发时间 和 测试开发时间，这一点在迭代排期时就要考虑，去做及做好的前提是有时间。

重构 - Refactoring

• 何时需要重构？
  • 有新的业务需求，当前的代码结构无法适应新的改动。
  • 随着变化的累积，当前的代码结构无法清晰易懂地表达业务知识。
  • 发现更好的代码结构
  • 消除重复
• 重构的方向？
  • 更好的抽象-封装，高内聚低耦合
  • SOLID原则
  • 函数式编程
  • DDD
  • 代码最佳实践
• 重构的方法？
  • 推荐阅读书籍：重构 - 改善既有代码的设计，Martin Fowler博客：https://martinfowler.com/
  • 健全的测试覆盖是安全重构的前提。
  • 具体的方法包括不限于
    • 重命名
    • 变量、函数、类的合并、分拆、增加、删除与移动
    • 设计模式的运用