🧩 Размоноличивание: что я понял после работы с DDD

Эта неделя началась с понедельничного факапа — попытка вынести один модуль в доменный слой превратилась в археологические раскопки. 😅

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

💡 1️⃣ Старайся заранее картировать зависимости.
Даже маленькая функция может знать про три разных слоя. Раннее понимание связей экономит кучу времени и нервов.

💡 2️⃣ "Мини-рефакторинг" почти всегда превращается в крупную работу.
Прими, что на один модуль уйдёт больше времени, чем планировал. Меньше стресса — больше контроля.

💡 3️⃣ Документируй каждый шаг.
Даже просто "какой сервис зависит" или "какие сущности вызываются" помогает при следующем заходе.

💡 4️⃣ Используй тесты как страховку.
Каждое изменение проверяй автоматикой. Ручная проверка работает, но на больших проектах — это стресс и потенциальные ошибки.

💡 5️⃣ Маленькие победы — огромный стимул.
Даже если вынесли только половину задуманного — это уже прогресс, и он важен.

💭 Вывод: размоноличивание — это не просто "сделать красиво", а шанс реально понять проект. Каждая сложная точка — это урок, и со временем ты начинаешь видеть, где можно идти быстрее, а где аккуратнее.

А у вас были похожие "археологические" рефакторинги? Какие лайфхаки для постепенного разбиения монолита работают лучше всего?👇

#itlife #мысли #размоноличивание #ddd #refactoring #codetogo #itshchen

🎉 Пятница. Конец недели непредвиденного рефакторинга

Эта неделя официально стала неделей "вынужденного размоноличивания". 😅
То, что начиналось как маленький шаг к DDD, превратилось в археологические раскопки: слои зависимостей, utils-файлы размером с энциклопедию, неожиданные связи…

И вот что удивительно: уже сейчас видно, что время не было потрачено зря.
✔️ Модули стало проще тестировать
✔️ Появилась ясность, куда что относится
✔️ Код меньше ломается при деплоях

💡 Мысль недели: иногда большие плюсы приходят не от запланированных задач, а от "вынужденного рефакторинга" в коде.

И даже если на понедельник казалось, что всё пошло не так — к концу недели цифры говорят сами за себя.
Одинаковый по объёму патч в монолите оказался вдвое более долгим и рискованным, чем в новом вынесенном модуле. Выигрыш налицо 😎

А у вас бывают такие недели "сюрпризов", которые в итоге приносят больше пользы, чем плановая работа?👇

#itlife #размоноличивание #рефакторинг #ddd #коднавынос #itshchen #codetogo

💥 Факап понедельника: "Техдолг всегда оплачивается"

Сегодня поймал классический случай: небольшой баг, который "надо бы пофиксить когда-нибудь", внезапно положил кусок функциональности.

Просто кнопка, обычная кнопка.
Но внутри — старая логика, которую все боялись трогать.
"Работает? Не трогай". Знакомо?😅
Ну вот, оно и не трогалось… год.

В понедельник утром кнопка решила, что достаточно.🙈

🧨 Вскрытие показало:
- кусок давно забытого костыля цеплялся за API, которое уже не существует;
- часть данных преобразовывалась странным способом "для совместимости" с чем-то, что уже удалили;
- и cherry on top — тут же оказалась ветка кода, которую никто не мог объяснить.

Когда вычищаешь это — понимаешь:
технический долг — как кредит под высокий процент. Он очень тихий, пока не приходит срок платить.

"Маленькая штучка на час" → часы анализа + фиксов + тестов. И это не конец, а только самое начало.

Неделя началась бодро. 😅
А как часто к вам приходят "коллекторы" за тех-долгом?👇

#техдолг #факапдня #itlife #codetogo #itshchen

🔍 Техдолг не про код. Он про решения.

После понедельничного факапа пересмотрел несколько мест в проекте — и понял одну вещь:
технический долг почти никогда не появляется из-за плохих программистов.

Он появляется из-за хороших людей, принимающих быстрые решения в неправильном контексте 😇

Вот три самых частых источника техдолга, которые я наблюдаю:

1️⃣ Скорость важнее качества.
"Завтра демо → сделаем как угодно, потом перепишем".
(Сюрприз: не перепишем 🙈)

2️⃣ Неопределённость.
Требований нет, дизайн меняется → код становится "пластилиновым" 🫠

3️⃣ Отсутствие владельца.
Если у модуля нет ответственного, он превращается в "общую кухню", где каждый добавляет по ложке соли 🤷‍♂️

