一、找个非常复杂的问题云栖号：https://yqh.aliyun.com
第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！
非常好！你选择了用寄生的复杂性增长感染代码库，产生无数小时只有你才能做的复杂工作（即“工作安全感”）。
神物就是一种产生高复杂性的好方法，只有非常了解它的开发者才能在不触怒质量保证的前提下一探究竟。
神物也有些别名，比如“Codethulhu”，“初级开发者的克星”和“质量保证分析员”。
首先得解决一个问题。我知道这篇文章的任务是增加复杂性和保住工作，解决问题不是核心。但是，请耐心听我说完。
如果代码解决的问题不够特殊，不够重要，未来的开发者很可能会避开它，甚至完全弃之脑后。
所以，我们要找的问题：
· 需要高度的技巧和思维能力来解决；
· 不能太好懂或不需要花时间想明白；
· 和很多其他复杂系统和流程交互，呈现一些它们的复杂性；
· 需要新特性，有潜力增长并扩展复杂性；
· 没有现成的简单替代品。
如果没想到什么的话，有两种选择：等待新的复杂特性到来，或者从代码库的现有层提取一个大文件进行展开。
可以考虑的对象：
· 通信/web服务层；
· 自定义用户界面控件；
· 数据访问层；
· 对象序列化/反序列化逻辑；
· 公共服务(业务逻辑)层。
当然，业务问题是所有问题中最特殊的，但是如果你的组织不愿提供足够大的，能扩展到Codethulhu规模的特性，那以上随便哪个都可以。
二、诞生Codethulhu
一旦找到机会发现了大问题，就到了最复杂的阶段。读下去之前先给自己打个气吧。
为了让神物能够存活并进入数据库，它必须可行。也就是说，首先，要解决或大部分解决工作中（或者所发现）的所有问题。
所以要先埋头苦干了。必须工作非常认真，才能在之后解决大特性会产生的问题，更别说一个故意在大文件中制造的大问题。
三、扩大感染然而，庞大的神物并不会一夜长大，我们想培养的巨兽需要时间和投入才能茁壮成长。刻意培育不是必需，但肯定会有帮助。
记住：将尽可能多的逻辑放到同一类里。
如果问题适用于对象，那就在对象中解决。比如：
· 序列化
· 反序列化
· 数据访问
· 验证
· 解析
· 格式化
· 记录日志
· 线程管理
· 状态管理
· 缓存
· Web服务调用
这些都可以在神物中解决。
切记如下口诀:
你的问题很特殊，解决的问题很复杂，所以和其他代码不同。如果其他代码也在这个问题中存在，它便不再特殊了。该代码内部需要特殊定制的逻辑。
在开发时，建议只在代码中添加少量注释。毕竟代码应该自动记录，对吧？
一定要利用外部库和可使用的每一种新的语言特性——特别是同事不熟悉的特性。
嵌套的三元表达式和正则表达式可有效确保只有特殊开发人员才能接触到代码。
记住：在别人发现并提问之前，你只有有限的时间来培育出神物，所以好好利用这段时间来让它达到庞大的规模和极高的复杂性。
如果创建大型复杂类时被质疑的话，就说它遵循单一责任原则（SRP），在单个文件中解决业务问题。
如果SRP理由仍被质疑，那就假借开会迟到跑掉。如果质疑仍在继续，那就是时候改变自己的态度了。
你要表现得好像受到了侮辱和冒犯，然后要求对方解释现场解决的问题的全部复杂性。如果对方没办法充分描述问题或者解决方案，就地反击并终止对话。
如果对方真的说对了，那就找没讲到的技术和其他问题。比如验证、持久性、线程、模糊边缘案例等。
讲到线程的时候，声称自己代码的复杂性是以一种提高性能的方式构造的效果会更好（如果是真的那就更好了）。
如果对方说要对这个代码进行完整代码检查，那就是在设陷阱。你就说日程太紧，不允许这样做，而且代码检查只针对垃圾开发人员。他们应该知道你编的代码很棒，所以才会录用你，才能让你继续解决关键问题。
如果还有人继续纠缠关于代码的问题，那也有个好办法。给别的开发人员一个机会，让他在没有帮助的情况下面对这个代码，最后彻底失败。这时你就能突然出现，大显身手。
最后，如果这个玩意儿还是会引起其他开发人员的不满，那就将它重命名，用外观、控制器或服务等词结尾。大家好像都不在乎这类数据不断增长。
你的神物迟早会在质量保证、程序员同事和潜在的生产时产生混乱。
别担心，这很正常。
神物就像教堂每月派送的果冻一样，是不断奉献的礼物。
当然，一些随之而来的工作会非常复杂紧急，但这就是你期待的结果。
作为唯一能够处理Codethulhu中存在的复杂状态管理、线程和操作顺序问题的人，你的名誉水涨船高，你的命运和它息息相关。
希望到目前为止，Codethulhu对企业的持续运营至关重要，否则你和它都会在下周前滚蛋。
如果Codethulhu已经根深蒂固，那么恭喜你，获得了自己赢来的长期工作。
当然，你没办法晋升，因为公司害怕除了你没人能管住这个野兽，但这是只是保住饭碗的小代价。
只是要小心最近有没有架构师或任何人阅读或发表了任何与“重构”有关的东西。
穿着闪亮盔甲的骑士总会时不时赶来杀死怪物。这通常没什么问题，因为Codethulhu可以让初级开发人员失去理智。
然而，有时也有人拥有软件体系结构和模式的混元一体的知识，对“改进”代码库的渴望，以及实现杀怪的技能和纯粹的意志力。
这种人真的出现时，那就糟糕了。赶紧开始找后路吧。
一般来说，这种人会大喊大叫，向开发公司大讲重构代码为通用模式、单一责任原则（SRP）、提取助手类，更倾向于组合而不是继承以及其他诸如此类的废话。
他们的桌上可能会有这些书：
· 《有效处理遗留代码》，Michael Feathers著
· 《重构》，Martin Fowler著
· 《测试驱动开发》，Kent Beck著
· 《干净的代码》，Robert C Martin著
· 《软件设计全解析》，Adam Tornhill著
要小心他们成功修改Codethulhu，或者更糟糕，对它进行测试。如果真的发生，事情败露，那可能是时候换个公司供奉神物了。
七、以上都是玩笑
所以，综上所述，本文是含有讽刺意味的。
然而，它和我早期职业生涯犯的一些错误很像。
我当时在为Windows桌面应用程序开发一个复杂的非标准的用户界面控制。虽然只工作了六个月，但那时我已经编了大约15年代码。
在工作进行到四分之一左右时，我创建了一个非常复杂的用户界面控件类，其中管理了：
· 动画
· 选定
· 焦点
· 数据虚拟化
· UI虚拟化
· 事件传播
· 键盘导航
每个新版本推出的时候，我们都会在里面加入需要的新特性，这个类便不断增长，甚至达到单一文件中有4000行代码。
这些特性不可避免地开始相互碰撞。在问题发生前，我们并不知道有一个神物在控制手中的代码库，之后导致了混乱和无法预测的错误，也很难复制和修复。
八、杀死Codethulhu
大多数人不会故意创造神物，但即使这样做了，里面的一切也都不会丢失。
以下有一些带你走出困境的高阶方法：
· SRP是你忠实的朋友。如果在开发类或方法时牢记这一点，就会默认避免这种反模式。
· 将非核心责任转移到其他对象以将逻辑提取到辅助类，这样有助于简化代码。
· 在对类进行任何修改之前，尽可能多地进行固定测试。这样可以捕获当前行为并知道明显变化。
· 不要害怕和管理层沟通技术债务并讨论对当前代码库的关注。领导很可能会欣赏诚实开放的员工，并希望获得有关缓解风险代码的最新信息。
提高警惕，希望你的代码库永远不会遇到Codethulhu。
最后，祝你好运！
云栖号：https://yqh.aliyun.com
第一手的上云资讯，不同行业精选的上云企业案例库，基于众多成功案例萃取而成的最佳实践，助力您上云决策！
