Я поддерживаю класс Java длиной 40 Кб .. проблема?

Question

Это может быть субъективный вопрос, приводящий к удалению, но мне бы очень хотелось получить отзыв.

Недавно я перешел к другому очень крупному корпоративному проекту, где я работаю разработчиком. Я был ошеломлен, обнаружив, что большинство классов в проекте имеют длину от 8К до 50К строк с методами длиной от 1К до 8К. В основном это бизнес-логика, связанная с таблицами БД и управлением данными, полными условных операторов для обработки сценариев использования.

Являются ли такие классы распространенными в крупных корпоративных системах? Я понимаю, что, не глядя на код, сложно определить, но работали ли вы когда-нибудь над системой с такими большими классами?

Answer 1

Вот десять самых больших классов в JDK 6 по количеству строк в 7209 .java-файлах. Эти классы содержат значительное количество комментариев, которые могут быть длиннее, чем код.

4495 ./javax/sql/rowset/BaseRowSet.java
4649 ./java/awt/Container.java
5025 ./javax/swing/text/JTextComponent.java
5246 ./java/util/regex/Pattern.java
5316 ./javax/swing/JTree.java
5469 ./java/lang/Character.java
5473 ./javax/swing/JComponent.java
9063 ./com/sun/corba/se/impl/logging/ORBUtilSystemException.java
9595 ./javax/swing/JTable.java
9982 ./java/awt/Component.java

Я бы согласился, что одна напечатанная страница достаточно длинна для метода. ИМХО, действительно, не необходимо для классов длиной более 10 тыс. Строк.

Answer 2

Это определенно не правильно.Метод не должен содержать больше кода, чем достаточно для одной единицы работы.Класс не должен содержать больше методов, чем те, которые связаны с состоянием экземпляра класса.

Это слишком похоже на анти-образец объекта Бога .Я бы лично бросил проект и искал другой.

Answer 3

Даже не взглянув на код, на самом деле определить его довольно просто. Никогда класс не должен содержать 40К строк, а метод не должен быть хотя бы 1КБ. Обычно, если я не могу распечатать метод на листе бумаги и вижу начальные и конечные скобки, я найду способ разделить его на части.

Могу ли я спросить, используют ли они принципы ООП вообще или они пытаются использовать Java больше как функциональный или процедурный язык? Я не могу представить себе действительно ООП-проект с классом строк 40К.

Answer 4

О, я думаю, что это ужасный знак, и мне не нужно смотреть на код, чтобы сказать это.Звучит так, как будто нужны огромные усилия по рефакторингу.

Позвольте мне угадать - у вас нет написанных модульных тестов для системы.Вы имеете мое сочувствие.

Answer 5

В дополнение к проблемам обслуживания программного обеспечения, описанным в других ответах, будьте осторожны с техническим ограничением, что скомпилированный метод Java не может превышать 64 Кбайт . (Сколько строк кода будет соответствовать, зависит от самих строк.)

http://www.databasesandlife.com/java-method-64k-limit/

Answer 6

За 12 лет разработки Java я могу честно сказать, что это необычно.

Фактически; За 25 лет разработки я никогда не сталкивался с файлами или классами такого размера на любом языке.

Взломайте инструменты рефакторинга!

Answer 7

Небольшая вещь, на которую следует обратить внимание, это разница между lines, lines of code и statements. Если вы анализируете свой проект, например, Сонар, вы легко можете увидеть разницу между ними.

Тем не менее, какой бы ни была точная мера, 40 000 строк бизнес-кода отвратительно .

В бизнес-модуле корпоративного приложения, которое я разрабатываю, наибольшее число составляет 444 строки кода. Это для довольно большого сервиса. Большинство классов обслуживания содержат от 200 до 100 строк кода. Сущности (объекты модели) в нашей ситуации находятся в основном между 40 и 100 loc.

В другой части этого же приложения у нас есть один класс, который составляет 1224 строки кода (всего 2477 строк, 706 операторов). Этот класс почти повсеместно ненавидят в команде из-за его размера. Это воспринимается как раздутый, сложный и делает слишком много.

Теперь, если вся команда думает так о классе, который всего 2477 строк, это может дать вам некоторое представление о том, какого рода мерзость класс 40k линий.

Answer 8

Когда я прочитал это, прозвучал сигнал тревоги:

В основном это бизнес-логика, связанная с таблицами БД и управлением данными, полная условных операторов для обработки вариантов использования.1005 *

Если этот код отсутствует на уровне данных и нет абстракции в отношении доступа к базе данных, значит что-то не так.У меня также есть ощущение, что некоторые из этих методов не имеют прямого отношения к классам, в которых они находятся.Комментарий об условных утверждениях и вариантах использования также не звучит правильно.Я повторю комментарий Даффимо о необходимости рефакторинга.

Answer 9

Я думаю, что ваше ужасное состояние квалифицировано :) Я не могу представить, что программа должным образом исправлена. Классы немного сложнее классифицировать, но методы просты: 1 поведение на метод (это не правило, но так и должно быть). Поведение не может быть даже близко 1k строк кода. По крайней мере, насколько мое воображение унесет меня.

Классы, с другой стороны, могут представлять многие вещи, но они должны представлять что-то . Если трудно сказать, что представляет класс, то у вас есть проблема.

Теперь я наполовину представляю, что вы хорошо знакомы с этими понятиями, и я проповедую хору. Итак, я просто сделаю вид, будто не пошел по касательной и прямо отвечу на ваш вопрос:

Да. К сожалению, для крупных корпоративных проектов характерно иметь ленивый код. Я работал над проектами почти такими же большими (ваш снимает все, что я видел из воды), и моя первая тенденция - начать разбивать вещи на логические компоненты, особенно там, где я собираюсь внести изменения. Я не могу справиться с такими спагетти, это слишком раздражает.

Answer 10

Я знаю, что какой-то раздел кода нужно разбить, когда у меня возникают проблемы, пытаясь понять, что он делает и как.Или если он больше, чем скриншот.

Обычно я делаю рефакторинг, если мне от этого плохо.Мне не нравится чувствовать себя плохо: - (

Я подозреваю, что код вышел из-под контроля, потому что руководство просто хотело сделать исправления / функции и ничего больше, и постепенно это становилось все хуже.

Рефакторинг кода для облегчения работы программистов, вероятно, был не слишком высок в их списке приоритетов. Вчера руководство всегда хотело, чтобы их исправления / функции были:сломался и разбил код, который был бы большим без юнит-тестов, и закончился бы катастрофой. Поэтому все тесты должны быть выполнены до того, как дотронуться до кода. Еще одна причина, по которой руководство не допустит этого.