TDD(测试驱动开发)

为何英雄难过命名关?

2020-06-30  本文已影响0人  袁慎建

Martin Fowler在他的博文中提到一句话:

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

老马并表示:“很久以来,我一直很喜欢这句话。一个典型的现象是:我找不到一个令人满意的URL”。

看起来小小的命名真的不小,软件先辈也对其非常关注。

2016年,我在Eums项目上,三个Tech Lead的同事(很资深的老程序员,82,83,85)跟我一起Review了一个方法的命名,花了10多分钟,最终觉得不是最完美的。足以说明,命名真的很难。

程序员小白会说:“那么纠结干嘛!起一个差不多的名字不就得了,程序又不是不能运行” 就是这一个差不多,让代码的维护成本呈指数级增长。那为什么,很多时候起一个好名字这么难呢?

如果定义一个好名字?我觉得好名字很容易定义 -- 在当前业务上下文中,准确表达业务含义的名字,使用通用的业务语言描述。从这个维度出发,越精确接近业务概念,这个名字就越好。

那为什么很多小白写出的代码,别人就是不能直接看懂呢?从两大方面都可以找出一些原因。

业务理解上:

  1. 自身对业务本身缺乏理解。
  2. 自身对业务理解了,但沟通过程未确认统一语言。

软件建模上:

  1. 干了两件事情,不知道以谁的业务为准。
  2. 做的事情太通用,名字没法赋予业务含义。
  3. 随意的编码习惯,引入没必要的简写。
  4. 对领域专有名词翻译成英文后,选词不一致。

在业务理解上,没有什么捷径可走:

  1. 首先要充分理解业务,这是软件交付的基础。
  2. 切记不要因为疲于沟通,自己就随意脑补概念。
  3. 通过沟通确认在团队中跟业务方形成一致理解。
  4. 对一些特有的专业术语,形成一套固定的术语表供团队参考。

在软件建模上,当遇到不好命名的时候,多半是因为做的事情太多了,或者过度追求通用性,而导致代码无法赋予确定的含义,遇到这种情况,思考代码是不是做的事情不单一,进行分析和分解。

对于一些简写习惯,也要确保每个人理解一致的前提下才这么做,如果业务上没有使用简写,代码也不要选择简写。另外,不到迫不得已,不建议用拼音命名。对于一些非专有术语,尽量用一些简单常用的,比如find就比retrieve好。实在词汇量匮乏,备一个汉英词典。

以上如果只通过自己一个人来预防,难免会有不自知的问题。在敏捷交付项目中,充分发挥个体交互,让反馈机制运转起来。像结对编程、Code Review,Story Kick-Off这些环节都是能够为我们的建模提供有益输入的,非常值得在项目中去实践。

上一篇下一篇

猜你喜欢

热点阅读