工程师身上学到的那些经验与教训

第一项任务是开发一款 React UI。当时我们拥有一个主组件，用于容纳其它所有组件。我喜欢在代码当中加点幽默元素，所以我把它命名为 GodComponent。但在代码审查时，我才意识到为什么命名工作如此重要、也如此困难。

计算机科学领域有两大难题：缓存失效、命名以及缓冲溢出错误。-—— Leon Bambrick

我命名的每一段代码都包含隐藏的含义。GodComponent？这个组件的含义，就是我会把所有不知道该放在哪的组件都放在这里。它囊括一切。如果我把它命名为 LayoutComponent，后续我才会意识到它的作用就是布局分配，其中不包含任何状态。

我发现的另一项心得在于：如果其体积过于庞大，就像是这里提到的包含大量业务逻辑的 LayoutComponent，那么我就会意识到是时候进行重构了，因为通过名称就能看出业务逻辑并不属于这里。但使用 GodComponent 这个名称，我们无法判断业务逻辑出现在这里是否正常。如何命名集群？最好是在运行了服务之后再对集群进行命名，而后根据运行内容的变化重新调整名称。最终，我们用自己的团队名称完成了集群命名。

函数命名的情况也是一样。doEverything() 这个名字就不怎么样，其会带来严重的后果。如果这项函数能够完成所有操作，那么我们将很难测试函数当中的某些特定部分。而且无论这个函数有多大，我们都会觉得很正常，毕竟它的名字可是叫“everything”。所以，最好的办法当然是更换名称，进行重构。

但是，我们在命名中也要考虑到另一类问题。如果名称的含义太过具体并忽略了某些细微差别，该怎么办？例如，在 SQLAlchemy 当中调用 session.close() 时，关闭会话不会关闭基础数据库连接。（我本应该跳出手册限制，对这项 bug 进行处理，具体情况将在调试部分进一步说明。）在这种情况下，我们可以考虑 x, y, z 这样的名称，而非 count(), close(), insertIntoDB()，从而避免为其分配隐含的意义。太过具体，会迫使我们不得不在后续维护时费力检查这些函数到底是用来干嘛的。

最后，当时的我从来没想到命名会成为值得单独一提的重要工作。

遗留代码与下一位开发者

大家有没有面对一段代码时，感觉摸不着头脑？他们为什么要这么写？这完全说不通啊。

我就“有幸”接手过遗留代码库。其中就存在类似于“跟穆罕

（编辑：唐山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!