💡 Мысль: техдолг — не ошибка, а решение.
Только решение без стратегии.

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

Расскажите, какие у вас наиболее популярные причины появления техдолга?👇

#техдолг #мысливслух #архитектура #codetogo #itshchen

🎉 Пятница. Неделя техдолга — итоги, которые не ожидал

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

После пары вынужденных погружений стало видно, что:

✔️ несколько старых кусков можно удалить полностью, без замены
✔️ почти везде, где "страшно трогать", на самом деле жил ненужный слой логики
✔️ а самый странный костыль вообще ускорял систему… случайно 🙃

Но главное — появилось понимание, какие места в проекте требуют реального плана, а не вечного "когда-нибудь".

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

А как у вас проходит неделя: боретесь с наследием или стараетесь не смотреть в ту сторону? 😄👇

#ретро #техдолг #итнеделя #itshchen #codetogo

💥 Факап понедельника: "Когда незаметная деталь бьёт по бизнесу"

Сегодняшний факап родом из "никто не считал, что это важно".

Есть небольшой сервис, у которого при определённом запросе ответ мог задерживаться на 400–500 мс.
Полсекунды — что такого? Разработчики махнули рукой.
Пользователи — терпели.
Аналитики — не замечали в усреднённых графиках.

А потом выяснилось, что эта маленькая задержка в одном ключевом сценарии давала минус 7% конверсии.
Просто потому, что часть пользователей думала: "не загрузилось" → жали "назад".

Это не баг, не поломка, не фича.
Это незамеченная техническая деталь, которая тихо, без драмы, съедала деньги компании годами.

И самое неприятное — никто бы и не нашёл это, если бы не попытка ускорить цепочку логирования.

💡 Понедельник начался под лозунгом:
Технические мелочи — не мелочи, если они смотрят в глаза бизнесу.

А как начался ваш понедельник? 👇

#факап #продукт #itlife #конверсия #itshchen #codetogo

🔍 Мысль дня: "Бизнес-эффект редко живёт там, где его ищут"

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

Но реальный эффект часто живёт в мелочах.

Например:

• случайная сортировка списка, которая меняет, какие товары пользователь видит первыми
• таймаут API, влияющий на путь, по которому данные тянутся в отчёты
• кнопка, которая по умолчанию не в фокусе, из-за чего исчезают 30% быстрых действий
• переиспользованный компонент, который сбивает контекст и увеличивает время решения задачи в два раза

И всё это — не про программирование.
Это про то, как люди взаимодействуют с продуктом.

💡 Заключение:
Архитектура — это не только про то, как работает сервер.
Это про то, как работает бизнес на другом конце запроса.

Как считаете, в каких ситуациях абсолютные технические метрики важнее бизнес-запросов? 😅👇

#мысливслух #архитектура #productthinking #uxengineering #itshchen #codetogo

🎉 Итоги недели: где техника реально влияет на продукт

Эта неделя неожиданно стала неделей микровлияний — тех мелких технических решений, которые незаметно тянут за собой бизнес.

Что удалось заметить, пока разбирали разные цепочки:

✔️ оптимизация 100мс в одном сервисе ускорила весь сценарий в среднем на 600мс — потому что создала "эффект домино"
✔️ обнаружился неочевидный UX-затык, который стоил менеджерам часа работы в день
✔️ изменения в одном API снизили нагрузку на другой сервис на 12% — просто потому что исчезло три лишних запроса
✔️ и самое приятное: выросла одна из микроконверсий, хотя никто её целенаправленно не трогал 😄

Неделя оставила чёткий вывод:

💡 Когда смотришь на проект как архитектор — видишь код.
Когда смотришь как продакт — видишь людей.
А когда совмещаешь — начинаешь видеть настоящие точки влияния 🔥

Хорошей пятницы всем, кто эту неделю выжил, нашёл инсайты и двигает продукты вперёд 🚀

#ретро #итоги #architecture #product #itshchen #codetogo

💥 Мелкое решение, которое убило фичу

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

Команда два месяца работала над новой фичей: тесты, нагрузка, мониторинг — всё чисто.
Релиз. Запуск. 30 секунд — и фича мертва.

Что произошло?
Много месяцев назад кто-то включил автоочистку temp-таблиц "на всякий случай". Логично, маленький гигиенический фикс.
Прошло время, фича поменялась, логика — тоже. А галочка осталась работать тихо, как невидимый демон.
И новая фича как раз опиралась на данные из этих таблиц.

Результат: система сама себе выбивает стул из-под ног 🪑

