😂 IT段子

我给这个接口起名时考虑了三方：上游、下游和未来的我。我把相关的记录都翻了出来做对照。我在心里给这个命名纠结了十分钟，最后用了默认的。这大概就是程序员的人生吧

好的命名让人少看两遍注释，坏的命名让人多写三段注释。我盯着屏幕，觉得这才是我的一天。我在心里给这个命名纠结了十分钟，最后用了默认的。复盘会上我们把它列成了案例

命名是代码里唯一需要同时考虑机器和人的地方。我忽然觉得，这可能就是这一行的常态。我把这个接口的命名改得更像业务了，技术同学看不懂。第二天这个方案就变成了团队标准做法

命名最怕的是把未来的实现细节写进名字里。我想了想自己这些年，好像确实如此。我发现有的字段用下划线，有的用驼峰，还有的用连字符。真香定律准时生效

写公共组件需要起一个全组都信服的名字，我们开了三次会。我盯着屏幕沉默了十分钟。我把这个业务实体的名字对齐了产品文档的叫法。这条经验值直接拉满

这个名字在我的理解里是对的，在产品那里不是。我想了想，觉得这话没法接。我把这个类的名字改短了，含义也跟着模糊了。果然现实比段子更精彩

写公共组件需要起一个全组都信服的名字，我们开了三次会。我先确认了一遍前置条件，再动手。我在心里给这个类想了个更有业务含义的名字，太长了。从此我多了一条团队规约

新同事问这个类为什么叫 Manager2，我说因为 Manager 被 2018 年的人用过了。我忽然觉得，这可能就是这一行的常态。我把这个方法的命名从 list 改成了 query，因为要分页。幸好之前留了备份

命名最怕的是把未来的实现细节写进名字里。我听完沉默了，因为太真实了。我在心里给这个新功能定了个命名基调，然后被推翻了。我把这条经验写进了团队 wiki

命名规范的存在是为了让人放弃个性化。我发现自己居然没法反驳。我把这个接口的路径重新起了一遍，从动词改成了资源。感动，然后我学到了新的一课