Завершился пятый модуль в Школе СТО в Стратоплане (хотел написать что и обучение, но внезапно накинули бонусный модуль про самоидентификацию руководителя).

Последний модуль не был каким-то цельным, скорее сложили все темы, которые нужны, но до этого не влезли:

1. Контракты-закупки-подрядчики
2. Работа с ключевыми сотрудниками
3. Работа с ключевыми стейкхолдерами, в первую очередь с СЕО

Контракты. Важная часть работы СТО, было интересно послушать, но так как я особо не касался этой области в работе - не хватило инсайдов. Как то все было обще (типа рассрочка платежа это хорошо, если мы платим, если рынок поставщика, то он и диктует условия и тп). И еще не хватило какой-то ситиошной специфики, кажется она есть.

Второй день про удержание ключевых сотрудников и в целом про мотивацию. Было полезно освежить знания. Местами спорно, но было полезно.

И последний день был про общение с СЕО и другими большими ребятами. По сути нет особого рецепта, главное знать, что каждой аудитории нужен свой формат. Три года назад на книжном клубе у Саши Поломодова мы как раз обсуждали главу Communicating the strategy из книги Technology Strategy Patterns -- многое перекликается (ссылка в первом комментарии).

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

Интересно, что Слава Панкратов (СЕО Старатоплана) недавно устроил опрос в Линкедине, видимо модулируя как раз сравнение "школы" против одного курса:

Быстрый опрос: на какой курс вы реально быстрее себя уговорите?

1 навык, 1 мес, 700 евро -- 78%

10 навыков, 5 мес, 2500 евро -- 19%

Но точно могу сказать, что Стратоплан дает хороший управленческий минимум, а с другими подобными русскоязычными школами я не знаком вовсе. Так что решение "идти-не идти" очень зависит от обучающегося. Если вы вначале управленческого пути, то вполне себе вариант, про их тимлидский курс, например, слышал много хороших отзывов. Ну и отдельные курсы (я был на Финансах, Найме, Стратегии) очень полезные и хорошие.

#обучение

Сегодня была интересная дискуссия про soft delete (ака мягкое удаление, но мне не нравится как это звучит на русском).

Что такое soft delete и как обычно его реализуют? Если мы говорим про sql базы данных, то обычно добавляют колонку is_deleted (и в довесок всякие deleted_at, deleted_by) и вместо DELETE FROM table_name where id =@id используют UPDATE table_name SET is_deleted=true where id = @id. Кроме этого во всех запросах (как минимум на чтение) добавляют предикат is_deleted=false.

Какая польза?
1. Мы не теряем данные и можем получать более полную картинку для аудита, аналитики и прочего.
2. Если кто-то (пользователь, крон) некоректно удалил что-либо, то мы можем восстановить данные без сложных манипуляций с бекапом (которого еще может и не оказаться).
3. Есть выигрыш по перфомансу на массовых операциях удалени.

Минусы тоже есть:
1. Код сложнее, надо не забывать везде отфильтровывать.
2. Перфоманс может страдать, если записей в таблице много и процент is_deleted достаточно большой, то надо будет что-то придумывать дополнительное (самое простое индекс по полю is_deleted).
3. Может пострадать доверие пользователя -- я не рекомендую (в общем случае) использовать soft delete на реально чувствительных для пользователя данных без дополнительных механизмов гарантии невосстановления.

Иногда приходит требование реализовать пользовательскую логику удаления/восстановления в корзину. И часто есть соблазн переиспользовать механизм soft delete для этих целей:
1. Удаление в корзину через set is_deleted=true
2. Восстановление через set is_deleted=false
3. Получение списка сущностей в корзине -- выборка с предикатом is_deleted=true
4. Удаление из корзины через hard delete.

Вроде все норм, разработчик ушел делать.

Но если посмотреть на это через призму DDD? Если обобщать, то у нас есть технические (инфраструктурные) решения и решения продиктованные бизнес-логикой.

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

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

Бонусный модуль «Идентичность руководителя» в школе СТО Стратоплана оказался неожиданно крутым.
Несмотря на странное название, это не про коучинг или философию, а про внутреннюю опору, когда вокруг всё меняется: проекты, роли, команды.

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

И, пожалуй, главный инсайт: я — разбитое сердце Джека больше, чем мои роли.
Роли могут меняться, но остаётся тот, кто их (осознанно? не всегда!) выбирает и соединяет в одно целое.

