为什么《程序员修炼之道》评分高达 9.1?

4,718 阅读10分钟

大家好,我是 方圆。开始接触到《程序员修炼之道:通向务实的最高境界》这本书是在豆瓣图书的高分榜单上,它的评分高达 9.1,其中有条蛮有意思的书评非常吸引我:“这本书我读过 5 遍信不信,每个字都磨出了感情... 爱看技术书的程序员,看看可以往上走走;不爱看技术书的程序员,看看可以轻松刷出阅读成就感”。所以,本着刷阅读成就感并希望磨炼技术的态度便开始了本书的阅读,抽业余时间读完,其中有部分收获能和大家分享,当然更希望大家去看原书。

1. DRY 原则

DRY 是书中强调和多次出现的原则,它的中文释义是“干的;干燥的”。在文中强调的是:在系统中,对于每一处的知识都要保持单一和明确。初看上去这个原则是值得坚持和肯定的,但其中提到了关于注释不要重复代码实现的想法,我对此并不是很同意,我觉得在接口层加入详细的注释还是有必要的。

以较为复杂的查询接口为例,如果不添加详细的注释的话,那么调用者需要深入到接口实现中去找、去看必要了解的知识,如果这个查询接口比较复杂,那么便需要花费比较多的时间。反之,如果有详细的注释,那么便节省了翻看实现的时间,比如说如下查询推荐延保的接口,简略注释只是对方法名的翻译,至于返回值是什么,请求参数需要哪些赋值需要去具体实现中寻找;详细注释则注明了这些内容。

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

但书中为什么反对注释重复方法的实现呢?因为它担心修改实现时,忘记维护注释使得注释过时。虽然有理,但是我觉得如果 将注释看成代码的一部分,并约束修改代码时,同时修改注释,是能够避免这个问题的,这样不仅仅是提高可读性,还能提高接口的抽象程度。

不过,DRY 原则也有值得坚持的地方,以如下线段类定义为例:

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

第一眼看上去貌似没什么问题,线段有起点、终点和长度。但是实际上出现了重复:长度是由起点和终点定义而来的,改变其中之一那么便将引起长度的变化,最好是把长度的定义变成方法,如下:

class Line {
    Point start;
    Point end;

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

这样消除了重复。但是如果该计算非常耗费性能,这样定义可能并不合适,还是需要为长度计算的结果,冗余出字段来保存,如下:

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

    public void setStart(Point p) {
      this.start = p;
      calculateLength();
    }

    private void calculateLength() {
      this.length = end.distanceTo(start);
    }

    public double length() {
      return length;
    }
}

所以,DRY 原则还是需要被辩证地看待。当然,程序中最明显的代码重复还是非常值得去处理的,将它们抽象提出来,能够 让复用变得更容易

2. 继承税

“少用继承,多用组合” 是之前在学习设计模式时接触到的原则,但是当时我对此并没有什么感触,甚至觉得继承蛮好用的,比如在应用模板方法模式时,使用抽象类来定义方法模板。不过在书中又提到了这个原则,它称之为“继承税”,并做出了一段蛮有意思的描述:

你想要一根香蕉,但得到的却是一只拿着香蕉的大猩猩,甚至还有整个森林

其表达的意思也不难理解:强调继承带来的父类与子类之间的 耦合太深 了,父类中通用字段、方法的变更对子类来说可能带来意想不到的后果

在这里插入图片描述

以如上继承关系为例,如果最高父类中某些内容发生变更,子类中对其使用的话,那么可能会引起子类行为的改变,而这种改变没有导致编译时异常,可能是没办法发现的,这样使得代码的可维护性大大降低,而且维护在每个类中的知识会在继承关系之间波动,暴露了太多的知识出来,做不到抽象和信息隐藏。

那么不用继承该怎么办呢?

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

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

从这也能理解为什么 C++ 语言中的多继承被诟病。此外,我觉得继承也并不能被一票否决,在 Java 源码中常用容器的实现里,都是有抽象层的(AbstractList, AbstractMap 等等),通过继承它们,实现了大量代码复用,为各种不同容器的具体实现提供了很多方便之处。但是我觉得继承能被这么应用需要具备前提条件:一是 抽象出来的父类不会或很少再变动;二是 开发者变动的前提是对此有清晰的了解

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

3. 重构

