Первые впечатления от работы

Ситуация. Разрабатываем anticorruption layer между бравыми цифровыми сервисами банка и глючным core. Проекту три месяца. У всех разработчиков опыта минимум 7 лет. Из репозитория машет маленький-жук навозник, почти свалявший себе шарик говна. Буду вести репортаж, как мы всё это будем пересаживать на рельсы clean architecture.

Пока план такой:
1. Понять, как должно быть, и насколько мы далеки от этого
2. Найти единомышленников или хотя бы неравнодушных
3 .Разработать план рефакторинга, включив туда как можно больше людей. Чтобы все были повязаны и не саботировали потом.
4. Запихнуть задачи на рефакторинг в ближайшие спринты. Чего ждать.

На следующей неделе расскажу, как пошло.

Нам писали, что курс «Поваренная книга дядюшки Боба» тормозит. Докладываю: курс перезалит, теперь можно смотреть без регистрации, VPN и тормозов. Даже с мобилы.

Ну вы поняли как действовать!

Почему агрегаты должны хранить свои секреты

Когда в чате обсуждают агрегаты, то в первую очередь упоминают инварианты и транзакционные границы, но есть еще один критический аспект, который нельзя игнорировать: сокрытие деталей внутренних сущностей. Агрегаты должны быть не просто контейнерами для реализации бизнес-правил - они также должны защищать свою внутреннюю структуру. Одна из важнейших функций агрегата - обеспечить, чтобы его внутренние сущности и объекты значений не использовались (и тем более не изменялись) внешним кодом. Например, агрегат Order может содержать список элементов Product. Вместо того чтобы разрешать доступ, например order.Products.Add(product), лучше добавить метод order.AddProduct(product).

Почему? Потому что таким образом агрегат контролирует все необходимые проверки и пересчеты внутри себя. Это сохраняет логику последовательной, гарантируя, что когда нам надо пересчитать что-то вроде TotalPrice, то мы сделаем это в одном месте и сразу для всех. Внешний код не должен знать, как именно это делается. Но это не все, самое важное:

Сохранение секретов == гибкость

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

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

Антипаттерн «Кадастровый инженер»

Хочет всё размежевать, чтобы не слиплось. Считает, что разделение по репозиториям и приложениям — панацея от скверны лапшекода. Мол, щас всё растащим, и никто не сможет использовать Х в У.

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

Крайнее проявление — вынести в отдельный репозиторий каждый компонент единой системы: тесты, вёрстку, сервисы, скрипты миграций и т.д. Тогда вашей работой становится жонглирование ветками и толкание локтями коллег в репозиториях в попытках собрать всё воедино хотя бы на CI-сервере.

Чтобы разрез сильно не болел, нужно научиться искать логические границы и уметь пресекать нарушения. Потом дать границам устояться, и только потом отрезать. Попытка что-либо отрезать в бардаке приводит к ещё большему бардаку.

Как понять, что разделили неправильно? Когда для одной задачи вам приходится коммитить сразу в несколько репозиториев и в строгой последовательности. У репозиториев оказался слишком высокий coupling. Да, представьте coupling и cohesion применим и в рамках git-репозитория.

Небольшая заметка о стрессоустойчивости и вреде гиблых проектов https://vk.com/@-200496256-timlid-ozverel

Ребята из Postgres Professional написали неплохую книгу «PostgreSQL 16 изнутри»

Какие темы охватывает книга:
— Устройство shared buffer
— Как работает WAL
— Как выполняются запросы
— Зачем нам вакуум
— Как работают индексы
— Как устроен MVCC
— etc

Всего 665 страниц годноты на русском. Кому лень читать — у ребят есть ютуп-канал, посвящённый той же теме

Просвещайтесь!

#полезнота

Последние несколько месяцев слышал от разных людей (у нас и за границей) похожие истории про техдолг:

Не можем получить новую фичу вообще никак. Сроки просраны, а результат не предвидится. Заливание баблом, джунами и индусами больше не работает. Начальство в бешенстве, переписывать нет времени, что делать — не понятно.

В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так.

Возможно, это явление массовое и происходит от общепринятого подхода в индустрии: да пофиг ваще, бизнес бабки колотит, остальное похер. В ключевых системах ожидаемо накопилась критическая масса, и техдолг начал стрелять у всех. Ну или это просто совпадение.

Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3

К посту про SQL. Пока лазил на сайте Postgres Professional, наткнулся ещё на одну интересную книгу — «Путеводитель по базам данных».

Что внутри:
— Какие структуры данных используются для построения СУБД
— На каких алгоритмах построены распределённые СУБД
— Репликация и бекапы
— Журналирование
— Управление доступом

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

#полезнота

На следующей неделе планируем провести стрим на тему «Внедрение DDD на практике — профиты и проблемы».

К нам в гости придет наш товарищ Константин Шибков, старший Java разработчик СДЕК, автор курсов и статей по разработке, соорганизатор митапа про бережливые бизнес процессы AgileUfa и клуба разработчиков JavaKeyFrames.

Мы обсудим как Константин внедрял архитектурные подходы и паттерны и узнаем, что из этого вышло.

Ссылку пришлем позже, приходите и задавайте вопросы 🙂

Предварительно, запланировали стрим в четверг 31 октября в 18:00 МСК

Напоминаем, что сегодня состоится встреча. Ссылку скинем перед началом. Не пропустите!

Погнали! https://youtube.com/live/HYI5XzQFE3U?feature=share

Мы не знаем кто автор, но это просто шедеврально

Нас много раз спрашивали как удобнее всего обрабатывать ошибки и исключения. Рассказываем, как мы это делаем и почему стандартный try-catch не всегда удобен.

Если видос показался полезным — поделитесь с братюнями. И подпишитесь на канал, конечно же

Приятного просмотра!

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

⚠️ Осторожно! В комментах местами портал в дурку, посему приглашаем к веселью (вы знаете что делать).

Приятного просмотра!

Инфляция тайтлов: 18-летние синьоры уже реальность
(*пост не ставит целью оскорбить или унизить кого-либо)

И к сожалению эта напасть касается нас всех.

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

(Продолжение ниже)

В продолжение поста

Громкому тайтлу можно меньше платить

Громкий тайтл может перекрыть разницу в деньгах, так что получать Principal Software Architect & Visionary Technologist может меньше, чем обычный Developer. Ну и ещё это престижно звучит: уезжал из деревни студентом, а вернулся тем, кого и назвать сразу не получается. Почёт и уважение обеспечены, — думает уязвимый к брехне человек и принимает офер.

Громким званием проще сманить. Люди переходят охотнее в новые компании, если им предложить тайтл выше их текущего + небольшая прибавка зарплаты. Жертве кажется, что она много добилась и двигается по карьерной лестнице вверх, а там уже томятся ещё 20+ гибридных позиций, порождённых инфляцией.

И теперь ничего не понятно

Нельзя наверняка сказать, чем занимается Senior Staff Software Engineer. Где как. Одни компании требуют писать код в 2 раза быстрее, чем Senior Developer. Другие ждут на эту позицию динозавра с 15 годами опыта. В общем, пока не допросишь HR, не поймёшь, что скрывается за названием позиции. А увидя должность Associate Vice President, типичный разработчик вообще пройдёт мимо, подумав, что не про него. И совершенно зря.

Только Executive Director не пишет код. Даже Сеньер Вице-Президент код писать должен.

Хотя науке известен случай когда Executive Director перешел на позицию Senior Developer в другую "нормальную" компанию. Даже так случается 🙂