Вообще кто такой сеньор? Знания java? Или знания проекта? Или "по жизни"? Нет ответа. И все таки - косяки ктр. в сфере сеньора, как я это дело понимаю. И которые встречал везде, где работал.
Стиль
Смешивание логики слоев (обращения к БД прям из rest). DTO игнорируется. Наружу отдаются “бородатые” Database Entity, ктр. сложно документировать и понимать фронту, связывают руки беку при изменении БД, тестировщики вешаются. Да что тут объяснять...
Жирные классы среднего слоя, нужно дробить. Делить по функционалу. Существует какой-то психологический барьер, когда нужно добавить новый класс. (для кого я это написал, это и так на всех заборах и собеседованиях, а гляньте-ка на свой service слой. Что-то типа ShopRestController, ShopServiceImplementation. И никаких вариаций типа выделить PriceRestController из ShopRestController, тут же сразу захочется PriceServiceImplementation выделить из ShopServiceImplementation и т.п.).
Тестирование
Отсутствие нагрузочных испытаний, хотя есть прекрасная утилита yandex-tank.
Интеграционные тестирование чаще ручное, хотя есть pytest и скрипты pytest. Утилита behave вообще волшебная штука.
Не используются скрипты httpie. Все через web интерфейс с ручным вводом. Беки должны помогать тестировщикам в этом деле. Что бывает психологически сложно принять для тестировщиков. "Я тут через браузер все руками попробовал и я уверен, а ты мне какую-то хрень утилиту подсовываешь".
Архитектура
Архитектура приложения никак не контролируется. Если нужна какая-то новая функциональность, выбор размещения места для кода почти случаен (ибо scrum).
Про кеши все дружно забываем.
Необоснованное бесконтрольное использование promise. И вообще: promise в spring как-то очень подозрительно выглядит.
Использование внешних сервисов, всякие сторонние rest, xml сервисы с их контролем и режимом доступа и т.п. все сложности нужно прятать в отдельном сервисном слое (а лучше вообще в отдельном микросервисе). Из этого слоя показывать только то, что нужно для конкретной системы. Безопасность при обращении наружу опять же проще контролировать devops инженерам.
Вообще все общение микросервисов обычно делается только через REST. Использование очередей при обмене между микросервисами почему-то в игноре на беке, только REST и точка.
Отдельно тут хочется упомянуть об использовании RabbitMQ. При непродуманном использовании, может ухудшить ситуацию. т.к. он “пушит” в приемный контроллер и создает отдельные потоки, на ктр. может не хватить ресурсов, если не указать max в rabbit обработчике.
Обращение к БД не кешируются.
REST запросы не кешируются.
Rest должен отдавать только то, что должно лежать в отдельной библиотеке DTO. Речь идет о ведении отдельной maven-зависимости DTO. Д.б. согласовано с "фронтовиками" и им понятно. Можно frontend разработчикам дать доступ к репозиторию DTO и настроить уведомления при изменениях для них. Документирование REST в этом случае сильно упрощается, описано в одном месте и не расползается на 150 вариантов во всяких wiki системах.
Можно рассмотреть 2 модели DTO для REST. DTO full для диалогов и DTO short для списков и т.п. Где какой использовать становится тривиальной задачей, решается за пару минут на дейлике. И не городить отдельный DTO на каждый метод REST контроллера. А еще можно добавить SimpleDto(long id, string name) когда не решили еще что же мы хотим от REST метода. Ну и заодно это "маячок" типа TODO. Можно от нее наследоваться, т.к. подавляющее кол-во JSON ответов имеют эти поля. Все что отдается наружу все должно быть в модели DTO. И никак не должны быть связаны с Entity, т.к. привязываемся к БД (хотя иногда очень хочется). Id все таки иногда нужен. Фронт у себя кеширует ответы, по id дергает из кэша.
Второе - это психологический момент. Мыслим бизнес сущностями, а не сущностями БД. Entity это средство, а не цель. Фронтовикам, аналитикам, тестировщикам лучше вообще не знать структуру БД. Пусть живут в своем мире DTO.
Сценарий:
Встречаемся, договариваемся о пути rest и набрасываем параметры запроса и json ответа (или лучше выбираем уже существующий DTO). И не выкручиваем руки фронтовикам, они по другому мыслят, другими задачами (ну разве что чуток фильтруем их хотелки). В общем договариваемся.
Держим в курсе этих дел тестировщиков(они сразу уже могут начать писать сценарии тестирования).
Идем работать.
Внутри бека возможно использование отдельного слоя DTO для обмена между микросервисами. Т.к. внешние DTO регламентированы, а Entity завязаны на базу. А внутренние DTO только для себя любимого, под свой вкус можно наделать.
Обмен между микросервисами может быть не только через REST, но и через очереди, не всегда нужен ответ REST прямо сейчас. Как то забывается частенько. Достаточно простого Ок, отправить в очередь запрос и "забить" на него. Вроде тривиально, а все равно вокруг одни RESTы и никаких вариантов.
Karaf в Kubernetes. Вроде бы вообще не тема для этой заметки. Но как-то подозрительно часто встречается. Ну не доходит до меня: для чего так делают. Точнее знаю. Накувыркался уже. Какая-то необъяснимая тяга к модульной java. Но это не она. Я и сам болел этим делом. Использование maven-зависимостей или отдельного микросервиса гораздо жестче и надежнее решает эту задачу. Уже пара проектов за плечами по "убийству" karaf в kubernetes. Надо в резюме уже писать "Убиваю karaf в кубере. Недорого." Как же легче становится писать!
Многопроектный проект в idea. Если пишешь один, то супер. Если в команде - засада.
Многопоточка
Игнорируется возможности Spring при многопоточности. Бесконтрольное (а чаще бессмысленное) использование многопоточки (Promise в ответе метода). В результате Promise расползается везде как короновирус => сложное программирование на promis-ах, сложное тестирование. Вообще 300 раз надо подумать, перед тем как возвращать Promise. (Да-да! Я не умею его готовить. Ок. А заодно вспомните что же такое RestController и Spring вообще?). Для себя использую такое правило: где породил Promise, тут же его и разруливай, если уж без него никак, и желательно через private. т.к. это локальное решение и не надо ради него усложнять остальной код, опять же вспоминаем что такое Spring.
Бумажка
Не используются графические средства типа miro.com diagrams.net . Именно как средство взаимодействия членов команды, а не как часть документации (да и документации тоже). Архитектурим прямо на доске, online.
Новый член команды
Отдельно выделил! Явление повсеместное! Какой-то нечеловеческий снобизм и в то же время безразличие(!) к новому сотруднику. Вход в новый проект, в другую команду. Тут и подключение через vpn, и знакомство с ресурсами, и людьми, с самим проектом и т.п. Лениво так какую-то левую ссылочку кинут на jira(не на раздел проекта, а просто на корень jira), после 10 обращения, если повезет то и на репозитории. Или тупо: посмотри в jira (к которой нет доступа). Или куратором назначат самого бесполезного члена команды, ктр. сам них.. мало знает. И позиция у него "Вот вам всем. За все хорошее". А дальше же вместе работать. А ответочка-то будет. И ее придется разруливать. Решение очень простое. В jira задача: "Довести нового сотрудника до 2-3 push в репу". Срок - неделя. Объем пушей по самому минимуму, задачи выбирает куратор. Или даже специально создает. 2-3 задачи никак ни на что не влияют. Отмазки типа "новичок тупой" в топку.
Команда
Не жалеть времени на общение бека с беком. Глаз замыливается. Даже отдельный дейлик для бека. Даже если их всего двое. Вопросы для дейлика размещать прямо в коде в виде todo. Todo помогает переварить речь перед обсуждением (и не только автора todo) и обязательно назначать регулярное время встречи, лучше сразу после дейлика. а не по мере возникновения вопросов.
Почему-то беки рулят(именно рулят!) и архитекторами, и тестировщиками, и фронтовиками, да и вообще развитием всего проекта. Как-то кривова-то. Может это только мой личный опыт.
Беки обычно интраверты, не склонны к болтливости. Следят за базаром. А зря.
Марк, постреляем?
Я о devops службе. Марк - это король devops, с ктр. мне повезло работать. "Постреляем" это про нагрузочные испытания. Хотя я не только про это.
Devops инженеры, случается, как-то за скобками команды. Вам повезло, если разработчики в контакте с devops инженером. Он пришлет вам результаты тестирования и развертывания. Проведет нагрузочные испытания. Укажет чего вы там забыли чего-то задокументировать. Вытащит условия возникновения ошибки на prode (хотя сами виноваты, когда отмахнулись e.printStackTrace ()). От эксплуатации мало толку ("Я работала как обычно, нажала эту кнопочку и вдруг все пропало" или "Ничего не работает"), а вот с devops инженером есть о чем поговорить.
Организует версионирование в понятной схеме.
Отразит эти отличия в разных wiki системах и в понятной схеме.
Укажет на перерасход ресурсов. А то и поделится опытом, как оптимизировать (очереди, кеши).
Finish
Вроде бы тривиальные вещи, но эти косяки встречаются очень часто. И звучат как какие-то откровения. С сомнениями, с многозначительными "Ну, не знаю. Посмотрим, как зайдет". А все очень реально, несложно и быстро. Уже пара проектов за плечами подобного рефакторинга.
И да! Это все сеньерские косяки. Т.к. ведет в параллель 2-3 проекта. Является заложником решений, ктр. уже на проде. Некогда анализировать, некогда объяснять коллегам, некогда объяснять каменты, некогда поднимать уровень коллег. Короче - некогда. Не просто лень. (Отмазался)
Как же сложно сделать просто.
P.S.
Еще бы не забыть черкнуть пару слов в отдельной статье, подробно и с примерами, о бессмысленности использования, причин возникновения, сопровождения и ухода от такого "чуда" как karaf в микросервисе kubernetes. Модульный karaf в микросервисе. Мозг в трубочку. А че не кубер в bundle карафа, да чего там мелочиться, лучше сразу windows в bundle, в ктр. запущен docker. Стоп! Stackoverflow. Короче, гнать karaf из микросервиса кубера. Не для этого он сделан.
Swagger!
Доступ к логам. И на проде тоже. Пооокааа дождешься от службы заказчика нужного куска лога. Есть способ для получения online. Немного полулегально, но безопасно, оперативно и без геморрроя в виде переписки со службой безопасности.
О! Женщины!
Просто само присутствие в команде как-то дисциплинирует что ли, автоматом включается "рыцарь", "мужик" (по-разному включается). Базар фильтруется. Перед дейликом причесываемся, пуговички застегиваются. Накосячить ну никак нельзя. Опять же внимательность к мелочам, порядку, чистоплотность, терпимость.