我在阅读[What to do about a 11000 lines C++ source file?]帖子时有一种dejavu的感觉，但由于我没有权力采取行动，我认为我不能自行采取行动。所以我认为第一步是说服组织中的人们认为大块代码是坏的。
我有类似的情况，其中有一个单独的类，包含11975行代码，每次有新功能时，这个类很有可能变得越来越大。
答案 0 :(得分：22)
你有我的同情心。任何巨大的类都不可避免地会破坏Single Responsibility Principle，使其难以维持。
我最好的建议是以身作则：
与遗留代码相比，您的代码将像灯塔一样闪耀，您的团队将了解哪些代码更易于维护。
答案 1 :(得分：11)
11975（或者它已经是12000 :)）类实现的行。这不好吗？ Cerainly看起来如此。但...
这取决于。通常，实现Mediator模式或Facade模式的类往往非常大。它们具有非常复杂的路由/通信协议。类似“上帝”的课程也往往非常庞大和单一。简而言之，A类实际上可能很大，但可能可能不是问题。
因此，不要将LOC作为参数集中在一起，而是专注于类的功能/设计。该课程违反了单一责任原则吗？如果一个类真的很大，那么单独的LOC不能成为唯一的决定因素。查看其他指标，例如循环复杂性。
但是，如果您得出结论认为这在您的项目背景下非常糟糕，那么您必须有充分的理由说服相关的利益相关者。例如，
一个。这个班有很多错误吗？
湾这个类错误修复总是会引入回归缺陷吗？ （高耦合，低内聚？）
℃。在这个课程中需要多长时间修复缺陷？这与其他模块相比如何？
d。为此模块生成一些UML图，以说明重要问题（例如耦合）。
即阅读指标/咨询您的质量/指标/ QA团队并生成足够的数据点。 OOAD指标的一个例子是here，但我确信有很多。
编辑2（一些小的改动）
F。从您控制范围内的一些关键利益相关者那里获得初步支持。接下来，得到一个能够很好地呈现这些事实的人！在这个阶段我看到很多事情都失败了！。
祝你好运！答案 2 :(得分：6)
告诉他们在一分钟内总结一下班级所代表的内容。
答案 3 :(得分：3)
如果这个类包含许多较小的方法，并且这些方法实际上属于类，即它们彼此之间以及类之间具有内聚性，那么这不一定是坏的。
一个类很大的事实并不会使它自动变坏。
更重要的是避免所谓的“上帝阶级”，它包含许多彼此之间或阶级本身没有概念关系的方法。
保持单个方法的大小也值得关注，因为大多数开发人员需要一次将整个方法“加载”到他们的大脑中，而不是整个类。因此，方法越简洁，开发人员就越容易维护。
您应该收集有关可以追溯到此类中的代码的支持问题数量的指标。此外，与其他较小的类相比，开发人员花费多长时间对此类进行更改？获得这些指标后，您可以更好地向管理层解释为什么这么大的类很糟糕。
在具有少量大型方法的大型类的情况下，我将使用Martin Fowlers book中描述的重构技术，以及单元测试以确保不会引入新的错误。
一旦你将一个巨大的方法重构为一些简单易懂的方法并成功进行单元测试，只需向同事证明这一点。
此时，如果您的同事不同意或无法看到重构代码的可理解性和可维护性得到普遍改善，那么您正在处理政治/人格问题。在这种情况下，如果你想继续在这样的环境中工作，那取决于你。
答案 4 :(得分：1)
拥有一个庞大的班级也不错。如果程序员可以管理和理解它，那么它就是一个完美的类。如果程序员在尝试更改或添加某些内容时完全丢失，那就很糟糕。
通过编程，这完全取决于偏好。如果他们更愿意拥有11975行代码，并且可以管理它，那么这就是他们的选择。
但是，这通常很糟糕。
答案 5 :(得分：1)
这是我最初的反应：
这里没有任何建议，除了重构你能做什么。查找违反D-R-Y的任何功能，然后将其擦洗干净。
答案 6 :(得分：1)
说服任何人改变现有的实施（特别是“如果它有效”）并不容易。
我首先要求对手做一些琐碎的任务（根据我对这些极端类的经验，我相信没有足够大的方法），比如在一个巨大的方法中添加一些东西。它应该教给他们一个教训：找到合适的位置将是非常痛苦的。然后，你可以问：“想象你支持这个课程，这将是一件容易的事吗？”。
您可以尝试不同的方法，但它可能会失败：请他们为此代码编写单元测试。或者只是让他们想到任何......
答案 7 :(得分：1)
基本上那些人没有oops的知识？在开始项目之前做OOAD是避免这种情况的更好的想法，根据我的经验，我可以说每个程序员都不知道oops，所以显然他们不能编写更好的代码。
这就是程序员和分析师的差异 -