高效能编码人士的7个习惯

Posted 2022-02-02 vigor2323

本文讨论的是编码风格、原则和艺术。

至于如何编码实现系统的功能和性能、如何架构设计、如何提高易用性、如何团队协作、如何项目管理，均不在本文讨论范畴之内。

本文也不讲大括号应该放在哪里，代码如何缩进，运算符周围是否加上空格这种规范，虽然这也很重要。

建议有7年以上编码经验的程序员阅读本文，编程年头太少的，很难理解本文。

如果你持续编码已经15年以上，但对本文没有共鸣，建议好好考虑一下你是否适合编程。

编码风格的所有目标

1、代码易读

2、代码易改

这就足够了。

而且这很难做到。

最重要的技巧

1、小函数；（注意这个技巧排在第一位）

2、小文件、小类；（小的东西，易读，易改）

3、做好单元测试！（所有都测到了，你就敢改）

4、少注释；（而是增加表达力！让人一眼看懂的代码不需要注释）

5、消除重复。（重复永远是丑陋的）

如果你记不住这么多条，就记一条：小函数。

七个习惯

一、保持精简

“小就是美”。

告诉你一个秘诀，即便你不会编码，也可以简单而准确地判断一个人是不是编程高手。

你只需要略微看一下他的代码就可以。

如果他代码中的函数，绝大多数都在20行以内，这就是高手。

如果基本都在10行以内，这是顶尖高手。

如果都在3、4行左右，这是大师。

如果有很多超于100行的函数，这是新手、低手。

类似地，看他代码中每个文件的长度，应该大多都在200行或者400行以内，才是正常的，虽然这无法直接判断是不是高手。

但如果动辄都在2000行以上，这是新手、低手。

大致而言，高手能做到：

1、小函数、小文件、小类；

2、小的单元测试用例。

3、函数有尽量少的参数。

最理想的函数参数数量是0个，其次是1个，再次是2个，应尽量避免3个及以上。

参数越少，越好测试，越不容易搞错参数的顺序。（为减少参数，可考虑封装成类。）

怎么做到这点？只要你有保持精简的意识，你总会做到的。

任何一个文件，一个函数，只要感觉它大到一定程度（比如超过10行），就着手拆分。

下面举个例子：

上图左边是一个长达15行的函数，经过整理后，可以写成右边那样，但这仍然不够。

右边每种颜色的代码块都应该由一个函数完成，所以，左边这个函数，最终变成4行。（每行都是一个函数调用）

类似的，稍微看到一点比较繁复的东西，就抽象它，精简它，让你的程序看上去非常简洁才可以。

这就是在践行KISS原则。（Keep It Simple,Stupid）

也是在践行“松耦合、高内聚”原则。（一个小函数、小类，必然是高度内聚的）

二、提高表达力

编写整洁、易读的代码。

高效能人士写的代码，即便在10年后，他把代码已经忘光光的时候，只要需要，他拿出来一看，就能轻松理解。

我写代码，从来不是为了别人看，我只是怕自己忘记。

我的记性不太好，而且我从来不依赖我的记性，所以，我必须写得非常易读。我很难忍受看不懂自己代码而产生的那种嫌弃感。（不是嫌弃现在的自己，而是以前的自已）

“代码的写法应当使别人理解它所需的时间最小化。”

如何做到？下面谈5点。

1、让代码读起来像自然语言。（不断磨练这点）

2、高度重视变量和函数的命名，要明确、无歧义。

所有函数命名，都以动词为开头。（类名用名词）

不要怕命名长，只要有助于理解，长点没事。

慎重选择用词，考虑不会让人误解。

举个例子：

上面这段代码是拷贝字符串的，如果参数名改为source和destination，就会清晰很多，而且，引用者会不太容易搞错参数顺序。

3、在实在没有办法用代码表达意图的时候，写注释。

除去版权和许可证这种必要的注释，绝大多数情况下，我只在觉得自己以后可能看不懂的情况写注释。

在比较古板的条条框框下，注释应该占代码的1/5以上。

然而，对高手而言：在大多数情况下，注释表明了一种失败。

所以，在你想注释的时候，再努力一下，看能不能仅用代码就可以明白表达。

“不要给不好的名字加注释——应该把名字改好”

注释不是代码，所以它是难以管理和测试的。由于人的懒惰天性，注释通常不会跟着代码的改动而改动，所以注释往往是过时的、错误的（而且难以发现）。

“不准确的注释要比没注释坏得多。它们满口胡言。”

4、照顾阅读者的感受

把关系相近的函数，放到一起。

如果函数A调用函数B，那么把A放到B前面，人就会自然阅读下去。而且阅读者会有一个预期，看到一个新的函数，知道很快就能读到它的实现。

（不过我的习惯是：把B放到A前面，因为有些编程语言，要求一个函数只能调用前面出现过的函数，如果不加声明的话。所以，看我的程序，需要从文件底部看起。）

同样地，概念相关的代码，放到一起，用空行分开。

不要再用微软提倡的匈牙利标记法（比如szAuthor这种命名），那已经过时了。使用大小写或者下划线分割单词的命名（比如deletePage）就很好，匈牙利标记法比较丑陋，直接影响阅读感受。

再举一个例子：为了便于阅读，避免使用do/while语句。

do/while这种写法很丑陋，通常来讲，逻辑条件应该出现在它们所“保护”的代码之前，if/while和for语句就是这么干的。而do/while把条件放在后面，这很反常，以至于大多数人读到do/while时，都需要读两遍。

5、不要重复！

“重复可能是软件中一切邪恶的根源。

“重复”会浪费编码者的时间、浪费阅读者的时间、浪费维护者的时间、浪费编译、运行的时间。而且，还浪费存储。

看到重复，就改写它，这是一个基本素质。

