#рефакторинг — Public Fediverse posts

Я перевёл 200K строк JS на TS с Claude Code. Что прошло, что сломалось

За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?

https://habr.com/ru/articles/1040326/

#claude_code #typescript #миграция #рефакторинг #ai_agents #вайбкодинг

Я перевёл 200K строк JS на TS с Claude Code. Что прошло, что сломалось

За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?

https://habr.com/ru/articles/1040326/

#claude_code #typescript #миграция #рефакторинг #ai_agents #вайбкодинг

Я перевёл 200K строк JS на TS с Claude Code. Что прошло, что сломалось

За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?

https://habr.com/ru/articles/1040326/

#claude_code #typescript #миграция #рефакторинг #ai_agents #вайбкодинг

Я перевёл 200K строк JS на TS с Claude Code. Что прошло, что сломалось

За 6 недель Claude Code преобразовал 200K строк JS в strict TypeScript. Не переименование файлов, а настоящая типизация: интерфейсы, строгие null-чеки, перехваченные баги в проде. Тут разбор реального кейса с цифрами, ошибками агента и главным вопросом: стоит ли вам это повторять?

https://habr.com/ru/articles/1040326/

#claude_code #typescript #миграция #рефакторинг #ai_agents #вайбкодинг

Эволюция Telegram‑бота на C++: от «лапши» в main() до ООП, in‑memory кэша и мутов по Фибоначчи

Привет, Хабр! В этой статье я расскажу об эволюции моего проекта — GroupModerBot , бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.

https://habr.com/ru/articles/1039564/

#c++ #c++20 #sqlite #telegram #telegram_bot #кэширование #модерирование #рефакторинг #бот #open_source

Эволюция Telegram‑бота на C++: от «лапши» в main() до ООП, in‑memory кэша и мутов по Фибоначчи

Привет, Хабр! В этой статье я расскажу об эволюции моего проекта — GroupModerBot , бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.

https://habr.com/ru/articles/1039564/

#c++ #c++20 #sqlite #telegram #telegram_bot #кэширование #модерирование #рефакторинг #бот #open_source

Эволюция Telegram‑бота на C++: от «лапши» в main() до ООП, in‑memory кэша и мутов по Фибоначчи

Привет, Хабр! В этой статье я расскажу об эволюции моего проекта — GroupModerBot , бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.

https://habr.com/ru/articles/1039564/

#c++ #c++20 #sqlite #telegram #telegram_bot #кэширование #модерирование #рефакторинг #бот #open_source

Эволюция Telegram‑бота на C++: от «лапши» в main() до ООП, in‑memory кэша и мутов по Фибоначчи

Привет, Хабр! В этой статье я расскажу об эволюции моего проекта — GroupModerBot , бота для модерации Telegram‑групп. Я покажу, как проект прошел путь от первой версии «всё в одном файле» до продуманной архитектуры с ООП, in‑memory кэшированием, безопасным выполнением команд и нестандартными алгоритмами наказаний пользователей.

https://habr.com/ru/articles/1039564/

#c++ #c++20 #sqlite #telegram #telegram_bot #кэширование #модерирование #рефакторинг #бот #open_source

Feature Based Clean Architecture. Часть 4: FBCA: формализация границ ответственности в NestJS-модуле

После трёх частей разбора деградации остаётся один вопрос: как написать NestJS-проект так, чтобы god-сервис и циклические зависимости были невозможны. «Писать аккуратнее», «лучше ревьюить», «выделять день в спринте на рефакторинг» — варианты, которые не работают: дисциплина не масштабируется на пятьдесят спринтов и пять команд. Работает другое — наложить на модуль структурные ограничения, которые TypeScript и NestJS DI просто не дадут нарушить. Слои, однонаправленные зависимости, изоляция домена от инфраструктуры — не папки ради порядка, а барьер, который физически не пропускает сценарии деградации из частей 1–3. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 4 — конкретная имплементация подхода на том же сквозном Twitter-подобном бэкенде. Как модуль режется на четыре слоя (domain / use-case / infrastructure / presentation), как раздутый сервис заменяется набором use-case’ов, куда уезжает работа с базой и почему оркестратор перестаёт быть god-функцией. Без художественности: реальный код, что именно изменилось по сравнению с feature-based-структурой из частей 1–3, и точка, в которой видно — прежние сценарии деградации теперь не запускаются не потому, что «все стали аккуратнее», а потому что нечем.

https://habr.com/ru/articles/1038438/