🔍 Вскрытие показало:
всё работало на своём уровне;
каждое решение было разумным;
конфликт появился только из-за того, что никто не держал «источник правды» под контролем.

🧩 Вывод: даже небольшие изменения могут стать невидимыми точками влияния.
Никакой архитектурной катастрофы нет — есть только слепые зоны контекста команды.

Единственное спасение:
1️⃣ определить master-источники данных;
2️⃣ зафиксировать, кто владеет поведением системы;
3️⃣ проговаривать любые изменения, влияющие на другие слои.

Даже опытные инженеры иногда попадают на "невидимые мины". И всё, что казалось мелочью, может съесть релиз. 😅

Делитесь своими историями в комментариях — самые интересные разберем вместе👍

#факап #itlife #codetogo #itshchen

🧭 Наблюдение недели: система всегда помнит больше, чем команда

Есть интересный феномен: чем старше проект, тем сильнее он ведёт себя как живой организм.
У него есть память. Своя логика. Свои рефлексы.

А команда… команда меняется.
Приоритеты меняются.
Фичи появляются и исчезают.

И вот однажды сталкиваешься с ситуацией, когда система делает что-то, что никто из текущих разработчиков не может объяснить:
"Почему она очищает этот кусок данных?"
"Зачем здесь два разных обработчика, которые делают одно и то же?"
"Откуда взялся этот обходной путь, если основная логика его не вызывает?"

Ответ почти всегда один:
кто-то когда-то решил, что это "маленькая оптимизация",
или "временный костыль",
или "аккуратное улучшение, на которое никто не заметит".

Система заметила.
И запомнила.

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

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

Без этого система продолжает жить своей жизнью, ориентируясь на реликтовые правила, которые никто не формулировал, но все продолжают наследовать.

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

А вы часто сталкивались с "призраками прошлого" в проде? 👇

#itlife #наблюдение #architecture #itshchen #codetogo

🎉 Пятничное БИНГО

Отмечайте, что слышали за последние пять дней:

1️⃣ «Фича как-то работает, не трогаем»
2️⃣ «API… так исторически сложилось»
3️⃣ «Это временное решение… ему пара лет»
4️⃣ «Если это убрать — всё упадет, не трогай»
5️⃣ «Оставим как есть, а потом разберёмся»
6️⃣ «Нужно MVP, но как финальный продукт»
7️⃣ «ТЗ ещё нет, но сроки нужны уже сейчас»
8️⃣ «Сначала запустим — потом доделаем»
9️⃣ «Это маленькое изменение, на один час»

Если совпало 3+, поздравляю:
✨ вы закрыли пятницу в режиме "выживших". 😅
Если 5+, соболезную, но искренне восхищаюсь! 🥲

Какие клетки у вас горели сильнее всего? Пишите — расширим народное бинго 👇

#пятница #юмор #itlife #business #codetogo #itshchen

💥 Факап понедельника: "Сначала согласования, потом тест"

Решили быть "моральными" и предупредить всех: мол, готовим тестовый MVP, всё прозрачно, согласования на подходе, тесты в процессе.

Реальность: бюрократия сработала мгновенно 😅
Три отдела, пять согласований, практически полноценное коммерческое ТЗ на тестовый прототип! Мы просто хотели проверить гипотезу, а получили почти готовый продукт по всем правилам корпорации 🥲

Итог понедельника:
— маленький эксперимент растянулся на дни;
— вместо быстрого прототипа — куча документации;
— "быстро проверить гипотезу" стало почти миссией по внедрению.

💡 Вывод: иногда проще сделать маленький рабочий MVP сначала, показать результаты, а потом объяснять и согласовывать. Процесс согласований до старта — это реальный риск утонуть в бюрократии, даже если твои намерения чисты 😇

А у вас были такие случаи, когда "сделаем красиво и законно" тормозило весь запуск? 😅👇

#факап #понедельник #стартап #интрапренёрство #корпорат #itshchen #codetogo

🔄 Апдейт эксперимента: параллельные процессы

Помните факап понедельника с согласованиями MVP? Пока бюрократическая машина крутила свои жернова, мы решили не сидеть сложа руки, а готовить прототип параллельно.

И вот что стало очевидно к середине недели:

Прототип vs Согласования:
⚡️ Разработка: 3 дня → рабочий MVP
📋 Согласования: 3 дня → еще не все одобрено, к разработке не приступали

Почему так происходит?

Когда согласовываешь план/идею:
→ Юристы видят риски в абстракции
→ Бизнес хочет фичи "на будущее"
→ Каждый отдел добавляет "свои требования"
→ Документация разрастается в ТЗ

