Продолжаю работу с ментатами (и ментатками 🌷) 🤓

5 задач ужасающей сложности оказались правда ужасающими сложными для меня. С такой сложной схемой БД, где более 50 таблиц, мне работать не приходилось. И задачи правда оказались невероятно сложными с требованием сложной аналитики. Обычно в работе сталкиваюсь с БД до 10-15 таблиц, а то и меньше.
Очень сложно (практически невозможно) выполнять такую работу с незнакомыми для тебя сущностями. Я привык к продажам, остаткам, логистике, БД различных пользовательских сервисов. С играми я никогда не работал. И продумывать аналитику влияния погоды на атаки или влияние лунной фазы на что-то невероятно сложно. И все это без боевых данных...

Получили трёхкратную разницу. Я не ожидал, что hibernate будет тащить так много лишних данных. В изначальном варианте с orm было очень много джоинов. Кажется это связано с тем, что сущности тесно связаны друг с другом и такая длинная цепочка джоинов является попыткой распутать клубок связей. Однако данные, которые достаются с помощью такого объёмного запроса нам не нужны и эти длинные запросы избыточны...

Однажды я полагал, что в одном из методов данные выдаются в упорядоченном виде, ну и закладывался на такое поведение. Потом выяснилось, что во время проверок так складывались звёзды и данные выдавались по возрастанию id...

Для себя я сформулировал простой принцип, который хочу применять дальше: перед тем как писать или менять код, стоит задать себе вопросы «зачем это существует?», «в каком месте системы это используется?» и «что нельзя делать с этим кодом». Если ответы не очевидны из сигнатур и структуры — они должны быть записаны в комментариях...

Тесты не спасают от всех багов — только от тех, на которые ты догадался написать проверку.
Например, что должен вернуть метод CalculateAverage для массива { 1, 2 } — 1 или 1.5? Если такой тест не написан,
баг может жить в коде годами, пока кто-нибудь не столкнётся с ним в продакшене...

Если честно, то я не задумывался о таких мелочах. Теперь понимаю, насколько это было недальновидно. Особенно мне казалось использование словаря в подобных случаях избыточным. Теперь вижу, что result['fresh_messages'] намного понятнее, чем fresh, old = some_function(). Не нужно держать в голове порядок возвращаемых элементов.
На будущее:
Нужно регулярно задавать себе вопрос: "А не скрыта ли здесь логическая связь?"
Чаще использовать словарь вместо кортежа...

Вообще, все больше и больше кажется, что иду (скажем мягко) не очень верным путем. Но тут, наверное, надо однозначно упереться в уже явный тупик, чтобы по факту можно было проанализировать свои шаги, которые туда и привели...

Затем я попытался достичь 10k RPS создав 10 тысяч пользователей(хотя для такого rps это, как будто, много). Но прогон завершился с ошибками и я даже не получил отчёт. Ещё впервые за долгое время услышал как мак гудит вентиляторами :)

По дипломному проекту, по заданию 42 следующий результат: поработал со Swagger. Самое для меня странное, что мы ведем документацию на апи в Swagger (все описание делаем вручную) - а я даже не в курсе был, что он может это все сам генерировать...

Чувствую, что надо переходить к AI-темкам, так как бизнес хочет вокруг AI строить все решения.
...В этом проекте я вообще максимально долго пытался сохранить монолит, но так как приходит вторая большая команда, то придется делить его как минимум на 2 (микро)сервиса, чтобы команды не толкались в одной кодовой базе...

Ну, "поделить монолит на несколько частей и будет проще автономным командам", это уже многократно проверенная иллюзия. Сейчас весь FAANG наоборот уходит в монолиты, на днях как раз несколько постов на эту тему выложу. Кодовую базу надо делить не на микросервисы (это техническое решение), а на правильную доменную логику, из которой архитектура будет следовать уже естественно и легко.
Как? Вот уже прям в марте будет вам гайд "Функциональные Архитектуры" 🔥