#NestJS #TypeScript #Clean_Architecture #Архитектура_ПО #Бэкенд #Featurebased #DomainDriven_Design #Слоистая_архитектура #Рефакторинг #SOLID

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 3: Архитектурный риск циклов в NestJS: ROI решений на горизонте пяти лет

Циклическая зависимость между двумя модулями в NestJS лечится двумя строчками forwardRef. Документация прямо это рекомендует, ревьюер пропустит за тридцать секунд, билд снова собирается. Через полгода окажется, что эти две строчки имеют ROI –35 000% за первый год и –360 000% к десятому: $30–60k в год сжигается в маленькой команде, $6–15M — в big tech, без единой написанной фичи. Счёт приходит размазанным платежом по будущим спринтам — и винить уже некого: автор уволился, команда сменилась, forwardRef стоит как стоял. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 3 — расчёт стоимости одной типичной декомпозиции по feature-based на горизонте пяти лет. Как первый forwardRef морозит цикл, как через пару спринтов он начинает блокировать соседние фичи и заставляет придумывать обходные костыли вокруг старой ошибки, во что это превращается в маленькой команде и в энтерпрайзе, и почему именно отсюда команды уходят в преждевременные микросервисы.

https://habr.com/ru/articles/1038426/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #Циклические_зависимости #featurebased #Технический_долг #ROI #Рефакторинг

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Feature Based Clean Architecture. Часть 2: Декомпозиция на сервисы: анализ ограниченности подхода

Стандартный ответ на god-сервис — декомпозиция: разнести логику по нескольким сервисам с чёткими зонами ответственности, оставить тонкий оркестратор. После рефакторинга код действительно становится приятнее на глаз, файлов больше, метод оркестратора плоский. Структурно — не меняется ничего: тот же god-сервис воспроизводится этажом ниже, в одном из новых сервисов. На следующей итерации декомпозиции — ещё раз. Это не ошибка реализации, а свойство подхода. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 2 — что произойдёт, когда команда честно сделает напрашивающийся после части 1 рефакторинг. Без художественности: реальный код после декомпозиции, демонстрация того, что на верхнем уровне всё действительно стало лучше, и параллельный запуск ровно того же сценария деградации уровнем ниже. Точка, в которой видно: декомпозиция не убирает проблему.

https://habr.com/ru/articles/1038416/

#nestjs #typescript #архитектура #бэкенд #антипаттерны #god_object #featurebased #технический_долг #рефакторинг #typeorm

Рефакторинг выпадающих списков: от enum к конфигу-константе

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

https://habr.com/ru/articles/1038350/

#фронтенд #typescript #рефакторинг

Рефакторинг выпадающих списков: от enum к конфигу-константе

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

https://habr.com/ru/articles/1038350/

#фронтенд #typescript #рефакторинг

Рефакторинг выпадающих списков: от enum к конфигу-константе

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

https://habr.com/ru/articles/1038350/

#фронтенд #typescript #рефакторинг

Рефакторинг выпадающих списков: от enum к конфигу-константе

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

https://habr.com/ru/articles/1038350/

#фронтенд #typescript #рефакторинг

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

Feature Based Clean Architecture. Часть 1: Эволюция NestJS-приложения в неподдерживаемое состояние

Если ваш NestJS-проект собран по рекомендованной документацией feature-based-структуре — через год активной разработки у вас будет god-сервис. Не «возможно», не «при стечении обстоятельств» — структурно неизбежно. У этой структуры нет встроенного барьера от деградации. Серия из пяти частей: пошаговый разбор траектории на сквозном Twitter-подобном бэкенде, расчёт ROI типичной деградации в долларах и человеко-часах ($30–60k в год для команды из двух мидлов, $6–15M в год для big tech — с полным расчётом в части 3), и формальное доказательство на языке теории графов, при каких структурных условиях деградация невозможна. Часть 1 — старт траектории: AuthService с двумя ручками, который через год становится god-функцией на 200 строк с шестью параметрами и четырьмя независимыми доменами бизнеса. Без художественности — только реальные продуктовые требования (анти-фрод, реферальная программа, маркетинг, партнёрская программа) и их кумулятивный эффект.

https://habr.com/ru/articles/1038240/

#NestJS #TypeScript #Архитектура_ПО #Бэкенд #Антипаттерны #God_object #Featurebased #Технический_долг #Рефакторинг #TypeORM

«Где новые фичи?» — Как AI-миграция легаси вернет IT-бюджет бизнесу

