Работаю больше 4 месяцев джуном на джаве (spring-boot, hibernate), познаю кровавый интерпрайз. Пока легаси поддерживать не кидали, пилю новый функционал на проектах.
В связи с чем у меня возникло сразу несколько глобальных вопросов по джава-индустрии, надеюсь матёрые форумчане помогут разобраться.
Getters/Setters
Постоянно в дтошках вижу одну и туже картину. Куча private полей, и к каждому из них геттер и сеттер. Больше ничего в классе нету. Я не понимаю, нафига строить тут типа «инкапсуляцию», если класс ничего семантически не инкапсулирует? Почему бы не сделать просто public филды?
Lombok
Крутая штука, но некоторые её до жути боятся и продолжают генерировать шаблонный код. Из трёх проектов, в которых я писал код, в двух ломбока не было и всё надо было делать руками (да, нажать биндинг для генерации в idea - тоже, считай, руками). Кроме того ломбок предоставляет @RequiredArgsConstructor, который в спринг-бинах просто мастхэв
Любовь к старым технологиям
Во всех трёх проектах (и это не легаси говно, с нуля все написаны в 2020) используется java 8. Почему не 9, где для optional подвезли нормальные методы? Почему вообще у чуваков такая тяга к старым технологиям? В новой джаве вот уже рекорды добавили, чтобы без ломбока и прочего жить нормально, так не, мы продолжим сидеть на 8, в худше случае и без ломбока.
И это не только с версией джавы, на проектах (новых!) используется версия querydsl 3.x, поддержка которой давно закончилась. Понятно, что в 4.x поломали совместимость, но неужели разобраться с этим это прям такое запарное дело?
Ехал singleton через singleton или процедурное программирование
По сути в архитектуре веб-приложухи на джаве нету никакого ООП. Все Service-компоненты с бизнес-логикой это по сути просто набор процедур. Все объекты service-классов существуют в единственном виде как синглтон. По крайней мере, я так это понял. Dtoшки это вообще не класс, это просто классический record в виде си. Всё в итоге сводится к процедурному программированию, когда дтошки (читай - записи) суются в методы сервисов (читай - в процедуры), откуда вызываются другие методы (по сути те же процедуры).
Код и данные максимально разделены. Это как-то не сходится с моими представлениями о ооп и тому, чего я ожидал от «ооп-языка»
Непонятные решения в БД и около её.
В лабах я привык использовать idшники в качестве PK, однако в реальном интерпрайзе везде uuidшники. Я погуглил, понял, что всё как-то связано с масштабированием и немного с безопастностью (если неавторизованные юзеры работают с сущностями), но в одном проекте у нас были и idшники, и uuidшники! Зочем?
Чейнджсеты ведутся в liquibase, причём все они хранятся в одном каталоги и инклюдятся в мастер-чейнджсет через includeAll. Нумеруются по принципу дата-айдишник-описание.xml. НО. Это же костыль! Если у меня в один день будет changeset в id=9 и с id=10, то 10ка попросту выполнится перед девяткой! Если уж использовать только числовые айди, то почему бы liquibase Не выполнять их по очереди?
Также не пишутся никакие sql-триггеры, вся логика прописывается в коде. Хотя в некоторых местах триггеры выглядели бы прям как образцовый пример из методички, на мой взгляд.