三、边写边测

程序如果易读，就很有利于修改。

但仅仅“易读”是远远不够的。

很多程序员敢写代码，但不敢改，他们都知道什么是“牵一发而动全身”。

所以，每次你让他们改程序的时候，他们的脸色都不好看的。

只有顶尖高手，才会“欣然改程序”，他们知道，这又是一次展示自己能力的机会。

他们是怎么做到这点的？

他们的底气来自测试。

测试覆盖率越高，你就越放心，你就可以放心地修改，甚至放心地改架构！

下面是TDD（来自极限编程）的方法论，值得参考和借鉴。（说实话，我并没有严格做到）

1.在写功能代码前，先写一个小的单元测试。（不要写太多，否则你会没有动力）

2.运行所有测试（先看这个测试是否能工作），测试应该失败。（因为还没有写生产代码）

3.编写仅仅能通过这个测试的最简单代码。（先不用写很好，后面还会重构；也不要写更多，因为其他还没写测试）

4.通过所有测试。（注意是所有测试，这保证了一切都是对的。）

5.根据需要重构，每次重构后都测试。（始终保持一切都是对的。）

6.重复上述循环。（测试和编码应该是小型和渐进的）

测试用例应该有这样的结构：设置、执行、验证以及可能需要的清理。

测试用例应该尽量小，一次只干一件事。

坚持TDD原则，你就会有覆盖率足够高的测试代码，否则可就不一定。

注意：“测试代码和生产代码一样重要。它可不是二等公民。它需要被思考、被设计和被照料。它该像生产代码一般保持整洁。”

当然，写测试代码本身是需要成本的，但是你要好好想想，值不值？

四、时时清理

所有东西，如果不维护，总是会变脏、变坏。（这就是这两年很多人喜欢说的“熵增”）

代码也一样。（除非你再也不用它了）

所以，每次你改动代码时，都要让代码变得更整洁。

正如美国童子军军规：“让营地比你来时更干净。”

注意，你敢于清理的前提是，你有足够的测试用例。

每次清理时，告诫自己，这会给自己带来巨大好处：可以避免今后巨大的麻烦。

这可以用在工作和生活中的任何方面，包括你的思想。

五、同时保持两种截然相反的思维

很多思维，都有截然相反的对立面，并且都有其拥趸。

比如有人说WEB3是未来，就有人说WEB3是垃圾。

有人说公司要人性化管理，就有人说必须要狼性管理。

再举两、三个例子：

1、应该自顶向下编程，还是自底向上编程？

正确答案是，这两种思维都要用。

2、先写代码，再写测试；还是先写测试，再写代码？

你自己看着办。

3、“三目运算符”的可读性也是有争议的。

拥护者认为这种方式简洁，只有一行；反对者则说这可能会造成阅读的混乱。

是下面这样好，



还是下面这样好？

正确做法：默认情况下都用if/else，只在最简单的情况下使用“三目运算符”。

保持两种思维的好处在于，你可以始终对这两种提法进行实践、测试、反思，在两种极端的说法中找到平衡，找到各自适用的场景，找到更适合自己的做法。

这会让你更从容、更灵活。

甚至，不要一味追求“小就是美”，偶尔大一下也没啥。

六、知道不做什么

最好读的代码就是没有代码。

如果有现成的，不要自己去做。

如果现在还用不到，就先不要写。（YAGNI原则：You Ain’t Gonna Need It）

你所写的每一行代码都是要测试和维护的。

你要节省自己的时间，你还有更重要的事要做。

七、更新自我

自FORTRAN语言在上世纪50年代后期出现之后，在编程思想方面，人们就在不断的学习和长进。

人们首先认识到封装的重要性，ALGOL语言的设计者在ALGOL60中采用了以Begin……End为标识的程序块，使块内变量名是局部的，以避免它们与程序中块外的同名变量相冲突，这是编程语言中首次提供封装的尝试。

上世纪60年代后期，随着《程序结构理论》和《GOTO语句有害论》的提出，证明了任何程序的逻辑结构都可以用顺序结构、选择结构和循环结构来表示，确立了结构化程序设计思想，这使得程序更容易维护。

上世纪80年代，面向对象程序设计思想经过20年的研究和发展逐渐成熟，一大批面向对象语言相继出现。

2001年2月，在美国犹他州瓦萨奇山，17个来自于各类敏捷方法的实践者共同达成了一个共识：《敏捷宣言》，提出了十二条敏捷原则。

其中第十条原则和本文密切相关：

简洁是敏捷的精髓，它是极力减少不必要工作的艺术。

Simplicity--the art of maximizing the amount of work not done--is essential.

然后，设计模式、重构开始普遍流行。

再然后，有了CI/CD，有了Devops。

以前的程序员，是不懂这些的。

如果你是搞IT的，你就会发现，编程思想、方法、语言、工具，层出不穷、学无止境。

真正的高效能人士，永远不会停止学习，永远不会停止更新自我。

因为永远会有更好的东西问世。

编程之外

我在命名这7个习惯时，刻意使用了普适的说法。

这些高度抽象的理论，完全可以用在其他领域。

1、保持精简

2、提高表达力

3、边写边测

4、时时清理

5、同时保持两种截然相反的思维

6、知道不做什么

7、更新自我

这些一样可以用在写作、工作、生活以及做人上。

成熟的人，都明白这点。

图｜高效能编程人士的七个习惯

本文用标题和图示向Stephen R. Covey致敬，感谢他的神书《高效能人士的七个习惯》。

本文引用主要来自以下两本广为人知的名著：

Robert C. Martin. 代码整洁之道. 人民邮电出版社.

Dustin Boswell,Trevor Foucher. 编写可读代码的艺术. 机械工业出版社.

文｜卫剑钒