Когда показываешь результат:
→ Видно, что реально работает
→ Обсуждаем конкретику, а не фантазии
→ 90% вопросов снимаются демонстрацией
→ Согласование = формальность

Инсайт недели:

В корпорации с тяжелыми процессами согласование РЕЗУЛЬТАТА проходит в 10 раз быстрее, чем согласование ПЛАНА 🥲

Потому что бюрократия эффективна для работы с конкретикой, а не с абстракциями.

Наш обычный подход (который мы на этот раз нарушили):
1. Быстрый прототип за 3-5 дней
2. Демо руководству/заказчику
3. Согласования на основе результата
4. Развитие или отказ — но с пониманием

Да, это не по классическому учебнику менеджмента. Но это работает.

Пятница покажет финальный результат эксперимента 🎯

А у вас в компании согласовывают планы или результаты? Что проходит быстрее?👇

#itlife #мысли #стартап #интрапренёрство #корпорат #itshchen #codetogo

🎉 Ретро недели: классический подход провалил проверку реальностью

Начали неделю с эксперимента: "А давайте сделаем правильно — сначала согласуем, потом разработаем!"

Финальные цифры:

📊 Путь "по учебнику":
— 4 рабочих дня на согласования
— ~25 человеко-часов команды на документацию
— Почти готовое коммерческое ТЗ для... теста гипотезы
— Финальное согласование: еще в процессе

⚡️ Путь "параллельный" (как мы обычно):
— 3 дня разработки → рабочий MVP
— Демо руководству с результатом
— Оставшиеся согласования закрылись за 1 день
— Причина: согласовывали уже не идею, а готовый продукт

Вывод эксперимента:

Наш "хакерский" подход — сначала делать, потом спрашивать — для нашей корпоративной реальности работает ЭФФЕКТИВНЕЕ классического.

Почему?

✅ Работающий MVP убирает 90% абстрактных опасений
✅ Бизнес видит ценность, а не обещания
✅ Согласования конкретики идут в 5 раз быстрее
✅ Риск "потратили 3 дня зря" < риск "застряли в согласованиях на месяц"

Важно:

Это НЕ призыв игнорировать процессы. Это про понимание контекста.

Если в вашей компании:
→ Согласование плана = 2 недели бюрократии
→ Согласование результата = 2 дня формальностей
→ Тестовый MVP можно сделать за 3-5 дней

То ваш "неправильный" способ и есть оптимальный для этих условий 🎯

Урок недели: Иногда нарушение правил — это не бунт, а прагматичная адаптация к реальности системы.

Проверено экспериментом. Провалидировано цифрами. Возвращаемся к рабочему процессу 😎

А у вас в компании как работает? "Сначала одобрение" или "сначала результат"? 👇

#ретро #процессы #интрапренёрство #mvp #pragmatic #codetogo #itshchen

💥 Факап понедельника: отпуск с ноутбуком

Понедельник.
Я в отпуске.
И это два факта, которые почему-то не исключают друг друга 😅

Формально — out of office.
Фактически — ноутбук в рюкзаке "на всякий случай", рабочий чат не замьючен — "ну вдруг что-то важное".

И вот ты уже:
— "одним глазом" смотришь алерт,
— "на пять минут" отвечаешь в чате,
— "быстро проверяешь", что там произошло.

Факап в том, что отпуск незаметно превращается в режим фоновой поддержки продакшена. Без ответственности. Без компенсации. И без ощущения, что ты реально отдыхаешь.

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

А у вас отпуск — это реальный оффлайн или тоже "на всякий случай гляну"? 😅👇

#факап #понедельник #отпуск #itlife #баланс #codetogo #itshchen

🧠 Наблюдение среды: отпуск ≠ выключение по кнопке

Самое странное в отпуске — даже не ноутбук в рюкзаке.
Самое странное — что голова всё равно работает в рабочем режиме.

Ты идёшь гулять, а в фоне:
— "а если тот алерт всё-таки был не шумом или его никто не увидел?"
— "надо бы потом проверить логи"
— "интересно, задеплоили или отложили?.."

Поймал себя на мысли: за годы в IT мы так привыкли быть доступными, что отсутствие задач начинает ощущаться как баг в системе.

💡 Маленький инсайт: настоящий отдых — это не когда нет задач, а когда ты разрешаешь себе не знать, что там происходит без тебя.

И да, это навык. Не встроенный. Его тоже приходится прокачивать 😅

