神之物件：如何召唤Codethulhu

如果您关注我的文章，您就会知道我通常会写很多关于软件质量最佳实践的文章。

回想起来，这种方法偏向于那些想要提高软件质量的人。我无意中忽略了那些想在系统中注入更多 Bug 的人。

因此，对于那些热爱缺陷的人来说，让我与你们分享我的第一个秘诀，即系统地创建缺陷滋生地：上帝对象。

警告：本文可能带有讽刺意味。请理性地编写代码。

找到一个足够复杂的问题

太棒了！你选择让代码库承受这种寄生式增长的复杂性，这将催生出无数小时只有你才能完成的重要工作（这读作“工作保障”）。

上帝对象是产生足够复杂性的绝佳方式，只有非常熟悉它们的开发人员才能触碰它们，而又不敢引发质量保证的愤怒。

我所谈论的对象类型以诸如 Codethulhu、初级开发人员的折磨者和质量保证分析师等名称而闻名。

但首先，他们需要解决一个问题。我知道，我们的业务是增加复杂性和安全性，而不是解决业务问题。不过，请听我说完。

如果您的代码不能解决一个独特而关键的问题，那么未来的一些开发人员可能会绕过它并将其完全丢弃。

因此，您需要找到一类问题：

• 需要高超的技能和批判性思维来解决
• 如果不花时间仔细思考就无法轻易理解
• 与足够多的其他复杂系统和流程进行交互，以承担其部分复杂性
• 具有足够的潜力来随着新功能的需要而增长和扩展复杂性
• 没有现成的替代品

如果什么都想不起来，您可以等待新的复杂功能推出，或者从代码库的现有层中取出一个大文件并进行扩展。以下是一些需要考虑的对象类型：

• 通信/Web 服务层
• 自定义用户界面控件
• 数据访问层
• 对象序列化/反序列化逻辑
• 公共服务（业务逻辑）层

然而，这些都不是像业务问题那样独特，但是如果您的组织似乎不愿意为您提供足够大的功能以便您扩展到 Codethulhu 规模，无论出于何种原因，所有这些都会在紧要关头发挥作用。

诞生Codethulhu

一旦你确定了自己的机会，你就进入了这个过程中最艰难的部分之一。在继续阅读之前，你可能需要做好准备。

为了让你的对象能够存活下来并进入代码库，它必须能够正常工作。这意味着，你需要解决或基本解决业务最初给你（或你发现）的任何问题。

这意味着你必须全力以赴，全力以赴。实际上，你可能需要非常努力，因为大型功能更难实现，而且你将特意创建一个大型类来实现它，以便在单个文件中管理复杂性。

扩大感染

然而，巨大的神物并非一夜之间就能出现。我们所说的那种恐怖需要时间和奉献才能成长。你不必刻意去培育它们，但这确实有帮助。

记住：尽可能多的逻辑都放在同一个类中。

如果问题与你的对象相关，请在对象中解决它。我指的是：

• 序列化
• 反序列化
• 数据访问
• 验证
• 解析
• 格式化
• 日志记录
• 线程管理
• 状态管理
• 缓存
• Web 服务调用

所有这些事情都可以在你的神对象中处理。

记住这个咒语：

您的问题很特殊，与其他代码不同，因为它解决的问题很复杂。如果其他代码可以处理您的对象，它就不会那么特殊，因此您的代码需要在其中添加特殊的自定义逻辑。

在开发过程中，我建议只在代码中添加少量注释。毕竟，代码应该是自文档化的，不是吗？

一定要充分利用外部库和所有可用的新语言功能 - 特别是当您的同事还不熟悉或使用这些功能时。

嵌套三元表达式和正则表达式是确保只有优秀的开发人员才能接触代码行的可靠方法。

请记住：在其他人注意到并开始提出问题之前，您只有有限的时间来发展新生的上帝对象，因此请充分利用这段时间来达到关键的规模和复杂性。

捍卫尚处于起步阶段的Codethulhu

当有人质疑创建一个庞大而复杂的类时，你可以声称它遵循了单一职责原则 (SRP)，即用一个文件解决业务问题。如果别人告诉你这不符合 SRP 的原则，你就说自己开会迟到了，然后突然跑开。

如果人们继续挑战你，那么是时候提高态度了。

表现出被冒犯和冒犯的样子，然后要求他们当场解释你正在解决的问题的全部复杂性。如果他们没有充分描述问题或解决方案，指出这一点并终止对话。如果他们确实说对了，那就寻找他们没有提到的技术细节和细节。例如验证、持久化、线程、模糊的边缘情况等等。

关于线程这个话题，如果你声称你的复杂性是以一种可以提高性能的方式构建的，那么你就可以避免很多问题（如果这确实是真的，那就加分了）。

