Я поддерживаю класс Java, длина которого составляет 40K. Проблема?

Ответ 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 тыс. Строк IMHO.

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Предположим, у вас нет модульных тестов для системы, как написано. У вас есть мое сочувствие.

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

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

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

Ответ 8

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

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

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

Ответ 9

Как молодой программист, я до сих пор помню, как мой учитель говорил нам разбить большие функции и работать над хорошим дизайном OO, прежде чем писать код.

Поэтому, если в вашем дизайне не существует НАСТОЯЩЕЙ веской причины навязывать 40 тыс. строк (что я сильно сомневаюсь), то у вас уже есть свой ответ: ваш класс слишком большой.

Я процитирую свою жену (которая химик и не программирует): "40k строк кода, есть что-то действительно не так!"

У меня были друзья, которые занимались проектами в своих компаниях, которые были действительно старыми, отброшены от одного программиста до конца, и мы все согласились, что класс, размер которого просто означает:

-patch и fix: люди должны были делать небольшие изменения здесь и там и не хотели/не имели времени, чтобы сделать это правильно.

во время выполнения не может быть никаких проблем с этим кодом, все работает, но обычно возникают проблемы, когда вы хотите сделать какие-либо изменения:

• требуется много времени, чтобы найти что-либо

• когда есть ошибка, которую вы не можете легко указать на нее

...

В заключение я хотел бы сесть заново о дизайне вашего проекта и реструктурировать (по крайней мере, в классах 1k ~ 5k линий для начала), я знаю, что его раздражает делать bu обычно в долгосрочной перспективе лучше

Ответ 10

50K строк кода? Я думал, что KLOC - это метрика размера проекта, а не размер файла. Это похоже на нашу всю кодовую базу (включая тесты).

Я работаю с JavaScript, поэтому он не сопоставим напрямую, но у нас есть только несколько файлов длиной более 500 строк - и это очень проблематичные.

Ответ 11

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

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

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

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

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

Ответ 12

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

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

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

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