Раз пошла такая пьянка с тире и прочим — вот дисклеймер:

Я регулярно использую и планирую продолжать использовать LLM для написания постов.

Но я не постил и не собираюсь постить результат генерации напрямую. Я как минимум внимательно вычитываю, но обычно заметно переписываю текст (причем сперва несколько раз корректирую промптами).

Основные кейсы:
1. Сгенерить связки. Иногда у меня в голове из А гладко следует Б, но в тексте чувствую «прыжок» мысли — прошу ллмку сгенерить переход.

2. Генерация псевдокода.

3. Генерация финального предложения.

4. Ресерч данных.

5. Фактчекинг и редакторская правка моей писанины.


PS. При написании дисклеймера ни одна LLM не пострадала использовалась

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

Да, это не просто. Требует понимания и трудозатрат. Но результат стоит того:

— зафиксированные договоренности с бизнесом
— снижение когнитивной нагрузки
— понятные и поддерживаемые автотесты и много другое.

Сегодня Seb Rose и Gáspár Nagy поделятся своим видением проблем и подходов при использовании BDD. Можно просто смотреть, но можно и зайти в мит, позадавать вопросики (надеюсь)

https://virtualddd.com/sessions/patterns-of-bdd-automation-a-fireside-chat-with-seb-rose-and-gaspar-nagy/

Вчера стартанул Advent of Code 2025. Легкое развлечение на стыке математики и разработки. Если есть желание — присоединяйтесь по коду 5146453-917f4767 Let's fun!

Внезапно попал в мир мультитенантных архитектур. Раньше особо не работал, было только какое-то поверхностное понимание.

Тенант - группа пользователей, которые объединены общим контекстом. Например все пользователи организации могут образовывать тенант. У каждого тенанты свой (до какой-то степени) набор ресурсов и деплой.

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

Минусы.
1. Наверное основной минус — это стоимость. Для каждого тенанта вы создаете новый стенд, оплачивая ресурсы.
2. Второе: это сложнее деплоить, мониторить и поддерживать. Каждый релиз вы раскатываете на каждый тенант, каждую джобу для, например, восстановления данных после сбоя — вы запускаете на каждом тенанте.

И задачка со звездочкой — интеграция. Предположим, есть внешний сервис, который умеет дергать вебхук с каким-то пейлоадом. Вам надо доставлять этот пейлоад до тенанта по определенным правилам (самое простое: пейлоад содержит id тенанта получателя). Два основных подхода:
1. в лоб, регистрировать вебхук для каждого тенанта.
2. создавать роутер, который будет на основе какой-то логики перенаправлять пейлоад конкретному тенанту. Этот подход гибче, но требует доплнительных затрат на разработку и поддержку.

Много интересного на этом пути. Кстати облачные провайдеры с удовольствием делятся свои опытом. Поделитесь и вы своим 🙏

https://learn.microsoft.com/en-us/azure/architecture/guide/multitenant/overview
https://aws.amazon.com/solutions/guidance/multi-tenant-architectures-on-aws/

Если вдруг так вышло, что вы все прочитали, то вышла новая книга https://www.oreilly.com/library/view/domain-driven-transformation/9798341640108/

Судя по содержанию и введению выглядит очень интересно

@Drsnvld опубликовал статью на Хабре https://habr.com/articles/975936/
Фидбек, вопросы, комментарии — велкам 🙏

Сейчас все пытаются использовать LLM для ускорения разработки. Зачастую инструменты просто встраиваются ровно там где был человек. Это простой путь, но не всегда верный.

Возьмем код ревью (как бы мы к нему не относились). Есть, например, Code Rabbit, который подключаются к гитхабу-гитлабу и при создании пулл реквеста (мерж реквеста, кому как привычнее) оставляет свое веское мнение насчет кода. Классический код ревью как его делает человек.

Что здесь не так:
Мне всегда казалось, что такой код ревью можно сделать ДО коммита на локальной машине! Ведь результат, по-хорошему, нужен только автору кода и нужен прямо здесь и сейчас на каждый коммит, иначе у нас получается слишком длинная петля обратной связи и мусорные коммиты в репе (не все любят стешить).

Было приятно узнать, что не я один так думаю и команда копайлота сделала именно такой код ревью https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review

Еще один прекрасный бандл, в этот раз от O'Reilly

https://www.humblebundle.com/books/software-architecture-2025-oreilly-books-encore