然后是一个绿灯，为了清理环境，有人编写了GameManager。可能要保留一堆GameState，也许要存储一些GameObject，实际上并没有什么大的。可爱的小经理。
你知道，当我读这篇文章的时候，我的脑海里几乎没有警报声。名称为“ GameManager”的对象永远不会变得可爱或很小。有人这样做是为了清理代码？以前看起来像什么？好吧，开个玩笑：一个班级的名称应该清楚地表明班级的工作，这应该是一回事（又名：单一责任原则）。
另外，您可能最终仍会得到像GameManager这样的对象，但是显然，它存在于非常高的层次上，它应该与高层次的任务有关。维护游戏对象目录？也许。促进游戏对象之间的交流？当然。计算对象之间的碰撞？没有！这也就是为什么经理这个名字不被接受的原因-它太宽泛了，并且在该旗帜下允许大量滥用。
关于类大小的快速经验法则：如果每个类遇到数百行代码，则开始出现问题。不必过于狂热，任何超过300 LOC的代码对我来说都是一种代码气味，如果您超过1000，警告铃应该响起。通过相信某种方式比4种结构良好的类（每类250条）更容易理解1000行代码，您正在自欺欺人。
当时间成为问题时，就无法编写单独的类，也不能将此巨型管理器拆分为子管理器。
我认为是这种情况，只是因为问题被允许传播到一切都是一团糟。重构的实践确实是您要寻找的- 您需要以很小的增量不断改进代码的设计。
您有什么建议可以防止这种情况发生？
问题不是技术问题，因此您不应该为此寻求技术修复。问题是这样的：您的团队中有一种趋势是创建整体的代码段，并且相信这样的代码在中期/长期内会以某种方式受益。似乎团队也缺乏强大的架构领导力，他们无法控制游戏的架构（或者至少，这个人太忙于执行此任务）。基本上，唯一的出路是让团队成员认识到这种想法是错误的。它没有人支持。产品的质量会变差，团队只会花更多的时间来修理东西。
好消息是，编写干净的代码所带来的直接，实在的好处是如此之大，以至于几乎所有开发人员都很快意识到了自己的好处。说服团队以这种方式工作一段时间，结果将完成。
困难的部分是，要对构成错误代码的内容（以及快速提出更好的设计的才能）产生一种感觉，这是在开发中要学习的较难技能之一。我的建议取决于希望您的团队中有足够高级的人可以做到这一点-这样说服人们会容易得多。
编辑-更多信息：
总的来说，我认为您的问题不仅限于游戏开发。从本质上讲，这是一个软件工程问题，因此，我对此有何评论。我不确定游戏开发行业的性质，它是否比其他类型的开发更具结果性和针对最终期限。
但是，专门针对游戏开发，在StackOverflow上有关“特别是游戏架构”技巧的问题的公认答案说：
遵循面向对象设计的坚实原则 ....
这基本上就是我所说的。当我承受压力时，我也发现自己在编写大量代码，但是我已经把它钻到脑海中，那就是技术债务。对我来说，行之有效的方法是花一天的前半部分（或四分之三）来制作大量中等质量的代码，然后坐下来思考一会儿。在我的头上或在纸/白板上做一些关于如何改善代码的设计。通常，我会注意到重复的代码，并且能够通过分解代码来减少代码的总行数，同时还能提高可读性。这次投资很快就收回了投资，以至于称其为“投资”听起来很愚蠢-如果我允许它继续下去，我经常会捡拾可能浪费了我半天（一周后）的错误。
- 在编写代码的同一天修复问题。
- 您会很高兴在几个小时内完成。
真正相信上述困难；我之所以能够为自己的工作做这件事，只是因为我一遍又一遍地体验到了效果。即便如此，当我可能会提出更多建议时，我仍然很难为修正代码辩解...所以我绝对知道您来自哪里。不幸的是，这个建议可能太笼统了，不容易做到。我对此深信不疑！:)
要回答您的特定示例：
Bob叔叔的Clean Code总结了高质量的代码是多么出色。我碰巧同意几乎所有内容。因此，当我想到您的30000 LOC经理班级示例时，我真的不同意“充分理由”部分。我不想冒犯他人，但以这种方式会导致问题。没有充分的理由在一个文件中包含这么多的代码-这几乎是1000页文本！局域性的任何好处（执行速度或设计“简单性”）将立即被开发人员完全束之高阁，他们试图解决这种怪异，甚至在我们讨论合并之前，都将使其无效。
如果您不相信，我最好的建议是拿一本上面的书，然后仔细阅读。将这种类型的思想应用到人们自愿创建干净，易于解释的代码中，该代码结构良好。