我正在维护一个 40K 行长的 Java 类..有问题吗？
这可能是一个导致删除的主观问题，但我真的很想得到一些反馈。
最近，我转到另一个非常大的企业项目，在那里我担任开发人员。我惊讶地发现项目中的大多数类的长度都在 8K 到 50K 行之间，而方法的长度则为 1K 到 8K 行。它主要是处理数据库表和数据管理的业务逻辑，充满了处理用例的条件语句。
这么大的类在大型企业系统中常见吗？我意识到，如果不查看代码，很难做出决定，但是您曾经在具有如此大的类的系统上工作过吗？
This may be a subjective question leading to deletion but I would really like some feedback.
Recently, I moved to another very large enterprise project where I work as a developer. I was aghast to find most classes in the project are anywhere from 8K to 50K lines long with methods that are 1K to 8K lines long. It's mostly business logic dealing with DB tables and data management, full of conditional statements to handle the use cases.
Are classes this large common in large enterprise systems? I realize without looking at the code it's hard to make a determination, but have you ever worked on a system with classes this large?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
以下是 JDK 6 中 10 个最大的类（按 7209 个 .java 文件的行数计算）。这些类包含大量注释，这些注释可能比代码还要长。
我同意一张打印页对于一种方法来说已经足够长了。恕我直言，实际上不应该需要超过 10K 行的类。
Here are the ten largest class in the JDK 6 by line count of 7209 .java files. These classes include significant amount of comments which could be longer than the code.
I would agree one printed page is long enough for a method. There really should not be a need for classes over 10K lines long IMHO.
这绝对是不对的。方法包含的代码不应多于单个工作单元的足够量。类所包含的方法不应多于与类实例的状态相关的方法。
这太像上帝对象反模式了。我个人会放弃该项目并寻找另一个。
This is definitely not right. A method should not contain more code than sufficient for a single unit of work. A class should not contain more methods than the ones related to the state of the class' instance.
This is too much like God Object anti-pattern. I would personally drop the project and look for another.
不看代码，实际上仍然很容易做出决定。一个类永远不应该有 40K 行，一个方法也不应该有 1K。通常，如果我无法在一张纸上打印出方法并同时看到开始和结束括号，我会找到一种方法将其拆分。
我想问一下，他们到底是使用 OOP 原则，还是尝试将 Java 更多地用作函数式或过程式语言？我无法想象一个真正的 OOP 项目有 40K 行的类。
Without looking at the code, it actually remains quite easy to make a determination. Never should a class be 40K lines, and never should a method be even 1K. Typically, if I can't print out a method on a piece of paper and see both the beginning and end brackets, I find a way to split it up.
Might I ask, are they using OOP principles at all, or are they trying to use Java more as a functional or procedural language? I can't imagine a truly OOP project having a 40K line class.
哦，我认为这是一个可怕的迹象，而且我不必看代码就能这么说。听起来需要大量的重构工作。
让我猜一下 - 您也没有针对所编写的系统进行单元测试。我对你表示同情。
Oh, I think this a terrible sign, and I don't have to look at the code to say so. Sounds like a massive refactoring effort is needed.
Let me guess - you have no unit tests for the system as written, either. You have my sympathy.
除了其他答案中描述的软件维护问题外，还要注意编译的 Java 方法不得超过 64k 字节的技术限制。 （对应的代码行数取决于代码行本身。）
http: //www.databasesandlife.com/java-method-64k-limit/
In addition to software maintenance issues described in other answers, be careful of the technical limit that a compiled Java method may not exceed 64k bytes. (How many lines of code that will correspond to will depend on the lines themselves.)
http://www.databasesandlife.com/java-method-64k-limit/
在我 12 年的 Java 开发生涯中，我可以诚实地说，这很不寻常。
实际上;在超过 25 年的开发过程中，我从未在任何语言中遇到过如此大小的文件或类。
破解重构工具！
In 12 years of Java development I can honestly say that this is unusual.
In fact; I have never come across files or classes of that size in any language in over 25 years of development.
Crack out the refactoring tools!
需要注意的一点是
行、代码行和语句之间的区别。如果您使用声纳等工具分析您的项目，您可以轻松看出它们之间的差异。然而，无论具体衡量标准如何，4 万行业务代码都是可怕的。
在我开发的一个企业应用的业务模块中，最多的是444行代码。这是针对相当大的服务。大多数服务类的代码都在 200 到 100 行之间。在我们的情况下，实体（模型对象）大多在 40 到 100 个位置之间。
在同一应用程序的另一部分中，我们有一个包含 1224 行代码的类（总共 2477 行，706 条语句）。由于其规模，这个班级在团队中几乎普遍受到憎恨。它被认为是臃肿、复杂并且做得太多。
现在，如果整个团队都对一个总共只有 2477 行的类进行思考，这可能会让您了解 40k 行的类是多么令人厌恶。
A small thing to pay attention to is the difference between
lines,lines of code, andstatements. If you analyze your project with e.g. Sonar you can easily see the difference between those.Nevertheless, whatever the exact measure, 40k lines of business code is hideous.
In the business module of an enterprise application I develop, the highest number is 444 lines of code. This is for a rather large Service. Most Service classes are between 200 and 100 lines of code. Entities (model objects) are in our situation mostly between 40 and 100 loc.
In another part of this same application we have one class that is 1224 lines of code (2477 lines total, 706 statements). This class is almost universally hated within the team because of its size. It's perceived as bloated, complicated and doing way too much.
Now if an entire team thinks this about a class that's only 2477 lines total, this may give you some perspective about what kind of abomination a 40k lines class is.
当我读到这篇文章时，警钟开始响起：
如果此代码不在数据层中并且没有关于如何访问数据库的抽象，那么就会出现问题。我还感觉其中一些方法与找到它们的类没有直接关系。关于条件语句和用例的评论听起来也不正确。我会回应达菲莫的评论，即需要进行一些重构。
An alarm bell started going off when I read through this :
If this code isn't in the data layer and there is no abstraction with respect to how the database is accessed, something is wrong. I also have the feeling that some of these methods aren't directly related to the classes where they are found. The comment about conditional statements and use cases doesn't sound right either. I'll echo duffymo's comment that some refactoring would be needed.
我认为你的惊愕是有资格的:)我无法想象该程序是正确的 OOP 化的。类的分类有点困难，但方法很简单：每个方法 1 个行为（这不是规则，但应该如此）。行为不可能接近 1k 行代码。至少，就我的想象力而言。
另一方面，类可以代表很多东西，但它们应该代表一些东西。如果很难判断该类代表什么，那么就有问题了。
现在，我想你们已经很清楚这些概念了，而我正在向唱诗班宣讲。所以，我就假装我没有离题，直接回答你的问题：
是的。非常不幸的是，大型企业项目的代码如此懒惰是非常常见的。我曾经参与过几乎同样大的项目（你的项目可以拍摄我在水中看到的任何东西），我的第一个倾向是开始将事物分解为逻辑组件，特别是在我打算进行更改的地方。我受不了那种意大利面，太烦人了。
I think your aghastness is qualified :) I can't imagine that the program is properly OOPified. Classes are a bit tougher to classify, but methods are easy: 1 behavior per method (that's not a rule, but it should be). Behaviors can't possibly be even close 1k lines of code. At least, as far as my imagination will take me.
Classes, on the other hand, can represent many things but they should represent something. If it is difficult to tell what the class represents, then you have a problem.
Now, I half imagine that you are well aware of these concepts and I'm preaching to the choir. So, I'll just pretend like I didn't go off on a tangent there and answer your question directly:
Yes. Very unfortunately, it is remarkably common for large enterprise projects to have code that lazy. I have worked on projects almost as large (yours shoots anything I've seen out of the water) and my first tendency is to start breaking things up into logical components, particularly in places where I intend on making changes. I can't handle that kind spaghetti, it's too irritating.
作为一名年轻的程序员，我仍然记得我的老师告诉我们在编写代码之前要分解大的函数并进行良好的面向对象设计。
因此，除非你的设计中有一个真正充分的理由强加 40k 行（我强烈怀疑），否则你已经有了答案：你的类太大了。
我会引用我的妻子（她是化学家，不会编程）的话：“40k 行代码，确实有问题！”
我有朋友在他们的公司里接手了一些非常古老的项目，从一个程序员到最后都被扔掉了，我们都同意，一个这样大小的类仅仅意味着：
- 补丁和修复：人们必须在这里做一些小的改变在那里，不想/没有时间正确地做这件事。
在运行时，该代码可能没有任何问题，一切正常，但当您想要进行任何形式的修改时，通常会出现问题：
它需要很长时间才能找到任何东西
当出现错误时，您无法轻松地指出它
......
总之，我会坐下来重新思考项目的面向对象设计并进行重组（至少要从 1k ~ 5k 行课程开始），我知道这样做很烦人，但从长远来看通常会更好
As a young programmer I still remember my teacher telling us to break up big functions and work on a good OO design before writing code.
So unless there is a REALLY good reason in your design to impose 40k lines (which I strongly doubt) then you already have your answer : your class is too big.
I will quote my wife (who is chemist and doesn't program) : "40k lines of code, there is something really wrong!"
I've had friends take up projects in their companies that were really old, tossed from one programmer to the over and what we all agreed on is that a class that size simply means:
-patch and fix : people had to do minor changes here and there and didn't want to/ didn't have the time to do it corretly.
at runtime there might not be any problems with that code, everything works, but usually problems occure when you want to do any form of modifications:
it takes ages to find anything
when there is a bug you can't pin point it easily
...
In conclusion I would sit down rethink the oo design of your project and restructure (at least into 1k ~ 5k lines classes to start with), I know its annoying to do bu usually on the long run its better
50K 行代码？我认为 KLOC 是项目大小的度量，而不是文件大小。这就像我们的整个代码库（包括测试）。
我正在使用 JavaScript，所以它不能直接比较，但我们只有少数文件超过 500 行长 - 这些是问题很严重的文件。
50K lines of code? I thought KLOC was a metric of project size, not file size. That's like our whole codebase (including tests).
I'm working with JavaScript, so it's not directly comparable, but we only have few files that are over 500 lines long - and these are the highly problematic ones.
我知道当我在尝试弄清楚代码的作用和方式时遇到问题时，某些代码部分需要分解。或者如果它比屏幕截图大。
通常，如果它让我感觉不好，我就会重构它。我不喜欢感觉不好:-(
我怀疑代码失去了控制，因为管理层只想完成错误修复/功能而不做其他事情，并且一点一点地慢慢变得更糟。
重构代码以使程序员的工作更轻松是管理层昨天总是希望修复错误/功能:-(
而且，一个可以运行的程序显然比坏掉的程序要好，并且在没有单元测试的情况下分解这么大的代码将会导致灾难。所有的测试都必须在接触代码之前进行，这也是管理层不允许这样做的另一个原因。
I know some section of code needs breaking up when I have problems trying figure out what it does and how. Or if its larger than a screen-shot.
Typically I refactor it if it makes me feel bad. I don't like feeling bad :-(
I suspect the code got out of control because the management just wanted bugfixes/features done and nothing else, and bit by bit it slowly got worse.
Refactoring the code to make the programmers job easier was probably not very high on their list of priorities. The management always want their bugfixes/features yesterday :-(
Also a working program is obviously better than one thats broke, and breaking up code that large without unit-tests would end in disaster. So all the tests would have to be made before touching the code. Yet another reason management wouldn't allow it.