Наверное, каждый, кто занимался эксплуатацией и развитием корпоративных систем, знает эту бесконечную претензию от бизнеса: «Мы столько тратим на IT – а результата ноль. Новых продуктов нет. Или они появляются мучительно медленно». И бизнес по-своему прав. Если из каждого рубля, потраченного на IT, менее 20 копеек уходит на то, что видит клиент – скорость появления новых продуктов будет именно такой, какая она есть - неудовлетворительной.

https://habr.com/ru/articles/1038146/

#Управление_IT #Legacy #AI #Миграция_кода #Банковские_технологии #Техдолг #AIагенты #DevOps #Рефакторинг #Цифровая_трансформация

Когда онбординг длится 2 месяца: день 3 — проследить главный поток данных

Иногда систему нужно быстро объяснить человеку со стороны: новому разработчику, техлиду, архитектору, аудитору или инвестору на technical due diligence. Но если показать все data flow сразу, человек не поймёт ничего. В этой части цикла я показываю, как выбрать один главный поток, проследить конкретную сущность от source до consumer и заранее привязать дебаг к слоям данных. Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.

https://habr.com/ru/articles/1035392/

#онбординг #data_flow #архитектура #документация #UML #API #SDK #debugging #legacy #рефакторинг

Когда онбординг длится 2 месяца: день 3 — проследить главный поток данных

Иногда систему нужно быстро объяснить человеку со стороны: новому разработчику, техлиду, архитектору, аудитору или инвестору на technical due diligence. Но если показать все data flow сразу, человек не поймёт ничего. В этой части цикла я показываю, как выбрать один главный поток, проследить конкретную сущность от source до consumer и заранее привязать дебаг к слоям данных. Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.

https://habr.com/ru/articles/1035392/

#онбординг #data_flow #архитектура #документация #UML #API #SDK #debugging #legacy #рефакторинг

Когда онбординг длится 2 месяца: день 3 — проследить главный поток данных

Иногда систему нужно быстро объяснить человеку со стороны: новому разработчику, техлиду, архитектору, аудитору или инвестору на technical due diligence. Но если показать все data flow сразу, человек не поймёт ничего. В этой части цикла я показываю, как выбрать один главный поток, проследить конкретную сущность от source до consumer и заранее привязать дебаг к слоям данных. Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.

https://habr.com/ru/articles/1035392/

#онбординг #data_flow #архитектура #документация #UML #API #SDK #debugging #legacy #рефакторинг

Когда онбординг длится 2 месяца: день 3 — проследить главный поток данных

Иногда систему нужно быстро объяснить человеку со стороны: новому разработчику, техлиду, архитектору, аудитору или инвестору на technical due diligence. Но если показать все data flow сразу, человек не поймёт ничего. В этой части цикла я показываю, как выбрать один главный поток, проследить конкретную сущность от source до consumer и заранее привязать дебаг к слоям данных. Внутри 4 практичных артефакта: чек-лист выбора flow, карточка сущности, таблица изменения формы данных и чек-лист точек поломки. А чтобы схема осталась в памяти надолго, я обернула её в кальмара с полипом на лице.

https://habr.com/ru/articles/1035392/

#онбординг #data_flow #архитектура #документация #UML #API #SDK #debugging #legacy #рефакторинг

Ваша кодовая база умрёт через 7 лет. Считаем на пальцах

Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO: переписать нормально. Поздравляем, у вас уже работают проценты по техдолгу, которые вы пока не считали.

https://habr.com/ru/companies/simpleone/articles/1034560/

#технический_долг #техдолг #legacy #рефакторинг #aiкод #vibe_coding #mckinsey #управление_разработкой #архитектура_по #Knight_Capital

Ваша кодовая база умрёт через 7 лет. Считаем на пальцах

Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO: переписать нормально. Поздравляем, у вас уже работают проценты по техдолгу, которые вы пока не считали.

https://habr.com/ru/companies/simpleone/articles/1034560/

#технический_долг #техдолг #legacy #рефакторинг #aiкод #vibe_coding #mckinsey #управление_разработкой #архитектура_по #Knight_Capital

Ваша кодовая база умрёт через 7 лет. Считаем на пальцах

Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO: переписать нормально. Поздравляем, у вас уже работают проценты по техдолгу, которые вы пока не считали.

https://habr.com/ru/companies/simpleone/articles/1034560/

