我接手的第一样东西就是React UI。我们有一个主要组件，它容纳了其他所有组件。我喜欢在代码中加入一点幽默感，我想把它命名为GodComponent。在code review的时候，我才明白为什么命名是一件很难的事情。

计算机科学有两个难点：缓存失效，给变量命名，以及差一错误。

我经手的每一段代码都带有隐喻意。GodComponent?那时用来盛放所有那些我不知道该放到哪里的的烂代码的。它包罗万象。如果我将一个变量命名为LayoutComponent，未来我会知道，它所做的只是规划布局，而不涉及任何状态。

我发现的另一个好处是：如果它看起来太大了，就像包含大量业务逻辑的LayoutComponent一样，我知道是时候重构了，因为业务逻辑不应当属于那部分。而如果使用GodComponent这个名称，那对里面的业务逻辑就不会产生任何影响。

命名你的集群?根据在它上面运行服务来命名是个好主意，可是你以后还可能会在上面运行其他东西。最终，我们是用团队名称来命名的。

对于函数来说也是一样。doEverything()是一个可怕的名字，这会产生很多后果。如果这个函数可以完成所有操作，那么测试这个函数的特定部分就会变得特别难。无论这个函数有多大，你都不会觉得奇怪，因为毕竟这个函数就是要做所有事情的。所以需要换个函数名，重构。

有意义的命名也有不好的一面。如果名称太有意义并隐藏一些歧义怎么办?例如，在SQLAlchemy中调用session.close()时，closing sessions不会关闭基础数据库连接。

在这种情况下，将名称视为x，y，z而不是count()，close()，insertIntoDB()可以防止赋予它们隐含意义——并迫使我仔细检查它们正在做什么。

从来没想到，关于命名我要说的东西居然不能用一句话就概括完。

旧代码和下一个开发者

你有没有看过一些代码并觉得很奇怪?那些开发者为什么这样做?这完全说不通啊。

我有幸曾经使用过遗留代码库。其中有类似这样的注释，“在与穆罕默德一起解决了这个问题以后，注释就删掉了。”你在做什么?谁是穆罕默德?

我可以在这里做一个角色转换——想想以后来接手我代码的人们——他们会不会发现它很奇怪。Peer review 部分解决了这个问题。这让我意识到了环境的重要性：要时刻记得我的团队正在工作的环境是什么样的。

如果我忘记了代码，稍后又看到它，而无法重新回想起当时的环境时，我会说：“到底为什么他们会这样做?这讲不通......哦等等，这是我自己写的。”

这就是文档和代码注释发挥作用的地方了。

文档和代码注释

它们有助于保留环境(上下文，语境)，以及分享知识。

正如Li在“如何建立良好的软件”中所说的那样，“软件的主要价值不在于生成的代码，而在于产生它的人所积累的知识。”

“软件的主要价值不在于产生的代码，而在于产生它的人所积累的知识。”——Li

我们有一个面向客户的API终端，似乎没有人使用过。我们只是删除它吗?毕竟，这是技术负债。

如果我告诉你，每年在特定国家/地区，10名记者会将他们的报告发送到该终端，该怎么办?你要如何测试?如果没有文档(现实中确实没有)，我们就没办法。所以，我们没有那么做。我们直接删除了该端点。几个月以后那个一年一度的时刻到了。十名记者无法发送10份重要报告，因为终端不再存在了。

拥有关于这个产品的知识的人离开了团队。当然，现在代码中有一些注释解释了端点的用途。

据我所知，文档是一个每个团队都在努力解决的问题。不仅仅是代码文档，还有代码周围的流程。

我们还没有找到一个完美的解决方案。

我很喜欢Antirez对不同类型的有价值的代码注释的详细分类。

原子提交

如果你必须回到之前的步骤(是的你会的。详见测试部分)，这个提交作为一个单元是否合适?

在删除烂代码的时候有自信

删除烂代码或过时的代码会使我感到非常不舒服。我认为多年之前被写下的代码是神圣的。我的想法是“当他们写下这些东西时，他们肯定是考虑到一些事情的。”这是传统和文化与第一原则思维方式之间的较量。删除一年一次的终端也是如此。我在这方面得到了太多具体的教训。

我会试着从周围解决代码，而高级工程师则会试着从中间解决。删除所有内容。一个永远不会运行的if语句?一个不应该调用的函数?是的，一切都没了。我?我只会在最上面写下我自己的函数而已。我没有减少技术债务。如果我做了什么的话，我也只是增加了代码复杂性和给他人的误导而已。对下一个人来说把这些代码功能拼凑到一起会更艰难。

我现在使用的启发式是：现在有的代码你无法理解，而且你知道有些代码是你永远也不会用到的。删除那些你永远不会用到的代码，并对那些你不理解的代码保持谨慎的态度。

Code Reviews

Code review是非常棒的学习途径。这是一个外部反馈循环，反映了你现在和将来会怎么写代码。差别在哪里?有一种方式比另一种更好吗?我在每次code review时都会问自己这个问题：“为什么他们那样做?”。每当我找不到合适的答案时，我都会和他们谈谈。

在第一个月之后，我开始在我的队友代码中发现一些错误(就像他们曾经为我做的那样)。这太疯狂了。同行评论对我来说变得更加有趣了——变成了我期待的一场游戏——一场改善我的代码感的游戏。

我的启发是：在我了解代码如何工作之前不要批准代码。

版权声明：转载文章来自公开网络，版权归作者本人所有，推送文章除非无法确认，我们都会注明作者和来源。如果出处有误或侵犯到原作者权益，请与我们联系删除或授权事宜。