Комментарии 18
Имхо, порядок в ИТ будет только тогда, когда введут что-то типа ГОСТ 2.109-73, и в каждой шараге будет свой отдел нормоконтроля.
Вот у вас, в Райффайзен банке, есть отдел нормоконтроля для кода? Нет? Ну тогда все эти холивары, языки, линты и прочие код-ревью, которые делает "звезда" проекта - все чепуха.
И в этом основная сила Java, потому что разработчики не тратят время на то, чтобы выработать общий стандарт оформления кода, что критично для масштабных корпоративных проектов.
Но, есть и обратная сторона. В той же Java из-за многословности разработчики понапридумывали костылей. Ладно Lombok если более менее на кодогенерации работает и предсказуем. Но огромная часть Java это дикое количество АОП. И вроде бы язык не самый вариативный а приложения порой работают также непредсказуемо как на JS, когда в рантайме выясняется что нет какого-то класса потому что версии библиотек не сошлись. Одного языка мало, нужна еще и адекватная экосистема.
Если в команде больше одного разработчика, уже есть риск, что они будут писать методы в разном стиле. То есть даже в таком банальном примере возникает необходимость в выработке единого стиля, а также контроль за выполнением этих договорённостей на code review.
Простой вопрос - зачем? Единственное что приходит на ум это то что разработчики не знают язык на котором пишут, ну тогда и меры другие нужно принимать наверное.
История развития многих языков программирования показывает, что чем сильнее мы можем задать ограничения в коде — тем проще потом контролировать корректность его работы и искать баги.
Если бы было так то все бы писали на Haskell или Rust.
По поводу непредсказуемости Java не соглашусь с вами.
В Java всегда можно посмотреть, например, полный стектрейс и найти, в чём именно ошибка. А несовместимость версий в рантайме выясняется легко при первом запуске. Особенно если мы пишем на фреймворке типа Spring.
Что касается написания методов в разном стиле: с точки зрения производительности и бизнес-логики как будто разницы нет, но ведь каждый разработчик, при очередных правках в этом участке кода, будет стараться переписать его в своём стиле. Может даже и неосознанно. Что приводит к повышению вероятности ошибок и усложняет ревью. А ценности для конечного пользователя мы тут не привносим никакой.
В Java всегда можно посмотреть, например, полный стектрейс и найти, в чём именно ошибка.
А если ошибки нет и просто что-то не работает не подавая виду не нужно будет SpringBoot по запчастям разбирать чтобы понять что не так попутно гадая на картах?
А несовместимость версий в рантайме выясняется легко при первом запуске.
Видно не сталкивались с проблемами которые легко не выясняются.
Что касается написания методов в разном стиле: с точки зрения производительности и бизнес-логики как будто разницы нет, но ведь каждый разработчик, при очередных правках в этом участке кода, будет стараться переписать его в своём стиле. Может даже и неосознанно. Что приводит к повышению вероятности ошибок и усложняет ревью. А ценности для конечного пользователя мы тут не привносим никакой.
А то что мы вместо того чтобы писать решение занимается бюрократией с вызовом расово правильных видов синтаксиса это мы так ценность вносим?
Как правило, если мы используем стандартные компоненты Spring Boot и что-то не работает, не подавая виду, то там либо сразу выдаётся ошибка (а подчас ещё и решение предлагается прямо в логах), либо мы просто не повесили где-то аннотацию или не добавили какой-то параметр в конфиг.
Что касается бюрократии, то от этого никуда не уйти в сколь-нибудь крупных проектах и командах. Иначе проект очень быстро превращается в зоопарк, который сложно поддерживать. Ценность тут заключается в снижении стоимости разработки: все пишут более-менее одинаково и не начинают очередной холивар на ревью.
Что касается написания методов в разном стиле: с точки зрения производительности и бизнес-логики как будто разницы нет
При едином стиле можно бегло читать код. И тогда при нарушении можно что-то не заметить. Это отнимает время. Не критично, но всётаки. Ну и конечно раздражает.
Вопрос к автору (я так понял, шарит за Котлин)/котлинистам: null safety в реальности реально работает? Ну окей, типа пользовательский ввод будет не null, а "", но этот случай же придётся обработать, ведь он по факту некорректный, верно? Тогда смысл? Или я что-то не так понял?
Пустая строка из вашего примера не то же самое, что null, т.к. на пустой строке мы можем спокойно вызывать любой метод из класса String. Тогда как попытка вызова такого метода на переменной, содержащей null, тут же приведёт к NPE. Разница вроде на первый взгляд небольшая, но значительная. Поэтому да, null safety в Kotlin спасает, и ещё как)
Я вам даже больше скажу, иногда хочется разделять строки на подтипы, чтобы не перепутать их при передаче в метод, где несколько параметров и все - строки. Например, строка-логин, строка-пароль, строка-email и т.п. Хотя технически всё это строки. В Kotlin есть решение и для этого - value class.
Спасибо за пояснение, понял о чём вы. Хотя, конечно, защита от null всё равно не спасает от пустых строк, которые тоже не всегда желанные гости, это, судя по всему, всё же имеет смысл.
Хочу ещё дополнить, что null safety в полной мере работает только для кода, написанного на котлине. Если же у вас интероп между котлином и джавой, тут надо быть аккуратнее, иначе ошибка произойдёт в точке вызова java-кода. Но сама возможность сказать, что "в данном коде не может быть NPE" - это очень круто!
Ну да, интеграция с джавой в этом плане конечно бывает проблемно. Я держу проектик на джаве, но объекты dto у меня на котлине (немного уменьшает количество кода + повёлся на null safety) И периодически была проблема, когда null пытался пройти в неналловый объект в итоге пришлось делать доп. проверки, которых хотел избежать
Если вы используете котлин только для dto, а всё остальное пишете на Java, наверное, логичнее использовать record-классы.
Я рассматривал этот вариант, но у рекордов вроде нет сеттеров. А в data-классах котлина есть и геттеры и сеттеры, что для меня важно (изначально хотел избавиться от использования ломбока)
P.s. "а зачем ты хотел избавиться от ломбока, спросите вы?" А я отвечу: "Понятия не имею, хотел поэкспериментировать!"
То, что хотели избавиться от ломбока - это похвально)
Концептуально что record, что data-классы разрабатывались как неизменяемые (т.е. без сеттеров) сущности для хранения данных. Использование var в data-классах - это не совсем в духе котлина. Поэтому если нет каких-то явных технических ограничений (типа Spring Data JPA), рассмотрите возможность ухода от сеттеров в сторону неизменяемых объектов. У таких объектов есть множество преимуществ.
Сравнивать чистые языки не совсем практично. В экосистеме Питона есть имуляция проверки строгой типизации. Работает вполне неполохо и реально ловит баги.
То есть данный код будет отформатирован любым разработчиком абсолютно одинаково. Иначе он просто не будет работать.
Есть еще варианты как в Питоне записать функцию. И лямбды и однострочники. Но это всё решается линтерами и форматерами. После них вариантов уже не будет.
Java, C# сильно отастают в плане инструментов по работе с кодом. Часто когда спрашиваю про тулзы у разработчиков, они делают удивлённые глаза. Компиляция неполохо защищает от ошибок и мне кажется на этом все останалваются. В Go уже получше, больше вещей встроенно в компилятор. Но всё равно подключаешь стронюю тулзу и видишь страницы проблем.
В голом Питоне ничего нет, но за счёт этого бурно растет сторонний инструментарий. И люди активно им пользуются.
Стандартизация без боли: как строгий синтаксис экономит время и нервы