😂 IT段子

程序员最难的两个问题：架构怎么设计，和这个变量叫什么。我忽然觉得，这可能就是这一行的常态。我召集了两同事开了一个十五分钟的命名讨论会。办公室安静得能听见键盘声

给变量起名纠结十分钟的人，写 bug 只用了十秒。我想反驳，但发现他说得对。我把这个类的名字加了 Impl 后缀，其实只有一个实现。这条经验值直接拉满

接口命名规范写了三页文档，线上接口还是叫 /api/getDataNew2。我把这个枚举的名字统一了前缀，可读性提升明显。办公室安静得能听见键盘声

这个名字的复数形式很有歧义，我犹豫了很久。我叹了口气，然后打开了编辑器。我把这个模块的命名缩写展开了一遍，比原来还长。我把这条经验写进了团队 wiki

命名规范里没写怎么处理这几种情况，于是大家都自由发挥。我把这个字段的命名从简称改成了全称，行变长了

接口文档写着返回三个字段，实际返回了五个，还有一个叫 extra 的神秘字段。我发现有的地方叫 user，有的叫 customer，其实是同一个。从此我多了一条团队规约

接口设计评审会上，我为一个字段该叫 name 还是 title 争了二十分钟。我先确认了一遍前置条件，再动手。我在心里给这个命名纠结了十分钟，最后用了默认的。真香定律准时生效

接口命名规范写了三页文档，线上接口还是叫 /api/getDataNew2。我先给自己泡了杯茶，做好了打持久战的准备。我把这个模块的命名统一加上了业务前缀，有点冗余。那一刻我觉得自己还是很专业的

命名是代码里唯一需要同时考虑机器和人的地方。我笑了笑，决定不解释。我在心里给这个函数想了五个名字，最后用了最长的那个。世界瞬间清净了

程序员最难的两个问题：架构怎么设计，和这个变量叫什么。我在心里点了点头。我发现有的地方叫 user，有的叫 customer，其实是同一个。从此我多了一条团队规约