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

Работая над этими задачами, я понял, как важно внимательно изучать схему БД перед написанием запросов...

Я долго не понимал, почему мои тесты разваливаются после каждого рефакторинга. Решил изменить структуру агрегата, перенёс логику — тест сломался. Хотя с точки зрения бизнеса ничего не поменялось, правило как обновлялось, так и обновляется.
В общем, дошло до меня не сразу. Я проверял не то. Проверял, как код работает внутри, а надо было — что он делает.
С TDD у меня поэтому не складывалось раньше. Я думал, это про "напиши тест, потом код". А на самом деле это про другое: сначала пойми, что должно работать, потом напиши тесты на это понимание, и только потом реализуй. Тесты и код не связаны напрямую, они оба следуют из спецификации...

Раньше пытался всё запихнуть в классы с наследованием. Теперь вижу, что часто проще использовать обычные функции.
Теперь перед написанием кода задаю себе вопрос: "Что может измениться в будущем, и как сделать так, чтобы эти изменения не ломали существующий код?"
Думаю во многих случаях ответ почти всегда: "Вынести изменяющуюся часть в отдельные функции и сделать механизм композиции"...

Мне долго доказывали, что код вида spring-hibernate-n1-problem не приводит к проблеме N+1. Не знаю, зачем нужен был этот спор, если можно просто написать тест на количество запросов. Все равно от версии к версии Hibernate поведение может поменяться).

Доп. задания АСД, конечно посложнее, на коленке за 5 минут не сделаешь, но в целом все достаточно доступно, как раз на новогодние праздники то, что надо было, чтоб и отдохнуть и не отупеть...

Далее опять не решил алгоритмическую задачку, отчасти потому что меня два раза сбили при решении, отчасти потому что медленно и плохо их решаю. Поэтому продолжаю курс по алгоритмам...

Тут множество циклических зависимостей, и никак нельзя сказать, что проект соответствует принципу МУРА. Когда я писала проект, под конец у меня было ощущение сильной запутанности. Глядя на этой график, понимаю, почему. Здесь все зависит друг от друга...

Позавчера я завершил обновлённый курс по ФП.
Чувствую, что на меня стал сильно влиять C++. Он и на новой работе, и в pet-проекте. Ваш курс - как глоток свежего воздуха.
Больше всего впечатлили следующие вещи:
Totality - очень подходящее слово, мощное. Нужно решиться писать программы, которые гарантированно завершаются, такие, где можно эти гарантии доказать. Это как минимум побуждает писать более чистый код без запутанных конструкций с высокой цикломатической сложностью. Так проще доказывать завершимость.
Ко-рекурсию можно и потерпеть, тем более, что в математике её не мало - те же универсумы в теории типов.
Призмы - "А что, так можно было что ли?" (с)
То есть, можно просто писать код без кучи if-ов, и он не будет падать. Без всяких "Rectangle has no attribute radius" и прочих проблем.
Expression problem. Больше всего в Python я скучаю по multiple dispatch. Это было красиво, хоть и многословно и полностью ломало работу тайпчекера.
Errors as values. Вот это стал активно применять в своём pet-проекте. Тем более, что на работе такая практика очень распространена - ни разу не видел там выбрасывания или обработки исключения.
Расширяемые эффекты. Даже сделал такую штуку в рабочем проекте. Потом, правда, придумал другой способ, о котором расскажу дальше.
В рабочем проекте возникла необходимость организовать несколько цепочек вычислений и синхронизировать их в ключевых точках. Там это было частично сделано через глобальное (в масштабах экземпляра класса) состояние с кучей полей.
Благодаря курсу по ФП я придумал полностью stateless решение через функции высшего порядка. Можно собрать всю логику запуска и синхронизации задач, а также передачи данных, в одном абсолютно линейном методе (с нулевой цикломатической сложностью). Потом запустить это в режиме fire&forget. Даже поля класса не нужны.