当人们说需要对你的代码进行全面的代码审查时，这是一个陷阱。你可以说你的日程安排太紧，没时间，而且代码审查只适合糟糕的开发人员。你的代码很好，他们应该知道这一点，因为他们雇佣了你，而且你一直在解决关键问题。

如果人们继续向您提出有关代码的问题，那么一个很好的策略是让另一个开发人员有机会在没有帮助的情况下处理该类并惨遭失败，而您只需立即介入并挽救局面即可。

最后，如果您的对象仍然引起其他开发人员的愤怒，您可以将其重命名为以单词 、 或 结尾的名称，Facade因为Controller人们Service似乎并不介意这样的类随着时间的推移变得越来越大。

混乱，又称工作保障

迟早，你的上帝对象会给质量保证、你的开发人员同事以及潜在的生产带来混乱。

别担心，这是正常的。

就像月度俱乐部的果冻一样，上帝物品是一份持续赠送的礼物。

当然，这些对象给你带来的一些工作会非常复杂，而且可能很紧急，但这些工作正在向你涌来，这正是你想要的。

您已经建立了声誉，成为唯一能够处理 Codethulhu 中存在的复杂状态管理、线程和操作顺序问题的人，因此您与它的命运息息相关。

希望此时 Codethulhu 对业务的持续运营至关重要，否则您和它可能会在下周就倒闭了。

如果Codethulhu已经站稳脚跟，那么恭喜你白手起家，赢得了这份宝贵的任期。当然，你可能无法晋升，因为组织担心除了你之外没人能维护好这头“巨兽”，但为了保住工作，这点代价也算小。

只要留意任何改革派建筑师或任何在过去一个月内读过或写过任何包含“重构”一词的资料的人即可。

警惕那些可以杀死Codethulhu的人

时不时地，就会有某个身披闪亮盔甲的骑士驾临，试图斩杀你的怪物。通常情况下，这没什么问题，因为 Codethulhu 会吞噬那些水平较差的开发者的理智。

然而，有时合适的人选会具备软件架构和模式方面的知识、“改进”代码库的愿望，以及实现这一目标的技能和意志力。

当这种情况发生时，情况非常糟糕，你应该开始寻找逃生出口。

通常，这个人会大声宣扬并向开发组织宣扬将代码重构为通用模式、单一责任原则（SRP）、提取辅助类、优先使用组合而不是继承以及其他类似的废话。

他们的书桌或书架上可能有这样的书：

• 《有效地使用遗留代码》，作者：Michael Feathers
• 重构，作者：Martin Fowler
• 测试驱动开发，作者：Kent Beck
• 《代码整洁之道》（作者：罗伯特·C·马丁）
• 软件设计 X-Rays，作者：Adam Tornhill

小心他们成功修改 Codethulhu，或者更糟的是，围绕它进行测试。如果发生这种情况，可能是时候寻找另一个需要新“上帝对象”的组织了。

这是个笑话

所以，事实证明，这篇文章是讽刺性的。

尽管如此，其中一些错误还是让我深刻地体会到了我在职业生涯早期所犯的一些错误。

我当时正在为一款 Windows 桌面应用程序开发一个复杂且非标准的用户界面控件。当时我的职业生涯才刚刚开始 6 个月，但那时我已经编码了大约 15 年了。

在一个季度的时间里，我制作了一个非常复杂的用户界面控制类，它管理（除其他事项外）：

• 动画片
• 选择
• 重点
• 数据虚拟化
• UI虚拟化
• 事件传播
• 键盘导航

随着每个新版本的发布，我们都会添加它需要做的事情，因此这个类变得越来越大，直到单个文件中的代码行数达到近 4,000 行。

这些功能不可避免地开始相互冲突，在我们意识到之前，我们手中就有了一个拥有我们代码库的上帝对象，并导致了难以复制和修复的混乱和不可预测的错误。

杀死Codethulhu

大多数人不会故意陷入上帝物体场景，但如果你这样做了，一切也不会丢失。

这里有一些可以帮助您摆脱困境的高级想法：

• 单一职责原则是你的朋友。如果你在开发类或方法时牢记这一点，你就能默认避免这种反模式。
• 将逻辑提取到辅助类有助于通过将非核心职责转移到其他对象来简化代码。
• 在对类进行任何修改之前，尽可能多地进行固定测试。您需要捕捉当前的行为，并明确了解它是否正在发生变化。
• 不要害怕向管理层沟通技术债务，并讨论你对当前代码库的担忧。他们很可能会欣赏你的诚实和开放，并希望了解风险代码的缓解措施。

祝你好运，希望 Codethulhu 永远不会困扰你的代码库。

Unsplash上的封面照片由Yosh Ginsu拍摄

上帝反对：如何召唤 Codethulhu一文首先出现在Kill All Defects上。