先前我对重构的观点是:如果能用,尽量避免重构,当代码实在难以满足需求时,再推翻它重新来。但是书中提出的观点则不同:代码需要演化,它不是静态的东西。 当遇到绊脚石或是注意到有两件事的确需要合并,又或是被其他什么事情触动而心生悔意时,那么请不要犹豫,去改掉它。并且它主张的重构是一项日复一日、小步快走的工作,并不是“大厦的倒塌重建”,这样低风险小步骤进行改造有助于使代码更易于维护和更改。

不过理想总是好的,在现实中重构总会面临一些问题:

  1. 时间压力:这个需求预计 3 天能开发完,但是为了优化代码设计和逻辑,需要增加 2 天时间。增加出的额外时间,可能并不会被接受

  2. 改动带来的风险:如何才能保证重构的影响全部在可控的范围内非常值得思考,如果重构会引发 Bug,那么开发者会宁愿重构并没有开始

事实上,时间压力并不太能站得住脚,因为随着功能增加,复杂度会不断累积,那么未来便需要投入更多的时间来修复,并且将引发更大规模的改动,带来 Bug 的风险也会增加;而对于改动带来的风险,我觉得本书强调“小步、多次”重构也是想将此风险降低,它更像是一项慢慢地、有意地、仔细地进行的活动,除此之外使重构安全的方法是在重构之后有良好的测试,如果我们有 完善的业务场景的单元测试用例,在重构完能及时发现问题所在,也不至于对重构这件事情畏手畏脚了。

此外,不对代码进行重构往往会触发开发者心中的“破窗效应”,在已经很难维护的代码上继续叠加功能,而不是对其进行改善,使得代码更加难以维护,还会拿“这段代码已经很烂了”作为“合理的借口”。所以,重构该成为日常开发中,需要注意和进行的活动。

破窗效应:一种社会心理学理论,它表明环境的恶化会导致人们行为的恶化。该理论认为,如果一个社区的某个小问题没有及时得到修复,那么这个小问题的存在就会给人一种信号,即这个地方被忽视或者管理不善。这种信号会诱使人们模仿这种不良行为,从而导致更多的窗户被破坏,最终可能导致整个社区的秩序崩溃。

4. 命名

每次提到命名或者在为接口命名时,我都会有一种非常强烈的让它自解释的想法,但是我最近这种想法的欲望逐渐降低,原因有二:

  1. 阅读习惯:对国人来说,可能大多数人没有先去读英文的习惯,更倾向于读中文相关的内容,比如注释

  2. 英语水平参差:可能有时候想要自解释的初心是好的,但是如果使接口名变成了长难句,可读性将降低

即使是这样,也并不能降低命名的标准,应该有一个适度的折中:不引入长难句,将其中难以表达的内容考虑使用注释来补充。此外,我觉得命名保持一致性也非常重要,比如在项目中对于补购已经命名为 AddBuy,那么便不要再引入 SupplementaryPurchaseReplenishment 等命名,团队内成员将知识统一才是最好的,并不在于它在英文语境下是否表达准确。但是对于这一项工作,我还没有发现团队花费心血来做这件事,如果不去翻看原有代码的话,冒然的命名可能不符合系统内现有规范,所以我觉得可以创建相关的文档或者在 README 中将这些命名规范记录下来,这不光降低了命名难度,而且使得团队内成员能够统一,也方便交流。

除了在方法自解释上下功夫外,方法的表达也值得注意,比如定义一个打折的方法:

void deductPercent(double amount);

deductPercent 扣除百分比指的是 要做的事情,但是扣除什么的百分比是不明确的,其次,入参 amount 也容易让人疑惑,是绝对值呢?还是百分数?应该有几位小数?所以,换一种方式会更好一些:

void applyDiscount(Percentage discount);

applyDiscount 方法名表达了折扣的意图,并且将 double 类型换成了对象类型,在对象中进行准确的定义,也是一种方法。当然,如果仍然采用 double 类型的入参也没有问题,在注释中注明容易让人迷惑的部分也是不错的方案。

5. 终

我觉得这本书更多的是在传达一种 务实的工程师精神和责任,不只是要编写好的代码,还要为你编写的代码负责,积极地为编码添加上 @author 的标志,当开发者看到你的名字时,他们能联想这段逻辑是可靠的、可读性好的和易于维护的,也是专业性的体现。

除了本文中提到的内容之外,其中还有关于基础工具的使用、编码的习惯、需求管理和人生哲学等内容,我觉得用它的结尾来作为本文的结尾也再合适不过:

你要为自己的人生做主,精心营造,与人分享,并为之喝彩!