#технический_долг #техдолг #legacy #рефакторинг #aiкод #vibe_coding #mckinsey #управление_разработкой #архитектура_по #Knight_Capital

Ваша кодовая база умрёт через 7 лет. Считаем на пальцах

Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO: переписать нормально. Поздравляем, у вас уже работают проценты по техдолгу, которые вы пока не считали.

https://habr.com/ru/companies/simpleone/articles/1034560/

#технический_долг #техдолг #legacy #рефакторинг #aiкод #vibe_coding #mckinsey #управление_разработкой #архитектура_по #Knight_Capital

Техдолг = налог. Как перевести его в рубли и показать финдиру

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

https://habr.com/ru/companies/simpleone/articles/1033086/

#техдолг #технический_долг #рефакторинг #DORA #SonarQube #CodeScene #управление_разработкой #бюджет_на_разработку #метрики_кода

Техдолг = налог. Как перевести его в рубли и показать финдиру

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

https://habr.com/ru/companies/simpleone/articles/1033086/

#техдолг #технический_долг #рефакторинг #DORA #SonarQube #CodeScene #управление_разработкой #бюджет_на_разработку #метрики_кода

Техдолг = налог. Как перевести его в рубли и показать финдиру

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

https://habr.com/ru/companies/simpleone/articles/1033086/

#техдолг #технический_долг #рефакторинг #DORA #SonarQube #CodeScene #управление_разработкой #бюджет_на_разработку #метрики_кода

Техдолг = налог. Как перевести его в рубли и показать финдиру

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

https://habr.com/ru/companies/simpleone/articles/1033086/

#техдолг #технический_долг #рефакторинг #DORA #SonarQube #CodeScene #управление_разработкой #бюджет_на_разработку #метрики_кода

Между нами SLA: как бизнесу и поддержке договориться до первого инцидента

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

https://habr.com/ru/articles/1032878/

#системное_администрирование #devops #sla #техническая_поддержка #мониторинг_сервера #инциденты #ревью_кода #рефакторинг #аварийное_восстановление #аварийные_ситуации

Между нами SLA: как бизнесу и поддержке договориться до первого инцидента

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

https://habr.com/ru/articles/1032878/

#системное_администрирование #devops #sla #техническая_поддержка #мониторинг_сервера #инциденты #ревью_кода #рефакторинг #аварийное_восстановление #аварийные_ситуации

Между нами SLA: как бизнесу и поддержке договориться до первого инцидента

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

https://habr.com/ru/articles/1032878/

#системное_администрирование #devops #sla #техническая_поддержка #мониторинг_сервера #инциденты #ревью_кода #рефакторинг #аварийное_восстановление #аварийные_ситуации

Между нами SLA: как бизнесу и поддержке договориться до первого инцидента

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

https://habr.com/ru/articles/1032878/

#системное_администрирование #devops #sla #техническая_поддержка #мониторинг_сервера #инциденты #ревью_кода #рефакторинг #аварийное_восстановление #аварийные_ситуации

Рефакторинг. Что нужно понять в первую очередь

Если начать читать книгу Марина Фаулера «Рефакторинг. Улучшение проекта существующего кода» в первый раз, то для программиста с небольшим опытом можно легко запутаться в том, что же сделать в первую очередь в своей программе чтобы навести там более-менее порядок или чтобы не допустить беспорядка если программа еще не написана. Т. к. рефакторингов там очень много, и чтобы их как следует освоить нужны годы, а программу нужно написать сейчас. Опишу здесь самые главные рефакторинги, без которых не обойтись.

https://habr.com/ru/articles/1030960/

#рефакторинг

Самые популярные ошибки начинающего SDET-специалиста

По мере того как современная разработка программного обеспечения движется в сторону непрерывной доставки и микросервисов, цена ошибок возрастает. Нестабильные тесты, плохо масштабируемый код автотестов или неправильное использование инструментов могут приводить к задержкам релизов или к росту количества багов из-за затрат времени и ресурсов на выявление причин падения автотестов. То, что сначала кажется временным исправлением, впоследствии может обернуться отложенными последствиями для всей команды. В этой статье мы рассмотрим семь распространенных ошибок, которые совершают начинающие SDET. Разберем не только то, что идет не так, но и почему это имеет значение и как подходить к решению каждой из проблем наиболее эффективно. Цель статьи — помочь начинающим SDET заложить прочный фундамент для эффективного тестирования, основанного на качестве, масштабируемости и взаимодействии с командой. Читать далее 🦾

https://habr.com/ru/companies/simbirsoft/articles/1027022/