А у вас как — голова в отпуске реально отдыхает или всё ещё "на проде"? 👀

#itlife #мысли #отпуск #баланс #codetogo #itshchen

🎉 Пятница: вывод недели "отпуск с ноутбуком"

Неделя в режиме отпуска показала одну простую вещь:
проблема не в ноутбуке. И даже не в чатах.

Проблема в том, что система слишком долго опиралась на одного человека — и этим человеком часто был ты сам.

И когда ты уходишь, система:
— либо начинает скрипеть,
— либо всё-таки… продолжает работать 🤯

💡 Вывод недели:
если без тебя всё падает — это не героизм, а сигнал.
Если без тебя всё работает — значит, отпуск наконец-то можно считать отпуском.

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

Хороших выходных.
И пусть хотя бы в них прод живёт своей жизнью 😎

#itlife #пятница #отпуск #выводы #codetogo #itshchen

Зависимость — это всегда принятый компромисс.
И чаще всего чужой.

В разработке с этим сталкиваются постоянно: любая библиотека, сервис или API — это чужое решение с чужими приоритетами и ограничениями. И если зависимость критична — её либо изолируют, либо страхуют.

С контентом происходит ровно то же самое.
Просто об этом реже думают в таких терминах.

Telegram — удобный продукт. Быстрый, простой, почти без порога входа. Но это всё ещё продукт со своей моделью распространения, хранения и жизни контента.

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

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

Это не недостаток. Это осознанный продуктовый выбор.
Проблема начинается там, где этот выбор принимается молча.

И именно здесь возникает зависимость: контент вынужден жить по правилам, которые не предназначены для его долгой жизни.

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

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

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

Риск очевиден: однажды платформа может измениться, исчезнуть или закрыть доступ. Контент станет недоступным. Архив потерянным. Контроль утраченным.

На практике вариантов немного.
Обычно всё сводится к двум направлениям.

Сохранение и фиксация контента как архива.
Первое, что приходит на ум: системы контроля версий и репозитории. Классический подход из разработки. Зафиксировал, задокументировал, сохранил.

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

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

Именно об этом сейчас и идёт размышление: не о платформе, а о том, как изолировать её ограничения и вернуть себе полный контроль.

Я нахожусь на этапе определения пути и формирования гипотезы для PoC — проверяю, что работает, а что нет, и подбираю наиболее простой и подходящий для моего случая вариант реализации.

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

На то он и «Код на вынос»

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

#зависимости #платформы #контроль #архитектура #контент #индексация #poc #разработка #мысли #itshchen #codetogo

Контент без компромиссов (PoC)

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

В прошлом посте я обозначил два пути: архив или доступность.

Оказалось, это ложная дихотомия.
Архив в сети — это и есть решение, если правильно выстроить архитектуру.

Эксперимент уже запущен.
Этот пост уже на сайте.

С чего началось
У меня был личный архив в Obsidian — Markdown-файлы и структура.

Работало, но не давало внешнего контура. Telegram не давал ни индексации, ни органики.

Что сделал
Markdown — источник истины.
Git — версионность и история.
Статический генератор — читает файлы, собирает сайт.

Сайт на бесплатном хостинге. Telegram — канал доставки, а не хранилище.

Результат:
Никаких серверов, баз данных и других дополнительных платформенных зависимостей.

Почему именно так
У меня уже был Obsidian с Markdown — использовал как базу.
CMS или кастомное решение = новые зависимости. Я выбрал минимум.

Markdown переживёт любой сервис.
Сайт переносится одним коммитом.
Telegram может исчезнуть — контент останется.

Плачу только за домен.

Что это даёт
Долговечность: текстовые файлы + Git
Доступность: индексация, постоянные ссылки
Контроль: я решаю где, как и когда публиковать
Масштабируемость: новый канал — один коммит

Что отсутствует в PoC
Автопостинг пока вручную.
Комментарии — в Telegram.
Фильтры заложены через тэги.

Работает ли это? Да — основные проблемы решены!

Это решение для всех? Нет!
Разный контекст = разные решения.

Но если боль совпадает — зависимость от платформ, потеря контроля и отсутствие внешнего контура — подход Content as Code может сработать.


Сейчас PoC-сайт работает: itshchen.ru

Это не продукт, а эксперимент.
Делюсь процессом и опытом, а не готовым решением.

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

Обсудим в комментариях:
Как вы храните и распространяете свой контент? Какие факапы встречались?

#contentascode #эксперимент #контроль #git #платформы #poc #разработка #codetogo