# 命名
摘自：[警惕软件复杂度困局][1]
软件中的API、方法、变量的命名，对于理解代码的逻辑、范围非常重要，也是设计者清晰传达意图的关键。
然而，在很多的项目里我们没有给Naming /命名足够的重视。
我们的代码一般会和一些项目关联，但是需要注意的是项目是抽象的，而代码是具体的。
项目或者产品可以随意一些命名，如阿里云喜欢用中国古代神话（飞天、伏羲、女娲）命名系统，
K8s也是来自于希腊神话，这些都没有问题。
而代码中的API、变量、方法不能这样命名。
一个不好的例子是前一段我们的Cluster API 被命名为Trident API（三叉戟），
设想一下代码中的对象叫Trident时，我们如何理解在这个对象应该具备的行为？
再对比一下K8s中的资源：Pod, ReplicaSet, Service, ClusterIP，
我们会注意到都是清晰、简单、直接符合其对象特征的命名。名实相符可以很大程度上降低理解该对象的成本。
有人说“Naming is the most difficult part of software engineering”，
或许也不完全是个玩笑话：Naming的难度在于对于模型的深入思考和抽象，而这往往确实是很难的。
需要注意的是：
（a）Intention vs what it is
需要避免用“是什么”来命名，要用“for what / intention”。“是什么”来命名是会很容易将实现细节。
比如我们用 LeakedBarrel做rate limiting，这个类最好叫 RateLimiter，而不是LeakedBarrel：
前者定义了意图（做什么的），后者 描述了具体实现，而具体实现可能会变化。
再比如 Cache vs FixedSizeHashMap，前者也是更好的命名。
（b）命名需要符合当前抽象的层级
首先我们软件需要始终有清晰的抽象和分层。
事实上我们Naming时遇到困难，很多就是因为软件已经缺乏明确的抽象和分层带来的表象而已。
[1]https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247498895&idx=1&sn=35b1d00e367c18c3d4ed7d4b15b38996&chksm=e92ac180de5d4896fd5d789ffbe8c963986717b634f2dac09821c2b3ab2270a42f4a1c006ff5&scene=21#wechat_redirect