命名

最新推荐文章于 2024-07-01 11:49:52 发布

金庆

最新推荐文章于 2024-07-01 11:49:52 发布

阅读量159

点赞数

分类专栏：软工与管理

原文链接：https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247498895&idx=1&sn=35b1d00e367c18c3d4ed7d4b15b38996&chksm=e92ac180de5d4896fd5d789ffbe8c963986717b634f2dac09821c2b3ab2270a42f4a1c006ff5&scene=21#wechat_redirect

版权

软工与管理专栏收录该内容

61 篇文章 0 订阅

订阅专栏

本文探讨了软件命名的重要性，强调了清晰、直观的API、变量和方法命名，并指出如何通过遵循‘意图’而非实现、适应抽象层级来提高代码可理解性。文中引用实例说明命名不当可能带来的困扰，并提倡遵循命名的最佳实践，如LeakedBarrel vs RateLimiter和K8s资源命名的对比。

摘要由CSDN通过智能技术生成

命名

摘自：[警惕软件复杂度困局][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