程序员修炼之道

书籍介绍：https://book.douban.com/subject/35006892/

DRY原则

在系统中，对于每一处的知识都要保持单一和明确

书中提到了关于注释不要重复代码实现的想法，其实在接口层加入详细的注释还是有必要的

以较为复杂的查询接口为例，如果不添加详细的注释的话，那么调用者需要深入到接口实现中去找、去看必要了解的知识

• 如果这个查询接口比较复杂，那么便需要花费比较多的时间

• 反之，如果有详细的注释，那么便节省了翻看实现的时间

  • 比如说如下查询推荐延保的接口，简略注释只是对方法名的翻译，至于返回值是什么，请求参数需要哪些赋值需要去具体实现中寻找，详细注释则注明了这些内容

程序中最明显的代码重复还是非常值得去处理的，将它们抽象提出来，能够让复用变得更容易

/**
 * 简略注释：查询推荐的延保
 * 详细注释：结果中推荐延保数量至多为 2；入参中分页查询信息 ...
**/
Result queryRecommand(Request req);

为什么书中要反对注释重复方法的实现？

因为它担心修改实现时，忘记维护注释使得注释过时

• 将注释看成代码的一部分，并约束修改代码时，同时修改注释，是能够避免这个问题的
  • 这样不仅仅是提高可读性，还能提高接口的抽象程度

举例线段类定义：

class Line {
    Point start;
    Point end;
    double length;
}

出现了重复：长度是由起点和终点定义而来的，改变其中之一那么便将引起长度的变化

• 最好是把长度的定义变成方法

class Line {
    Point start;
    Point end;

    public double length() {
      return end.distanceTo(start);
    }
}

继承税

继承带来的父类与子类之间的 耦合 太深 了，父类中通用字段、方法的变更对子类来说可能带来意想不到的后果

如上继承关系为例：如果最高父类中某些内容发生变更，子类中对其使用的话，那么可能会引起子类行为的改变

而这种改变没有导致编译时异常，可能是没办法发现的，这样使得代码的可维护性大大降低

• 而且维护在每个类中的知识会在继承关系之间波动，暴露了太多的知识出来，做不到抽象和信息隐藏

使用 接口实现来代替类的继承，保证多态性又不会造成信息的紧耦合

使用 组合代替继承：比如想要香蕉，那么直接将包含香蕉的类注入进来，不再通过继承去获取了

继承能被应用需要具备前提条件：

• 抽象出来的父类不会或很少再变动
• 开发者变动的前提是对此有清晰的了解

如果不是这样，在业务代码中引入继承树，那带来的复杂性就太高了

重构

在现实中重构总会面临一些问题：

• 时间压力：这个需求预计3天能开发完，但是为了优化代码设计和逻辑，需要增加2天时间

  • 增加出的额外时间，可能并不会被接受

• 改动带来的风险：

  • 如何才能保证重构的影响全部在可控的范围内非常值得思考，如果重构会引发Bug，那么开发者会宁愿重构并没有开始

重构该成为日常开发中，需要注意和进行的活动

命名

团队内成员将知识统一才是最好的，并不在于它在英文语境下是否表达准确

可以创建相关的文档或者在 README 中将这些命名规范记录下来

• 这不光降低了命名难度，而且使得团队内成员能够统一，也方便交流