Эта статья первоначально появилась на Блог ИГ
После более чем 15-летнего опыта работы с Java я склонен отмахиваться от комментариев по поводу многословия Java одним из следующих аргументов:
- строки кода (LOC) – это фиктивная метрика;
- IDE генерируют 90 % моего кода Java;
- уроки, извлеченные из печально известной и непостижимой краткости ПЕРЛА.
Показатели локализации просто не важны.
Или они есть?
Некоторое время назад мы начали создавать наши первые Spark рабочие места. Первые два, которые мы написали, в основном одинаковы:
Так получилось, что мы написали один в Clojure и один на Java. Когда мы рассмотрели код, вот как выглядела версия Java:
Сначала я был удивлен, что здесь было так много занятий.
Тогда я был удивлен, что был удивлен, обнаружив так много занятий. В конце концов, код был совершенно идиоматичным Java-кодом, который мы все пришли писать.
Но почему я был удивлен в первую очередь? Вероятно, потому, что версия Clojure выглядела так:
Но, может быть, это был один огромный файл с сотнями строк кода? Нет. Всего 58 строк кода.
Возможно, версия Clojure была совершенно нечитаемой тарабарщиной из магических переменных и круглых скобок повсюду? Вот основная логика преобразования между двумя версиями:
Единственная разница в удобочитаемости заключается в том, что в версии Java намного больше скобок.
Обзор кода
Обычно я не обращал внимания на многословие Java, но во время обзора кода Java я поймал себя на том, что думаю о:
- С какого класса мне следует начать?
- На какой урок мне пойти следующим?
- Как классы сочетаются друг с другом?
- Как выглядит график зависимостей?
- Кто реализует эти интерфейсы? Необходимы ли они?
- Каковы обязанности каждого класса?
- Где происходит преобразование данных?
- Правильно ли преобразование данных?
В то время как обзор кода Clojure был о:
- Правильно ли преобразование данных?
Это заставило меня понять, что версия Clojure была намного проще для понимания, и что факт наличия одного файла с 58 строками кода был очень важной причиной для этого.
А как насчет более крупных проектов?
У меня нет более крупного проекта, где требования точно такие же, как здесь, но это правда, что наши микросервисы Clojure содержат не более 10 файлов, обычно 3 или 4, в то время как самый простой из наших микросервисов Java имеет несколько десятков.
И по опыту мы знаем, что время для понимания кодовой базы с 4 небольшими классами не то же самое, что для понимания базы с 50 классами.
Случайная Сложность
Итак, учитывая, что присущая сложность проблемы одинакова, и что версия Clojure способна выразить решение в 58 строках кода, в то время как версия Java требует 441 строки кода, и что версия Clojure легче понять, о чем эти дополнительные 383 (87 % кодовой базы) строки идеально идиоматичного кода Java?
Ответ заключается в том, что все эти дополнительные строки кода попадают в случайную сложность корзину – ту сложность, которую мы (программисты) создаем сами, не используя правильные инструменты, сложность, за создание которой нам заплатил наш бизнес, платит нам за поддержание, но никогда по-настоящему не просил.
Важны ли строки кода? Не как показатель производительности, но, безусловно, как показатель сложности, особенно если эта сложность является случайной, а не врожденной.
Представьте, что вы удалили 87 % всего кода, который вам нужно поддерживать!
Оригинал: “https://dev.to/danlebrero/java-maybe-verbose-but-who-cares”