#qa #тестирование #qa_automation #автоматизация_тестирования #автотесты #code_quality #качество_кода #чистая_архитектура #рефакторинг #python

Самые популярные ошибки начинающего SDET-специалиста

По мере того как современная разработка программного обеспечения движется в сторону непрерывной доставки и микросервисов, цена ошибок возрастает. Нестабильные тесты, плохо масштабируемый код автотестов или неправильное использование инструментов могут приводить к задержкам релизов или к росту количества багов из-за затрат времени и ресурсов на выявление причин падения автотестов. То, что сначала кажется временным исправлением, впоследствии может обернуться отложенными последствиями для всей команды. В этой статье мы рассмотрим семь распространенных ошибок, которые совершают начинающие SDET. Разберем не только то, что идет не так, но и почему это имеет значение и как подходить к решению каждой из проблем наиболее эффективно. Цель статьи — помочь начинающим SDET заложить прочный фундамент для эффективного тестирования, основанного на качестве, масштабируемости и взаимодействии с командой. Читать далее 🦾

https://habr.com/ru/companies/simbirsoft/articles/1027022/

#qa #тестирование #qa_automation #автоматизация_тестирования #автотесты #code_quality #качество_кода #чистая_архитектура #рефакторинг #python

Самые популярные ошибки начинающего SDET-специалиста

По мере того как современная разработка программного обеспечения движется в сторону непрерывной доставки и микросервисов, цена ошибок возрастает. Нестабильные тесты, плохо масштабируемый код автотестов или неправильное использование инструментов могут приводить к задержкам релизов или к росту количества багов из-за затрат времени и ресурсов на выявление причин падения автотестов. То, что сначала кажется временным исправлением, впоследствии может обернуться отложенными последствиями для всей команды. В этой статье мы рассмотрим семь распространенных ошибок, которые совершают начинающие SDET. Разберем не только то, что идет не так, но и почему это имеет значение и как подходить к решению каждой из проблем наиболее эффективно. Цель статьи — помочь начинающим SDET заложить прочный фундамент для эффективного тестирования, основанного на качестве, масштабируемости и взаимодействии с командой. Читать далее 🦾

https://habr.com/ru/companies/simbirsoft/articles/1027022/

#qa #тестирование #qa_automation #автоматизация_тестирования #автотесты #code_quality #качество_кода #чистая_архитектура #рефакторинг #python

Самые популярные ошибки начинающего SDET-специалиста

По мере того как современная разработка программного обеспечения движется в сторону непрерывной доставки и микросервисов, цена ошибок возрастает. Нестабильные тесты, плохо масштабируемый код автотестов или неправильное использование инструментов могут приводить к задержкам релизов или к росту количества багов из-за затрат времени и ресурсов на выявление причин падения автотестов. То, что сначала кажется временным исправлением, впоследствии может обернуться отложенными последствиями для всей команды. В этой статье мы рассмотрим семь распространенных ошибок, которые совершают начинающие SDET. Разберем не только то, что идет не так, но и почему это имеет значение и как подходить к решению каждой из проблем наиболее эффективно. Цель статьи — помочь начинающим SDET заложить прочный фундамент для эффективного тестирования, основанного на качестве, масштабируемости и взаимодействии с командой. Читать далее 🦾

https://habr.com/ru/companies/simbirsoft/articles/1027022/

#qa #тестирование #qa_automation #автоматизация_тестирования #автотесты #code_quality #качество_кода #чистая_архитектура #рефакторинг #python

# Старый код как налог на разработку

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

https://habr.com/ru/articles/1028080/

#технический_долг #legacy_code #clean_code #рефакторинг #backend #архитектура #поддержка_кода #ci_cd

# Старый код как налог на разработку

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

https://habr.com/ru/articles/1028080/

#технический_долг #legacy_code #clean_code #рефакторинг #backend #архитектура #поддержка_кода #ci_cd

# Старый код как налог на разработку

Старый код редко лежит бесплатно. Даже если его никто не вызывает, он попадает в поиск, ревью, CI, локальный запуск и голову каждому новому разработчику. Разбираю на примерах: DTO, endpoint’ы, которые «скорее всего не используются», deprecated events, конфиг-поля, Docker/CI-хвосты и продуктовые фичи «на будущее».

https://habr.com/ru/articles/1028080/

#технический_долг #legacy_code #clean_code #рефакторинг #backend #архитектура #поддержка_кода #ci_cd