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

И еще хотел отметить как сильно нагрелся компьютер при тестировании
Впервые мак настолько нагрелся за все время учебы и работы..

Понял, на что уходит непозволительно много времени. В топе самое банальное из того что можно было представить - отладка :) На работе распределенный монолит as is, пачка микросервисов, перекрестно зависимых друг от друга, чтобы завезти фичу, нужно внести изменения сразу в несколько сервисов, одновременно их задеплоить (при этом, окружение для тестирования одно, а разработчики все хотят задеплоиться), увидеть ошибку интеграции, повторить N раз...

Делаю систему возврата товаров для маркетплейса. Была сложность в том, что у них информация о товарах передается в 4 модулях, при этом информация из модулей сильно связана между собой (например в модуле 1 находится информация о продукте, в модуле 2 его характеристики (цвет, размер), а в модуле 3 информация о его возвратности и гарантиях).
И получается, что без получения самого продукта из модуля 1 некуда применять события из остальных модулей, пришлось думать над этой задачей. Плюс к этому они раз в день выгружали полный дамп базы в эти модули, получалось по 10 млн событий в каждом модуле, которые надо обрабатывать и дедуплицировать...

Сложно придумать более наглядный анти-паттерн, когда доменную модель разрывают на несколько модулей :) Когда скорее всего есть связка по айдишникам товаров, но асинхронщина по времени.

От free monad коллеги, скорее всего, в шоке будут, но уж больно хорошо она сюда подходит...

Не забывать, что разница между «трачу на работу 50-70% времени» и «выполняю работу за 50-70% времени» существенная!!!
Рефлексия! Ни в коем случае не забрасывать – очень мощный инструмент совершенствования себя и своих процессов...

На проекте после выполнения задания решили уйти от генерации исключений в невалидных стейтах в пользу игнора ошибки и отправки специального события в аналитику.
И не стоит забывать, что большое количество исключений могут быть заменены добавлением строгой системы типов...

При выполнении очередного задания по Hard Work писал много кода на ассемблере. Заметил, что для меня это то самое программирование, которое привлекло ещё в школе. Глобальное состояние, императивный код, спагетти из goto jmp... Романтика.
Видимо с тех пор у меня в голове сидит идея о том, что ядром программы является последовательность команд. В случае с GUI - это главный цикл приложения, которы обрабатывает системные сообщения.
Но ведь это не так! Цикл - это технические детали, которые у всех программ более или менее одинаковы в рамках платформы/фреймворка, а основная логика вовсе не там.
Отсюда и погружение в технические детали, много размышлений об ECS (который в итоге может и не понадобится). Это всё из-за глубокого внутреннего ложного убеждения, что тут находится главная часть приложения.
Так вот почему лучше начинать изучения программирования с ФП! :)

Теперь над каждой задачей буду принудительно думать сначала в терминах ФП, чтобы заменить вредную привычку полезной...