Почему больше разработчиков не означает меньше работы

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

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

Рост команды сам по себе не уменьшает объём изменений, необходимых для каждой фичи. Разберём одну из причин, по которой этот объём растёт: сильную связность модулей внутри сервиса. При сильной связности небольшое изменение затрагивает сразу несколько компонентов. Разработчик меняет нужную логику, затем связанные с ней интеграции, проверяет соседний код и исправляет тесты. Задача растёт, хотя бизнес просил примерно то же, что и раньше. Новый сотрудник получает ту же систему зависимостей. Ему тоже нужно разобраться, что затронет его правка. Дополнительные люди могут взять часть работы, но сам объём изменений от этого не сокращается.

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

Как проверка паспорта затрагивает обработку заявки

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

Допустим, сначала внешний сервис принимает только номер паспорта. Затем команда переходит на другой сервис, которому нужны ещё ФИО и код подразделения. Меняются состав запроса, протокол взаимодействия и формат ответа. При этом условия прохождения заявки остаются прежними. Если вызов провайдера и разбор его ответа находятся прямо в коде обработки заявки, менять придётся этот код. В одном месте оказались две причины для изменений: новые бизнес-правила и новый способ получения данных.

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

Как отделить бизнес-правила от технических деталей

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

В модели чистой архитектуры выделяют четыре области:

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

Зависимость здесь означает, что один модуль использует определения другого: например, его интерфейсы или классы. Контроллер может обращаться к сценарию приложения. Сценарий при этом не должен зависеть от конкретного контроллера или реализации доступа к базе.

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

Поэтому проверить архитектуру можно по конкретному месту: от чего зависит сценарий обработки заявки? Если ему нужен класс клиента определённого API или конкретный модуль доступа к БД, техническая реализация всё ещё влияет на его устройство.

Что останется прежним при смене провайдера

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

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

Это работает, пока сохраняются бизнес-правила и приложению доступны нужные данные. Если ФИО или код подразделения раньше вообще не собирали, потребуется изменить и получение этих данных. Один адаптер не решит эту часть задачи. А если изменились условия, по которым заявка проходит дальше, правки понадобятся и в бизнес-логике.

С базой данных действует тот же принцип. Сценарий обращается к интерфейсу репозитория, а конкретная реализация работает с БД через SQL, ORM или собственный модуль доступа к данным. При переходе с PostgreSQL на Oracle это помогает сохранить код бизнес-правил, если их удалось отделить от особенностей конкретной БД.

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

Почему на старте получается три дня вместо одного

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

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

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

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

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

Как сохранить границы, когда фича нужна вчера

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

В разборе есть три способа, рассказывающие, как с этим работать.

• Подготовить шаблон сервиса. Заранее задать структуру для сущностей, сценариев и репозиториев, а также интерфейсы между ними. Тогда разработчику будет проще добавить логику в готовую структуру. При этом команде всё равно нужно понимать назначение границ и соблюдать их.
• Зафиксировать технический долг. Если ради срока пришлось связать сценарий с конкретной интеграцией, описать принятое решение и запланировать рефакторинг. Так временное упрощение останется видимой задачей.
• Объяснять затраты на конкретных изменениях. Обсудить с бизнесом, что произойдёт при замене сервиса проверки: где потребуется новый запрос, какие части приложения останутся прежними и почему команда тратит время на их разделение сейчас.

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

С чего начать в существующем проекте

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

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

Сначала понять, нужно ли трогать систему

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

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

Поэтому начинают с проблемы:

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

Всё это можно измерить, проверить и объяснить бизнесу. Дальше — варианты.

1. Оставить систему как есть

Иногда самое разумное решение состоит в том, чтобы ничего не менять.

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

Следить за ней всё равно придётся. Обновления безопасности нужно ставить, резервные копии проверять, а документацию по запуску, интеграциям и восстановлению держать в актуальном состоянии.

Заранее стоит договориться, какое событие станет сигналом к началу модернизации. Например:

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

Пока ничего из этого не случилось, систему оставляют в текущем виде.

2. Вывести ненужную часть из эксплуатации

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

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

• проверить логи и запросы к компоненту;
• найти связанные сервисы и задания;
• узнать, какие команды пользуются его данными;
• подготовить способ быстро вернуть его обратно.

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

3. Обновить стек без смены архитектуры

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

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

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

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

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

4. Перенести систему на другую платформу

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

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

Такой перенос сам по себе не ускоряет приложение. Если проблема находится в коде или базе данных, смена инфраструктуры её не решит. Зато команда может отказаться от устаревших серверов и упростить дальнейшую поддержку системы.

Старую среду лучше отключать только после проверки новой. Если при запуске возникнут ошибки, трафик можно будет вернуть обратно.

5. Заменить готовым продуктом

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

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

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

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

6. Рефакторить по частям

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

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

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

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

7. Переписать систему постепенно

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

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

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

Как выбрать стратегию

Для всей системы один подход выбирать необязательно. Стабильный модуль можно не трогать, старую интеграцию удалить, а авторизацию постепенно вынести из монолита.

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

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

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

Что подготовить до начала работ

Работу делят на этапы, и каждый должен давать результат, который можно проверить и выпустить отдельно. Задачу длиной в несколько месяцев тяжело оценивать, тестировать и откатывать.

До начала изменений нужно:

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

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

Итого

Легаси необязательно переписывать целиком. Сначала стоит понять, какая именно часть системы мешает работать и почему.

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

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

Агент забывает, что было пять минут назад, предлагает удалить сто раз проверенную функцию и генерирует код, который противоречит архитектуре. Здесь многие разработчики подумают: «модель совсем испортилась», но проблема не в модели, а в контексте.

Современные LLM устроены так, что качество ответа зависит не только от модели, но и от того, какую информацию она получает в запросе. Поэтому по мере увеличения кодовой базы самым сложным для модели становится управление контекстом. Уже даже появился термин — context engineering (передаем привет промт-инжинирингу), и сейчас команды, работающие над агентами, все больше внимания уделяют правильному формированию контекста.

В статье рассказываем, почему теперь недостаточно просто написать хороший промпт.

Контекстное окно — не равно память

Многие разработчики воспринимают контекстное окно как память модели, но это не совсем так. У LLM нет долговременной памяти в привычном смысле. При каждом запросе модель получает некоторый объем информации: промтп, историю диалога, файлы, ссылки, сообщения пользователя и найденные в поиске части кода. Это превращается в последовательность токенов, которая называется контекстным окном.

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

Если нужного файла нет в контексте — для модели он буквально не существует.

Размер окна — не единственная проблема

В базовой модели ChatGPT 5 — 16 000 токенов, в платных число доходит до 400 000. Если вы используете API-платформы, такие как RouterAI, то вам доступен 1 млн токенов — это примерно 750 000 слов. Вот как модели переводят слова в токены:

Действительно, миллион токенов — огромное количество, но есть важный нюанс: возможность прочитать миллион токенов совсем не означает, что модель способна одинаково хорошо использовать каждую их часть. Это подтверждает исследование Lost in the Middle 2023 года: авторы показали, что модели с большим контекстом лучше всего обрабатывают информацию, которая находится в начале или конце входного текста, а то, что в середине, можно сказать, ей упускается.

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

Почему большие проекты особенно сложные

Если текстовый файл обычно читается последовательно, то код — нет. Чтобы изменить один метод в бэке, агент будет искать информацию по самым разным частям репозитория, поскольку UI может лежать в одном пакете, реализация — в другом, а бизнес-логика и вовсе распределена между несколькими сервисами, и ещё, конечно, тесты.

Здесь важно учитывать, что разработчик выстраивает архитектуру и карту проекта постепенно (и зачастую не в одиночку), а модель вынуждена анализировать ее практически мгновенно. Следовательно, чем больше проект, тем выше вероятность того, что важная зависимость банально не попадет в текущий контекст. Именно поэтому агенты начинают использовать старый UI, дублировать код, нарушать архитектуру или генерировать ломающие друг друга изменения.

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

«Так я могу взять и загрузить весь репозиторий»

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

Но самая неприятная проблема — информационный шум, который создается при большом контексте. Представьте: перед код-ревью вам дали не один пакет или pull request, а весь репозиторий — вы потратите на это огромное количество сил и времени. С ИИ происходит примерно то же самое.

Как бороться с деградацией контекста

Может показаться, что современные AI-инструменты научились работать с огромными репозиториями — этим славятся GitHub Copilot, Claude и Cursor. Но на самом деле мало кто пытается загрузить в модель репозиторий целиком — поскольку важнее не размер контекстного окна, а качество информации. Именно поэтому нужно знать несколько архитектурных приемов.

Chunking

Это первый и самый очевидный прием: вместо хранения одного репозитория в виде одного огромного текста его заранее разбивают на смысловые фрагменты (chunks).

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

Поэтому в современных инструментах есть структурный чанкинг. В нем границы определяются элементами синтаксического дерева (AST — Abstract Syntax Tree): классом, функцией, UI, модулем, SQL-запросом и т.д. Такой подход позволяет сохранить логическую целостность кода.

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

И здесь на помощь приходит RAG.

Retrieval Augmented Generation

Сейчас RAG чаще ассоциируют с чат-ботами, которые ищут ответы в документации. Но принцип работает абсолютно так же и для кода.

Вот пример классической архитектуры:

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

Если в процессе retrieval нашлись не правильные файлы, даже GPT-5, Claude 4 или Gemini 2.5 будут уверенно рассуждать на основе неверных данных. Поэтому современные агенты все больше напоминают поисковые системы, а не просто оболочку вокруг LLM.

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

Суммаризация

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

Реализовал новую версию UserRepository, обновил миграцию, синхронизировал тесты с новой схемой.

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

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

Когда большой контекст необходим

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

• Большой рефакторинг. Например, команда решила перейти с одной библиотеки на другую, а код лежит в нескольких сотнях файлов. Модели нужно одновременно понимать старую архитектуру и предложить новую реализацию, которая не сломает приложение. В этом случае большой контекст поможет снизить количество итераций поиска.
• Монорепозитории. В крупных компаниях, например, в Google, один репозиторий может содержать десятки и даже сотни сервисов. Даже при точном поиске ограниченность узкого контекстного окна будет большой проблемой.
• Генерация больших изменений. Суть примерно та же самая, что и с рефакторингом: модель должна переписать кучу файлов, сохранить единый стиль, не нарушить связи и обновить тесты — большой контекст просто поможет удерживать всю информацию о задаче.

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

Что делать, если одной модели недостаточно

Если мы говорим о повседневных задачах, например, автодополнение кода или написание небольшой функции, то здесь важнее будет стоимость и скорость ответа, поэтому часто модели с небольшим контекстом будет достаточно.

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

Именно по этой причине сейчас появляется много сервисов, которые предоставляют единый доступ к различным моделям через API. Например, в RouterAI можно переключить агента на другую модель с большим контекстным окном, не меняя клиентский код и интеграцию с API. Это не решает проблему формирования контекста автоматически, но заметно упрощает эксперименты с разными моделями и позволяет выбирать инструмент под конкретный сценарий, а не подстраивать приложение под особенности каждого отдельного провайдера.

Итоги

Когда разработчикам кажется, что модель начинает «глупеть», проблема часто не в самой LLM, а в контексте, с которым она работает. И сейчас качество определяется не только количеством токенов, но и тем, как устроены RAG, суммаризация, чанкинг, а главное — поиск. Таким образом, нужно прокачивать и промпт-инжиниринг, и контекст-инжиниринг, чтобы научить модель видеть именно то, что необходимо для решения конкретной задачи.

В статье разберём этот эффект на примере легаси-систем, с которыми работает Centicore Group. Компания занимается модернизацией устаревшего кода, баз данных и инфраструктуры, а также системным и бизнес-анализом, разработкой ПО и контролем качества.

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

Что считаем техдолгом

Чтобы посчитать ROI рефакторинга, сначала нужно определить, что именно команда считает техническим долгом. Без этого в один список попадут баги, старые библиотеки, слабые тесты или желание сменить стек. У таких задач разные причины, цена и источники бюджета, поэтому их нельзя приоритизировать как одну категорию.

Термин «технический долг» ввёл программист Уорд Каннингем в 1992 году. Он использовал финансовую метафору: команда может выбрать более быстрое техническое решение, получить выгоду сейчас, а позже заплатить за это доработкой и дополнительными расходами.

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

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

1. Баг — это ошибка в реализации. Техдолга здесь нет: никто не принимал осознанного решения сделать хуже. Поэтому баги относятся к дефект-менеджменту и финансируются из бюджета на поддержку, а не из бюджета на рефакторинг.
2. Желание применить новую технологию — это новое требование к продукту. Команда хочет заменить PostgreSQL на что-то другое или перейти с REST на gRPC. Если это обосновано и полезно — отлично, но это отдельная задача со своей оценкой и своим источником финансирования.
3. Устаревший код без измеримых последствий — тоже не долг. Если модуль написан пять лет назад, но команда работает с ним без дополнительных затрат времени, он никого не тормозит и не создаёт рисков — переписывать его ради переписывания не нужно. Техдолг возникает в момент, когда команда признаёт: вот это решение замедляет нас, и мы можем точно сказать, как именно.

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

Как техдолг превращается в расходы

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

Объём работ — это всё, что нужно сделать, чтобы вернуться в целевое состояние. Раздробить монолитный модуль, заменить самописную библиотеку на поддерживаемую, переписать слой работы с БД. Объём работ оценивается в часах или стори-поинтах — это конечная сумма, которую команда выплатит один раз.

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

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

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

Какие задачи по техдолгу считать через ROI

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

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

• рефакторинг проблемного модуля,
• замена устаревшей зависимости,
• переработка слоя интеграций,
• доработка тестового покрытия на критическом участке.

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

• вывод старых сервисов из эксплуатации,
• изменение требований к отказоустойчивости,
• обновление платформы,
• пересмотр архитектурных ограничений.

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

Где искать расходы в легаси перед расчётом ROI

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

• Сначала проверяют зоны частых изменений. Если команда регулярно дорабатывает один и тот же модуль, а перед каждой задачей тратит время на разбор старой логики, такой долг стоит учитывать в первую очередь, потому что он возвращается в каждой новой задаче.
• Затем оценивают поддержку и эксплуатацию. Старые решения могут увеличивать время на инциденты, ручные операции, деплой, проверку интеграций и передачу знаний внутри команды. Эти затраты не всегда явно видны в разработке фич, но они каждый раз сокращают общий ресурс команды.
• Отдельно смотрят ограничения для будущего развития. Если текущая архитектура мешает новым интеграциям, требованиям к безопасности, масштабированию или изменению бизнес-логики, долг влияет уже не только на поддержку, но и на продуктовый план.

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

Как считать ROI

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

Шаг 1. Посчитайте текущие потери. Зафиксируйте, сколько дополнительного времени команда тратит из-за конкретной проблемы прямо сейчас. Медленная сборка — сколько минут в день суммарно по команде. Сложный для понимания модуль — сколько часов уходит на оценку задач в нём. Отсутствие тестов — сколько времени занимает ручная проверка перед каждым релизом. Переведите это в деньги через стоимость часа работы команды.

Шаг 2. Оцените объём работ. Сколько займёт исправление — в часах, с буфером на непредвиденное. Это тоже деньги: стоимость часа умножить на объём.

Шаг 3. Посчитайте горизонт окупаемости. Если текущие потери составляют 20 000 рублей в неделю, а объём работ стоит 80 000 рублей, рефакторинг окупается за четыре недели. Дальше каждая неделя — чистая экономия. Если горизонт окупаемости укладывается в срок, на который планируется развитие продукта, рефакторинг финансово обоснован.

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

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

Как обосновать рефакторинг бизнесу

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

Аргумент «там плохой код» не работает, потому что для бизнеса это не проблема — проблема это замедление или остановка поставки фич. Поэтому аргументы должны быть на том же языке.

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

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

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

Итого

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

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

Но при этом к такому коду часто боятся прикасаться. И не без причины. В старых системах редко бывает понятная карта зависимостей. Документация устарела, часть знаний живет только в головах нескольких разработчиков, а бизнес при этом продолжает ждать новых релизов, интеграций и продуктовых экспериментов.

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

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

Проблема не в самой идее переписывания, а в условиях, при которых оно проваливается. Большой риск возникает, когда совпадают четыре фактора: переписывание занимает много месяцев, в это время бизнес продолжает развивать старую систему, новая версия покрывает сразу большую часть функциональности, а откат связан с миграцией данных. Если все четыре пункта присутствуют, Big Bang почти гарантированно превратится в долгий и дорогой проект.

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

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

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

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

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

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

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

Представим старый монолит интернет-магазина. Внутри него есть каталог, корзина, заказы, платежи, скидки, личный кабинет и уведомления. Переписать всё сразу — рискованно. Но можно начать с относительно изолированного участка, например с уведомлений.

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

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

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

Например, в системе расчета налогов может быть правило: для контрактов, заключенных до 2018 года, НДС округляется в меньшую сторону до целого рубля, а для всех остальных — по математическим правилам. Новый разработчик может решить, что это ошибка, и «исправить» округление. Но потом выяснится, что часть крупных клиентов держит это поведение в своих сверках, а смена правила приведет к расхождениям в актах и претензиям.

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

user_id передается явно, чтобы решение «попал ли пользователь в новый сегмент» было стабильным от запроса к запросу. Иначе один и тот же клиент будет получать разные ответы при обновлении страницы, и поведение системы станет непредсказуемым.

На первом этапе флаг включают только для внутренней команды. Потом для тестового сегмента пользователей. Затем для небольшой доли реального трафика. Если метрики стабильны, долю увеличивают. Если появляются ошибки, флаг выключают, и пользователи снова идут в старую реализацию.

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

Важно, что фича-флаг — это не просто if в коде. Для серьезной миграции нужны правила: кто может включать флаг, как быстро его можно отключить, какие метрики отслеживаются, когда флаг должен быть удален.

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

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

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

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

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

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

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

Обратимые с компенсацией. Новая реализация пишет дополнительные данные (например, дублирует операции в новую таблицу), но старый источник тоже обновляется. Откат возможен, но требует решить, что делать с уже записанными данными: оставить, очистить, синхронизировать. План этих действий должен быть написан до выкатки, не во время инцидента.

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

Базовое правило: ни один шаг миграции не должен уходить в продакшен, если у команды нет письменного ответа на вопрос «как мы откатываемся в случае проблемы». Иначе при инциденте откатываться будут на ходу — и не факт, что успешно.

Пример: как тот же сервис мигрировали со второй попытки

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

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

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

Через два месяца чтение полностью перешло в новый сервис. Старый код чтения и фича-флаг удалили в том же релизе. После этого по той же схеме мигрировали запись документов, потом публикацию событий, потом импорт из внешних систем. Полная миграция заняла девять месяцев — почти столько же, сколько провалившийся Big Bang, — но продукт всё это время продолжал развиваться, инцидентов не было, и в конце команда осталась с системой, которую понимает.

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

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

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

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

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

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

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

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

Продукт, который уходит из эксплуатации. Если через год сервис будет выключен или заменён на покупное решение, тратить квартал на его рефакторинг бессмысленно. Достаточно стабилизировать то, что есть.

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

Потому что цель модернизации — не написать красивую новую систему. Цель — сделать так, чтобы продукт продолжал развиваться, команда могла безопасно вносить изменения, а пользователи не становились участниками инженерного эксперимента.

Всё началось с безобидного, почти рутинного тикета в саппорт:

«У меня тут несколько одинаковых карт создалось. Я вроде один раз нажимал, а их штук пять висит в приложении».

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

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

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

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

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

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

Круг замкнулся. Эпидемия началась.

В компании такого уровня это не было предусмотрено. И это такая обидная ошибка.

Как так получилось?

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

Ответ на вопрос “почему так было сделано?” очень простой - это было осознанное упрощение на старте. Все знали об этом, но задача на фикс потерялась в недрах бэклога на очень долгое время. Это классический пример того, как архитектурное допущение и отложенный рефакторинг годами живут в проде, пока их не вскрывает редкая последовательность отказов.-

Что потребовалось изменить

Пришлось в срочном порядке внедрять полноценный механизм идемпотентности по request-id, который не зависел бы от порядка вызова downstream-сервисов. И это было достаточно тяжело, потому что окно для легкого внедрения закрывается в первый день продакшена: до этого момента нет ни живых пользователей, ни накопленных данных, ни клиентов старых версий, с которыми нужно сохранять обратную совместимость. Ниже — ответы на вопросы, которые мы получили от коллег, когда разбирали этот инцидент.

FAQ: Часто задаваемые вопросы

1. Почему нельзя просто заблокировать кнопку на фронте?

Блокировка кнопки решает проблему только при стабильной сети. Если запрос ушёл, сервер создал сущность, но ответ потерялся — кнопка разблокируется по таймауту, и пользователь нажмёт снова. Это не устраняет корневую причину, а лишь слегка снижает вероятность дубля.

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

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

4. Что делать со старыми клиентами, которые не шлют request_id?

Мы сделали несколько версий API для создания карт — под разные версии приложения. Для новых клиентов работала полноценная идемпотентность с клиентским ключом. Для старых версий приходилось принимать риски и генерировать request_id на стороне сервера. Альтернативой может быть хэширование payload запроса, но это менее надежно и сложнее: таймстемпы и случайные поля могут отличаться от вызова к вызову. Поэтому мы выбрали подход с генерацией ключа на сервере для устаревших клиентов: риски дублей на переходный период оказались меньше, чем сложность поддержки двух схем валидации одновременно.

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

6. Как понять, что в вашей системе уже есть скрытая проблема с дублями?

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

• В базе данных периодически появляются записи с одинаковым содержимым, созданные с разницей в несколько секунд.
• Пользователи жалуются на дубликаты карт, заказов или платежей, но вы не можете воспроизвести проблему локально, списываете на то, что пользователи что-то делают не так
• В логах API Gateway периодически всплывают HTTP 500 ошибки, но downstream-сервисы при этом отрабатывают успешно.

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

Итог

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

Метрик на всплески повторных запросов у нас не было. А зря — это самый дешёвый способ увидеть проблему до того, как она обрушит продакшен. Системы, спроектированные на 10% нагрузки, ломаются на 60% — и обычно это становится неожиданностью для команды.

Практический чек-лист: что проверить в своей системе уже сегодня

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

Сделал себе инструмент, который это решает. Потом оформил в продукт. Называется CoAlly - сервер, который дает агентам общую память.

Что он делает

Агент автоматически сохраняет контекст работы: какие решения принял, какие файлы затронул, почему сделал так, а не иначе. Когда другой агент (или тот же, но в новой сессии) берется за связанную задачу, он находит этот контекст через семантический поиск.

Запрос "проблемы с авторизацией" найдет запись про "token refresh rotation", хотя слова совершенно разные. Работает через эмбеддинги и косинусное расстояние, скоро выйдет фича с анализом смысловой корреляции при поиске.

Подключение

Шаг 1: регистрация

Заходим на coally.cortexally.ai, создаем аккаунт. Получаем API ключ.

Шаг 2: подключение к агенту (Claude, Cursor и др.)

Одна команда в терминале:

claude mcp add coally-nexus --transport sse https://coally.cortexally.ai/sse --header "Authorization: Bearer ВАШ_КЛЮЧ"

Перезапускаем Claude Code. В списке MCP-инструментов должен появиться coally-nexus.

Cursor, Windsurf, VSCode

Заходим в настройки Cursor -> Settings -> MCP -> Settings (значок шестеренки) или создаем/редактируем файл `.cursor/mcp.json` в корне проекта (или в домашней директории для глобального подключения):

Файл `~/.codeium/windsurf/mcp_config.json` для Windsurf или соответствующее меню для VSCode и других его форков.

Перезапускаем IDE|Agent. Готово.

Первая сессия

После подключения агент при первом взаимодействии проиндексирует проект автоматически. Если нет - попросите: "проиндексируй этот проект через CoAlly".

Что происходит при индексации: сканируется дерево проекта, находятся конфиги, важные воспоминания, memorybanks и др., все это эмбеддится и сохраняется как контекст.

Дальше агент сам начнет сохранять контекст работы после значимых изменений. Если нужно явно сохранить что-то: "сохрани контекст этой задачи в CoAlly".

Что получаем

На вопрос "что вчера делали по задаче авторизации? какой статус бага с токеном и сколько времени потребуется на доработку" Агент достает из CoAlly записи: "вчера в Cursor поправили ротацию токенов, причина была в TTL, затронули два файла. Могу сразу продолжить и на основе коммитов ... исправить точечно флоу, время на исправление — N минут."

Если работаете в команде - еще полезнее. Контекст коллеги тоже доступен. Его экспертиза и навыки также постепенно приобретают цифровую версию. Не нужно ждать стендап или писать в Slack.

Ограничения

Агенты иногда игнорируют инструкции и не сохраняют контекст. Бывает. Можно просить явно.

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

Бесплатный тариф - 2 проекта. Для личного использования хватает. Для команд - тарифы Team и Enterprise.

По его словам, нейросеть сможет делать это даже эффективнее традиционных компиляторов.

Звучит громко. Но если разобрать тезис технически, все не так однозначно.

Что именно предлагает Маск

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

Фактически это означает отказ от исходников как основного артефакта разработки. Промпт на входе, а .exe или ELF на выходе.

Почему это спорно с технической точки зрения

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

Один и тот же код при одинаковых условиях дает один и тот же бинарник.

LLM работают иначе: они генерируют вероятностный результат. Малейшая ошибка в бинарнике приведет к падению программы или трудноуловимому багу.

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

Кроме того, компиляция стоит дешево — это миллисекунды CPU. Генерация крупных бинарников через LLM потребовала бы миллионов токенов и значительно больших вычислительных затрат.

Где ИИ действительно меняет разработку

На фоне громких заявлений Маска, многие как будто забыли, что ИИ уже активно используется в программировании. Но в другом формате. Технология помогает писать исходный код, объяснять сложные участки, генерировать тесты, предлагать рефакторинг.

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

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

Начиная с 22 декабря 2025 года, ее больше нельзя будет скачать. Ни через Toolbox App, ни через другие официальные каналы. Разработка и выпуск обновлений также прекращаются.

При этом JetBrains подчеркивает: речь идет не о провале эксперимента, а о смене стратегии. Команда Fleet, технологическая база и наработки никуда не исчезают — вместо IDE компания готовит новый продукт, ориентированный на агентную разработку.

Почему Fleet не взлетела как IDE

Fleet задумывалась как попытка переосмыслить IDE JetBrains через более легкую архитектуру, современный UI и отказ от наследия IntelliJ Platform.

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

Однако как самостоятельный продукт, Fleet не смогла занять четкую нишу. Она не смогла заменить IntelliJ IDEA и другие IDE JetBrains, но и не предложила достаточно убедительных преимуществ, чтобы существовать параллельно с ними.

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

Ставка на ИИ тоже не спасла Fleet

JetBrains пыталась перепозиционировать Fleet как AI-first редактор. Команда экспериментировала с новыми сценариями и проводила масштабные пользовательские исследования.

Вывод оказался неприятным, но честным: еще один ИИ-редактор не имеет шансов выделиться на фоне десятков ИИ-ориентированных форков VSCode.

В результате JetBrains решила сосредоточить развитие ИИ-функций внутри уже существующих IDE, где они действительно приносят ценность.

Новый фокус — агентная разработка

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

Речь идет о рефакторинге, обновлении тестов, исследовании незнакомого кода и даже реализации фич целиком — с последующим ревью результата.

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

Поэтому JetBrains и решила не «втискивать» агентные сценарии в IDE, а создать отдельную среду разработки для ИИ-агентов. Именно в этом виде Fleet получила вторую жизнь — но уже под новым именем и с другим позиционированием.

Что будет с текущими пользователями Fleet

Если Fleet уже установлена, ею можно продолжать пользоваться. Однако обновлений больше не будет. А функции, завязанные на серверные сервисы JetBrains — включая AI Assistant — со временем могут перестать работать.

JetBrains обещает отдельно рассказывать о новом продукте по мере его разработки.

Почему релиз Node.js 22 важен

30 апреля 2025 года завершился жизненный цикл версии Node.js 18. Сообщество заранее предупреждало об этом через официальный аккаунт в X. Там напомнили разработчикам о необходимости перейти на более свежие версии — Node.js 20 или 22. Восемнадцатая версия перестала получать патчи безопасности, поэтому обновление стало критичным для поддержания стабильной работы приложений.

Наиболее надёжным вариантом стала миграция на Node.js 22, которая сейчас находится в статусе долгосрочной поддержки (LTS) и гарантирует обновления безопасности и стабильность на ближайшие годы.

Хотя релиз этой версии не выглядел революционным, он существенно изменил основу платформы. Многие возможности, которые раньше требовали внешних библиотек, теперь встроены прямо в платформу: WebSocket-клиент, стабильный fetch(), работа с файлами, Blob и URL, улучшенная совместимость ESM и CommonJS. Это уменьшает количество зависимостей, снижает вероятность уязвимостей и значительно упрощает поддержку проектов.

Помимо удобства разработки, в новой версии усилились производительность и безопасность. Обновлённый движок V8 ускоряет выполнение кода, а оптимизация старта и снижение потребления памяти делают Node.js более стабильным в высоконагруженных и serverless-сценариях. Улучшенная модель разрешений, строгие настройки TLS и расширенная поддержка AbortController повышают защиту на уровне рантайма, ограничивая последствия уязвимостей в сторонних пакетах. Это даёт компаниям возможность строить более надёжные сервисы с меньшими затратами на контроль рисков и эксплуатацию.

Node.js 22 также стал удобнее для работы гибридных команд. Стабильная интеграция ESM и CommonJS облегчает миграцию старых проектов, а унификация Web-API делает код универсальным и понятным даже для сотрудников без глубокого опыта в бэкенде. Улучшенные инструменты тестирования и диагностики повышают прозрачность разработки и снижают время на нахождение ошибок.

Node.js 22 — эволюционный релиз. Он развивает ранее введённые возможности (fetch, ESM, WebSocket и др.), но не переворачивает парадигму разработки. Это укрепление уже заданного курса.

Возможности Node.js 22

Расширение JavaScript и обновление V8. Получив движок V8 12.x, Node.js подтянул все улучшения ECMAScript 2024. Код стал исполняться быстрее как за счёт оптимизаций в компиляторе, так и благодаря улучшенной работе с асинхронностью. Например, async/await теперь обрабатываются эффективнее, а создание структур данных, активно используемых в серверах, стало менее затратным.

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

Corepack включён по умолчанию. До выхода Node.js 22 разработчики сами решали, подключать ли Corepack. Теперь он активен без дополнительной настройки, и это серьёзное изменение в экосистеме. Все менеджеры пакетов контролируются единой прослойкой, что устраняет зависимость от версии, установленной глобально у разработчика или в CI.

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

Corepack, как мне кажется, сильно упростит жизнь большим командам. Исчезает вечная история “а у меня Yarn другой версии” или “Pnpm не подтянулся”. Corepack берёт на себя управление версионированием менеджеров пакетов, а значит, сборки становятся более воспроизводимыми. Для корпоративных проектов это плюс, особенно если речь идёт о распределённых командах или CI/CD-конвейерах.

WebSocket API и улучшенные Web Streams. Node.js 22 внедрил нативную поддержку WebSocket API. Теперь можно создавать WebSocket-клиенты и серверы без сторонних библиотек вроде ws. Это делает код чище и ближе к браузерному API.

Параллельно были улучшены Web Streams. Работа с потоками стала предсказуемой, а инструменты вроде CompressionStream и DecompressionStream функционируют так же, как и в современных браузерах. Поддержка универсального кода — сервер + клиент — стала проще, а объём внешних зависимостей уменьшился.

Улучшения в работе CommonJS и ESM. Node.js постепенно движется в сторону ESM, но у огромного количества проектов всё ещё используется CommonJS. В новой версии улучшена производительность смешанных проектов и сокращены ошибки при импорте модулей между двумя системами. Между ними появилось меньше «подводных камней», а значит миграция на ESM может идти постепенно, без ломки архитектуры.

Стабильный встроенный fetch(). Его реализация теперь полностью совпадает с браузерной, так что в простых кейсах можно отказаться от axios или node-fetch. Меньше зависимостей — быстрее запуск и меньше технического долга.

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

Я бы отметил более зрелую работу с Permission Model. Она уже не экспериментальная и реально помогает ограничивать доступ к файловой системе и сети. Параллельно улучшилась производительность V8, а вместе с ней и общая отзывчивость серверных приложений. Подтянули и Web-стек: стабильнее стали Web Streams, Request/Response и другие API, которые сближают Node с браузерами. Всё это не революция, но тренд на унификацию растёт.

Расширенные возможности тестирования. Node.js продолжает развивать встроенный тестовый фреймворк node:test. Теперь доступны кастомные репортеры, покрытие кода без внешних инструментов и mock timers (замена реальной работы таймеров). Это позволяет использовать встроенный тест-раннер для большинства задач, отказавшись от Jest или Vitest в простых проектах.

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

С точки зрения безопасности рывка не произошло, но заметное движение есть: Permission Model, улучшенная работа с OpenSSL, более аккуратная валидация входящих данных. Всё это снижает риски, но полностью опасность не снимает, потому что реальная безопасность всё равно лежит в архитектуре, процессов CI/CD и культуре разработки.

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

Международные стандарты и локализация. Были обновлены Intl API на базе новой версии ICU. Преимущества: точные часовые пояса, поддержка новых календарей и систем чисел. Это критично для глобальных SaaS-платформ, аналитических сервисов и финтех-продуктов.

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

Как безопасно мигрировать на Node.js 22

Переход лучше начинать с аудита и подготовки окружения. Сначала стоит убедиться, что все зависимости поддерживают Node.js 22. Особенно это касается библиотек, которые используют нативные модули, криптографию и WebSockets. Проверка совместимости позволит избежать неожиданностей вроде ошибок компиляции или падений при запуске.

После этого нужно прогнать тесты. Даже минимальный набор позволит выявить проблемы, связанные с изменениями в ESM/CJS, WebSocket API или OpenSSL.

Само обновление среды зависит от выбранного инструмента. Через nvm или n процесс занимает секунды, а для Docker достаточно указать новый базовый образ. Если проект использует CI/CD, стоит уделить внимание Corepack: теперь он активен всегда, что может изменить поведение сборки.

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

Обновление стоит внедрять поэтапно, начиная со staging или частичного продакшена, и держать готовность к откату.

Я обычно советую подход двухконтурного обновления. Сначала поднять проект на 22-ю версию в отдельной среде, включить максимальный объём логов, запустить тесты и прогнать реальные сценарии. Потом обновить линтеры, сборщики и самые старые пакеты, чтобы убрать накопленные за годы предупреждения. И только когда всё стабильно, имеет смысл переключать продакшен. По сути, обновление Node нужно делать так же аккуратно, как обновление облачных сервисов: через изоляцию, наблюдаемость и бэкап-стратегию.

В Node.js 22 удалены некоторые устаревшие, малоиспользуемые функции, поэтому при переходе может потребоваться рефакторинг мест, где они использовались. Следует проверить депрекейты: Node.js 22 помечает ряд старых возможностей как устаревшие и предлагает альтернативы. Необходимо убедиться, что все библиотеки и пакеты, используемые проектом, поддерживают новую версию Node.js.
При скачке сразу с 18/20 на 22 некоторые зависимости могут оказаться несовместимыми с обновлённым движком V8 или новыми APIs — может понадобиться их обновление до последних версий.

Кому стоит подождать с переходом

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

• Тем, кто использует инструменты сборки или менеджеры пакетов, которые ещё не совместимы с Node.js 22 и могут выдавать ошибки или не работать вовсе.​
• Командам, которые работают на старых версиях ОС. Известны проблемы совместимости с macOS 10.14 и ниже, а также возможны ошибки на Windows при миграции старых приложений.​
• Тем, чьи CI/CD, контейнеры или Docker-образцы завязаны на конкретные версии Node.js и npm. Переход на 22-ю версию требует много регрессионного тестирования.​
• Проектам с критически важными C++-добавками. Смена major-версии влечёт за собой обновление бинарных интерфейсов, что может вызывать ошибки при компиляции нативных модулей.
• Пользователям определённых интеграций. Для некоторых версий MongoDB‑драйверов зафиксированы фатальные баги после перехода на конкретные промежуточные версии Node.js 22.x.​
• Если вы используете проекты, которые сами рекомендуют Node.js 18 или 20, а обновление их зависимостей под 22 только планируется.

В продакшене чаще всего проблемы возникают не из-за самих изменений в платформе, а из-за того, как эти изменения проявляются в реальных проектах. Где-то обновился V8 и стал вести себя строже, где-то повылезали deprecated-модули, а где-то просто сломались сборщики или старые зависимости. Многие команды до сих пор живут на Webpack 4, Express 4 или TypeORM старых версий: вот они первыми столкнутся со сложностями.

Что дальше

Среди будущих трендов в экосистеме Node.js Максим Захаренко выделяет следующие: «Первое — постепенное сближение Node с Web-стеком, чтобы код становился максимально универсальным. Второе — рост влияния Bun и Deno, которые будут подталкивать Node к более агрессивной оптимизации. И третье — всё более активная интеграция с AI-инструментами, особенно в DevTools и в цепочках генерации кода».

Всё больше веб-API внедряются в Node.js (fetch, WebSocket, EventTarget). Этот тренд будет продолжаться. ESM становится стандартом, поддержка будет расширяться, CommonJS постепенно уйдёт в прошлое. Расширяется WASI и поддержка WASM-модулей. Node.js движется в сторону мульти-языковой среды. Модель прав доступа и другие sandbox-механизмы также продолжат развиваться. Кроме того, в версии Node.js 22.5.0 экспериментально добавлен встроенный модуль SQLite (через –experimental-sqlite). Это важное уточнение: в релизе 22.0.0 SQLite отсутствовал.

Даниил Гоник хотел бы увидеть в будущих релизах стабильную и удобную модель разрешений, возможность require() для ESM без флагов, улучшения в DevX: поддержка TS «из коробки», больше инструментов в ядре, расширение SEA (Single Executable Apps) и встроенные механизмы верификации зависимостей (подписи, integrity).

Выводы

Node.js 22 делает приложения быстрее, безопаснее и совместимее с Web API, улучшает работу с памятью и снижает зависимость от глобальных инструментов. Хотя переход требует подготовки, он не представляет серьёзных рисков, если следовать базовой процедуре: проверить зависимости, прогнать тесты и обновить среду постепенно. Если инфраструктура современная, а стек устойчивый, переход на Node.js 22 принесёт ощутимые преимущества как в скорости работы, так и в удобстве разработки.

В сети появился материал, автор которого — программист с 20+ летним стажем — вспоминает, как еще в 90-е взрослые уверяли его, что программирование обречено.

Тогда активно утверждалось, что ООП решит все проблемы раз и навсегда: появятся библиотеки-«кирпичики», а бизнес просто будет собирать приложения как LEGO, вообще без инженеров.

Прошли десятилетия, а профессия не только не исчезла — она стала одной из самых востребованных. Каждый уровень абстракции, который должен был «убить» разработчиков, просто поднимал планку и открывал новые задачи.

Мультимедиа, IDE и другие «концы света», которые не случились

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

Но через несколько лет это стало обыденностью — просто очередным <video /> в HTML. Никто массово не разорился из-за отсутствия мультимедиа в продуктах.

В 2000-х на горизонте появился новый «убийца профессии» — умные IDE вроде IntelliJ. Автодополнение, рефакторинг, перенос классов, исправление ошибок до сборки — все это казалось магией, которая вот-вот заменит людей.

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

Автоматизация в реальности: она освобождает время, а не людей

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

Вывод простой: работы становится не меньше, а больше. Автоматизация убирает рутину, но не отменяет необходимости решать новые проблемы.

Новые ввения приходят и уходят, но разработка остается

Интернет, Web 2.0, машинное обучение — каждая волна начиналась как революция и заканчивалась чем-то будничным. Мы привыкли к тому, что технологии, которые вчера казались чудом, сегодня воспринимаются как мелочь.

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

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

Вместо финала: ИИ не убьет разработчиков, но сделает их работу другой

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

Как и последние 30 лет, разработка остается живой потому, что мир постоянно усложняется. А значит — всегда будет кому этот мир программировать.

Среднее время активного использования встроенного дебаггера — 1,4% от общего времени кодинга. Это примерно 13 минут в месяц.

В то же время медианное значение и того меньше — всего 0 минут. Это означает: большинство разработчиков не открывали отладчик вообще.

Console.log правит миром

Как выяснилось, в 75% случаев разработчики никогда не ставили брейкпоинты, предпочитая старый-добрый console.log().

Остальные использовали отладчик лишь эпизодически: 10% — менее одного процента времени, и только 15% — чаще, чем раз в месяц.

В среднем структура работы выглядела так:

• 46,2% времени — написание кода, включая «отладку логами»;
• 28,7% — чтение и анализ чужого кода и стектрейсов;
• 23,7% — рефакторинг и удаление отладочных вставок;
• 1,4% — работа в интерфейсе отладчика VS Code.

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

Исследователи называют феномен «психологией мгновенного отклика»:

Сonsole.log("here") дает результат через 3 секунды. Настроить дебаггер — 10 минут. Мозг выбирает дофамин, а не дисциплину.

Среди других причин — привычка («мы изучали console.log с первого дня»), кажущаяся сложность интерфейса и эффект «еще одной строчки лога». Это когда проще добавить еще один console.log, чем переключаться в режим пошаговой отладки.

Что это значит

Исследование не утверждает, что разработчики не отлаживают код — просто делают они это вручную. В среднем около 15–20% рабочего времени уходит на расстановку логов, чтение вывода и перезапуск приложения.

Авторы FlouState считают, что освоение встроенного дебаггера могло бы сократить этот цикл в разы. Но для большинства программистов console.log() остается самым надежным и быстрым инструментом.

«VS Code имеет отладчик мирового уровня. Мы просто им не пользуемся», — подытожил автор исследования.

Испытание выполняли на одной и той же TypeScript-задачe (экспоненциальный бэкофф, управление состоянием, очередь сообщений), а выводы оценивал динамический судья — GPT-5.

Всего было пять критериев: качество, полнота, корректность, производительность и безопасность.

Результаты и рейтинг

Полный список восьми протестированных моделей (счет/токены):

1. GPT-5 — 93.4 / 7919 токенов
2. Claude Sonnet 4.5 — 89.0 / 8425 токенов = OpenAI o3 — 89.0 / 5191 токен
3. Gemini 2.5 Pro — 86.6 / 2621 токен
4. GLM 4.6 — 84.4 / 3334 токена
5. Claude Opus 4.1 — 81.6 / 6052 токена
6. Claude Haiku 4.5 — 74.4 / 13 666 токенов
7. Grok 4 — 70.0 / 888 токенов

Haiku сгенерировал наибольшее количество токенов (13 666) и занял лишь 7-е место по итоговой оценке.

Почему Haiku хуже — проблема переусложнения

Разбор показал: Haiku стремилась покрыть все — большие слои логирования, множество абстракций, метрики, дублированные функции. В результате:

• качество кода: 60/100 (много дублирования и смешанных ответственностей),
• корректность: 65/100 (повторяющиеся определения, потенциальные ошибки в боилерплейте),
• полнота: 90/100 (много функционала реализовано).

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

Sonnet 4.5, напротив, дала более компактный, корректный и читабельный код: 8425 токенов и 89 баллов.

Что это значит на практике

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

Для инженеров и команд это сигнал — оценивать ИИ-генерацию не по объему, а по компактности, ясности и корректности.

Вывод

Claude Haiku 4.5 оказался эффективен в покрытии функциональности, но не в написании качественного, поддерживаемого кода.

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

Меня зовут Юрий Каган, я Software/System Architect в IT_ONE. Расскажу об опыте применения Stryker.NET на проекте в крупном банке.

Качественные юнит-тесты — основа надежного ПО

Несмотря на то, что юнит-тесты — только один из компонентов пирамиды тестирования ПО, они — база для создания качественного кода:

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

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

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

Для оценки качества юнит-тестов разработчики обычно пользуются метрикой Code Coverage, отражающей процент покрытия тестами исходного кода. Такая информация может собираться различными способами в зависимости от типа используемого инструмента, но результат получается схожий: данные о том, какие конкретно фрагменты кода выполнялись во время тестов. О каких бы то ни было проверках речи не идет. То есть, по нашему опыту, технически очень легко можно написать тесты, которые будут давать 100% Code Coverage и при этом ничего не проверять. Это означает, что даже высокий процент покрытия кода тестами не гарантирует, что они разработаны качественно и поведение вашего кода надёжно зафиксировано. После них нельзя исключать скрытые ошибки.

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

Но существует и другая, не столь широко известная метрика, которая более объективно описывает надёжность проведённых тестов: она определяется в процессе мутационного тестирования. Первые упоминания об этом подходе мы встречаем еще в 1970-х годах. Тогда он уже признавался перспективным, но в то же время — практически неприменимым из-за запредельного объема работы. Сегодня мы имеем возможность автоматизировать большую часть этой работы с помощью инструментов, например, Stryker.NET.

Принципы мутационного тестирования

Алгоритм мутационного тестирования достаточно прост: в исходный код (базу) вносятся различные изменения (мутации). Существует несколько разновидностей мутаций. Основные из них:

– изменение операторов: замена арифметических и логических операторов (например, + на -, >= на >),

– изменение значений: замена булевых значений, удаление вызовов методов или изменение литералов,

– изменение условий: в if, циклах и логических выражениях.

Затем на этом модифицированном коде выполняются модульные тесты для проверки их чувствительности к изменениям. Мутанты, которые вызывают провал тестов, считаются «убитыми» (Killed Mutants), остальные — «выжившими». По итогу проверки формируется отчет, где ключевая метрика качества тестов — Mutation Score — доля убитых мутантов от их общего количества. Если тесты не «убивают» подавляющее число мутантов, значит их нельзя считать достаточно эффективными.

Среди инструментов для автоматизации проведения мутационного тестирования мы остановили выбор на Stryker.NET и вот, почему:

– на данный момент Stryker.NET обладает наибольшим объемом автоматизированных операций: он самостоятельно вносит мутации в исходный код, запускает юнит-тесты и генерирует подробные отчеты;

– Stryker.NET полностью интегрирован с .NET-экосистемой: поддерживает .NET и .NET Framework, основные тестовые фреймворки (xUnit, NUnit, MSTest);

– Stryker.NET – это бесплатный инструмент с открытым исходным кодом, постоянно обновляемый и поддерживаемый сообществом, что гарантирует его актуальность и развитие.

По нашей практике, Stryker.NET будет полезен для трех категорий пользователей:

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

– Ревьюер может быстро и надежно проверить качество тестов в pull request.

– ИТ-архитектор и руководитель разработки могут регулярно строить и анализировать отчеты, чтобы мониторить «здоровье» юнит-тестов во всей кодовой базе.

Установка и использование Stryker.NET

Технически Stryker.NET представляет из себя dotnet tool. Соответственно, чтобы его установить, необходимо выполнить команду в cmd или в PowerShell консоли:

dotnet tool install -g dotnet stryker

Получение и анализ отчетов: результаты выводятся в консоль и сохраняются в подробном HTML-отчете.

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

dotnet stryker -p “project.csproj” -tp “c:\git\project.tests\project.tests.csproj”

В результате тестирования программа сгенерирует отчет, где в первой колонке будет выведена метрика Mutation Score в целом по проекту и по отдельным файлам, причем разделённая на две группы: Of total — общее количество мутантов, Of covered — количество мутантов, находящихся в тех фрагментах кода, для которых вообще существуют тесты.

В колонке Killed отображается количество убитых мутантов, в колонке Survived — количество выживших. В колонке Timeout — количество мутантов, которые привели к зацикливанию выполнения тестов и их прерыванию утилитой. Значения остальных колонок, а также другую важную информацию можно посмотреть в документации на официальном сайте https://stryker-mutator.io/docs/stryker-net/introduction/.

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

Stryker.NET умеет генерировать отчеты не только в HTML, но и в других форматах: например, в JSON, который очень удобен для автоматического анализа, если разработчики планируют встроить этот инструмент в свой CI/CD-пайплайн. Кроме того, есть встроенный дашборд, который, к сожалению, невозможно развернуть локально — он доступен только как online сервис (https://dashboard.stryker-mutator.io).

Применение Stryker.NET при разработке банковских продуктов

Мы внедрили использование Stryker.NET в проекте для крупного банка, чтобы с помощью этого инструмента решить ряд взаимосвязанных задач. Самая главная проблема заключалась в том, что мы хотели улучшить качество тестов посредством мутационного тестирования, но его проведение вручную — предельно утомительная и требующая много времени процедура. Ни Product Owners, ни разработчики не были готовы постоянно выделять на это ресурсы.

Без регулярного мутационного тестирования, нам было практически невозможно оценить текущее состояние всей кодовой базы с точки зрения качества unit тестов. У нас было много unit тестов, мы имели высокий процент Code Coverage, но не знали, насколько эти тесты нас защищают. В свою очередь, без понимания текущего состояния у нас не было возможности устанавливать команде цели по улучшению ситуации.

На данный момент команда активно использует Stryker.NET на всех этапах разработки.

Мы столкнулись и с ограничением использования Stryker.NET: попытка его интеграции в CI/CD-пайплайн оказалась неудачной. Это связано с тем, что кодовая база проекта насчитывает несколько миллионов строк, и выполнение всех проверок занимает примерно 12 часов. Однако мы думаем, что на проектах меньшего размера такая интеграция должна сработать.

Мы выбрали альтернативный вариант: был внедрен регулярный автоматический пост-релизный прогон Stryker.NET по ветке master, в результате которого генерируется сводный отчет. Проводится анализ изменений сводного отчета по всем проектам от релиза к релизу. По данным каждого сводного отчета мы можем оценивать работу конкретных проектных команд, и если их метрика Mutation Score недостаточно высока, – ставить цели по улучшению.

Резюме

Итак, мутационное тестирование – мощный инструмент для повышения качества юнит-тестов и, соответственно, качества кода. Оно позволяет не только узнать, какой процент кода покрыт тестами, но и убедиться в том, что эти тесты действительно защищают код от ошибок.

Внедрение Stryker.NET — шаг к более надёжной и предсказуемой разработке. Его регулярное использование помогает уверенно вносить изменения, рефакторить код и добавлять новый функционал.

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

GPT-5 — флагманская reasoning-модель с упором на агентные сценарии, кодинг, интеллект и управляемость. «Из коробки» она хорошо решает широкий спектр задач, но качественные промпты (подсказки) заметно повышают стабильность, скорость и соблюдение инструкций. Ниже — проверенные практики, готовые шаблоны и заметки по параметрам API (reasoning_effort, verbosity, Responses).

Предсказуемость агентного рабочего процесса

Используйте API Responses для агентов

Responses сохраняет логические следы между вызовами инструментов: это снижает задержку, экономит токены и повышает качество планов за счёт механизма previous_response_id.

Контролируйте «рвение» агента

Сдержанный режим (меньше вызовов, ниже задержки):

• Установите reasoning_effort=low|medium.
• В подсказке ограничьте глубину поиска контекста и задайте ранние критерии остановки.

Проактивный режим (больше автономии и настойчивости):

• Поднимите reasoning_effort.
• Включите явное требование «не возвращаться к пользователю до полного решения».

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

При ограничении основного поведения сбора контекста полезно явно предоставить модели запасной вариант, облегчающий выполнение более короткого этапа сбора контекста. Обычно это делается в виде условия, позволяющего модели продолжать работу в условиях неопределенности, как «even if it might not be fully correct» в примере выше.

С другой стороны, если вы хотите поощрить автономность модели, увеличить настойчивость в вызове инструментов и сократить количество уточняющих вопросов или иных случаев возврата информации пользователю, рекомендуется увеличить reasoning_effort и использовать такой промпт, чтобы поощрить настойчивость и тщательное выполнение задачи:

Хорошая практика — чётко указать условия остановки задач агента, обозначить безопасные и небезопасные действия и определить, когда, если это вообще возможно, модель может вернуть данные пользователю. Например, в наборе инструментов для покупок инструменты оформления заказов и оплаты должны явно иметь более низкий порог неопределённости, требующий пояснений пользователя. В то же время инструмент поиска должен иметь чрезвычайно высокий порог; аналогично, в конфигурации кодинга инструмент удаления файлов должен иметь гораздо более низкий порог, чем инструмент поиска grep.

«Преамбулы» к инструментам (чтобы пользователь понимал, что происходит)

GPT-5 обучен предоставлять чёткие предварительные планы и последовательные обновления о ходе работы с помощью сообщений «преамбулы инструмента».

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

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

Усилия рассуждения и повторное использование контекста

• reasoning_effort регулирует интенсивность размышлений и готовность к вызову инструментов. Значение по умолчанию — medium. Но для многошаговых задач повышайте этот показатель.
• Разбивайте сценарий на несколько ходов агента с сохранением previous_response_id в Responses — модель не тратит токены на перестройку плана.
• Настоятельно рекомендуют использовать API Responses в GPT-5, чтобы улучшить потоки агентов, снизить затраты и повысить эффективность токенов в приложениях. Авторы отмечают, что наблюдали статистически значимые улучшения в оценках при использовании API Responses по сравнению с завершением чата. Например, рост оценки Tau-Bench Retail с 73,9% до 78,2% был только благодаря переходу на API Responses и включению previous_response_id (функции передачи предыдущих элементов рассуждений в последующие запросы). Это позволяет модели ссылаться на предыдущие трассировки рассуждений, экономя токены и устраняя необходимость перестраивать план с нуля после каждого вызова инструмента, что снижает latency. Эта функция доступна всем пользователям API Responses.

Максимизация продуктивности в кодинге

GPT-5 умеет работать с крупными кодовыми базами, накатывать многофайловые изменения, рефакторить и строить новые приложения.

Рекомендованный стек для фронтенд-приложений

• Фреймворк: Next.js (TypeScript), React, HTML
• Стили/UI: Tailwind CSS, shadcn/ui, Radix themes
• Иконки: Lucide / Heroicons / Material Symbols
• Анимации: Framer Motion
• Шрифты: Inter, Geist, Mona Sans, IBM Plex Sans, Manrope

Разработка приложений с нуля

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

Соответствие стандартам разработки

При внедрении постепенных изменений и рефакторинга в приложения, код, написанный на основе модели, должен соответствовать стандартам стиля и дизайна и максимально аккуратно вписываться в кодовую базу. Без специальных подсказок GPT-5 автоматически ищет справочный контекст в кодовой базе, например, читая package.json для просмотра уже установленных пакетов. Но это поведение можно улучшить с помощью подсказок, обобщающих ключевые аспекты, такие как принципы разработки, структура каталогов и передовой опыт кодовой базы.

Фрагмент подсказки ниже демонстрирует один из способов организации правил редактирования кода для GPT-5: не стесняйтесь изменять фактическое содержание правил в соответствии со своими предпочтениями в программном дизайне.

Форматирование Markdown

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

Иногда соблюдение инструкций Markdown, указанных в системном запросе, может ухудшаться в течение длительного разговора. Если вы столкнулись с такой ситуацией, стабильное соблюдение инструкций Markdown будет работать при добавлении их к каждому 3–5 пользовательскому сообщению.

Это значит, что даже без подписки Ultimate вы сможете использовать и разрабатывать плагины на основе Language Server Protocol.

Что произошло?

JetBrains продолжает переход к единой дистрибуции IntelliJ IDEA — начиная с версии 2025.3, будет один установщик для всех пользователей, вне зависимости от подписки.

Уже в версии 2025.2 вступает в силу новый fallback-режим. Это бесплатный уровень для пользователей с истекшей подпиской, в котором доступен ограниченный набор возможностей IDE.

Одна из ключевых новостей: поддержка LSP API теперь входит в этот бесплатный набор. Ранее такая возможность была только в Ultimate-редакции, но впредь плагины на основе LSP можно запускать и без платной лицензии.

Что это значит для разработчиков плагинов?

Если вы пишете плагины на базе Language Server Protocol, они станут доступны куда более широкой аудитории — не только платным пользователям IntelliJ Ultimate, но и тем, кто работает в бесплатном режиме.

Важно: поддержка LSP исчезнет из Community Edition (она будет выведена из обращения после релиза 2025.2), так что fallback-режим станет основным способом бесплатного использования LSP в IntelliJ. Чтобы использовать LSP в своих плагинах, нужно:

• Таргетить IntelliJ IDEA Ultimate 2025.2.1 или новее.
• Указать опциональную зависимость на модуль com.intellij.modules.lsp.

Что умеет LSP в IntelliJ?

LSP API в платформе IntelliJ уже поддерживает:

• Подсказки с resolve-поддержкой.
• Переход к определению.
• Документацию при наведении.
• Диагностику.
• Code actions и быстрые фиксы.
• Форматирование документов.

В то же время представители JetBrains подчеркивают, что LSP — это не замена PSI. Встроенная PSI-система остается основой глубокой интеграции языков в IDE и именно она обеспечивает расширенные функции вроде рефакторинга, анализа кода и т.д.

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

Что дальше?

Полный переход случится с релизом 2025.3, когда Community Edition перестанет существовать как отдельная сборка, а fallback-режим станет основной бесплатной точкой входа.

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

Он делит подходы к ИИ на два лагеря и предупреждает об опасностях одного из них.

Два подхода: помощник и костыль

Разработчик предлагает разделить все способы работы с ИИ на два условных сценария.

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

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

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

Учеба — это неотъемлемая часть кодинга

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

В этом и заключается суть разработки: постоянное обучение и понимание контекста. Именно это позволяет находить лучшие решения и писать надежный код. А не просто автоматическая генерация функций.

ИИ может «украсть» этот путь

Автор отмечает: с появлением так называемого агентного кодинга (agentic coding), где ИИ-инструменты вроде Cursor и Claude Code могут взять задачу «под ключ», часть инженеров рискуют потерять контроль над кодом и проектом.

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

Я не могу сказать «это ошибка ИИ» — ответственность все равно на мне. Поэтому я лучше сначала сам реализую решение, а уже потом спрошу ИИ, как его улучшить.

Опасный соблазн скорости

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

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

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

Вывод: ИИ — не замена, а партнер

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

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

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

GPT-5 думает с помощью инструментов

Эксперты из Latent.Space отметили, что GPT-5 демонстрирует новый уровень интеграции с внешними средствами: от баз данных и интерпретаторов кода до веб-поиска и интерфейсных API.

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

Это делает GPT-5 особенно сильным в инженерных задачах. Например, она смогла с первого раза устранить сложные конфликты зависимостей в реальном проекте, где другие модели (Claude, o3, Cursor) справиться не смогли.

Кроме того, GPT-5 успешно создаёт полноценные веб-приложения «с нуля» — от HTML и CSS до баз данных, причём с минимальными подсказками от пользователя.

GPT-5 — не лучший писатель, но идеальный инженер

Парадоксально, но GPT-5 проигрывает предшественникам вроде GPT-4.5 в задачах творчества и письма.

Там, где GPT-4.5 сохраняет стиль и тон автора, новая модель выдает слишком «рыночные» и шаблонные ответы. Однако в инженерных задачах — от рефакторинга до генерации сложных SQL-запросов — GPT-5 не знает себе равных.

Разработчики называют GPT-5 «практичной» моделью: она буквальна, понятлива и предсказуема. Ей можно задавать чёткие цели, и она будет выполнять их последовательно и точно.

Агентская эпоха наступила

Авторы Latent.Space называют выход GPT-5 «началом каменного века для агентов». Аналогия: человечество стало разумным, когда научилось использовать инструменты. Так же и GPT-5 — она мыслит через инструменты.

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

Демо GPT-5 на русском

Представьте: пятница, 18:30. Релиз через час. Вы меняете один роут в конфиге — и внезапно половина приложения отлетает. Поздравляем, вы только что познакомились с классической болью фронтендеров.

Проблема кроется в самой природе JavaScript. Строковые пути вроде /users/profile/${id} существуют в коде как обычные строки — без проверок, автокомплита и гарантий корректности. Опечатался в /usres вместо /users — и твоя навигация сломалась, а TypeScript молчит как рыба.

Двадцать лет назад мы кликали по window.location.href, десять лет назад — радовались React Router, а сегодня пора переходить на типизированные решения.

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

Суть проблемы

Проблема очевидна: путь /admin/products размазан по всему коду. TypeScript не знает, что эти строки связаны с определенной директорией, поэтому не проверяет их корректность. Опечатка в product вместо products — и вылетает ошибка 404.

В больших проектах эта проблема критична. Приложение с 200+ путями, где навигация разбросана по сотне компонентов, превращается в минное поле. Один программист меняет структуру URL, а остальные даже не подозревают об этом. Команды используют TypeScript для типобезопасности, но навигация остается уязвимой.

Что такое типизированная навигация?

Типизированная навигация превращает строковые пути в типизированные объекты. Вместо /admin/products/123/edit программист работает с функциями, которые знают структуру приложения и проверяют корректность написания путей на этапе компиляции.

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

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

Польза зависит от уровня разработчика:

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

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

Как использовать React Router вместе с TypeScript

Для базовой типизации в React Router v6 сначала определите структуру путей. Создайте интерфейс, который описывает все пути в приложении:

Типизация параметров URL решает проблему с useParams. Вместо any получаете конкретные типы:

Query-параметры типизируются аналогично через useSearchParams. Создайте интерфейс для каждой страницы с query-параметрами и оберните хук.

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

Как внедрить типизированную навигацию в проекты

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

Конфигурация избавит от нужды дублировать код при генерации типов. TypeScript автоматически выведет все возможные пути и их параметры из одного объекта.

Современные библиотеки решают проблему из коробки. Например, Tanstack Router предоставляет полностью типизированную систему путей с автогенерацией типов, а Type-route создает типобезопасные пути через API.

Библиотека typesafe-routes внедряется даже в крупные проекты без необходимости менять сотни строк кода.

Выбор инструмента зависит от размера программы. Если у вас небольшое приложение — быстрее написать хук в пару строк. Но если разрабатываете сложный сервис — используйте библиотеки.

Как не сломать код при использовании типизированной навигации

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

Чеклист для код-ревью поможет не уронить прод:

• Все новые navigate() и используют типизированные версии;
• Параметры путей явно типизированы;
• Нет магических строк в навигации;
• Query-параметры описаны интерфейсами.

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

Автоматизация упрощает процесс. ESLint правило no-hardcoded-routes запретит использование строк в навигации. Код-генераторы создают типы из OpenAPI схем или конфигурации роутера.

Производительность не страдает — типы исчезают после компиляции. Теряется немного времени на компиляцию TypeScript, но экономия на отладке перекрывает затраты.

Где применять типизированную навигацию

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

E-commerce проекты выигрывают от типизации каталогов и фильтров. Пути вроде /catalog/:category/:subcategory?filters=price,brand содержат много параметров, которые легко сломать при рефакторинге.

Интеграция с Redux и Zustand упрощает синхронизацию состояния с URL. Типизированные селекторы автоматически обновляются при изменении роутов:

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

Типизированная навигация — стандарт современной разработки. Команды, которые до сих пор полагаются на строковые пути, тратят лишнее время на поиск багов. Программисты увереннее рефакторят код, не боятся мелких ошибок и не роняют прод в пятницу вечером из-за одного символа в пути.

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

Как все начиналось

Sandpolis задумывался как универсальный инструмент для системных администраторов. Идея пришла в университете, энтузиазма хватало. Уже в 2019 году у проекта была рабочая Java-серверная часть (~50 000 строк кода) и небольшой iOS-клиент на Swift (~10 000 строк).

Но затем случился «переписон» — автор решил, что все нужно перевести на Rust, «язык будущего». Так началась вторая жизнь проекта. К сожалению, безрезультатная.

Почему за 7 лет не получилось даже MVP

Вот как сам автор описывает главные причины провала:

• Переписывание ради языка. Rust стал увлечением, и проект превратился в площадку для экспериментов, а не развития продукта.
• Фокус на «интересном», а не важном. Вместо ключевых проблем (например, проработки модели данных) автор занимался второстепенными деталями: паролями, мелкой оптимизацией.
• Дыры вместо структуры. Поскольку сложные задачи откладывались, проект обрастал кусками кода, которые не складывались в единую систему.
• Отсутствие дисциплины. Основной диагноз: нежелание делать трудное и скучное. Работа велась по принципу «где интересней» — но не «где нужней».

Что автор понял спустя 7 лет

Дисциплина — это то, чего в инженерии сегодня не хватает так же сильно, как хорошего вкуса.

Основные выводы:

• Делай приоритетное — даже если оно скучное. Не отвлекайся, пока не решишь главную задачу.
• Чем дольше код сломан — тем сложнее его починить. Правки должны возвращать проект в рабочее состояние как можно быстрее.
• Не переписывай без причин. Переписка кода на новом языке может уничтожить весь прогресс.
• Ранние ошибки становятся дорогими. Лучше «заплатить» временем сразу, чем страдать потом.
• Идеи без реализации — это просто мечты. Рабочий код важнее красивых концептов.

Что дальше

Разработчик пообещал, что в 2025 году он сосредоточится только на одной вещи: идеальной модели данных для Sandpolis. А уже после — будет строить вокруг нее приложение.

В статье мы разберёмся, как запустить кодген на основе OpenApi схемы для веб-приложения на стэке React + redux-toolkit.

Для справки: контракт — соглашение о формате данных между клиентом и сервером

Какие проблемы решает кодген?

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

В микро-сервисной архитектуре цена таких ошибок высока — оперативно доставить обновления многочисленным клиентам иногда бывает проблематично.

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

Синхронизация контрактов

При активной разработке бекенд постоянно обновляет контракты. Без кодгена все обновления на стороне фронтенда синхронизируются вручную.

Также на основе контрактов создаются побочные интерфейсы, например, для redux-слайсов и react-компонентов. Ошибка в основном контракте создает цепочку проблем со связанными типами и интерфейсами.

Сочетание кодген-контрактов и typescript-утилит для создания побочных интерфейсов делает доставку обновлений простой и безопасной.

Устранение дубликатов

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

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

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

Что понадобиться для кодгена?

Прежде чем запускать кодген нам нужно минимально настроить проект:

Подготовить схему

OpenAPI-схема в формате yaml:

Важно: Любая ошибка в схеме приводит к поломке кодгена. Поэтому важно, чтобы ваша схема проходила валидацию.

Проверить валидность OpenAPI схемы можно на в swagger редакторе

Настроить Redux

Redux-клиент для API-запросов:

Redux-слайс для хранения данных из API-запроса:

Redux-хранилище с подключенным API-клиентом и редюсером:

Настроить кодген

Для кодгена возьмём официальную библиотеку от Redux — @rtk-query/codegen-openapi

Затем создадим файл настройками кодгена:

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

Если вам нужна гибкость, попробуйте использовать @openapitools/openapi-generator-cli с различными готовыми шаблонами или Orval от tanstack

Запуск кодгена

Для запуска добавим команду в package.json:

Далее заходим в корень проекта и запускаем команду:

На выходе должен получиться файл codegenApi.ts с содержимым:

Проверяем результат:

• Инджект кодген эндпойтов в baseApi;
• Системные типы Props Response Error;
• Контракт User;
• RTK-query хуки.

Совет: создание кодгена можно автоматизировать, например, сделать его отдельным этапом в CI/CD, который выполняется прямо перед билдом приложения.

Возможные проблемы

Необычные типы данных

При внедрении кодгена в проект на Kotlin я столкнулся с проблемой парсинга: кодген не мог распарсить тип данных LocalDateTime, который должен возвращать строку с датой в формате ISO. Вместо строки когден возвращал пустой объект.

LocalDateTime — это класс из Java-библиотеки java.time, который представляет дату и время без учёта временной зоны.

Данную проблему я решил с помощью кодмода:

Кодмод запускается после команды codegen. Он бежит по файлу сверху вниз, находит нужный тип и меняет его значение на string.

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

Кодмоды отлично генерируются с помощью AI.

Плюсы и минусы кодгена

Плюсы:

• Генерируем API-слой всего приложения за секунды;
• Получаем автоматическое строгое создание интерфейсов и типов;
• Избавляемся от опечаток в URL и параметрах;
• Обнаруживаем проблемы с обратной совместимостью контрактов на ранних этапах сборки;
• Экономим время.

Минусы:

• Качество кодгена зависит от качества описания OpenAPI схемы;
• Если схема не генерируется в автоматическом режиме, актуальности OpenAPI схемы потребуется поддерживать вручную;
• Логику нестандартных запросов придётся описывать вручную.

Напоминание: API-слой сложного проекта невозможно покрыть кодогенерацией на 100% — это нормально. Будьте готовы при помощи методов enhanceEndpoints и injectEndpoints комбинировать когден-эндпойнты с эндпойнтам написанными вручную

Заключение

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

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

Ускоряй работу, автоматизируй рутину, используй лучшие тулзы. Все самые полезные инструменты тут.

Больше новостей — в нашем тг-канале «Представляешь»

Он просто хотел заменить phpMyAdmin чем-то более безопасным и понятным для клиентов. Сегодня у его проекта — более 30 000 звезд, клиенты из списка Fortune 500 и команда из 50 человек.

10 лет в одиночку

Первые 10 лет инструмент был сугубо личным. Без сообщества, без поддержки, без амбиций. Только PHP, MySQL и Бен. Когда-то он просто поставил на стол счетчик звезд с GitHub — и каждая новая звезда ощущалась как маленькая победа.

10 000 звезд: первая волна

Где-то в 2015 году о проекте начали говорить — в Reddit, Slack, GitHub Explore. К проекту присоединился Рейк ван Зантен, будущий со-основатель.

Вместе они вычистили кучу спагетти-кода, переписали все с PHP на Node и Backbone на Vue. Тогда же их позвали в Сан-Франциско — крупная компания хотела внедрить проект, но испугалась, что за ним стоит всего два человека без юрлица.

20 000 звезд: время становиться бизнесом

Хейнс закрыл имевшееся у него агентство и оформил компанию. Поднял $1 млн, собрал команду, запустил облачный сервис.

Затем, после сотни встреч с инвесторами и обвала венчурного рынка, нашел партнера, который понял ценность OSS. Удалось закрыть $8 млн — и с этого момента встал вопрос устойчивости: как зарабатывать, не предавая open-source?

Ответ — собственная лицензия с бесплатным использованием для всех, кроме корпораций. Работали даже с Брюсом Перенсом, сооснователем OSI.

30 000 звезд: устойчивость

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

И да, недавно они тихо подняли еще $9 млн — на новый архитектурный рефакторинг.

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

Итеративная разработка: почему начал с малого

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

Почему именно конвертер? Это идеальный “hello world” для криптомира:

• нужно подключить внешний API (в моем случае — CoinGecko)
• есть базовая бизнес-логика
• есть простое взаимодействие с пользователем

Это не только полезный юзкейс, но и отличная точка входа для чего-то большего.

Архитектурные решения v1.0

1. Работа с CoinGecko API

Первая реализация была прямолинейной:

Проблема: Каждый запрос — это сетевой вызов. При 1000 пользователях мы превысим лимиты API.

Решение в v1.1: Добавил кеширование через @lru_cache с TTL=5 минут.

2. Упрощённая машина состояний

Вместо полноценного FSM использовали словарь:

Почему не FSM? Для v1.0 важна была скорость реализации. Aiogram 3.x предоставляет отличный FSM, но его настройка требует дополнительного времени.

3. Валидация ввода

Я решил использовать гибридный подход:

• Кнопки для выбора криптовалюты
• Ручной ввод суммы с regex-валидацией:

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

Расскажу о проблемах, с которыми столкнулся. Спойлер: они были.

Ненадёжность публичных API

CoinGecko иногда отвечает 10+ секунд или возвращает 502. Решение:

Особенности пользовательского ввода

Даже с кнопками пользователи умудрялись:

• Присылать “BTC” вместо “bitcoin”
• Использовать запятые вместо точек
• Вводить отрицательные суммы

Пришлось добавить нормализацию:

Состояния при перезапусках

При деплое нового кода все сессии сбрасывались. Временное решение — ручное сохранение в JSON, в планах — переход на Redis.

Наступив на все грабли, я продумал дальнейший roadmap. Среди приоритетов:

1. Система алертов
2. Графики через matplotlib
3. Portfolio tracker

Код и рефакторинг

Проект выложен на GitFlic. Самые спорные места кода:

1. Отсутствие DI — сервисы передаются через глобальные переменные
2. Смесь sync и async вызовов
3. Тесты покрывают только core-логику

Приветствуются пулл-реквесты, особенно по:

• Улучшению обработки ошибок
• Оптимизации запросов к API
• Рефакторингу хендлеров

Вы можете проголосовать за дальнейшую ветвь развития в Опроснике на моем ТГ-канале.

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

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

Container + Presentational Components

На первом месте работы ещё во время разработки на Vue мы с подачи нашего тимлида решили ввести этот паттерн. Глобально у нас были так называемые «умные» и «тупые» компоненты (или как я тактично называл их на демо — визуальные). Как вы наверняка догадались, роль Container у нас исполняли «умные» компоненты, а роль Presentational — «тупые». В чём, собственно, суть этого паттерна? Слышали выражение «разделяй и властвуй»? Паттерн Container & Presentational Components (контейнерные и презентационные компоненты) ровно об этом: он разделяет логику (данные и взаимодействие с ними) и отображение (UI) на разные компоненты.

Presentational Components отвечают только за то, как что-то выглядит. Они получают данные через props и отображают их, больше ничего. Это, как правило, чистые функциональные компоненты, часто без собственного состояния (ну разве что мелкий UI-стейт типа «раскрыт ли dropdown»). Им всё равно, каким образом взять список пользователей — они просто ожидают условный props.users и отображают его в соответствии с дизайном.

Container Components, напротив, знают, что показать и откуда это взять, но не занимаются тем, как это отображается. Они содержат в себе всю логику: могут загрузить данные, подписаться на store или контекст, хранить состояние, а рендерят в презентационных компоненты, передавая им готовые данные. Контейнер может вообще не иметь собственного HTML, кроме того, что приходит от дочернего презентационного компонента. Его задача — это взаимодействие с данными.

Зачем же нужен такой подход? Во-первых, лучшая разделённость ответственности (UI отдельно, данные отдельно) упрощает понимание и поддержку приложения. Во-вторых, улучшается переиспользование: один визуальный компонент вероятно использовать с разными источниками данных через разные контейнеры. Дизайнеры могут менять внешний вид компонента в одном месте, не затрагивая бизнес-логику. И тестировать тоже проще: можно отдельно протестировать логику контейнера (без верстки) и отдельно визуальный компонент (с моком данных).

В этом примере UserList не содержит никакого стейта, не подписан на store или контекст, лишь отображает список. Ему всё равно, как и где получают пользователей — просто принимает проп users и выводит его. Контейнер UserListContainer же занимается работой с данными: делает fetch, сохраняет результат в useState, и потом рендерит UserList, прокидывая в него данные. Благодаря такому делению компонент UserList легко переиспользовать — хоть для локальных данных, хоть для данных из Redux или context — достаточно написать другой контейнер.

Конечно, не всегда нужно городить пару компонентов вместо одного. Этот паттерн полезен, когда приложение растёт: вы начинаете замечать, что пропсы идут через несколько уровней просто транзитом, или один компонент слишком перегружен логикой. Тогда вы «вытаскиваете» логику в контейнер, а UI — в презентационный компонент, и код сразу становится чище. Это не обязательное правило, а приём для рефакторинга по мере необходимости.

Стоит отметить, что с появлением React-хуков граница между логикой и отображением несколько размылась. Теперь можно выносить логику в кастомные хуки и вызывать их прямо внутри компонента, вместо того чтобы создавать отдельный контейнер-класс, как это делали до 2018 года. Тем не менее, принцип «держи логику отдельно от представления» по-прежнему полезен. Даже с хуками можно структурировать код, разделяя функциональность: написать хук useUsersData() для получения пользователей и применять его в разных компонентах (вместо дублирования запроса).

Плюсы: чёткое разделение обязанностей, возможность переиспользовать и заменять части независимо (UI-компонент можно переиспользовать с разными данными), облегчение тестирования.

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

Higher-Order Component (HOC)

Когда я впервые услышал термин HOC, он показался мне чем-то из математики. Но на практике всё горадо прозаичнее: HOC — это всего лишь функция, которая принимает React-компонент и возвращает новый компонент, оборачивая исходный дополнительной функциональностью. Проще говоря, HOC — это «обёртка». Мы помещаем один компонент внутрь другого, чтобы на выходе получить расширенную версию переданного в HOC компонента.

Зачем это может понадобиться? Представим, у нас есть несколько разных компонентов, и всем им нужно что-то общее: например, обработка ошибок или подписка на внешние данные. Можно было бы скопировать этот код в каждый из компонентов, но куда элегантнее написать HOC один раз и применить ко всем. Классический пример — Redux-функция connect: вы пишете export default connect(mapState)(MyComponent), и ваш компонент получает пропсы из глобального стейта.

connect — как раз и есть HOC, который инъектирует данные из Redux в компонент, не требуя от вас переписывать все под Redux вручную.

Создать свой HOC тоже несложно. Супер банальный пример — сделаем HOC, который добавляет компоненту стейт счётчика:

Здесь withCounter — HOC, он возвращает новый функциональный компонент WithCounter, который внутри себя использует useState и передаёт состояние и функцию увеличения внутрь WrappedComponent. В итоге EnhancedButton — это улучшенная версия ClickButton, которая умеет считать клики, даже если исходный ClickButton об этом не знал.

Плюсы: один HOC может добавить функциональность множеству компонентов сразу — не надо копировать код везде. Логику обновляется в одном месте (внутри HOC) — и все обёрнутые компоненты получают изменения. HOC можно комбинировать: например, обернуть компонент сначала в HOC, добавляющий тему оформления, потом в HOC, добавляющий логирование, и т.д. В итоге получим компонент, обладающий сразу несколькими дополнительными возможностями.

Минусы: за такую магию мы платим усложнением структуры. Когда компонентов обёрток становится много, React-дерево раздувается, и возникает эффект «матрёшки». В DevTools вы могли видеть что-то вроде: Connect(withRouter(WithTheme(MyComponent))) — разобраться, что к чему, становится сложнее. Дебаг таких цепочек — тоже удовольствие то ещё, приходится пробираться через несколько уровней абстракций. Кроме того, HOC часто прокидывают пропсы во внутренний компонент, что чревато конфликтами имён (нужно следить, чтобы, например, prop.title от HOC не перезаписал пропс title, который вы передали самому компоненту). Ещё нюанс — HOC усложняют типизацию в TypeScript (надо правильно описывать generic для пропсов), но это выходит за рамки нашей темы.

React-разработчики со временем несколько охладели к HOC. В официальной документации прямо сказано: «компоненты высшего порядка не так часто используются в современном React-коде». Отчасти их вытеснили хуки, тем не менее, HOC никуда не делись: их продолжают применять сторонние библиотеки — тот же Redux, Relay и другие. Да, и в старом проекте вы почти наверняка встретите хотя бы пару HOC. Поэтому понимать этот паттерн стоит. Просто имейте в виду современные альтернативы и используйте HOC там, где это действительно необходимо.

Паттерн Render Props

Следующий паттерн я бы назвал «перевёрнутый HOC». Render Props — это подход, когда компонент сам не рендерит что-то внутри себя, а принимает функцию (часто через проп render или просто используя детей как функцию) и вызывает её, чтобы получить содержимое. То есть мы передаём компоненту инструкцию, что именно отрендерить, а он сам обеспечивает, когда и с какими данными вызвать эту инструкцию.

Представьте компонент <MouseTracker> для отслеживания положения курсора. Классически он может хранить x, y в своём состоянии и отрисовывать, скажем, <p>Mouse at (x, y)</p>. Но что, если мы хотим переиспользовать эту логику уже с другим UI? Паттерн Render Props предлагает сделать компонент <Mouse>, который не определяет жёстко JSX внутри себя, а вызывает функцию, переданную через проп (или children функцию), передавая ей координаты. Эта функция сама решит, что рисовать. Таким образом, <Mouse> инкапсулирует логику (слежение за мышкой), а отображение делегирует наружу.

Пример: реализуем компонент-утилиту <FilteredList items={...} filter={...}>, который отображает список на основе передаваемого фильтра. Вместо того чтобы жёстко прописывать разметку элемента списка, сделаем его с render проп через children:

Здесь <FilteredList> знает, как отфильтровать массив (items.filter(filter)), но не знает, как отрисовать каждый элемент. Вместо этого он вызывает функцию, которую мы передали в качестве дочернего элемента (children), для каждого элемента списка. Эта функция возвращает <li> для каждого item. В результате логика фильтрации инкапсулируется внутри FilteredList, а конкретное отображение списка задаётся извне. Мы могли бы так же использовать этот компонент для массива объектов, отрисовывая, например, товары — достаточно передать другую children-функцию.

Паттерн Render Props здорово повышает гибкость компонентов. Мы можем переиспользовать <FilteredList> для списков чего угодно — чисел, пользователей, товаров — просто изменяя функцию отображения. Другой пример: компонент <Mouse> может предоставлять координаты курсора, а внешний код решит, просто вывести текст, нарисовать по координатам картинку или вызвать какую-то совершенно другую логику — не нужно делать несколько вариаций компонента для каждого кейса.

Плюсы: Render Props позволяет компоненту-провайдеру (в примере выше FilteredList является провайдером данных) быть максимально универсальным, а конкретную разметку делегировать наружу. Многие библиотеки воспользовались этим паттерном: например, React Router (до версии 6) позволял вместо компонента страницы передать проп render в <Route> — функцию, которая отрисует JSX на основе параметров маршрута. Formik предлагал компонент <Formik> с функцией-ребёнком для рендеринга формы. Downshift (библиотека для автокомплитов) — тоже классический пример паттерна render props.

Минусы: главное неудобство — излишний шум в JSX. Код с вложенными функциями бывает тяжело читать. В нашем простом примере всё компактно, но представьте, если у вас будет несколько уровней таких компонентов: <Foo>{foo => ( <Bar>{bar => ( ... )}</Bar> )}</Foo> — легко получить «оберточный ад» из стрелочных функций прямо в разметке. Это значительно затруднит отладку такого кода при возникновении каких-либо проблем. К тому же, каждый раз при рендере создаётся новая функция, что может негативно сказаться на производительности, если таких компонентов много (React конечно оптимизирует функции в пропсах через механизм сравнения, но всё же). Также возникает неявная связь: внешний код должен знать, какие аргументы ожидает функция. TypeScript конечно помогает, но при чтении кода не сразу видно, что children, например, это не просто элемент, а функция.

Как и HOC, паттерн Render Props сейчас используется реже. Многие задачи, решаемые через него, теперь элегантнее с точки зрения кода решаются хуками, в официальной документации это также отмечено. Но всё же понимать его нужно, потому что легаси-код и некоторые библиотеки всё ещё работают на нём. Если видите, что компонент принимает функцию в виде пропса (чаще всего называется render или передаваётся через детей), знайте — это он, Render Props.

В следующей части расскажу про хуки и кастомные хуки, а также про Compound Components и Серверные компоненты и Suspense.

Вместе с Артемом Геташвили и Анастасией Редченковой, менторами Solvery, мы собрали ТОП-10 самых раздражающих вещей, которые сводят программистов с ума.

Почему разработчики так часто жалуются?

Если вы хотя бы раз общались с программистом, то наверняка слышали жалобы на чужой код, странные требования от заказчиков и бесконечные дедлайны. Кажется, что IT-специалисты всегда чем-то недовольны. Но почему так происходит? Разве работа в IT — это не высокие зарплаты, гибкий график и интересные задачи? Давайте разберемся.

Миф о том, что разработчики просто «пишут код»

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

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

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

И, конечно же, баги. Их исправление может занимать часы, дни и даже недели.

Иногда они не дают спать, есть и нормально жить. Бывают простые баги, которые раскапываешь и чинишь за пару часов, а бывает, что ты на неделю-две уходишь в нее с головой. Если видите в 2 часа ночи где-нибудь человека на кухне с ноутбуком, кофе и красными глазами — это точно программист.

Почему раздражение — это нормально? (Но как не довести себя до выгорания?)

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

Как понять, что раздражение не угрожает вашему психическому здоровью?

Здоровое раздражение:

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

Выгорание:

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

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

Реальные причины, которые взрывают разработчикам мозг

Вместе с экспертами определили топ-10 вещей, которые выводят из себя даже самых стойких разработчиков.

Нереалистичные сроки

Что бесит?

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

Как бороться?

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

Постоянные прерывания и невозможность сконцентрироваться

Что бесит?

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

Как бороться?

• Блокировать время для глубокой работы.
• Устанавливать «тихие часы» в команде.
• Использовать методы Pomodoro, ALPEN, GTD и прочие.
• В офисе советую работать в наушниках с шумоподавлением.

Технический долг

Что бесит?

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

Как бороться?

• Внедрить правило в команде по обязательному рефакторингу каждый спринт (примерно 10–20% времени будет хватить на улучшение кодовой базы).
• Проводить код-ревью и следить за чистотой кода.
• Объяснять руководству, почему технический долг замедляет разработку.

Размытые и постоянно меняющиеся требования

Что бесит?

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

Как бороться?

• Требовать четкой документации требований.
• Фиксировать договоренности письменно.
• Использовать прототипы для согласования на ранних этапах.

Плохая документация

Что бесит?

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

Как бороться?

• Создавать и поддерживать актуальную документацию.
• Следовать стандартам оформления документации.
• Автоматизировать процесс обновления документации (например, Swagger).

Культура переработок

Что бесит?

В IT нередко ожидают, что ты будешь работать сверхурочно, чинить баги в продакшене ночью и быть на связи 24/7. Это ведет к выгоранию и снижению мотивации.

Как бороться?

• Четко устанавливать границы рабочего времени.
  
• Искать компании, где соблюдаются нормы трудового кодекса.
• Говорить «нет» переработкам, если это не форс-мажор.

Проблемы с зависимостями в проекте

Что бесит?

Обновляешь одну библиотеку — и рушится весь проект. Версии зависимостей конфликтуют, а разбираться с этим приходится вручную.

Как бороться?

• Фиксировать версии зависимостей.
• Использовать инструменты автоматической проверки совместимости.
• Регулярно обновлять пакеты, чтобы не копить проблемы.

Недооцененность работы разработчика

Что бесит?

Менеджеры и заказчики не понимают, сколько усилий уходит на написание чистого кода. Им кажется, что программисты просто «печатают код» и всё готово.

Как бороться?

• Показывать метрики и результаты работы.
• Объяснять технические решения простым языком.
• Искать признание среди коллег и в профессиональном сообществе.

Необходимость постоянно учить новые технологии

Что бесит?

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

Как бороться?

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

Ошибки, которые сложно отловить (дебаг и баги)

Что бесит?

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

Как бороться?

• Использовать системы логирования и мониторинга (например, Sentry, Datadog).
• Разрабатывать с учетом отладочности (например, писать больше тестов).
• Применять методы бэктрекинга, чтобы анализировать ошибки шаг за шагом.

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

Какой из этих пунктов раздражает вас больше всего? Делитесь в комментариях!

Проблема динамической типизации

Как мы обычно объявляем переменные в JavaScript? Просто пишем let или const, даём имя и присваиваем значение:

Никаких указаний типа. JavaScript не требует от нас заранее объявлять, что userName — это строка (string), а userAge — число (int). И в этом кроется как сила, так и слабость языка.

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

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

Удобно, да? Не надо прописывать int или string, среда сама определит, какой тип у переменной. Только вот иногда такой подход приводит к куче ошибок, особенно когда мы имеем дело с большим проектом.

Разберём на примере функции, которая рассчитывает итоговую стоимость товаров:

В этом примере мы получим 500300 вместо 800. Дело в том, что мы данные здесь в виде строки, а не числа. При этом во время выполнения JS решил, что мы хотим провести конкатенацию строк, и склеил числа.

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

В статье «Python Versus C++: An Analysis of Student Struggle on Small Coding Exercises in Introductory Programming Courses» проанализировали успехи студентов в решении задач по программированию на Python и C++. Студенты, которые работали с Python, чаще сталкивались с трудностями при решении задач (23% против 13% у C++) и это при том, что задачи были одинаковые. Python — язык с такой же динамической типизацией данных, как и JS. Большинство трудностей студентов были связаны с ошибками типизации. Вывод: динамическая типизация увеличивает количество ошибок.

Критичность ошибки с типами в крупных проектах

Теперь представьте, что мы работаем над системой рекомендаций в каком-нибудь крупном сервисе по типу Netflix. У нас десятки тысяч строк кода, тысячи переменных, и нам непонятно, какого они типа.

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

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

Инструменты JS для борьбы с ошибками типов и их недостатки

Не поймите неправильно, динамическая типизация — это удобно. Мы можем быстро разрабатывать прототипы, небольшие проекты и функции. Но в крупных проектах, таких как системы e-commerce или банковские приложения, где кодовая база превышает десятки тысяч строк, она может стать источником скрытых ошибок.

В JS есть инструменты, которые нивелируют эту проблему, но они тоже со своими нюансами:

JSDoc — аннотации типов прямо в комментариях, которые подсказывают IDE (например, VS Code) и разработчикам, что ожидается в коде:

Плюс: даёт автодополнение и базовую проверку типов в редакторе. Минус: это не часть языка, а просто подсказки — JS сам по себе их не проверяет на этапе выполнения или сборки.

'use strict' — включает строгий режим, который ловит некоторые ошибки (например, использование необъявленных переменных):

Плюс: убирает часть «опасных» особенностей JS. Минус: не влияет на типизацию напрямую, а только на синтаксис и поведение.

Ручная проверка в applyDiscount. Мы можем добавлять свои проверки типов:

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

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

Что такое TypeScript и как он решает проблему типизации

Строгая статическая типизация

TypeScript — язык программирования от Microsoft со строгой статической типизацией. Это значит, что перед объявлением переменной мы заранее определяем тип данных. Например, вот так выглядит переменная строки в JS и TS:

Мы добавляем к переменной tsString тип данных — string, тем самым, явно указываем, что наша переменная — это строка. Благодаря этому среда понимает тип данных до выполнения кода и распознаёт больше потенциальных ошибок.

При этом код на TypeScript компилируется в JavaScript. Так у нас сохраняются преимущества JS, но со статической типизацией и минимумом ошибок.

Более удобная работа в IDE

Компилятор TypeScript способен находить больше ошибок, чем JavaScript. Если среда разработки настроена корректно, то он будет находить ошибки на лету, включая проблемы с типами.

Рассмотрим 2 примера на JS и TS:

В выводе с JS после отладки мы получим 53, хотя должно быть 8. Из-за ошибки с типизацией переменной b, среда, скорее всего, не подсветит эту проблему, консоль отладки тоже явно на неё не укажет.

В пример с TS мы увидим ошибку ещё до отладки, сразу после ввода кода:

Но даже если по каким-то причинам IDE её не подсветит, мы обнаружим проблему при отладке:

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

Нам проще избежать ошибок, связанных с опечатками в именах свойств, вызовами методов с null объектами, передачей аргументов неправильного типа, отсутствием обработки возможных состояний данных. Если мы будем делать рефакторинг, то компилятор быстро подсветит места в коде, которые стоит обновить.

Лучшее понимание кода разработчиками

Также статическая типизация в TypeScript помогает лучше понять код. Мы можем видеть:

• Какие параметры принимает функция и какого они типа.
• Что функция возвращает.
• Какие свойства имеет объект.
• Какие значения может принимать переменная.

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

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

Сложно представить большой и сложный проект без TypeScript — сегодня это стандарт. Он помогает избежать простых, но очень коварных ошибок, например, передача неправильного типа данных в метод — ошибку увидите сразу. В целом, в таких вещах можно отметить быстрый цикл обратной связи, так как компилятор сразу сообщит о проблеме, и код, который мог бы работать неправильно, не дойдёт до продакшена.

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

На одном проекте в моей практике было стандартное правило, которое принимают разработчики, если серьезно относятся к типизации на Typescript. Это запрет на использование типа any. При этом, благодаря линтеру на этапе сборки коммита типа any в коде не было, приходилось все подробно типизировать. В процессе приходили новые разработчики и видели, что мы используем Typescript и все подробно описано, поэтому вопросов по коду у них почти не было.

Одним из ярких примеров стало внедрение TypeScript в разработку нашего фронтенда. Ранее в JavaScript у нас часто возникали проблемы, связанные с неправильными типами данных при передаче между модулями, особенно когда один разработчик писал код, а другой его использовал. В TypeScript строгая типизация и контракты между модулями помогли нам избежать многих таких ошибок. Еще один пример — API-интеграции. В JavaScript легко передать не тот объект или пропустить обязательное поле, что приводит к неожиданным багам в продакшене. С TypeScript мы смогли использовать интерфейсы и автоматические проверки.

Совместимость TypeScript с экосистемой JS

Многие популярные библиотеки и фреймворки поддерживают TypeScript. Например, можно смело кодить в React, Angular, Vue. Любой валидный JS код, в большинстве случаев, валиден и для TypeScript. Достигается это за счёт следующих «фишек»:

Тип any. Это универсальный тип данных, он отключает проверку типов в TypeScript. С одной стороны, этот подход немного неудобный, так как лишает разработчиков преимуществ статической типизации. С другой стороны, бывают случаи, когда это необходимо.

В этом примере функция берёт данные с сайта (API) и говорит TypeScript: «Не проверяй, что внутри, я сам разберусь с помощью any». Потом мы пишем data.user.name, и TS не ругается, даже если там нет user или name.

С одной стороны, any — это «костыль», который сводит на нет смысл TS, но с другой — он бывает полезен, например, при работе с плохо типизированными API.

Пакеты @types. Допустим, нам надо импортировать JS библиотеку в TypeScript код. Но эта библиотека не поддерживает TypeScript из коробки. Вариант с типом any нам не подходит, так как мы можем получить много ошибок. В таких случаях подойдёт @types.

Это обычные npm-пакеты из DefinitelyTyped. С их помощью мы получаем доступ к репозиторию, в котором хранятся файлы типов (.d.ts). В них прописаны типы данных для объектов, переменных и иных структур JS библиотек. С помощью этих файлов наш TS код сможет «переварить» JavaScript без ущерба для типизации.

На февраль 2025 года в DefinitelyTyped доступны типы для более чем 8 тыс. библиотек, что покрывает подавляющее большинство популярных npm-пакетов.

Пример установки пакета для библиотеки Lodash:

Файлы типов (.d.ts). Если мы используем какую-то старую JS библиотеку, она не поддерживает TypeScript и для неё нет файлов типов (.d.ts), мы можем прописать их вручную. Пример:

Мы сделали файл .d.ts, чтобы рассказать TypeScript, что старая библиотека old-lib имеет функцию doMagic, которая берёт строку и возвращает число. Теперь, когда мы пишем doMagic('test'), TS понимает, что результат — это число, и не даёт нам случайно использовать его как строку.

Файлы типов (.d.ts) не добавляют исполняемый код, а лишь описывают структуру библиотеки для компилятора TypeScript. Они как переводчик с русского на английский, который подсказывает правильные артикли.

TypeScript создавался с прицелом на полную совместимость с JavaScript, так что серьёзных проблем обычно не бывает. За последние пару лет я сталкивался с трудностями только в тех случаях, когда использовались старые библиотеки без типизации. Например, однажды пришлось подключить устаревший пакет, у которого не было деклараций типов. Мы решили это, написав минимальный `.d.ts` файл вручную — заняло полчаса. Для современных и популярных библиотек таких проблем не бывает — как правило, у всех есть поддержка TypeScript из коробки.

Недостатки TypeScript

Замедляет разработку

Когда мы пишем код на TypeScript, то вынуждены явно прописывать типы и исправлять большее количество ошибок, чем при разработке на чистом JS. Это замедляет процесс разработки.

Также не у всех JS библиотек есть встроенные типы TypeScript, иногда их приходится прописывать вручную, поэтому мы тратим время.

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

Избыточен для небольших проектов

Преимущества TypeScript актуальны для крупных продуктов, где работает команда разработчиков и много запутанного кода. Если мы пишем какой-то свой небольшой проект, например, одностраничный сайт, то у нас будет не так много объектов, классов, переменных и сложных структур. Можно написать это всё на TypeScript, чтобы упростить поддержку, но это замедлит разработку, плюс здесь можно обойтись и стандартными инструментами JS.

Сложная кривая обучения для новичков

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

Эпоха TypeScript не означает конец JavaScript — скорее, это новый этап в его эволюции. Динамическая типизация хороша для старта, но в сложных системах без строгих типов не обойтись. TypeScript становится всё популярнее, и это не просто хайп: он реально помогает избегать ошибок и ускоряет разработку в долгосрочной перспективе. Его точно стоит добавить в свой стек.

Как удалось достичь ускорения

Microsoft начала портировать TypeScript на нативный код, отходя от текущей JavaScript-реализации. В результате:

• Компиляция ускоряется в 9–13 раз (в зависимости от проекта).
• Редактор загружается в 8 раз быстрее (на примере Visual Studio Code).
• Потребление памяти уменьшилось почти вдвое.

Вот как изменилось время компиляции в известных проектах:

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

Редакторы и новые возможности

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

• Время загрузки VSCode сократилось с 9,6 до 1,2 секунд.
• Редакторы станут быстрее за счет перехода на Language Server Protocol (LSP).
• Автодополнение, поиск ссылок, навигация и рефакторинг станут мгновенными.

Будущее TypeScript: версия 7.0 и переходный период

• TypeScript 6.x (JS) продолжит получать обновления.
• TypeScript 7.0 (нативный) выйдет, когда достигнет полной совместимости.
• Обе версии будут поддерживаться параллельно до полного перехода.

Microsoft обещает регулярно публиковать обновления о проекте.

Первая версия нативного TypeScript для CLI появится уже в середине 2025 года, а полноценный релиз ожидается к концу года.

Анализируем производительность API

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

• Время отклика — сколько времени проходит от запроса до получения ответа.
• Нагрузка на сервер — сколько ресурсов потребляет API при обработке запросов.
• Частота ошибок — как часто сервер возвращает некорректные ответы.

Отслеживать эти показатели помогают инструменты вроде Postman, New Relic и APM-систем. Они визуализируют данные, автоматизируют тестирование и позволяют находить проблемы в режиме реального времени.

Postman

Используется для ручного тестирования запросов. Postman показывает время отклика и ошибки. Также через него удобно тестировать сценарии работы API.

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

Большой гайд по работе с Postman API Platform

New Relic

Платформа для мониторинга производительности приложений. Можно отслеживать время обработки API-запросов, статистику по операциям, загрузку системы.

New Relic показывает распределение времени выполнения между сервером, БД и внешними сервисами, что помогает в рефакторинге разных частей системы.

APM-системы

Инструменты Datadog, AppDynamics или Dynatrace сохраняют данные о том, как работает API. Через них можно смотреть трассировку запросов, выявлять проблемы с медленными вызовами или зависимостями от внешних систем.

Ищем узкие места в запросах

Для выявления проблемных фрагментов кода необходимо посмотреть, как API реагирует на разные нагрузки, и как распределяется время обработки запроса.

Поиск состоит из 7 этапов:

• Анализ общей картины. С помощью APM-систем и логирования нужно выделить самые медленные запросы.
• Локализация длинных операций. В одном запросе может быть несколько узких мест (тяжелый SQL-запрос, внешний API-вызов).
• Поиск запросов с высокой частотой вызовов. Например, запросы к слою авторизации или ручки API, к которым обращаются массово при каждом действии пользователя.
• Проверка ошибок. Ошибки приводят к дополнительной нагрузке: например, если клиент совершает повторные запросы после тайм-аута.
• Анализ распределения нагрузки. Если одни эндпоинты перегружены трафиком, а другие используются редко, в рамках рефакторинга нужно сбалансировать нагрузку. Например, добавить серверы только под обработку горячих эндпоинтов.
• Тестирование в условиях пиковой нагрузки. Стресс-тест средствами JMeter поможет выявить проблемы, скрытые в условиях обычного трафика.
• Анализ зависимостей API. Замедленная работа внешнего сервиса увеличивает время отклика для каждого запроса. Через Jaeger или Zipkin можно посмотреть цепочку зависимостей.
• Локализация длинных операций. В одном запросе может быть несколько узких мест (тяжелый SQL-запрос, внешний API-вызов).

Оптимизация запросов к базе данных

Уменьшить время отклика API без переписывания кода можно за счёт оптимизации работы с БД. Один из ключевых инструментов — индексы. Они ускоряют поиск данных, снижая нагрузку на сервер.

Что индексировать в первую очередь:

• Поля, используемые в WHERE, JOIN, ORDER BY, GROUP BY. Например, если запросы часто фильтруют по email, имеет смысл добавить индекс.

• Запросы с несколькими условиями фильтрации — их лучше оптимизировать составными индексами. Важно, чтобы порядок полей соответствовал порядку в SQL-запросах.

• Только те данные, где индексация действительно ускорит поиск. Например, индекс для gender (male/female) не даст прироста скорости.

Лишние индексы замедляют операции записи, их нужно удалять. В PostgreSQL они могут пересекаться, но при дублировании замедляют запросы. Вместо нескольких отдельных индексов эффективнее использовать составные.

Агрегация и выбор только необходимых полей

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

Например, команда SELECT * выбирает все колонки таблицы, включая неиспользуемые. Вместо SELECT * FROM users следует указывать целевые поля: SELECT id, name, email FROM users.

Если к запросу добавлены ненужные JOIN-ы, группировки или сортировки, в рамках рефакторинга нужно постараться избавиться от них. Избыточные операции на стороне БД рекомендуется переносить в бизнес-логику приложения.

Снизить объем данных можно за счет COUNT, SUM, AVG, MAX, MIN — эти функции возвращают обобщенные записи вместо отдельных значений. Частичную обработку данных можно выполнять на стороне БД. Например, в PostgreSQL есть встроенные функции по типу JSON_AGG.

Пагинация и лимиты в запросах

API, работающие со списками пользователей и транзакциями, обязательно должны использовать пагинацию. Лимит на объем возвращаемых записей предотвращает перегрузку серверов и клиента.

Самое простое решение — во время рефакторинга ограничить количество строк с помощью LIMIT или FETCH FIRST. Например, вместо загрузки всех пользователей SELECT id, name FROM users LIMIT 30 вернет только первые 30 строк.

Еще можно использовать постраничную выборку (комбинацию LIMIT и OFFSET):

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

Пагинация с курсорами заменяет OFFSET значением последнего взятого элемента. Например, вместо LIMIT 20 OFFSET 100 можно использовать запрос:

Чтобы пагинация работала корректно, всегда нужно использовать явный ORDER BY.

Пагинация на Go в PostgreSQL

Кэширование

Количество запросов к серверу можно сократить, если сохранять часто запрашиваемые данные. Это называется кэшированием. Рефакторинг кэширования уменьшает нагрузку на сервер, снижает время отклика API.

Рассмотрим инструменты для кэширования.

Redis

Подходит для серверного и распределенного кэширования. Поддерживает TTL, работу со списками, хэшами и включение репликации для отказоустойчивости. Для интеграции доступны библиотеки и клиенты — ioredis для Node.js или StackExchange.Redis для .NET.

Как использовать Redis для кэширования и очередей в веб-приложениях

Рефакторинг кэширования повысит производительность сервиса:

• если API возвращает неизменяемые или редко изменяющиеся данные,
• если часть запросов к БД выполняется кратно дольше остальных.

Например, в Redis можно сохранять список активных пользователей:

Memcached

Применяется для уменьшения нагрузки на базу данных и работы с временными данными. Memcached менее функционален, чем Redis, но более эффективен для сценариев, где не требуется сложная логика или постоянное хранилище.

Как использовать серверы Redis и Memcached для кэширования

Виды кэша

Выбор типа кэширования зависит от архитектуры API и характера данных.

• Клиентский кэш — данные хранятся на стороне клиента. Например, браузеры загружают страницу дольше в первый раз, но затем мгновенно извлекают её из кэша.
• Серверный кэш — данные сохраняются на сервере или в промежуточном хранилище (Redis, Memcached). Это снижает нагрузку на базу данных: повторные запросы возвращаются из кэша, а не пересчитываются заново.
• Распределённый кэш — данные кэшируются в нескольких узлах для масштабирования и высокой доступности. Например, Redis в режиме кластера помогает организовать кэширование в микросервисной архитектуре.

Уменьшение объема передаваемых данных

Скорость API зависит от объема данных, передаваемых между клиентом и сервером.

Оптимизация формата ответа: JSON vs Protobuf

Формат JSON популярен из-за читаемости и универсальной поддержки большинством языков программирования. Он менее эффективен по сравнению с бинарными форматами. JSON занимает больше места из-за текстового представления структур и значений.

Protobuf (Protocol Buffers) — бинарный формат, разработанный Google. Он компактен, быстрее сериализуется и занимает меньше места по сравнению с JSON. В формате Protobuf каждый элемент закодирован с минимальным количеством байтов.

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

Удаление избыточных данных и компрессия

Часто API отправляет больше данных, чем реально нужно клиенту. Это лишний сетевой трафик и задержки:

• Удаление ненужных полей — ограничение выборки данных на стороне сервера: используются выборочные запросы к БД, настройка сериализаторов или фильтрация на уровне представлений.
• Сжатие Gzip — уменьшение размера текстовых данных (JSON, XML) на 70–90%, не требуя изменений в API. Включается на уровне Nginx, Apache или через middleware. Клиенты автоматически распаковывают такие ответы, сохраняя прозрачность процесса.

Версионирование API

Клиенты обычно нуждаются в данных разного объема. Вместо универсального ответа для всех пользователей рекомендуется разработать несколько версий API.

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

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

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

Параллелизация и объединение запросов

Оптимизировать API можно за счет рефакторинга batch-запросов. Они объединяют несколько запросов в один — количество обращений между клиентом и сервером сокращается.

Клиенты отправляют массив запросов, сервер обрабатывает их и возвращает всего один ответ.

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

Например, мобильное приложение может запрашивать информацию о пользователе и связанных с ним объектах (сообщения, уведомления) за один вызов.

Если API поддерживает вложенные запросы, клиент может запрашивать связанные данные одним вызовом. Пример на GraphQL:

Асинхронные операции

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

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

Для асинхронных операций часто используются очереди сообщений RabbitMQ или Apache Kafka.

Оптимизация на уровне серверной логики

Обработку запросов можно откладывать до момента, когда данные действительно понадобятся. Это полезно при работе с запросами, где связанная информация не требуется или используется не полностью. Такое поведение называется lazy loading (ленивая загрузка).

Загружать связанные данные можно заранее в одном запросе, чтобы сократить количество запросов к БД. Такой принцип работы API называется eager loading (стремительная загрузка). Используется в случаях, когда известно, что все связанные данные понадобятся в ходе операции.

Lazy loading подходит, если только небольшая связка данных используется в каждом запросе.

Eager loading лучше применять, когда количество запросов к БД критично или весь объем данных необходим для выполнения операции.

Очереди для обработки задач в фоне

Вместо выполнения тяжелых задач в реальном времени, сервер может добавлять их в очередь, чтобы они обрабатывались фоновыми воркерами.

Очереди используются для задач, не влияющих на основной ответ клиенту:

• отправка писем,
• формирование отчетов,
• обновление статистики,
• построение индексов,
• обработка данных.

При поступлении запроса API выполняет только основные операции (валидацию данных или запись в базу), после чего создает задачу в очереди. Процессы выполняются в отдельной среде, не влияя на основной поток обработки запросов.

Разделение сложных операций на этапы

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

Вместо последовательного выполнения всех шагов, задачу можно поручить системе планировщиков или pipeline в Jenkins. Каждый этап становится в очередь и выполняется отдельным процессом.

Мониторинг и тестирование

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

• нагрузочное тестирование,
• сравнение метрик до и после рефакторинга,
• автоматизацию наблюдения за состоянием API.

Нагрузочное тестирование определяет, как API справляется с возрастающей нагрузкой. Оно выявляет точки перегрузки. Инструменты для стресс-теста API: Apache JMeter, Gatling.

На основе результатов нагрузочного тестирования можно проанализировать, насколько рефакторинг улучшил производительность API. В сборе метрик помогут APM-инструменты.

Если показатели значительно улучшились, поздравляем, рефакторинг удался.

Автоматизация мониторинга повышает надежность API и предотвращает проблемы до их масштабного проявления. Инструменты для поддержания производительности в реальном времени: Prometheus + Grafana, Datadog.

Что запомнить

• Производительность API оценивается с помощью метрик: времени отклика, нагрузки на сервер и частоты ошибок.
• Для мониторинга API используются инструменты Postman, New Relic и APM-системы, которые выявляют узкие места системы.
• Оптимизация запросов к базе данных включает индексацию, удаление избыточных операций и выбор только необходимых полей. Для работы с большими объемами данных используется пагинация с применением LIMIT, OFFSET или курсоров.
• Кэширование снижает нагрузку на сервер, сохраняя востребованные данные локально.
• Уменьшение объема передаваемых данных достигается за счет перехода с JSON на Protobuf, компрессии Gzip и фильтрации полей.
• Для сокращения числа запросов к API применяются batch-запросы.
• Асинхронная обработка операций с помощью очередей RabbitMQ или Kafka ускоряет время отклика API для клиентов.
• Очереди для фоновой обработки задач снижают нагрузку на основной поток запросов.
• Нагрузочное тестирование помогает оценить улучшения после рефакторинга.
• Автоматизация мониторинга предотвращает проблемы API до их критического проявления.

Что такое облачные IDE и почему они важны

Облачные IDE (или онлайн-редакторы кода) позволяют работать над проектом прямо из браузера, без сложной локальной настройки окружения. На сервере уже установлены необходимые инструменты (компиляторы, интерпретаторы), можно быстро переключаться между различными стеками технологий. Это удобно, когда нужно:

1. Быстро протестировать идею или прототип,
2. Работать из любого места и с любого устройства,
3. Обучаться программированию (особенно новичкам, которым сложно настраивать среду разработки),
4. Совместно редактировать код в реальном времени.

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

Replit

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

Возможности

• Поддержка множества языков: Python, JavaScript, C++, Java, Go, Rust и другие.
• Встроенный чат с искусственным интеллектом (Ghostwriter) для помощи в написании кода.
• Возможность совместной работы: можно дать ссылку коллеге, и он зайдёт в ваш проект, чтобы вместе отлаживать или рефакторить код.
• Хостинг: Replit умеет публиковать веб-приложения «на живом URL» одним нажатием кнопки.

Плюсы

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

Минусы

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

Где пригодится

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

CodeSandbox

CodeSandbox ориентирован, прежде всего, на фронтенд-разработчиков. Он замечательно подходит для проектов на React, Vue, Angular, Svelte и других библиотечных и фреймворковых решениях.

Возможности

• Автоматическое создание окружения для фронтенд-проектов: нужен React? Выбираем шаблон — и сразу получаем структуру, файлы конфигурации и пакетный менеджер.
• «Live preview» (живая перезагрузка): при каждом изменении в коде страница в правой части обновляется без перезагрузки.
• Интеграция с GitHub: можно подтянуть репозиторий, внести правки в CodeSandbox, а затем запушить изменения обратно.
• Возможность запускать бэкенд-сервер (через Docker-контейнеры) в отдельных sandboxes.

Плюсы

• Удобно для веб-разработки: всё уже настроено (Webpack, Vite или другие сборщики).
• Поддержка TypeScript из коробки.
• Отлично работает совместное редактирование, есть возможность прямого «шеринга» результатов.

Минусы

• Фокус именно на веб-технологиях, так что для языков, не связанных с фронтендом, CodeSandbox не всегда подойдёт.
• Бесплатные sandboxes могут засыпать при простое, что не всегда удобно для постоянного хостинга.

Где пригодится

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

GitHub Codespaces

GitHub Codespaces — по сути, облачное продолжение Visual Studio Code. Если у вас есть репозиторий на GitHub, вы можете открыть его в Codespaces и получить преднастроенную среду разработки прямо в браузере. Это решение особенно нравится разработчикам, которые уже привыкли к VS Code.

Возможности

• Полноценная интеграция с GitHub: открываем репозиторий, создаём Codespace, и всё готово к работе.
• Расширения VS Code в облаке: многие привычные плагины можно установить и использовать.
• Поддержка Docker и Dev Containers: можно создавать контейнеры со своим набором инструментов, чтобы каждый член команды имел идентичную среду.
• Возможность «подцепиться» к Codespaces и локальным VS Code, если хочется работать в офлайне или со своим привычным окружением.

Плюсы

• Знакомая среда для тех, кто пользуется VS Code.
• Гибкий вариант конфигурации (Dev Containers), позволяющий упростить онбординг новых сотрудников.
• Нет проблем с зависимостями: всё хранится в контейнере, поэтому переходить между проектами очень удобно.

Минусы

• Требует платного тарифного плана GitHub, если нужен серьёзный объём ресурсов (хотя есть ограниченное бесплатное время).
• Для маленьких проектов может быть избыточен, так как мощь Codespaces раскрывается больше в средних и крупных командах.

Где пригодится

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

JetBrains Fleet

Fleet — новый проект от JetBrains, который позиционируется как «умная и быстрая» IDE нового поколения. Предлагается как облачная среда с возможностью локальной установки. JetBrains известны своими тяжёловесными, но очень функциональными IDE (IDEA, PyCharm, WebStorm и т.д.), а Fleet стремится занять более лёгкую нишу с возможностью работать в облаке.

Возможности

• Режим «смарт-редактирования», когда Fleet по мере необходимости подгружает функции анализа кода.
• Распределённая архитектура: можно разворачивать часть Fleet в локальном окружении, часть — в удалённом, чтобы снизить нагрузку на машину.
• Совместное редактирование кода в реальном времени, причём JetBrains обещают, что это будет «ровно, как в Google Docs, только для кода».

Плюсы

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

Минусы

• Fleet пока ещё развивается, некоторые функции отсутствуют или реализованы не до конца.
• Менее дружелюбен к новичкам, чем Replit или CodeSandbox, потому что ориентирован скорее на опытных разработчиков.

Где пригодится

• Разработка на языках, где особенно важны рефакторинг и интеллектуальные подсказки: Java, Kotlin, Python и т.д.
• Если нужна более «лёгкая» альтернатива классическим IDE JetBrains, но при этом с возможностью работать удалённо.

StackBlitz

StackBlitz — ещё один «фронтенд-ориентированный» онлайн-редактор, но с упором на выполнение кода прямо в браузере без специальных серверных окружений. Он запускает Node.js-среду в браузере через WebAssembly, благодаря чему проекты могут работать очень быстро и автономно.

Возможности

• Мгновенный запуск Angular, React, Vue, Svelte и т.д., без серверной компоненты.
• Поддержка Node.js-приложений (через WebContainers) прямо в браузере: по сути, локальная VM работает «внутри» вкладки.
• Отличная интеграция с GitHub и возможность деплоя проектов.

Плюсы

• Реально быстрая загрузка и мгновенный старт проектов на популярных фреймворках.
• Почти не зависит от «серверной» стороны, потому что всё работает через WebContainers.
• Хорошо подходит для офлайн-режима (в разумных пределах).

Минусы

• Частично функционал ограничен: если нужны какие-то специфические системные зависимости, WebContainers могут не справиться.
• Не так универсален, как решения уровня GitHub Codespaces. В первую очередь он предназначен для веба.

Где пригодится

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

Мой личный опыт и выводы

За 10 лет работы программистом я привык, что «настоящая IDE» должна быть у меня локально, с тщательно настроенными плагинами. Однако чем дальше, тем больше я использую облачные решения. В одних случаях это экономит время на настройке окружения, в других — позволяет быстро работать даже на слабом устройстве, а в третьих — просто удобно для совместной разработки.

• Replit я использую, когда хочу быстро показать фрагмент кода на собеседовании или протестировать идею на маломальном языке, где нет желания ставить компилятор локально.
• CodeSandbox прекрасно подходит для демонстрации и прототипирования фронтенд-проектов. Идеально, если нужно поделиться примером React или Vue-компонента.
• GitHub Codespaces — моё решение для серьёзных проектов, где нужна стабильная облачная среда уровня VS Code, плюс глубокая интеграция с GitHub Actions и репозиториями.
• JetBrains Fleet я «щупаю» как потенциальную легковесную замену IntelliJ IDEA, но с возможностью облачной синхронизации и удалённой мощью серверов JetBrains. Пока рано говорить о полной замене, но направление впечатляет.
• StackBlitz — это «волшебство», когда нужно поднять Node.js в браузере. Очень люблю показывать StackBlitz на воркшопах по фронтенду, потому что всё запускается буквально за секунды.

Какую из этих сред выбрать — зависит от задач и предпочтений. Если вы профессионал, который «сидит в одной IDE 8 часов в день», возможно, вы пока предпочтёте локальные решения. Но всё чаще облачные сервисы дают такую же мощь и удобство, причём сэкономив кучу времени на конфигурации. В любом случае, всем рекомендую попробовать, хотя бы ради эксперимента. Может оказаться, что облачная IDE для некоторых задач станет вашим новым любимым инструментом.

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

Почему TTM считается злом, выдуманным менеджерами

В разработческих кругах нередко можно услышать скептическое отношение к TTM. Эта метрика воспринимается как инструмент давления со стороны менеджмента: “Сократите сроки! Ускорьте процессы! Почему мы до сих пор не выпустили фичу?”

Вот основные причины:

1. Поверхностное сокращение сроков. Вместо того чтобы разбираться в главных причинах задержек, руководство часто требует банально сократить сроки. Это может привести к снижению качества кода, поскольку в таком случае вы отказываетесь от рефакторинга и уменьшаете время на тестирование, а значит, продукт на выходе будет куча багов. Вы можете даже пропустить важные стадии проектирования, и в результате получаете непродуманный продукт.
2. Выгорание сотрудников. Постоянное давление со стороны менеджмента заставляет команды работать в условиях жестких дедлайнов. Это может вылиться в хронический стресс и выгорание, а потом — в низкий уровень вовлеченности и отсутствие мотивации. Следовательно, высокая текучка кадров и дальнейшее усугубление проблемы.
3. Фокус на скорости, а не на ценности. Менеджеры, ориентированные исключительно на TTM, могут забывать о главной цели разработки — создании ценности для юзера. В результате продукт выходит на рынок недоработанным (но я давно не видел полностью доработанных продуктов выходящих на рынок) и не удовлетворяет потребности целевой аудитории. Как следствие, пользовательский опыт у нас ухудшается, что может негативно сказаться на репутации компании.
4. Конфликты внутри команды. Когда TTM становится основным KPI, команды начинают ощущать постоянное давление. Это часто приводит к разногласиям между менеджерами и разработчиками, снижению доверия к руководству и в итоге к потере «командного духа», поскольку каждый отдел начинает бороться за выполнение своих задач в ущерб общим целям.

Типичные примеры, которые я встречал:

• В одной из компаний менеджмент решил сократить TTM, урезав время на тестирование. Это привело к тому, что после выпуска продукта пришлось устранять множество багов, что в итоге заняло больше времени, чем изначальная доработка.
• В другой ситуации команда была вынуждена работать сверхурочно несколько месяцев подряд, чтобы уложиться в установленные сроки. Итог — массовое увольнение ключевых специалистов.

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

Почему TTM — это простая и полезная метрика

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

Несколько преимуществ правильного использования TTM:

1. Объективный показатель скорости. TTM четко показывает, как быстро идеи становятся реальными продуктами. Это позволяет выявить узкие места в процессе разработки (например, слишком долгие этапы технического проектирования, согласования или тестирования) и оценить эффективность внедрённых изменений в рабочие процессы.
2. Фокус на ценности для пользователя. Чем быстрее новая функциональность будет доступна пользователю, тем быстрее он сможет ею воспользоваться, следовательно, аудитория может закрыть свои потребности. За счет этого мы укрепляем конкурентное преимущества компании и в итоге увеличиваем доход благодаря более быстрому выходу продукта на рынок.
3. Стимул к оптимизации процессов. TTM помогает выявить и устранить неэффективные процессы. Например, автоматизация тестирования может сократить время на проверку функциональности. А улучшение коммуникации между отделами ускоряет согласование задач.
4. Поддержка стратегического планирования. Понимание TTM позволяет нам реалистично оценивать сроки вывода продукта на рынок и учитывать временные рамки при планировании рекламных кампаний и запуске связанных инициатив.
5. Мотивация для команды. Когда TTM используется как инструмент для улучшения, а не для давления, он помогает командам чувствовать удовлетворение от оперативного выполнения задач и понимать вклад каждого участника в общий успех.

Пара успешных примеров применения TTM:

• Компания внедрила автоматизацию процессов пайплайна CI/CD , что сократило TTM на 30%. Это позволило быстрее тестировать и выпускать обновления.
• В другой компании улучшили взаимодействие между бизнес-аналитиками и разработчиками, сократив время на согласование требований. В результате TTM для новых фич уменьшился на 20%.

Баланс между скоростью и качеством

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

Заключение

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

Сбой длился 4 часа и привёл к сбою в работе Netflix, Airbnb и даже Комиссии по ценным бумагам и биржам США. А виной всему человеческий фактор: сотрудник занимался рутинной отладкой системы, ошибся в команде и отключил сервера, которые отключать было нельзя.

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

Так отлаживать или дебажить?

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

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

Ошибки бывают разные:

Синтаксические

Синтаксическая ошибка –– это, например, забытая закрывающаяся скобка или пропущенный отступ.

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

В Python обязательно нужно ставить двоеточие после объявления функции. Без этого язык не поймет, что за двоеточием следует тело функции. Поэтому программа выполнена не будет.

Как правильно:

Логические

Логические ошибки –– неправильная логика программы. Код может выполняться без проблем в синтаксисе и не выбрасывать исключения, но при этом не давать ожидаемого результата. Такие ошибки трудно отследить, потому что Python не сообщает о них явно.

Допустим, мы пишем программу для проверки чётности:

Вместо проверки number % 2 == 0 проверяется number % 2 == 1. Это логическая ошибка.

Исключения

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

Разберём деление на ноль. Это действие вызовет исключение ZeroDivisionError:

Такие исключения можно обрабатывать, чтобы программа не упала. Используем try-except:

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

Перейдём к инструкции по отладке.

Шаг 1: Анализируем ошибки и логи

Перед тем, как отлаживать код, важно понять: что именно пошло не так? Поэтому первый шаг –– анализ.

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

Что с ними делать:

1. Изучите сообщение об ошибке. Важно понять, где и почему произошёл сбой. Обычно сообщение указывает тип ошибки и место, где она возникла. Мы уже видели такое поведение в предыдущем разделе, когда забыли поставить двоеточие;
2. Проверьте логи. В логах будут важные данные об ошибке. Обратите внимание на ключевые слова: Error или Exception;
3. Воспроизведите ошибку. Попробуйте выполнить код несколько раз. Возможно, это был случайный баг, который больше не повторится.

Шаг 2: Разделяем задачу на более мелкие части

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

Как это работает:

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

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

• Загружается ли файл?
• Обработались ли данные?
• Успешно ли записывается результат?

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

Это лучше, чем хаотично бросаться то в одну, то в другую часть кода и искать иголку в стоге сена.

Шаг 3: Воссоздаём проблему

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

Тут стоит схитрить:

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

И тут мы подобрались к самому интересному. Пока что мы говорили о том, как решать проблему. Но не упомянули, с помощью чего. Исправляемся.

Отладчики и логирование

Отладчики встроены в большинство IDE. Например, в PyCharm или Visual Studio есть встроенные отладчики, с помощью которых можно поставить точки останова.

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

Как это работает:

1. Установите точку останова в нужной строке;
2. Запустите программу в режиме отладки;
3. Выполнение остановится на этой строке: изучите текущие данные.

Разберём на примере Visual Studio:

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

Поставим точки останова на переменных width, height и result:

Перейдём вот в эту панельку:

И запустим дебаггинг:

После запуска в редакторе появится новая панелька –– для управления отладкой:

С помощью неё можно остановить или перезапустить отладку, перейти к следующей точке останова и так далее.

В панели слева появятся значения, за которыми мы следим:

Здесь вы можете увидеть, чему равна каждая переменная.

Напишем функцию с ошибкой, которую уже разбирали:

Мы пытаемся получить элемент, индекс которого не существует. Красная плашка предупреждает, что возникло исключение:

List index out of range –– такого индекса в списке нет. Вроде всё понятно, но можно разобраться.

Сбоку мы видим список colors, его элементы и длину len(). В Python, как и во многих других языках, отсчёт начинается с 0. Если в списке 3 элемента, то индекс последнего –– 2. Поэтому мы и получаем ошибку.

Помимо точек останова можно следить за стеком вызовов.

Стек вызовов — цепочка вызванных функций. Она показывает, что происходит на каждом шаге программы.

Это особенно важно при сложных ошибках, скрытых глубоко в коде. Перепишем немного и сделаем несколько программ:

Ошибка всё ещё на месте, но теперь её появление происходит не сразу в функции main, а глубже.

И стек вызовов нам показывает, что сначала выполняется main, затем display_favorite_color и уже потом get_favorite_color, где и живёт ошибка:

Эту проблему можно решить с помощью try-except. Советуем попробовать самостоятельно🙂.

И последний способ отладки, который разберём –– логирование. Можно использовать print() или модуль, который уже заботливо написали за нас. Результат одинаковый — вывод нужных данных в определённое время. Так мы поймём, что лежит в переменной и почему программа ломается.

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

Разберём вариант посложнее с модулем logging. Его нужно импортировать и настроить:

Теперь подробнее про конфигурацию. В logging есть несколько типов сообщений:

• Отладочные –– DEBUG. Они показывают подробности о значениях переменных или работе отдельных функций;
• Информационные –– INFO. В них можно прописывать статусы выполнения программы;
• Предупреждения –– WARNING. Сообщения с потенциальными проблемами;
• Ошибки –– ERROR и CRITICAL.

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

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

Это намного удобнее, чем прописывать все данные в print вручную.

Если нам нужны только ворнинги, то меняем конфигурацию:

Шаг 4: Тестируем — юнит-тесты и их роль

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

Юнит-тесты — отличный способ проверять, что каждый блок вашего кода работает как положено.

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

Для этого можно использовать pytest или unittest.

Давайте поработаем с pytest. Напишем в файле main.py очень простую функцию:

Функция принимает число и возвращает квадрат числа.

Напишем тест. Для этого нужно установить pytest в свою IDE и создать файлик. Например, test.py:

Наша гипотеза: 2 в квадрате равно 4. Для того, чтобы её проверить, используем assert.

Если в терминале запустить команду pytest test.py, то увидим, что всё прошло успешно:

Если же заменить 4 на 5, то тест упадёт. Так как 2 в квадрате –– не 5:

Советы по улучшению процесса отладки

Мы разобрались, как дебажить и тестировать код. Напоследок дадим три базовых совета, которые актуальны не только для Python, но и для любого языка программирования.

Делите код на небольшие модули

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

Пишите автоматические тесты

Автоматическое тестирование позволяет ловить ошибки на ранних этапах. Вы можете и не увидеть их сразу. Зато они вас видят.

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

Комментируйте код

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

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

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

Frontend фреймворки

React

Это самый популярный фреймворк для создания веб-приложений. React используется в лендингах, динамических веб-приложениях и даже мобильных приложениях (React Native).

UI здесь разбивается на независимые и переиспользуемые блоки. Такие компоненты легко интегрировать, комбинировать в разных частях приложения или между проектами. Фреймворк ускоряет разработку и рефакторинг.

React обращается к DOM только для обновления изменившихся компонентов. За счет этого повышается производительность приложения.

Пример простого React компонента:

Преимущества фреймворка:

• Облегчает повторное использование кода и поддержку приложений;
• Имеет множество дополнительных библиотек и инструментов;
• Виртуальный DOM снижает прямые манипуляции с DOM и повышает производительность приложения;
• Фреймворк пользуется популярностью в сообществе. Как результат  —  множество учебников, разборов документации и сторонних библиотек.

Недостатки фреймворка:

• Концепции JSX и управления состоянием могут быть сложны для новичков;
• Плохая кроссбраузерная поддержка;
• Требует дополнительных библиотек для маршрутизации и управления состоянием.

Vue.js

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

Преимущество Vue в его простоте и низком пороге входа. При этом фреймворк сохраняет статус мощного инструмента для разработки сложных веб-приложений.

Vue автоматически отслеживает зависимости между блоками и обновляет DOM при их изменении, как React.

Компонентная архитектура Vue позволяет разбивать UI на переиспользуемые части. Разметка, стили и логика разделяются «оболочкой», а это облегчает поддержку и масштабирование приложения.

Пример простого компонента Vue:

Экосистема Vue включает множество библиотек и плагинов, расширяющих возможности фреймворка. Например, Vuex для управления состоянием, Vue Router, Nuxt.js и другие.

Преимущества фреймворка:

• Понятный синтаксис и подробная документация;
• Может использоваться как библиотека или цельный фреймворк в зависимости от проекта;
• Есть поддержка серверного рендера;
• Автоматически обновляет интерфейс при изменении данных;
• Имеет небольшой вес файлов.

Недостатки фреймворка:

• Меньше ресурсов и сторонних библиотек по сравнению с React и Angular;
• Неполная документация на русском языке.

Angular

С помощью Angular разрабатывают клиентские части веб-приложений. Этот фреймворк сложнее Vue и React.

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

По аналогии с Vue и React, фреймворк разбивает приложение на независимые, переиспользуемые блоки кода. Компоненты: шаблон; класс, описывающий поведение; стили.

Освоение Angular требует больше времени и усилий по сравнению с Vue и React из-за архитектуры и специфических концепций. Нужны углубленные знания по внедрению зависимостей, декораторам и модулям.

Пример простого Angular-компонента:

Преимущества фреймворка:

• Богатый выбор инструментов, шаблонов, которые сокращают сроки реализации сложных приложений;
• Angular CLI расширяется за счет shematics, поэтому его легко доработать под конкретные задачи;
• Есть поддержка TypeScript: статическая типизация улучшает качество кода;
• Встроенная утилита для обновления проекта при переходе на новую версию Angular.

Недостатки фреймворка:

• Ангуляр сложнее, чем Вью и Реакт. Его изучение занимает больше времени, если это первый фреймворк в карьере разработчика.

Backend фреймворки

Django (Python)

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

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

Django следует архитектурному шаблону Model-View-Controller (MVC). Модели определяют структуру данных, представления обрабатывают логику и взаимодействие с моделями, а шаблоны отвечают за представление данных пользователю.

Сильная сторона Django — его ORM (Object-Relational Mapping). Интерфейс для работы с базой данных на Python используется для написания сырых SQL-запросов. Django поддерживает PostgreSQL, MySQL, SQLite, Oracle.

Если ищете универсальный фреймворк для бэкенд-разработки на Python, Django определенно заслуживает вашего внимания.

Пример модели Django:

В примере определяем модель Article с полями title, content и published_at. Метод __str__ возвращает строковое представление объекта:

Представление article_list получает объекты Article из базы данных и передает их в шаблон для отображения.

Преимущества фреймворка:

• Широкий набор инструментов: включает ORM, аутентификацию и админ-панель;
• Фреймворк задаёт структуру проекта — помогает разработчикам понимать, как и где добавлять новую функцию;
• Защищен от SQL-инъекции и подделки межсайтовых запросов;
• Подходит для высоконагруженных приложений.

Недостатки фреймворка:

• Django ORM уступает последней SQLAlchemy.

Ruby on Rails (Ruby)

Rails подходит для быстрого прототипирования и проектов, ориентированных на работу с базами данных. Его используют для SaaS-платформ, CRM-систем, CMS, маркетплейсов и многого другого.

Rails применяет архитектурный паттерн MVC (Model-View-Controller). Фреймворк хорош с точки зрения бизнес-логики и взаимодействует с базой данных с помощью ActiveRecord ORM.

Rails поставляется со встроенными инструментами и библиотеками. Например, ActiveRecord для работы с базами данных, ActiveStorage для управления файлами, ActionMailer для отправки email.

В сообществе Rails огромное количество гемов (библиотек), расширяющих функциональность фреймворка.

Пример модели Rails (с использованием ActiveRecord):

Пример контроллера Rails:

В примере определяем модель Article с валидациями и связями. Контроллер ArticlesController содержит экшены для списка статей, отображения отдельной статьи, создания новой статьи. Приватный метод article_params используется для фильтрации параметров.

Преимущества фреймворка:

• Продуманная структура, которая продвигает стандарты качества и лучшие практики веб-разработки;
• Active Record ORM упрощает взаимодействие с базой данных;
• Vue, Angular.js и React легко интегрируются с Ruby on Rails.

Недостатки фреймворка:

• Ruby on Rails js медленнее Django и Node.js.

Node.js с Express (JavaScript)

Express — фреймворк Node.js с набором функций для разработки веб-приложений и API. В нем реализован простой интерфейс для HTTP-запросов и маршрутизации.

Node.js + Express используется для сервисов, серверных приложений (например, чатов или игр).

Преимущество Node.js и Express состоит в возможности писать на JavaScript как клиентскую, так и серверную сторону. Можно вести разработку на одном языке и делиться кодом с фронтендом и бэкендом.

Пример простого приложения на Express:

Преимущества фреймворка:

• JavaScript на всем стеке — один язык для фронтенда и бэкенда;
• Имеет минимальные ограничения, можно строить архитектуру как удобно.

Недостатки фреймворка:

• Отсутствуют встроенные компоненты, требуются дополнительные настройки для безопасности и работы с базами данных;
• Управление обратными вызовами усложняет код и его поддержку.

Full-Stack фреймворки

Laravel (PHP)

Laravel — фреймворк для веб-разработки на PHP. Он использует архитектуру MVC: разделяет логику приложения и улучшает организацию кода.

Laravel выбирают для разработки CMS, SaaS-платформ, электронной коммерции и др. Встроенные библиотеки ускоряют работу.

В фреймворке реализована:

• Система миграций для управления структурой базы данных;
• Eloquent ORM для работы с данными;
• Система шаблонизации Blade;
• Встроенная поддержка аутентификации и авторизации;
• Очередь заданий и планировщик для выполнения асинхронных задач.

Пример определения маршрута в Laravel:

Пример контроллера Laravel:

Пример модели Eloquent:

В примерах выше определяем маршрут, который принимает id и возвращает строку с идентификатором. Контроллер UserController методом show получает пользователя из базы данных по id и передает его в представление user.profile. Модель User представляет таблицу пользователей в базе данных и определяет заполняемые атрибуты.

Преимущества фреймворка:

• Шаблонизатор Blade упрощает создание представлений;
• ORM Eloquent облегчает работу с базами данных;
• Есть автоматизация задач с помощью встроенных инструментов и командной строки.

Недостатки:

• Сложности с долгосрочной поддержкой версий.

Spring Boot (Java)

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

Фреймворк имеет встроенный контейнер сервлетов (Tomcat, Jetty), чтобы запускать приложение как автономный JAR-файл без развертывания на внешнем сервере.

Фреймворк также предлагает:

• Автоконфигурацию библиотек (JPA, JDBC);
• Встроенные метрики мониторинга;
• Поддержку внешней конфигурации;
• Интеграцию с базами данных.

Преимущества фреймворка:

• Есть встроенные серверы Tomcat, Jetty и Undertow;
• Облегчает управление зависимостями с помощью стартовых пакетов;
• Оснащен встроенным контейнером сервлетов;
• Автоматическая конфигурация экономит время на старте проекта.

Недостатки:

• Spring Boot создает множество неиспользуемых зависимостей и увеличивает размер файла развертывания.

Meteor (JavaScript)

Особенность Meteor в том, что он синхронизирует данные в реальном времени. Фреймворк автоматически обновляет пользовательский интерфейс при изменении данных на сервере. Это возможно благодаря протоколу DDP (Distributed Data Protocol) и реактивным источникам данных, таких как MongoDB.

На JS + Meteor можно писать код, который работает как на клиенте, так и на сервере. Фреймворк также предоставляет интегрированную систему сборки, которая автоматически объединяет ресурсы приложения.

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

Преимущества фреймворка:

• Архитектура и синтаксис с понятным кодом упрощают обучение новичков и повышают производительность команды;
• Есть мгновенная синхронизация данных между клиентом и сервером;
• Возможна интеграция базы данных MongoDB.

Недостатки фреймворка:

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

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

Теперь разработчики могут использовать возможности ChatGPT прямо в своих средах разработки.

Какие IDE поддерживаются?

Обновление охватывает следующие инструменты:

• Visual Studio Code и форки: поддержка включает помощь с генерацией кода, рефакторингом и разъяснениями сложных частей проекта.
• JetBrains IDE: поддержка распространяется на такие популярные IDE, как IntelliJ IDEA, PyCharm, GoLand и другие. Она расширяет возможности разработчиков, работающих с различными языками программирования.
• Xcode: интеграция позволяет iOS-разработчикам использовать ChatGPT для ускорения процесса написания кода и тестирования.

Возможности интеграции

Обновление добавляет несколько полезных функций:

• Подсказки и генерация кода: ChatGPT помогает автоматически генерировать шаблоны, подсказки и готовые решения.
• Рефакторинг и улучшение кода: возможность улучшать читаемость и оптимизировать структуру кода.
• Обучение и документация: AI может объяснять сложные части кода и предлагать альтернативные подходы.

Зачем это нужно?

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

Это также удобно для обучения, особенно для тех, кто только начинает работать с новыми технологиями.

Доступность

Обновление уже доступно для пользователей macOS.

Чтобы воспользоваться интеграцией, достаточно обновить приложение ChatGPT и настроить плагин для вашей IDE. Инструкции по установке доступны на сайте OpenAI.

Реакция сообщества

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

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

Основные особенности и преимущества

Визуализация на холсте

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

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

Автоматизация с помощью ИИ

Одним из ключевых преимуществ Haystack является навигационный «копилот», который использует искусственный интеллект для автоматизации рутинных задач.

Этот инструмент предугадывает ваши следующие шаги и предлагает изменения в коде, что позволяет ускорить процесс разработки. Например, Haystack может автоматически создавать методы или вносить изменения в код, которые вам потом нужно будет просто подтвердить или отклонить.

Удобство и интеграции

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

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

Многофункциональность

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

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

Планы на будущее

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

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

Скачать IDE можно с официального сайта.

CI/CD-инструменты

CI/CD-инструменты позволят автоматизировать сборку исходного кода и процессы поставки. Разработчики теперь могут воспользоваться уже написанными скриптами сборки, в один клик перенося свои проекты с Git-репозиториев. Технология оповещения о новых событиях на сервере (вебхуки) позволяет реализовать еще больше сценариев автоматизации. По событиям в GitVerse можно вызвать через API сторонние сервисы. Например, при определенных событиях в репозитории можно запустить сторонний сборочный конвейер или отправить уведомление в мессенджер.

Новые функции персонального AI-ассистента разработчика GigaCode

Теперь AI-ассистент поможет разработчику решать задачи, связанные с кодом, в окне чата непосредственно в среде разработки. Сервис чата также доступен и в GitVerse, где при просмотре репозитория можно получить объяснение, что делает та или иная часть кода, а также советы по его улучшению. Список языков программирования, которые поддерживает GigaCode, пополнил Ruby, а также стала доступна генерация текстовых данных в формате JSON. На сегодняшний день AI-ассистент поддерживает уже более 15 популярных языков программирования и устанавливается как плагин в привычные среды разработки, включая IDEA, PyCharm, VSCode, Jupyter.

Функциональность для организаций

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

При разработке новой функциональности мы учитываем пожелания пользователей, добавляем необходимые инструменты, чтобы они могли вести разработку еще проще и быстрее. С каждым релизом платформа будет становиться все более удобной и пополняться новыми популярными репозиториями, open source-версиями продуктов и инструментами для эффективной разработки. Будущее разработки мы видим в создании удобной среды по принципу единого окна, в которой все члены команды могут работать на своем этапе производственного процесса, заказывать облачную инфраструктуру и общаться. На всех этапах разработки партнерскую роль будет занимать AI: помогать писать код, советовать, как сконфигурировать стенд, готовить документацию, подсказывать шаги по CI/CD-конвейеру

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

• новые инструменты для управления проектами, позволяющие удобно организовывать рабочие процессы;
• интегрированная среда разработки позволит разворачивать полностью настроенные инструменты разработки в облаке. Функциональность будет доступна прямо из браузера: разработчик сможет легко и быстро открыть любой репозиторий GitVerse в среде разработки;
• новые функции GigaCode: генерация тестов, автоматическое создание документации и умный рефакторинг. Число языков, которые поддерживает GigaCode, пополнят PHP, HTML, CSS, Markdown и Rust;
• инструменты для безопасной разработки (оркестрация CI/CD, статический анализатор, управление секретами и безопасность зависимостей);
• удобный и безопасный вход через популярные сервисы идентификации личности, а также мобильная версия платформы.

Реклама Реклама АО “Сбертех” ИНН 7736632467, LjN8KXJG3

Меня зовут Виталий Киреев, я руководитель отдела исследований и разработок хостинг-провайдера SpaceWeb. В статье расскажу, как мы с нашей командой проводили рефакторинг кода при переходе с PHP 7.4 на PHP 8 и на что заменили одну из самых популярных функций — create_function.

Статья будет полезна и тем, кто только погружается в язык PHP. На примере реальной задачи по рефакторингу подробно разберу, как использовать анонимные и стрелочные функции. И объясню, чем они отличаются.

Контекст: когда стало ясно, что нужен рефакторинг

В части проектов SpaceWeb много legacy-кода. Мы поддерживаем проекты с версии PHP 5.6, которая появилась в 2014 году. С некоторой периодичностью переходим на новые версии PHP, постоянно обновляя код.

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

Когда вышла версия PHP 7.4, функция create_function, которая часто использовалась в нашем коде, стала deprecated, то есть перестала поддерживаться и работать. Из-за этого стали появляться ошибки в коде. Тогда и стало ясно, что нужен рефакторинг.

Подсветить часть проблем в коде нам помогли статические анализаторы кода — PHP Code Style Fixer и PHPstan. Но большую часть кода мы проверяли и обновляли вручную. В первую очередь нужно было придумать, на что заменить популярную create_function. Сперва начали переход на анонимную функцию и замыкание. А спустя время внедрили и стрелочные функции, чтобы повысить читаемость кода и решить дополнительные задачи.

Анонимные функции: как работают и как применить замыкание

Особенность анонимных функций в том, что они задают область видимости. Внутри этой области будут работать только те переменные, которые определены там же. Если мы пропишем переменные за пределами функции, код будет выдавать ошибку.

На самом деле, create_function, которую мы обычно использовали до PHP 8 — это классический пример использования анонимной функции. Ее часто применяли для обработки данных в массиве. Функция содержит два аргумента — массив аргументов функции и сам код.

Когда эта функция стала deprecated в PHP 8, мы начали рефакторинг кода. Анонимные функции стали выглядеть так:

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

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

Стрелочные функции: в чем отличие от анонимных и где лучше использовать

Стрелочные функции позволяют избежать постоянного использования use, потому что в них есть автоматический захват внешних переменных. Это позволяет сделать код более лаконичным. Еще стрелочные функции лучше подходят для работы с большим количеством переменных или с частой сменой переменных в процессе.

В этом примере была задача отфильтровать контракты и соотнести их с нужным ИНН. Если бы решали ее с помощью анонимных функций, то под каждый ИНН пришлось бы писать отдельную функцию. А еще везде использовать use.

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

Важно отметить, что у стрелочных функций есть ограничение. Они не могут быть слишком сложными, у них компактный синтаксис. Если нам нужно разместить многострочный код, мы используем анонимные функции.

Итоги

Для замены create_function в PHP 8 можно использовать как анонимные, так и стрелочные функции.

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

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

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

Неважно, как хорошо и чисто написан код — рано или поздно он станет легаси.

А что плохого в легаси?

Основные недостатки легаси для бизнеса, это:

• низкое соотношение пользы к вложенным усилиям на изменения;
• медленные изменения;
• сложности с подбором команды для работы над кодом.

Причины, по которым появляется легаси

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

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

В другую группу можно отнести низкую культуру или плохую организацию процесса разработки.

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

Отсутствие такой практики будет приводить к тем же проблемам. Пользователи будут сильно зависеть от экспертизы разработчиков. А если последние уволятся, то восстановления знаний из кода займет слишком много времени. В результате остается много вопросов «почему так сделали?» или «зачем это?».

Неверная архитектура или плохо спроектированный код провоцируют написание «костылей» (плохое решение, на момент написания которого мы знаем, что с ним будут или могут быть проблемы в будущем, однако которое решает проблему «здесь и сейчас»). Обсуждению архитектуры и проектирования можно посвятить отдельную статью или даже книгу, но если коротко, то нарушение общепринятых практик написания ПО, в частности, SOLID, будет приводить к проблемам, нежели позволит избегать их.

Выбраны неподходящие технологии (СУБД, фреймворки, библиотеки, или сторонние сервисы); не учтены особенности масштабирования.

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

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

Сюда же отнесем плохо организованный проект: нет системы контроля версий; отсутствие задачника (системы фиксации запросов на изменения к системе); нет связи между коммитами и задачами (требованиями);

Отсутствие людей, которые имеют навык поддержки кода продукта, также делает код более “легаси”.

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

Легаси с «положительной обратной связью»

Важным свойством легаси является его разрастание. Если не прилагать усилий для минимизации, то с каждым изменением (и даже без них) степень легаси будет нарастать. Как во втором начале термодинамики энтропия замкнутой системы не может уменьшаться. Поэтому нам надо методично «вычерпывать воду из нашей протекающей лодки».

Почему легаси неохотно заменяют

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

Минутка математики!
Можно представить, что легаси L(t) — это неотрицательная функция от времени. Пусть скорость разработки S(t) = F(L(t)), где F — некоторая функция, которая учитывает влияние легаси на скорость разработки при прочих постоянных факторах. Точный вид F неизвестен, но для нее верно: чем больше “легаси”, тем меньше скорость разработки, а при легаси равной 0 скорость максимальная F(0) = Fmax.
При этом польза компании V определяется как интеграл от затрачиваемых ресурсов:
V = ∫K·S(t)dt, где K — это сумма, которую бизнес готов вложить в разработку софта за интервал времени.
Если К представить в виде суммы Ks (деньги на пользу) и Kl (деньги на борьбу с легаси), такие, что Ks + Kl = K, то, зная форму F, можно максимизировать V для компании.
И вот эта задача, которую в том числе решает СТО – определить форму F и максимизировать V ?

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

Бывают случаи, когда легаси «починке/доработке» не подлежит, только замене. В такой ситуации перед бизнесом встанет выбор:

• отказаться от доработок (если это возможно);
• отказаться от доработок в текущей системе и начать разработку новой;
• перейти на готовое стороннее решение.

Одна из главных задач СТО — минимизировать риски возникновения «внезапных проблем» и иметь план действий в случае их наступления.

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

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

Как бороться с Легаси

• выделять время на мониторинг индустрии. Если какие-то технологии или ПО устаревают, надо планировать переход на новые технологии / обновление ПО;
• организовать процесс разработки так, чтобы требования были четкие и зафиксированы в какой-то системе, чтобы изменения в коде были привязаны к этим требованиям;
• покрывать систему тестами;
• следить за актуальностью документации;
• приостанавливать разработку и проводить рефакторинг кода в случаях, когда костылей становится слишком много (здесь важен баланс, так как постоянный рефакторинг в борьбе за «скорость разработки» отнимает время от разработки);
• передавать владение кода от программиста к программисту: 1) больше людей знакомы – меньше рисков, что код остается бесхозным, 2) отработанная практика передачи владения стимулирует поддерживать код и документацию в надлежащем виде (в процессе передачи будут выявляться недостатки), придает уверенность, что новый человек сможет разобраться;
• следить за чистотой кода (как минимум настроить линтеры, проводить ревью).

Польза от Легаси

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

Однако польза от легаси может быть для сотрудников, с ней работающих. Особенно для новичков, приходящих в компанию. Во-первых, уровень зарплаты может быть выше, если в компании вы не первый, кто устраивается работать с «их легаси». Она может удерживать разработчиков, чтобы их код кто-то поддерживал. Во-вторых, уровень стресса может быть ниже, если компания привыкла к медленным внедрениям (оговорка, не везде и не всегда). Плюс сомнительный, но для кого-то это может показаться более комфортным местом. В-третьих, есть возможность изучить поглубже определенные технологии, используемые в этой компании — все равно легаси изучать, можно и документацию по технологиям почитать. Особый плюс для стажеров и джунов, которым нужно первое место работы — если в компании готовы их взять и помогать разбираться с кодом, даже решая простые задачи в сложной системе можно начать хорошую карьеру. Еще один плюс — можно посмотреть, как делать НЕ надо.

Если вы «застряли» в какой-то технологии, не отчаивайтесь, возможно, через несколько лет, вы станете редким высокооплачиваемым специалистом. ?

В США ряд старых банковских систем написаны на COBOL — устаревшем языке программирования. Поддерживать системы надо, а молодые специалисты не горят желанием изучать этот язык, поэтому специалистов не хватает. Ситуация настолько накалилась, что энтузиаст COBOL создал собственную компанию по оказанию экстренной поддержки банкам и обучению молодежи языку, что вслед за ним сделало и IBM.

От легаси никуда не денешься. Он всё равно будет появляться и с ним предстоит жить и бороться. Это стоит воспринимать, как вызов. Или как возможность, если вы ещё на старте карьеры.

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

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

Что такое код ревью и пулл реквест

Процесс командной разработки зачастую включает в себя работу несколькими людьми над одним репозитием. В таком процессе необходимо следить за тем, чтобы репозиторий был максимально надежным и имел только качественный код, который был бы хорошо читаемым и содержал бы минимальное количество багов. Для выполнения этих требований существует процесс код ревью – участник команды выставляет часть кода на проверку, которую проводят другие члены команды и либо оставляют комментарии с пометкой “требуется доработка”, либо ставят галочку “одобрено”. Код ревью важен для команд с разработчиками любого уровня, поскольку все члены команды хотя бы верхнеуровнево начинают быть в курсе что именно добавляет в репозиторий другой разработчик.

Чтобы было удобно проводить код ревью, во всех современных системах репозиториев есть механизм “Пулл реквеста” или “merge request” (в gitlab), что по сути одно и то же.

Как интегрировано в жизнь разработчика

Когда разработчик работает над задачей, он делает это в отдельной ветке и рано или поздно наступает момент, когда работа закончена и нужно влить эти изменения в главную ветку. Тут наступает время для процесса код ревью. Разработчик выставляет пулл реквест, добавляет описание и прикладывает ссылку на задачу. И дальше ждет реакции коллег. Коллеги выступают проверяющей стороной и должны проверить этот пулл реквест таким образом, чтобы не допустить попадания опасного или неправильно работающего кода в репозиторий. И сделать это таким образом, чтобы сохранить дружелюбные отношения внутри команды. На первый взгляд ничего сложного, но нюансов в “правильном” пулл реквесте и “правильно” проведенном код ревью очень много.

Какие ошибки могут быть со стороны выставляющего пулл реквест

Создавать пулл реквест, содержащий несколько тикетов сразу

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

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

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

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

Как не допустить такой ошибки: неукоснительно соблюдать правило – в одном пулл реквесте максимум один тикет.

Слишком большой для одного тикета

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

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

А уж если пулл реквест оказался настолько запутанным, что никто из членов команды не может разобраться что именно и как там написано, то точно НЕ СТОИТ устраивать созвон на всю команду с демо своего пулл реквеста. Потому что только время свое и всех участников команды потратите, а к облегчению задачи едва ли приблизитесь

Как не допустить такой ошибки:

• Во-первых, оценить какие именно изменения были проведены в пулл реквесте. Где добавились новые модели, где добавились новые клиенты или интегарации, где рефакторинг зачесался.
• Во-вторых, по возможности разделить огромный пулл реквест на пулл реквесты поменьше. Главное чтобы каждый был емким и завершенным. Добавили модели – отлично. Добавили внешнюю интеграцию + тесты – супер.

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

Добавлять закомментированный код

Иногда кажется, что “да ладно, закомментирую эту функцию вместо того чтобы удалить”. Но это является ошибкой поскольку комментарии в коде катастрофически уменьшают читаемость кода. И каждый пулл реквест должен по возможности следовать правилу “сделай репозиторий лучше, чем он был до”. А добавление комментариев в пулл реквесте только множит хаос в репозитории. Если вы боитесь удалить что-то неиспользуемое, то держите в голове, что git – это машина времени для кода, в любой момент можно поднять историю и посмотреть как изменялся файл и что из него удалялось, а что добавлялось.

А если вы добавляете НОВЫЙ закомментированный код, то вероятно вы опасаетесь что он работает некорректно. Этого нельзя делать категорически. Закоментированный нестабильный код – это мусор.

t Как не допустить такой ошибки: не добавляйте закомментированный код в пулл реквест. Никакой. Вообще. Единственным исключением может быть описание какого-то блока бизнес логики, если у вас такая практика закреплена в команде. Либо комментарий с указанием “todo + номер задачи с описанием что должно быть здесь доработано”.

Если же есть что-то неочевидное в коде, то указать на это комментарием в самом пулл реквесте.

Запрашивать ревью пулл реквеста, который имеет сломанные тесты

Как правило, все команды имеют настроенные CI скрипты (Continious Integration пайплайн), которые выполняют запуск тестов на вашей ветке чтобы убедится что код внутри правильно работает. Бывает такое, что во время реализации новой фичи вы либо написали тесты, которые не работают, либо каким-то образом сломали старые тесты. И этот самый CI пайплайн падает с ошибкой в одном из ваших тестов.

Кажется, что в такой ситуации можно написать примечания к пулл реквесту мол “не обращайте внимание, потом поправлю”. Но это ошибка – поскольку пулл реквест должен быть “завершенным” и ни в коем случае не сломать основную ветку проекта. А запрос ревью на пулл реквест, который заведомо “сломает” ветку, крайне снижает уровень доверия к такому пулл реквесту и скептицизм взлетает до совсем высокого уровня. Такой пулл реквест можно сравнить с отвлечением команды от работы. Поскольку текущее ревью явно будет не последним и тем самым обесценит время, затраченное на него.

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

Запрашивать код ревью на код, не покрытый тестами

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

Как не допустить такой ошибки: всегда проверять, что ваш пулл реквест содержит тесты на тот код, который вы написали или исправили. Не допускать отсутствия тестов.

Иметь в одном пулл реквесте код от нескольких разработчиков

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

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

Какие ошибки могут быть со стороны принимающего пулл реквест

Придирки к мелочам и требовать переделать с таким же подходом, но “по-другому”

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

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

Если разработчик – новичок или не так опытен, то имеет смысл более внимательно относиться к его реквестам. Но даже в этой ситуации код ревью не должно быть процессом, где код причесывается под видение одного человека, даже если он “самый главный” в команде. Поскольку репозиторий – сущность, с которой работает команда, а не единственный человек.

Быть токсичным

День оказался неприятным, кто-то нагрубил, погода плохая, а тут еще пулл реквест этот, а в нем еще и ошибки какие-то. Бывает, что очень хочется написать “ну и чушь ты здесь понаделал”. И если взять во внимание, что вы – одна команда, которая работает над общим проектом, то становится очевидно, что токсичность даже одного члена команды может ухудшить атмосферу уважения во всем коллективе.

Токсичность – это непрофессионализм.

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

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

Пытаться найти максимальное количество ошибок

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

Однако код ревью не является соревнованием по поиску недоработок. Любой код не идеален по своей сути. И требование код ревью – не допустить опасного или вредного кода в репозиторий. Но не искать где можно придраться к код стайлу или неверному отступу.

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

Откладывать пулл реквест в долгий ящик

Вот это денек выдался – столько задач, столько созвонов, а еще эти код ревью поназапрашивали. Ничего не случится если завтра проверю, ну или послезавтра.

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

Как правило внутри команды заводится четкая практика – например, код ревью проводится строго с утра первым делом. Такая практика делает срок получения комментариев по пулл реквесту предсказуемым.

Выводы

Хороший пулл реквест – это какой?

1. Имеет понятное название + содержит ссылку или номер задачи.
2. Имеет тесты на все изменения.
3. Имеет пройденные проверки CI пайплайна.
4. Достаточно небольшой чтобы его можно было проверить в один заход.
5. Имеет только одного автора.

Хорошее ревью – это какое?

1. Своевременное.
2. Без токсичности, вежливое и хорошо читаемое.
3. Без излишней придирчивости к каждой строчке. Подсвечивает явные ошибки или потенциальные проблемы.
4. Не содержит требований “вам кажется, что можно написать по другому”. Если есть предложения – выдвигать их, но не требовать чтобы разработчик их выполнил.

Короткое дополнение для джунов

1. Если вас строго проверяют – это может быть как синдром вахтера, так и искреннее желание помочь вам развиться. Внимательно относитесь ко всем комментариям.
2. Пулл реквесты и код ревью это не страшно. У всех бывают тяжелые код ревью и легкие. Это необходимый процесс чтобы код в репозитории был чистым и работал.

Сперва опишем в README раздел «Назначение сервиса»

Чтобы все выглядело понятно, сперва «покопаемся» в теме: проанализируем документацию, если таковая есть, поговорим с экспертами. Они могут простыми словами объяснить, что должен делать сервис.

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

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

Получим первый бранч и MP. Для удобства важное вынесем в текст:

Назначение сервиса

Сервис является синхронным перекладчиком запросов систем-потребителей в системы-поставщики. Запросы поступают из систем-потребителей по очередям и обрабатываются сервисом-поставщиком согласно обобщенному бизнес-процессу:

• запросы из очереди направляются синхронно по REST в соответствующую систему;
• полученный ответ упаковывается в ответный конверт и отправляется в очередь ответа.

Подробнее в описании каждого процесса.

Обработка запроса из Платежной Системы (PipelineServicePS.kt)

• получает конверт с запросом;
• валидирует входящий запрос;
• отправляет квитанцию о результате валидации и принятии запроса;
• отправляет запрос на получение истории операций в Систему А (REST);
• отправляет полученный ответ в очередь;
• отправляет квитанцию об успехе либо ошибки обработки запроса.

Теперь перейдем к тестам

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

В процессе будем использовать инструменты:

• Testcontainers — поможет поднять IBM MQ в контейнерах на время исполнения тестов;
• Wiremock — прекрасный инструмент, чтобы поднять заглушку REST-ресурса на время исполнения тестов.

Полезные ссылки по теме

• TestContainers — интеграционное тестирование с Docker

• https://java.testcontainers.org/

• https://java.testcontainers.org/features/files/

Конфигурация тестового профиля

Зачищаем конфигурацию перед тестированием: /src/test/resources/application-test.yml

Если вы посмотрите в бранче с README содержание файла конфигурации application-test.yml, то увидите много лишнего: конфиг содержит 49 строк, при этом в основном дублирует настройки основного профиля. Это в какой-то момент приведёт к такой рассинхронизации с основным профилем, что тесты станут давать ложноположительные или ложноотрицательные срабатывания.

Чтобы этого избежать, лучше вынести общие конфигурации в main/resources/application.yml. А в тестовом профиле оставить записи, которые переопределяют основные. Как правило, application-test.yml содержит переменные, зависимые от окружения.

В результате получим 14 строк конфигурации против 49. Конфиг будет содержать только то, что нужно для локального тестирования.

Теперь есть смысл посмотреть на содержание:

Я описал разные способы игр с докером IBM MQ в исходниках. Например, чтобы поднять докер с очередями, нужно зайти в папку docker cd src/test/resources/docker.

Для локального тестирования посредствам монтирования раздела поднимем MQ

docker run \

–env LICENSE=accept \

–env MQ_QMGR_NAME=QM1 \

–publish 1414:1414 \

–publish 9443:9443 \

–publish 9157:9157 \

–mount type=bind,source=./src/test/resources/docker/20-config.mqsc,target=/etc/mqm/20-config.mqsc \

И получим брокер с очередями, которые забираются из файла 20-config.mqsc.

Далее можно написать простой тест конфигурации подключения к брокеру. Отправим в тестовую очередь MY.TEST сообщение и прочитаем его из очереди. Это позволит убедиться в работоспособности тестовой инфраструктуры.

Можно убрать наследование тестового класса от :AbstractIbmMqIntegrationTest() на 16 строке. Затем — запустить из папки /src/test/resources/docker/ команду в терминале, которую мы описали выше, и запустить тест. Так, в логах появятся отклики на тест MQ.

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

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

Настраиваем тест-контейнеры

Нам понадобится родная документация фрэймворка:

• https://java.testcontainers.org/quickstart/junit_5_quickstart/
• https://testcontainers.com/guides/testcontainers-container-lifecycle/
• https://java.testcontainers.org/examples/

Добавляем импорт либ для тестирования на тест-контейнерах в build.gradle, строка 35.

Исследуем документацию про Управление жизненным циклом контейнеров тест-контейнеров с использованием JUnit 5. Пробуем запустить паттерн Singleton Containers для запуска тестов на одном контейнере.

Создадим класс AbstractIbmMqIntegrationTest

В нем опишем сам контейнер, строка 16.

Обратите внимание на строку 21 — так можно подмонтировать файл и сконфигурировать стандартный контейнер. Эта полезная фича описана в доке https://java.testcontainers.org/features/files/

Установим переменную окружения для подключения к MQ

Метод setIbmMqProperties, строка 29, заполняем ibm.mq.connName.

Запустим контейнер при создании класса

Функция на строке 37 запускает контейнер перед запуском тестов.

Напишем тест на инфрастурктуру

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

• простота документации;
• простота реализации примера по документации;
• работоспособность экспериментального кода по документации.

Получим класс, который уже видели:

MqSimpleTest

Запустим тест и получим зачаток «грини-котлин приложения» (приложения на котлин с зелеными тестами). Тест работает, доки качественные, и мы не плясали с бубном.

Проверено: Фрэймворк testcontainers помогает писать интеграционные тесты.

Настраиваем WireMock

Чтобы локально в тестовом окружении поднять и сконфигурировать заглушку для REST-ресурса можно взять два классных инструмента:

• WireMock: https://wiremock.org/
• Mock Server: https://www.mock-server.com/

В документации Wiremock найдем рекомендацию того, как с ним работать в Spring:

• https://wiremock.org/docs/solutions/spring-boot/
• https://github.com/maciejwalkowiak/wiremock-spring-boot

Добавим зависимость в build.gradle

Добавим конфигурацию ответа сервиса rest-api-gateway. Проверим, что мок-сервер поднимается и подгружает конфигурации ответов из файлов.

Напишем тест на инструмент в классе WireMockWithStubsTest

Строкой 15 описываем инстанс мок-сервера с именем rest-api-gateway. Он определяет url конфигурации рест ресурса rest.configs.api-gateway.url:

Этот url загружается в контекст приложения из /src/main/resources/application.yml, строка 81.

Он используется в классе RestConfiguration, а далее — страшным классом RESTClient, который создатель наделил монструзоным методом на 80 строк sendRequest.

Таким образом, мы понимаем, что приложение на шаге «Отправить запрос история операций по кошельку банка (в систему А по Ресту)» будет обращаться к рест-ресурсу по конфигурации rest.configs.api-gateway.

Настроим и протестируем заглушку

Строка 21 конфигурирует WebTestClient на url рест-ресурса, который мокает wiremock:

Строка 26 тестирует конфигурацю мок-сервера, которую он подтягивает из src/test/resources/wiremock/rest-api-gateway/mappings/wallet-balance.json

Конфигурация содержит описание запроса:

И ответа:

Подробнее про файлы конфигурации запросов, ответов, матчинга ответов в зависимости от параметров в теле запроса, заголовках написано в документации Wiremock.

Тест «подмигнул» зеленым. То есть оба теста на инфру успешны, и мы можем:

• отправить сообщение в очередь;
• прочитать сообщение из очереди;
• отправить http-запрос на REST-ресурс и получать ответ на него.

Напишем интеграционный тест, который отработает недоступность REST-ресурса

PipelineServicePsFailTest

В случае сбоя на шаге отправки REST-запроса квитанция (строка 69) должна содержать сообщение об ошибке. Код, который описывает пайплайн бизнес-процесса, работает некорректно — возвращает Success.

Исправим функцию assertReceiptError так, чтобы она была достоверной и утверждала правильное поведение системы. Тест теперь красный, именно это нам и нужно.

Исходник. Строка 112 — ReceiptStatus. ERROR — ожидаемый статус в квитанции. Тест защищает код от бага красным оком контроля качества интеграционного-теста.

Опишем явно слушатель и уберем лишние классы

Слушатели динамично создаются в MqServiceConfiguration:

Вместо кода на 64 строки, который нужно осознать, простить и принять, мы можем просто описать слушатель на очередь запросов по бизнес-процессу четырьмя строчками кода в классе PipelineServicePS:

Даже если у нас 5–7 процессов лучше описать слушатель явно — так, появляется очевидная точка входа и код проще понять.

Разберем интеграционный тест успешного выполнения бизнес-процесса

Обобщая, поведение системы (SUT — System Under Test) должно быть таким: на вход в очередь запросов мы отправляем конверт с запросом и проверяем, что в ответных очередях есть сообщения.

Очередь для квитанций содержит два сообщения:

• сообщение об успешном принятии запроса;
• сообщение об успехе обработки запроса.

Очередь для ответа содержит результат взаимодействия с REST-ресурсом.

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

successful wallet balance request

Название понятное и сообщает нам, что тест проверяет успешный запрос баланса кошелька:

Простой понятный тест, который является документацией, написан по паттерну 3A:

• Arrange: подготавливаем сообщение, конверт с запросом createRequestEnvelope (строка 66), чтобы отправить его в очередь запросов IN.QUEUE.PS;
• Act: отправляем сообщение в очередь запросов publishToQueue, воздействуем на SUT (строка 71);
• Assert: проверяем утверждения с фактическими данными, которые выдает SUT, вызвав метод с понятным названием assertResponsesInQueues (строка 73).

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

createRequestEnvelope

Этот метод просто и понятно описывает процесс создания корректного конверта с запросом.

publishToQueue

Метод прост: используем jmsPublisher: MqPublisher для отправки сообщения в очередь

assertResponsesInQueues

Проверяем, что бизнес-процесс отработал корректно:

• в очереди две квитанции со статусами ReceiptStatus.SUCCESS (строка 77) и ReceiptStatus.ACCEPTED (строка 78);
• в очереди ответа ожидаемое сообщение ответа сервиса (строка 79).

assertReceiptSuccess

Тестируем факт чтения квитанции об успехе операции:

assertReceiptAccepted

Тестируем факт чтения квитанции о том, что запрос получен и взят в работу:

assertResponse

Проверяем ответ в очереди ответа, должно быть все понятно из содержания метода:

assertThatResponse

Добрались до содержания, в котором видно, какой ответ мы ожидаем получить в очереди ответов:

Рекомендуем использовать в тестах Soft Assertions

Обратите внимание: во всех блоках с проверкой утверждений, например, как в assertThatResponse, мы рекомендуем использовать Soft Assertions. Это удобная фича, которая позволяет увидеть все фэйлы теста одним сообщением.

Такая есть в fluent assertions java-либе assertJ, которую мы предпочитаем для работы с утверждениями, и рекомендуем разработчиками. Блок теста на проверку ответа с Soft Assertion выглядит так:

assertThatResponse

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

Это удобнее, чем править утверждение за утверждением и перезапускать тест множество раз.

Конфигурация успешного теста

Контейнер Ibm MQ

Данная конфигурация отличается от конфигурации MqSimpleTest, которую я использовал для тестирования фрэймворка testContainers. Простой инфраструктурный тест опирался на шаблон singleton container, а нам понадобится запустить тесты изолированно друг от друга.

Чтобы протестировать ошибочный и успешный пути исполнения тестов, запустим каждый тест со своим контейнером. Это дорого по ресурсам (cpu, mem), но мы гарантированно получаем изолированный запуск тестов.

Я для простоты выбрал подход использования методов обратного вызова жизненного цикла JUnit 5 (Using JUnit 5 lifecycle callback methods):

На строке 38 создадим контейнер, описанный в классе IbmMqContainer:

В строках 40–46 установим переменную среды ibm.mq.connName для подключения к IBM MQ:

Строки 48–58 отвечают за запуск и остановку контейнеров:

JUnit 5 сначала вызовет метод startContainers(), а затем выполнит все тесты, помеченные аннотацией @Test, Как только все тесты будут выполнены, JUnit 5 вызовет метод обратного вызова @AfterAll (строка 55).

Конфигурация WireMock

В предыдущем разделе мы подробно рассмотрели и протестировали необходимую нам конфигурацию WireMock. В тесте прописываем ее в строке 29:

Этого достаточно, чтобы протестировать успешно бизнес-процесс.

Несколько правил в заключение

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

И пара рекомендаций

• Более подробно про лучшие практики 3A рекомендуем прочитать в статье Владимира Хорикова Making Better Unit Tests: part 1, the AAA pattern.
• Также рекомендуем каждому разработчику купить и прочитать книгу Владимира:«Принципы Юнит-Тестирования», которая вобрала в себя прекрасные эссенции о тестировании.

• Для таких же неугомонных любителей тестирования, как и мы, рекомендуем прекрасный Доклад про DDD от Ion Cooper’а TDD, Where Did It All Go Wrong (Ian Cooper).

Эта статья — «прожарка». Она не отвечает на все вопросы и не содержит иллюстрации ко всей критике. В будущем мы шаг за шагом более атомарно будем всё разгребать.

Сперва «высечем» тезисы: как нельзя писать

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

• НЕ пишите, если не нравится — круто, если код вас увлекает, и время в компании IDE летит. Но если нет — выберите что-то кроме программирования. В IT много интересной работы.

• НЕ пишите слепо по ТЗ аналитика — лучше прописывать требования совместно (или хотя бы разобраться, что конкретно хочет аналитик). Потому что код — ответственность разработчика, и разгребать проблемы придется именно ему.

• НЕ пишите, пока кратко и четко не описали проблему — её нужно зафиксировать в README репозитория на понятном пользователю языке. В идеале — описать поведение системы так, чтобы его можно было легко переложить в тесты. Это поможет смотреть на систему с перспективы её поведения.

• НЕ пишите без предварительного проектирования — можно заранее визуализировать архитектуру приложения. Спросите себя, из каких компонентов будет состоять приложение, почему именно из них, какие роли будут исполнять классы на каждом уровне.

А теперь — сам «плохой код»

Представьте, вы — разработчик. Только пришли в команду, познакомились с классными коллегами. И увидели… сервис. Такой, как этот. Читать код невозможно, тестов почти нет, каждый класс «кусается» (ещё и на ChatGPT не свалишь).

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

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

Сканируем методы, классы и структуру пакетов.

Мы постарались сделать «прожарку» максимально понятной. Но всё равно может быть тяжеловато.

Пакет client.RESTClient

Довольно простой REST-клиент на базе WebClient. По сигнатуре функция sendRequest соответствует нашему гайду. Но 82 строки для подобного класса — это много. Так что стоит упростить: разбить код на блоки и вытащить каждый в отдельную функцию (метод класса в ООП).

Также RESTClient важно покрыть тестами.

Пакет configuration

MqConfiguration — контейнер конфигурации, который содержит класс MqServiceCfg. Захардкоженные значения полей timeout, messagePipeline и type смущают. Лучше вынести значения в конфиг-файл.

Класс WebClientConfiguration стоит проверить тестами.

Пакет exceptions

ProcessException — класс, который нигде не используется. Просто удалить.

Пакет mq

Опустим классы-контейнеры без инкапсулированной логики работы с данными. И остановлюсь на проблемах в других классах.

GetWalletBalanceRequest

Смарт-конструктор emerge может выкинуть исключение на этапе десериализации из файла.

Нужно это предусмотреть и обработать. Например. обернуть Result.runCatching{ }. Тогда emerge будет возвращать Result, то есть однозначно говорить о том, что функция (метод) может зафэйлиться при исполнении и вернуть Two Track Type — или результат выполнения в поле success или failure.

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

Валидацию формата полей класса dateFrom, dateTo лучше вынести в функцию emerge и если на вход влетели битые данные — вернуть понятную ошибку.

HttpRequestEnvelope

Класс — DTO, принадлежит слою представления, перегружен логикой, которой в DTO вообще быть не должно по определению. Её нужно вынести в соответствующие классы уровня бизнес-логики.

Поле класса body (31 строка) лучше сделать пустой строкой по-умолчанию — так приближаемся к Null Safety universe.

Функция emerge

Поля просто перекладываются из входных параметров функции в поля класса. Умный конструктор говорит «тут возможна ошибка создания валидного объекта, поэтому я верну Result», который нам не нужен. Поэтому лучше заменить его на простой of метод.

Функция putPsRequestInBody

В первую очередь — что за заклинание вместо названия? Переименовать.

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

Во-вторых, в 71 строке мы генерируем json-строку из класса, который собирается из тела body-запроса. И если GetWalletBalanceRequest зафэйлится и не сможет собраться из строки запроса, которая должна содержать JSON, мы получим необработанный Exception. Это плохо, так в коде преднамеренно заложена ошибка и не заложена обработка этой ошибки.

Лучше собрать класс в одном месте с HttpRequestEnvelope и GetWalletBalanceRequest.

В-третьих, в 63 строке вместо fold стоит использовать Result.map — он для этого и создан. Или вовсе — передавать на вход в данный метод не Result, а HttpRequestEnvelope.

Проектируйте систему так, чтобы она работала с валидными объектами — это возможно и помогает смоделировать процесс более надёжно. Так, на слое, где можно вызвать «Пут Пс Реквест Ин Боди» — что бы это ни значило — стоит обработать возможную ошибку, а не прокидывать её в наш замечательный метод.

Например так:

Кроме того, validatedRequest содержит в себе validatePsRequest.

Но валидации для PsGetBalanceRequest тут не место. Она должна находиться в умном конструкторе PsGetBalanceRequest. Да и саму функцию validatePsRequest (в 24 строки) можно описать элегантней.

HttpResponseEnvelope

Вопрос к nullable-полям. Почему в запросе перекладчика могут отсутствовать:

• method;
• service;
• operation;
• body;
• headers.

Нужно чётко описать контракт в README и вместе с аналитиком прояснить, в каких случаях эти параметры могут быть null. Часто можно прийти к выводу, что поля класса сделаны nullable «на всякий случай» потому что лень писать качественно.

toJsonString

Функция не используется — удалить.

47 строка, emerge

Это просто мэпер, поэтому смарт-конструктор тут не нужен. Например можно использовать of для такой задачи.

И выглядеть это будет так:

62 строка, emerge

В этой функции:

• не нужно создавать клон функции на 47-ой строке и передавать на вход Result — стоит удалить метод.
• нужен map вместо fold.

А ещё стоит читать документацию к классу Result на сайте Kotlin и использовать методы по назначению и на нужном уровне. Но с этим мы разберемся подробнее при рефакторинге.

86 строка emerge(correlationId: String, ex: Throwable):

Дружелюбный Alt + F7 показал, что HttpResponseEnvelope, MqResponseMessage, RestServiceRequest и PsGetBalanceRequest не используются — удаляем.

Мы работаем не с библиотекой, так что IDE подсказывает, что нужно убрать, через warning. Можно еще подключить плагины: SonarLint, SonarAnalyzer и так далее — они хорошо помогают.

Кстати, есть хорошая рекомендация от Марка Симана (кинга «Код, который умещается в голове»): делайте предупреждения ошибками и не допускайте пул реквесты с warning в коде.

Пакет service

MqHttpService

Метод registerJmsListener создает слушатель на очередь, когда мы поднимаем конфигурацию в классе MqServiceConfiguration. Описать слушатель на конкретной задаче лучше явно. Это упростит восприятие и сократит конфигурационную обертку.

При рефакторинге мы явно создадим слушатель в так называемом Buble Context — и покажем, как просто протестировать этот код.

MqPublisher

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

• Первый — асинхронный метод, который оборачивает отправку сообщения в очередь на строке 22 в mono. Вызов может выкинуть исключение, как минимум, в двух очевидных случаях: если очереди не существует или отвалилось подключение к MQ.

• Второй — небезопасный синхронный метод отправки сообщения в очередь.

Зачем нам вообще и асинхронный, и синхронный методы, когда можно завернуть IO-операцию в асинхронный стек реактивщины и оставить только publishToMq, переименовав метод в publish.

Функция fillMessageWithHeaders

Содержит бизнес-логику обогащения запроса заголовками. Такое сложно тестировать. Так что функцию следует вытащить в доменный объект и тестировать явно юнит-тестом.

Интерфейс PipelineService

Функция receiveMessage описывает громоздкий контракт, которому должны соответствовать сервисы обработки разных бизнес-потоков для разных слушателей. Если нужно передать много параметров — лучше оберните параметры в класс, получится проще и «чище».

Кроме того, большинство параметров передать инъекцией. Попробуйте написать Rest Controller, который описывает API URL-ресурса, и в сигнатуру метода пердеайте конфигурацию rest-сервиса, rest client, который понадобится под капотом на уровне application service, и mq publisher на всякий случай.

PipelineServicePS-сервис приложения

Application — сервис, помеченный аннотацией фреймворка как компонент. Если имплементировать интерфейс, начинаются очень странные дела в теле функции (честно, мы ее не придумали).

Входные параметры присваиваются полям класса, потому что разработчик так передал компоненты, конфигурацию и REST-клиент. Он логирует заголовки и тело запроса и пробрасывает входной параметр message в метод process.

А ещё код как бы поощряет невалидные ситуации. Он написан в ущерб тестам и может сломать контракт.

Пройдёмся по ошибкам в классе:

• processMessage. Метод на 30 строк, который состоит из секции настройки переменных (больше похожей на ловушки). Разберёмся с аналитиком по контракту и упростим.

• correlationId. 64-ая строка Устанавливается Elvis operator рандомно и при этом отсутствует в заголовке. На деле correlationId — должен передаваться в заголовке всегда, иначе система выдаст ошибку и сообщит об этом. Подробнее можно почитать тут.

• url. Глушим отсутствие в заголовке значения метода. Так делать нельзя. Нужно проверить контракт, и если url не задан — вернуть сообщение об ошибке.

• Вместо того чтобы писать комментарий ниже, лучше сразу найти способ или создать тикет и добавить его в комментарий — задача будет реализована в рамках 20-30% техдолга.

• httpReq должна быть неизменной — val.

Функция acceptedMqReceipt

Во-первых, нужно уменьшить количество входных параметров.

Во-вторых, в строке 106 — вместо fold можно применить map.

В третьих, прочитаем тело функции:

• Строка 107. Если на вход пришел успешный запрос, вызываем функцию createMessageForReceipt, входных параметров в которую слишком много.
• Строка 109. Вызываем map в котором лежит бизнес-логика преобразования сообщения, созданного в функции createMessageForReceipt.
• Строка 112. Отправляем ответ на что-то неизвестное, судя по имени jmsResponse.

• Строка 100. Если приходит успешный HttpRequestEnvelope, который был собран из строки 75 и провалидирован, берем некое Ps, помещаем в HttpRequestEnvelope и проваливаемся в странную функцию acceptedMqReceipt, где создаем сообщение для квитанции, превращаем его в jmsResponse и отправляем в строку 112

То есть функция должна отправить сообщение с квитанцией в очередь mq. Но из имени не понятно, что делается в теле. И происходящее описано очень сложно. Решение — переименовать функцию, отправить квитанцию на вход, подать один параметр, в теле отправить квитанцию в mq.

Функция fun createMessageForReceipt

Эта функция буквально говорит то же, что и предыдущая: «Я содержу много бизнес-логики преобразований. Меня неудобно читать. Во мне много входных параметров. Во мне неверно используют Result».

Кроме того, не стоит кидать fold в fold через map. А map{it} мэпит в самого себя строка 151.

createMessageForReceipt после упрощения будет возвращать объект, который легко протестировать.

Функция convertToReceiptJmsResponse

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

Функция convertToBasicJmsResponse

Те же замечания что и к предыдущей функции.

Функция prepareSipHeaders

Те же замечания что и к предыдущей функции.

Функция processMqResponse

В HttpResponseEnvelope.emerge нет умного конструктора, поэтому функцию назвать нужно было map и использовать просто в of.

Кроме того, нужно правильно применить Result в классе HttpResponseEnvelope. Сейчас, этот метод (функция) возвращает Result просто потому что.

Функция submitMqReceipt

Судя по развилке, функция делает несколько дел сразу.

• Если на вход залетает mqResponse — Result<MqResponseMessage> в виде Result.success — то функция некрасиво создает квитанцию createMessageForReceipt. И через две операции мэпит в JMS ответ и отправляет в MQ.

• Если на вход (строка 204) залетает mqResponse — Result<MqResponseMessage> в виде Result.failure — то создаётся createMessageForReceipt квитанции об ошибке.

К тому же функция submitMqReceipt принимает на вход слишком много лишних параметров.

Функция submitMqResponse чуть проще, но ошибки те же: выбор, конвертация, отправка.

После форматирования чуть проще воспринять.

В следующей части начнём рефакторить код и разбирать всё подробнее.

Что такое SOLID принципы?

Современная разработка требует передовых навыков и глубоких знаний сложных принципов программирования. Одной из наиболее важных структур, используемых сегодня в разработке программного обеспечения, являются принципы SOLID — они же пять основных принципов объектно-ориентированного программирования.

Понимание SOLID является обязательным для всех разработчиков, и в этой статье мы объясним их простым языком.

Расшифровка SOLID

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

1. Принцип единственной ответственности (Single Responsibility Principle – SRP): Каждый класс должен иметь только одну причину для изменения. Это означает, что класс должен быть ответственным только за одну конкретную функцию или задачу. Этот принцип помогает сделать классы более связанными, легко понятными и поддерживаемыми.
2. Принцип открытости/закрытости (Open/Closed Principle – OCP): Программные сущности, такие как классы, модули и функции, должны быть открыты для расширения, но закрыты для модификации. Вместо изменения существующего кода, следует добавлять новый код для внесения изменений. Это позволяет создавать более стабильные и гибкие системы.
3. Принцип подстановки Лисков (Liskov Substitution Principle – LSP): Объекты в программе должны быть заменяемыми экземплярами их базовых типов, не нарушая корректность программы. Это означает, что код, который работает с базовым типом, должен работать и с любым его подтипом, не вызывая ошибок или неожиданного поведения. Этот принцип обеспечивает согласованность в использовании наследования и полиморфизма.
4. Принцип разделения интерфейса (Interface Segregation Principle – ISP): Клиенты не должны зависеть от интерфейсов, которые они не используют. Вместо создания общих интерфейсов следует создавать специфические интерфейсы, предназначенные для конкретных клиентов. Это позволяет избежать излишней связности между компонентами системы и улучшить модульность.
5. Принцип инверсии зависимостей (Dependency Inversion Principle – DIP): Классы должны зависеть от абстракций, а не от конкретных реализаций. Высокоуровневые модули не должны зависеть от низкоуровневых модулей. Оба типа модулей должны зависеть от абстракций. Этот принцип помогает уменьшить связанность между компонентами системы и повысить их переиспользуемость.

Все эти пять принципов SOLID способствуют созданию гибкого и легко поддерживаемого кода, а также улучшают модульность, переиспользуемость и расширяемость системы.

Акроним SOLID принципов был сформулирован Робертом С. Мартином, также известным как «Дядя Боб», одним из самых влиятельных разработчиков программного обеспечения в области разработки программного обеспечения.

Хотя многим эти принципы могут показаться сложными, мы постараемся объяснить их простым и понятным способом.

Принцип единой ответственности

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

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

SOLID примеры на Python — принцип единой ответственности

Концепция принципа единой ответственности (SRP) заключается в том, что класс должен иметь только одну причину для изменения. Давайте рассмотрим пример с классом User, который нарушает этот принцип:

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

Давайте применим принцип единой ответственности, разделив класс User на несколько отдельных классов с единой ответственностью:

Теперь каждый класс имеет только одну ответственность. Класс User отвечает только за данные пользователя и сохранение их в базе данных. Класс EmailSender занимается отправкой электронной почты, а класс ReportGenerator отвечает за генерацию отчета пользователя.

Это пример применения принципа единой ответственности, который помогает разделить функциональность на более мелкие и специализированные классы, упрощает понимание кода и делает его более гибким для изменений.

Визуальное представление SRP

Визуализация SRP, как одного из SOLID принципов, может быть представлена в виде диаграммы классов, где каждый класс имеет только одну ответственность. Каждый класс должен быть ответственным только за выполнение одной конкретной функции или задачи. Если класс имеет несколько ответственностей, это может указывать на нарушение SRP:

В этой визуализации каждый класс представлен прямоугольником, и у каждого класса есть только свои собственные методы, относящиеся только к его ответственности.

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

Резюмируя

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

Принцип открытого-закрытого

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

SOLID примеры на Python — принцип открытого-закрытого

Принцип открытого-закрытого (Open/Closed Principle – OCP) заключается в том, что программные сущности, такие как классы, модули и функции, должны быть открыты для расширения, но закрыты для модификации. Давайте рассмотрим пример с классами Shape и AreaCalculator, где будем применять принцип OCP:

В этом примере у нас есть абстрактный класс Shape, который определяет метод calculate_area(). Затем у нас есть два класса-наследника Rectangle и Circle, которые реализуют этот метод для расчета площади прямоугольника и круга соответственно.

Класс AreaCalculator отвечает за вычисление общей площади для набора фигур. Он использует SOLID принцип OCP, поскольку он открыт для расширения новыми типами фигур, но закрыт для модификации своей основной логики. Если мы хотим добавить новый тип фигуры, например, треугольник, мы можем создать новый класс Triangle, реализующий метод calculate_area(), и передать его в AreaCalculator.calculate_total_area() без изменения самого AreaCalculator:

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

Резюмируя

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

Принцип подстановки Барбары Лисков

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

SOLID примеры на Python — принцип подстановки Барбары Лисков

Принцип подстановки Барбары Лисков (Liskov Substitution Principle – LSP) гласит, что объекты должны быть заменяемыми экземплярами их базовых типов без нарушения корректности программы. Давайте рассмотрим пример с классами Rectangle (Прямоугольник) и Square (Квадрат), чтобы проиллюстрировать принцип LSP:

В этом примере класс Rectangle представляет прямоугольник с методами для установки ширины и высоты, а также для получения площади.

Класс Square наследуется от Rectangle и переопределяет методы set_width() и set_height(). В случае квадрата ширина и высота всегда должны быть одинаковыми, поэтому при установке одного измерения класс Square автоматически устанавливает и другое измерение равным ему.

Однако данный пример нарушает SOLID принцип LSP. Рассмотрим следующий код:

В этом примере мы вызываем функцию print_area(), которая ожидает объект типа Rectangle. Когда мы передаем rectangle, результат площади правильный (20), потому что ширина и высота были установлены независимо. Однако, когда мы передаем square, ожидаемая площадь должна быть также 20, но фактически получаем 16. Это происходит из-за изменения поведения методов set_width() и set_height() в классе Square.

Таким образом, класс Square не является полностью заменяемым объектом для класса Rectangle, нарушая принцип LSP. Чтобы исправить это, мы можем пересмотреть дизайн иерархии классов, чтобы избежать нарушения принципа LSP, или использовать интерфейсы и абстракции для достижения корректного поведения при замене объектов.

Резюмируя

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

Принцип разделения интерфейса

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

SOLID примеры на Python — принцип разделения интерфейса

Принцип разделения интерфейса (Interface Segregation Principle – ISP) гласит, что клиенты не должны зависеть от интерфейсов, которые они не используют. Вместо создания общих интерфейсов следует создавать специфические интерфейсы для конкретных клиентов. Давайте рассмотрим пример с интерфейсами для различных устройств вывода ввода:

В этом примере у нас есть абстрактные классы InputDevice и OutputDevice, представляющие интерфейсы для устройств ввода и вывода соответственно. Затем мы определяем конкретные классы Keyboard, Mouse, Monitor и Printer, которые реализуют соответствующие методы.

Применяя SOLID  принцип ISP, мы разделяем интерфейсы на более специфические, чтобы клиенты могли зависеть только от интерфейсов, которые они используют. Например, если клиенту нужен только ввод с клавиатуры, он может зависеть только от интерфейса InputDevice и использовать класс Keyboard:

В этом примере функция process_input() принимает объект, реализующий интерфейс InputDevice, и обрабатывает его ввод. Здесь мы передаем объект Keyboard, который соответствует интерфейсу InputDevice. Таким образом, клиент зависит только от необходимого интерфейса и не зависит от лишних методов или классов.

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

Резюмируя

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

Принцип инверсии зависимостей

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

SOLID примеры на Python — принцип инверсии зависимостей

Принцип инверсии зависимостей (Dependency Inversion Principle – DIP) гласит, что классы должны зависеть от абстракций, а не от конкретных реализаций. Высокоуровневые модули не должны зависеть от низкоуровневых модулей. Оба типа модулей должны зависеть от абстракций. Давайте рассмотрим пример с классами Notification и EmailSender, чтобы проиллюстрировать принцип DIP:

В этом примере класс User зависит от конкретной реализации EmailSender в качестве сервиса уведомлений. Это создает прямую связь между User и EmailSender, что делает классы сложнее для тестирования и внесения изменений.

Чтобы применить SOLID принцип DIP, мы изменяем User, чтобы он зависел от абстракции Notification, а не от конкретной реализации:

Теперь User принимает объект notification_service, реализующий интерфейс Notification, через конструктор. Это позволяет передавать различные реализации уведомлений, такие как EmailSender или SMSNotification, без изменения самого User:

Теперь User зависит от абстракции Notification и может быть легко настроен для работы с различными реализациями уведомлений. Это уменьшает связанность между классами, делает их более гибкими и легкими для тестирования и модификации.

Резюмируя

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

Заключение

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

Примечание Рейтинг степени важности в разработке (0-10) является относительной оценкой и может различаться в зависимости от конкретной ситуации и контекста разработки.

Надеемся, что принципы SOLID на Python примерах оказались полезны и доступны для понимания.

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

1. Да кому вообще нужен этот чистый код?
2. Как написать чистый код?
3. Подробное руководство
4. Как править НЕ чистый код?

Да кому вообще нужен этот чистый код?

Читаемый, легко тестируемый, легко компонуемый код, который решает бизнес-задачу и сам является документацией, сокращает ТТM (time to market). За счёт времени, которое разработчик тратит на изучение приложения, внесение изменений в код, добавление новых фич и прочее.

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

Так что, по сути, он нужен всем, кто работает в IT.

Разработчикам

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

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

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

Лидам

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

Бегите из команды, если ваш техлид говорит: «Чистый код — это миф. А те, кто пишут про него книги, статьи и доклады, не работают, а выдумывают теорию, которая на практике неприменима».

Бизнесу

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

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

Хорошо, и как тогда написать чистый код?

Сперва почитать хорошие книги

Да, лень — но надо. Всё хорошее и «правильное» уже придумано, и чтобы писать код грамотно, необязательно 5 лет изобретать велосипеды, как это делал я.

Рекомендую читать Роберта Мартина, Владимира Хорикова, Джошуа Блоха, Скота Влашина, Стива Макконнелла и стремиться к профессиональной простоте кодирования. Важно: старайтесь читать книги в оригинале.

Важно понимать, что некоторые топики, которые тот же Мартин отстаивал в 2008, уже не актуальны. Советую отсеивать их и просто забирать полезное.

Обратить внимание на принципы Unix

• Write programs that do one thing and do it well — Каждая программа, класс, функция выполняет одну задачу — и выполняет хорошо.
• Write programs to work together — Программы работают совместно, и мы можем выстроить пайплайн. Компоненты на разных уровнях работают вместе и взаимодействуют посредством классов.
• Write programs to handle text streams, because that is a universal interface — Программы взаимодействуют, используя универсальный текстовый интерфейс, а классы — код. Тип — универсальный интерфейс взаимодействия функций и классов.

Эти принципы помогают мне осознавать архитектуру в срезе сложного приложения, и проектировать программы/классы/функции.

Unix-философия хорошо подходит для проектирования микросервисов (программ). Поэтому я рекомендую исследовать мир Unix и использовать Linux разработчикам.

Внимательно прочитать руководство ниже

Здесь я привёл основные рекомендации по написанию чистого кода, основанные на многих годах практики и книгах «Чистый код» и «Чистая архитектура: Руководство ремесленника по структуре и проектированию программного обеспечения».

Всегда улучшайте код, с которым работаете

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

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

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

Think twice, code once

Прежде чем приступить к разработке, доработке, рефакторингу, разберитесь в том, как функция/система работает по данному потоку. Станьте экспертом в предметной области.

Используйте функциональную парадигму

Она загоняет нас в рамки чистого кода и способствует следовать лучшим практикам. Кроме того, чистое ООП в программах не нужно. Серьёзно, нет.

Это тема для отдельной статьи, но тут поделюсь фактом: в нескольких больших банках функциональная парадигма — стандарт де-факто при написании микросервисов. И советую почитать, что Роберт Мартин пишет в блогеAnd the future is looking very functional to me.

Делите код на слои

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

• Разделяйте логику и представление, чтобы упростить тестирование и обеспечить независимость компонентов.
• Используйте Вертикальное разделение. «Переменные, функции должны быть определены близко к тому месту, где они используются» (G10 Vertical Separation Clean Code, page 292).
• Опирайтесь на луковичную архитектуру, где внутренний слой ничего не знает о внешнем — это помогает визуализировать и проектировать структуру приложения.

Пара материалов по теме:

• https://www.redhat.com/architect/5-essential-patterns-software-architecture#layered

• https://www.redhat.com/architect/14-software-architecture-patterns

• https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/

Соблюдайте принципы SOLID для проектирования сервисов, классов и функций

Нам особенно важен «Принцип единственной ответственности (Single Responsibility Principle)» для классов и функций, сервисов:

«Каждый класс или функция должны выполнять только одну задачу».

То есть пишите функции, которые делают только одну вещь — и делают её хорошо. Есть несколько способов убедиться, что выполнили это правило:

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

Избегайте наследования

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

Предпочитайте полиморфизм операторам If/Else

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

DRY

Код должен быть повторно использован только тогда, когда имеет ту же ответственность.

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

Не увлекайтесь DRY при написании тестов. Универсальность в них часто уменьшает читабельность, а значит, ясность. Помните, тест — это документация.

Классы не должны знать о внутренней реализации других классов

Не думайте о внутренней работе юнита (класса, функции) — лучше смотреть на него, как на чёрный ящик. Это поможет при проектировании и писании прекрасно тестируемого кода.

G22: Make Logical Dependencies Physical

Если один модуль зависит от другого, эта зависимость должна быть физической, а не только логической. Также зависимость должна быть очевидной

Используйте понятные и описательные имена

Для всего: переменных, функций, классов и других элементов кода. Избегайте сокращений и аббревиатур.

Форматируйте код

Казалось бы, очевидное правило. Но как показывает практика — нет. Поэтому:

• открыли класс в Idea, нажали Ctrl + Alt + L, продолжаем работу;
• одной пустой строки в отступах между блоками в коде достаточно.

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

Опирайтесь на 3 закона TDD

• You may not write production code until you have written a failing unit test — Мы не выпускаем в прод код, который не покрыт тестами.
• You may not write more of a unit test than is sufficient to fail, and not compiling is failing — Покрываем тестами код в достаточном количестве, чтобы убедиться, что данный слой (класс, функция) работает верно. Не дублируйте тест кейсы на разных уровнях. Если все сделали правильно: покрыли юнит-тестами бизнес-логику, не нужно дублировать проверку всех бизнес-кейсов интеграционными тестами.
• You may not write more production code than is sufficient to pass the currently failing test — Написал код — написал тесты. Или в обратном порядке.

Эти законы можно интерпретировать и использовать и тем, кто не придерживается каноничного TDD.

Не используйте исключения для обработки ошибок

Мартин рекомендовал в своё время использовать исключения. А я — нет. Исключения для нас — только сигналы багов. А для обработки ошибок мы используем R.O.P.

Комментарий — признак плохого кода

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

Общее правило для большинства случаев: если вам приходится добавлять комментарии — перепишите код.

Задавайте границы для внешних библиотек и систем

Оборачивайте внешние библиотеки или API в API который подходит вашему дизайну — это даст запас прочности.

Применяйте Anti-corruption Layer pattern в дизайне кода. И используйте юнит-тесты.

Живите в парадигме Null Safety

Не передавайте null

Не возвращайте null

Не используйте null

Размер функции или метода — максимум пять строк

Об этом пишет Кристиан Клаусен в книге «Пять строк кода» которую Роберт Мартин рекомендует.

Сам Мартин указывает, что размер функции не должен превышать 20 строк по 150 символов каждый, но чем меньше — тем лучше.

Идеальное количество входных параметров для функции — один

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

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

Отделите бизнес-логику предметной области от логики приложения

Например, бизнес-правила, консистентное состояние объектов в системе, проверки ограничений (валидация), расчёты, используемые в решении, не следует путать с техническими деталями, такими как схема базы данных, интеграции с внешними системами, сервисами уровня приложений и уровнем DTO.

Наконец, помните, что написание чистого кода — это ремесло и где-то даже искусство, которое требует практики и терпения. Не бойтесь переписывать код, если это поможет улучшить его качество и поддерживаемость. А если ищете элегантное простое решение, смотрите кукбук.

А если мне попал в руки НЕ чистый код?

Тогда начинаем рефакторинг. Я использую такой алгоритм:

• Просматриваем приложение сверху вниз, оцениваем насколько оно хорошо спроектировано и как описаны классы.
• Узнаем у автора этого непотребства, что делает сервис.
• Открываем Readme и в функциональном стиле описываем назначение сервиса. Нам пригодятся Markdown Best practices. Лучше визуализировать процесс (например, с помощью https://excalidraw.com/) это поможет представить правильную картину и структуру классов.
• Продумываем, как будем всё это тестировать. Если всё выглядит совсем монструозно, я предлагаю воспользоваться дорогими, но покрывающими максимум кода интеграционными тестами. Раз уж это творение орков работает, зафиксируем состояние и покроем крайние точки тестами. Проверенная тактика.
• Во время рефакторинга сразу покрываем код юнит-тестами.

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

А что дальше?

В первой части я описал смысл и принципы чистого кода. В следующей мы проанализируем приложение на предмет чистоты кода. Я пройдусь по каждому классу и опишу недостатки. И расскажу, как это исправлять.

Это — первая серия проекта «Код Раковского», где Александр Раковский, Senior Java разработчик компании ITentika, расскажет о том, что считает важным и интересным в сфере программирования.

Каких-то жестких правил тут не будет, главное, запомните:

1. Здесь не любят костыли и велосипеды.
2. Здесь не терпят код без тестов.
3. Здесь чтут отцов аджайла.
4. Здесь суровое экстремальное программирование.

Возьмем пример из революционной книги Мартина Фаулера «Рефакторинг». Книге в следующем году 20 лет стукнет, поэтому пример оттуда сегодня будет смотреться необычно.

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

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

Что мы будем рефакторить?

Давайте посмотрим на структуру кода.

Наш проект состоит из 4 классов: главного класса, класса клиента, класса аренды и класса фильма.

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

В классе клиента есть только метод вычисления счета — это, по сути, единственная логика во всей программе. Ее-то мы и будем рефакторить.

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

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

Длинные и короткие методы

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

Так в чем же тогда проблема длинных методов? Основных проблем две:

1. Обычно весьма трудно разобраться, что в них происходит.
2. Если метод уже стал большим по какой-то причине, то, скорее всего, по этой же причине он и будет расти дальше. Уверен, многие из вас видели «монстров» по несколько сотен и даже тысяч строк.

В то же время короткие методы имеют серьезные преимущества перед длинными:

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

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

— В конце концов, короткие методы больше способствуют переиспользованию кода.

Ну хорошо, а как понять, что метод длинный?

— Если встал вопрос, значит, скорее всего, длинный.

— Если вопрос не встал — метод, скорее всего, тоже длинный. Ведь в реальных кодовых базах есть очевидное преобладание длинных методов над короткими.

— Если за несколько секунд не удалось понять, что происходит в методе — он длинный.

— Наконец, если в нем больше 10-12 строк — абсолютно точно длинный. Хорошая длина метода — от одной до 3-4 строк.

Что же делать с длинным методом? В 99% случаев — извлекать из него маленькие методы. Извлечение метода должно стать первым инструментом на пути к более чистому коду. Первое, что делает любой программист, научившийся настоящему рефакторингу — начинает безудержно извлекать методы по поводу и без. И именно тогда он и понимает все преимущества коротких методов.

Что извлекать? Подсказками будут циклы, условные операторы и комментарии. Также стоит смотреть на места с высокой плотностью обращения к одной и той же переменной.

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

Feature Envy

Следующий код-смелл Feature Envy в русском переводе называется «завистливая функция». Весь смысл объектов в том, данные живут вместе с поведением, однако часто приходится видеть, как метод заинтересован больше в чужом классе, чем в своем. Вот и в нашем случае метод getCharge активно использует данные класса Аренды, а вот методы и поля же собственного класса он попросту игнорирует.

К счастью, решение очевидно: если ваш волк смотрит в лес — отпустите его туда. То есть, если метод getCharge так интересуется с классом аренды, то, собственно, там ему и место. Давайте перенесем уже, наконец, этот метод в его новый дом. Для этого воспользуемся автоматическим рефакторингом.

Локальные переменные

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

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

Чтобы избавиться от локальной переменной, мы воспользуемся методом рефакторинга «Встраивание переменной».

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

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

Продолжаем декомпозировать длинный метод

Следующий на очереди к извлечению у нас кусок кода, рассчитывающий очки лояльности, так называемые рентер-поинты.

Разделение цикла

В этот раз мы воспользуемся методом рефакторинга под названием «Разделение цикла». Он нужен для того, чтобы декомпозировать один цикл на несколько более маленьких циклов.

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

Как только мы разделили цикл на несколько, мы можем извлечь цикл в новый метод.

Замена цикла конвейером

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

На этом этапе уже можно встать на паузу и посмотреть на получившийся код. У нас есть метод, собирающий текст итогового счета, и есть отдельные методы, которые считают нужные нам данные. Этого нам УЖЕ достаточно, чтобы добавить новую фичу вывода данных в HTML. По сути, все, что осталось в этом коде — заменить текстовые строки на HTML-теги.

Switch case

Приступим к внедрению второй фичи: нам нужно добавить еще несколько типов фильмов. Мы могли бы поступить следующим образом: добавить новый код, например «драма», пойти в класс аренды и в switch-case добавить отдельное условие. И, если потребуется, добавить еще одно условие в метод расчета очков лояльности.

Здесь на нашем пути встает еще один код-смелл: switch-case. Это канонический пример нарушения Open-Closed принципа из всем известных SOLID-принципов.

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

Решением этой проблемы становится полиморфизм. В данном случае мы можем создать нескольких наследников для класса «фильм», перегрузив метод расчета чека. То есть, это будут классы Regular Movie, Children’s Movie и NewReleaseMovie

Но есть одна проблема. Мартин Фаулер, автор книги и нашего примера, пишет, что схема с полиморфным фильмом всем хороша, но не всегда работает. По его словам, фильм в течение своей жизни может менять свой тип: новый релиз может перестать быть таковым и просто стать детским. Взамен Мартин предлагает воспользоваться шаблоном проектирования State Pattern: в класс Movie будет добавлено поле Price с тремя наследниками: RegularPrice, ChildrensPrice и NewReleasePrice.

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

«Что дальше?»

Давайте посмотрим на первоисточник.

Единственным способом добавить в него HTML-вывод было бы просто скопировать тело метода и заменить текст на теги. Но в таком случае при каждом изменении правил ценообразования или при добавлении нового жанра нам пришлось бы править все в двух местах. А добавляя новые жанры в этот метод, мы бы сделали его огромным и неподдерживаемым источником багов. Теперь этот код выглядит так:

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

Перечисленных здесь код-смеллов и методов рефакторинга хватает для большинства задач.

Тесты и требования к ним

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

Начнем с тестов. Первая проблема современных кодовых баз — уровень покрытия. В командах обычно принято какое-то правило, например «80% покрытия тестами», что сразу вызывает вопрос: неужели это нормально, что 20% программы не работает?

Конечно, нет. Рефакторинг требует уверенности.

Самый лучший способ добиться полного покрытия — просто не писать код, на который не написан тест. Это может звучать невероятно глупо, но, поверьте, это работает, и работает очень круто. Этот подход, описанный Кентом Беком, называется Test-Driven Development.

Второе требование к тестам — тесты не должны быть хрупкими!

Помню, как я смотрел свой первый курс лекций по юнит-тестам. Именно там я узнал, что в словосочетании юнит-тест «юнит» — это класс. Я начал писать классы парами: продакшн класс и тестовый класс. Все взаимодействия с другими классами в такой ситуации необходимо было закрывать моками. Потом, прочитав книжку по рефакторингу, я начал активно рефакторить все подряд. И какова же была моя боль, когда при каждом переносе метода или извлечении класса мне приходилось мучительно переписывать тесты.

Так я впервые столкнулся с проблемой «хрупких тестов». Тесты не помогали рефакторить, как предполагалось. Наоборот, они невероятно сильно мешались под ногами. Это очень глупая ситуация, ведь тесты только для того и нужны, чтобы быть уверенным, что поведение написанного кода не изменилось при редактировании. А это и есть определение рефакторинга — изменение кода без изменения поведения. В итоге я попал в ситуацию, когда тесты свою задачу практически не выполняли.

Через некоторое время я узнал, в чем была проблема. Уже упомянутые Мартин Фаулер и Кент Бек, как оказалось, пишут тесты совсем иначе. В словосочетании «юнит-тест» для них слово «юнит» означало не «класс» и не «метод», а «поведение» — наименьший неделимый фрагмент функциональности.

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

Покажу на примере. Возьмем типичное корпоративное приложение со множеством интерфейсов ввода и вывода. В центре такого приложения всегда лежит бизнес-логика. Код, связывающий бизнес-логику со внешними системами, упакован в отдельные слои — gateway. Это могут быть репозитории, DAO, или, например, сложный клиентский код внешней системы.

Все, что необходимо глушить для того, чтобы тесты не мешали рефакторингу — это gateway. А чтобы код самих gateway тоже можно было рефакторить, пишутся отдельные тесты — интеграционные.

Как встроить рефакторинг в свой рабочий процесс?

Обычно самый первый вопрос — как правильно выделить время под рефакторинг. Заводить ли для этого отдельные таски и когда рефакторить, если фичи в приоритете?

Ответ такой: рефакторинг должен проводиться непрерывно на всем этапе разработки.

Обычно это выглядит так:

— Вы взяли задачу и начали читать код. На этом моменте обычно вам уже придется что-то подрефакторить.

— Потом вы приступили к разработке. Буквально через 5-10 минут, максимум полчаса-час, у вас должен быть рабочий кусок кода, покрытый тестом. Тут же надо его рефакторить.

— Снова разработка, снова покрытый тестами кусок кода через непродолжительный отрезок времени.

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

Если вы делаете это в парадигме TDD, то этот подход будет называться Red-Green-Refactor. То есть сначала пишете красный тест на какой-то фрагмент функционала, потом пишете код, который делает ваш тест зеленым, потом рефакторите.

Отсюда и следуют ответы на другие вопросы:

— Заводить ли под рефакторинг отдельные таски?

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

— Когда рефакторить, если надо делать фичи?

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

Как договориться с коллегами?

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

Что ж, самое простое тут — это менеджер. Рефакторинг — способ двигаться быстрее, так что можно попробовать зайти с экономической стороны вопроса. Но, в целом, можете просто ничего про рефакторинг не рассказывать, не его это дело. Фича готова? Готова. А как именно — это уже детали реализации. Самое главное — помнить, что вы профессионал и вам лучше видно, как делать свою работу.

Если против вас ополчилась команда и договориться не удалось никак, то тут все плохо. Обычно такие глубокие разногласия приводят к разводам — кто-то уходит, а кто-то остается. Вопрос лишь в том, кто у руля.

На этом мы, пожалуй, и закончим знакомство с НАСТОЯЩИМ рефакторингом.

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

Совет 1: Добивайтесь зелёной галочки

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

Затем мы взяли за правило ВСЕГДА избавляться от предупреждений (фиксить или заглушать их). При появлении новых предупреждений (из-за рефакторинга или добавления новых проверок), мы следуем правилу бойскаута (всегда оставляй после себя код в лучшем состоянии, чем до тебя).

Однако есть более сложный случай — точки входа, такие как фрагменты, на которые ссылаются только с помощью рефлексии (Android Studio помечает их как неиспользуемые). Чтобы избавиться от таких предупреждений мы сделали TonalEntryPoint.

Используя эту аннотацию в классе или конструкторе, который помечен как неиспользуемый, и нажимая alt+enter, мы получим возможность добавить неиспользуемый код в список точек входа.

Совет 2: Относитесь к предупреждениям Kotlin, как к ошибкам

Для этого добавим следующий код в файл build.gradle:

Совет 3: Делегат ViewBinding

Мы очень любим View Binding. Он отлично работает, и мы полностью перешли на него с ButterKnife/Kotlin Synthetics. Однако, синтаксис его создания не идеален, поэтому мы создали собственный делегат, чтобы создавать его в соответствии с жизненным циклом, это выглядит следующим образом:

Здесь можно посмотреть полный код.

Совет 4: fadeTo(visible)

Необходимость скрыть/показать view возникает часто. Для улучшения пользовательского опыта мы создали функцию fadeTo() в качестве замены для View.setVisibility() или View.isVisible = true/false.

Код функции можно найти на GitHub.

Совет 5: mapDistinct()

Это простое сокращение для Flow.map().distinctUntilChanged().

Совет 6: uniqueObservable()

Delegates.observable в Kotlin очень полезен. Однако:

1. Иногда нам нужно делать что-то только при изменении значения.
2. В таком случае писать лямбда-выражение с тремя параметрами и проверку на равенство чересчур шаблонно.

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

Совет 7: Отладка + Корутины и Broadcast Receivers

В настоящее время Broadcast Receivers (широковещательные приёмники) редко используются в Android. Однако они могут быть крайне полезны для тестов в процессе отладки.

Мы используем debug-only широковещательные приемники, которые, по сути, дают нам CLI для установки/обновления параметров в коде без необходимости вызывать меню отладки в UI или пересобирать приложение.

Наш coroutine friendly код будет выглядеть так:

Совет 8: ConflatedJob

Корутины часто используются для отмены выполнения Job, перед запуском нового (например когда пользователь делает pull to refresh). ConflatedJob автоматически отменяет старый Job, перед запуском нового.

Совет 9: Timber Property Delegate

Для логгирования мы используем Timber, однако его синтаксис Timber.tag(TAG).i(…)  — слишком громоздкий.

По аналогии с View Binding Delegate, мы написали делегат, который упрощает вызов:

Он автоматически создает TAG на каждое свойство (а не на строку журнала, как Timber.DebugTree), сокращает общие суффиксы, такие как “Impl” и “ViewModel” и обрезает теги до 23 символов.

Полный код на GitHub.

Совет 10: Number.dp

Так как в макетах обычно используют dp, а в свойствах View пиксели, часто в коде требуется конвертировать dp в пиксели. Именно поэтому вопрос о том как это сделать пользуется популярностью на StackOverflow. Мы используем для этого следующий extension на Kotlin:

С помощью этой функции очень просто обновить padding:

Как улучшить code review?

• Учитесь быстрее — правильно составляйте список изменений в коде, это поможет ревьюеру сконцетрироваться на главном и дать полезный фидбек.
• Делайте других лучше — подавайте пример коллегам.
• Избавьтесь от конфликтов в команде — code review это всегда споры. Относитесь к ним обдуманно и последовательно.

Золотое правило: цените чужое время.

Старайтесь сами находить ошибки, это полезно для вас обоих. Относитесь к ревьюеру не как к препятствию, а как к достойному доверия союзнику.

Техники подготовки к код ревью

Сделайте первое ревью самостоятельно

Дайте коду полежать до утра, а потом попробуйте представить, что видите его в первый раз. Что в нём вас смущает? Посмотрите на изменения в том же виде, в котором их увидит ревьюер. Избегайте повторяющихся ошибок (лишний файл, остатки отладочного кода).

Напишите понятный список изменений

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

Подробнее про списки изменений в статьях «How to Write a Git Commit Message» и «My favourite Git commit».

Автоматизируйте рутину

Не тратьте время ревьюера на проверку отступов у скобок. Отправляйте код на ревью только после того, как все автотесты отработали без ошибок. Используйте Git Hooks для проверки кода перед отправкой.

Пусть ваш код говорит сам за себя

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

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

Делайте узконаправленные изменения

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

Разделяйте функциональные изменения и рефакторинг

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

1. Добавьте поведенческие тесты.
2. Проводите рефакторинг, не изменяя код тестов.
3. Измените логику и обновите тесты.

Разделяйте длинные changelist’ы

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

Адекватно воспринимайте критику

При подготовке к code review морально настройтесь, что скорее всего вы получите в том числе негативный отклик. Лучший способ угробить code review — принять критику слишком близко к сердцу. Это особенно легко сделать, когда ревьюер формулирует фидбек как личные претензии.

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

Будьте терпеливы к ошибкам

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

Отвечайте на code review

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

Задавайте вопросы правильно

Если попадается непонятное замечание, спросите: «Что будет полезно изменить?». Также можно попробовать угадать намерения ревьюера и предварительно отредактировать код — это может помочь, даже если вы не совсем попали в цель.

В неоднозначных ситуациях отдайте преимущество ревьюеру

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

Оперативно отвечайте на комментарии

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

Расскажите, а как проходит ваша подготовка к код ревью? Готовитесь ли вы как-то вообще и считаете ли это необходимым?

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

В своей книге специалист подробно рассказывает о том, как избежать ошибок при написании кода и сделать его чистым.

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

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

Общие правила написания чистого кода

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

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

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

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

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

Наименование

При написании кода очень важно задавать верное название, поскольку наименование обеспечивает читаемость кода. Необходимо использовать наиболее понятные и подходящие наименования. Прочитав название метода или сущности, специалист должен сразу понять, за что она ответственна. Стоит также помнить о принципе единой ответственности, и если программист ему следует, то функция вряд ли будет содержать вставки “And” или “With”, поскольку функция выполняется лишь одно действие. При описании функции важно всегда использовать глаголы. Также желательно, чтобы в названии было ключевое слово, которое поможет понять, о чем эта функция.

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

Наименования лучше не сокращать, а прописывать полностью. Например, если используется слово «product», название «pr» будет не очень понятным для читателя. Важно, чтобы название полностью отражало ответственность сущности.

Функции

По мнению Р. Мартина, функции должны быть максимально короткими. Их длина не должна быть больше двадцати строк, а сами строки не должны быть длиннее ста пятидесяти символов. В противном случае ее лучше делить на части. Кроме того, важно, чтобы функция выполняла только одну операцию. Что касается входных параметров, в идеале их не должно быть. Но если входные параметры требуются, то их должно быть не больше трех. Чем больше входных параметров, тем тяжелее читать функцию.

Комментарии

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

Недописанный или некорректно работающий код всегда нужно комментировать, используя соответственно одно из двух ключевых слов «TODO» или «FIXME». В таком случае программист будет сразу понимать, что код не готов и его нужно дописывать. Также часто разработчики комментируют функции или части кода, чтобы когда-то к ним вернуться, и это переходит из ветки в ветку. Такие комментарии лучше не оставлять. Системы контроля версий хранят все состояния кода, поэтому необходимости переносить закомментированный код из ветки в ветку нет.

Форматирование кода, классы и обработка ошибок

При форматировании кода необходимо придерживаться общей стилистики проекта, его общепринятой архитектуры. Например, если в проекте используется архитектура V.I.P.E.R., то нужно использовать ее, иначе можно испортить код. Если же написание проекта начинается с нуля, то необходимо заранее продумать, какую архитектуру использовать и какой стилистики придерживаться.

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

Наконец, при обработке ошибок всегда важно использовать exсeptions (исключения) вместо возвращения кода ошибок напрямую. Обработка ошибок всегда должна представлять собой только одну операцию. В функции, которая ответственна за обработку ошибки, ничего другого после произведения обработки выполняться не должно. Хотя на это вам намекнет и сам компилятор.

Книга Р. Мартина является сводом правил по написанию правильного кода, которым каждый программист должен следовать. На мой взгляд, умение писать чистый код – важный навык, помогающий специалисту не только самому понимать свой код лучше, но и работать в команде. Именно поэтому я уверена в том, что, если после этой статьи хоть один разработчик узнает о данной книге и прочтет ее, в мире станет на одного хорошего разработчика больше.

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

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

Третья группа заблуждений связана с самими технологиями. Для большинства задач уже написаны библиотеки, которые упрощают написание кода. Но это не значит, что надо сфокусироваться на изучении библиотек. Если ты действительно хорошо знаешь JavaScript и добавляешь к этому базу computer science, тебе не важно React, Vue, Angular или новенький Svetle указан в ТЗ. Просто нужно время на чтение документации. Словом, нужно всегда стараться смотреть на более низкий уровень технологий и разбираться, как всё работает «под капотом».

Есть ещё проблема нежелания расширять кругозор, предпочитая учить что-то одно. Безусловно, на старте нужно привыкнуть к новому синтаксису или особенностям какого-то языка программирования или фреймворка. Но на самом деле учиться надо программировать, а не писать на чем-либо. Программирование — это не про конкретный язык, это про то, как писать инструкции компьютерам. Человечество многогранно изучило этот вопрос ещё до появления JS или Python. Парадигмы, паттерны, структуры данных, алгоритмы — это всё великое наследие, не стоит им пренебрегать.

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

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

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

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

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

Ещё один из немаловажных вопросов — стоит ли бояться костылей? Нет, но к ним нужно относиться настороженно. Это рабочий, но не универсальный код, который желательно отметить комментарием. Костыли могут теряться со временем и при расширении/увеличении программы костыль скорее всего сломается/придётся от него избавиться. Костыли — это меньшее зло. Большее — сорвать сроки!

Любому программисту всегда следует читать мануалы. Мануалы — любая литература/статьи/обзоры/видео по той теме которую делаешь. Причем начинать можно с азов: if, переменные, память, — и до чего-то объёмного: паттерны, архитектуры кода и что-то обособленное — VR, вёрстка, оптимизация. Если застряли — спрашивайте у опытных товарищей или на форуме. Можно сначала поискать информацию в интернете, а можно сразу бежать за советом — это вопрос совести.

Чужой код — это ловушка. Если вы не знаете, как это работает, — значит, не знаете и результат работы кода.

Плагин = чужой код, который ты не знаешь.

Будьте всегда готовы, что ОНО обновится и отвалится. Поэтому плагины стоит использовать с осторожностью.

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

• Следуйте стандартным правилам оформления кода.
• Пишите комментарии к своему коду в процессе написания. Что делает каждая из функций, её положительные и отрицательные стороны. Также стоит помнить, что лучший комментарий — это говорящие сами за себя названия функций и переменных.
• Не копируйте чужой код. Вместо этого изучите его. Как он работает и будет ли он полезен вам?
• Избегайте использования аналогичных кусков кода.
• Не забывайте проверять свой код на наличие ошибок.
• Проектируйте код с расчётом на дальнейшее расширение функциональности.
• Не полагайтесь на то, что определённые типы данных (integer, указатели и временные метки) будут иметь конкретную длину (например 32 бита), потому что этот параметр отличается на разных платформах.

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

Перфекционизм

Бывало ли у вас такое, что вы пишете код, потом понимаете, что могли бы сделать его более понятным или производительным, а потом начинаете усердно перерабатывать эти строки кода? Загвоздка заключается в том, что вас вновь не устраивает полученный результат, и вы думаете про себя: «Тут можно лучше назвать переменную, это лучше вынести в функцию», — и далее по списку. В итоге вы тратите много времени, а код становится лишь более понятным. Получается, что вы придерживаетесь «перевёрнутого» правило Парето: тратите 80 % усилий и получаете 20 % результата. Я ни в коем разе не призываю не рефакторить код во время его написания, но нужно держать во уме ту грань времени, после которой вы честно можете себе сказать, что нельзя сейчас всё сделать идеально и что будете двигаться дальше в решении задачи, а по прошествии времени, когда вы вновь столкнётесь с этим кодом, у вас уже может быть другое мнение о том, как организовать этот участок кода, и тогда вы сделаете это быстро.

Ранние оптимизации

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

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

«Велосипеды»

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

Пренебрежение трендами

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

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

«Одинокий рейнджер»

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

Не практиковаться ежедневно

Писать код нужно ежедневно, как и делать утреннюю зарядку. Любое действие должно обязательно сопровождаться практикой: изучил теорию — попрактиковался. Причем важно также упражняться в тех вещах, которые прямо сейчас в проекте не задействованы, но которые позволяют держать пальцы «разогретыми».

Не делать физическую зарядку

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

Пытаться сначала всё до конца продумать в голове и только потом писать

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

Цепляться за первоначальный вариант

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

Не общаться с себе подобными, замыкаться в себе

Нужно обязательно посещать мероприятия, участвовать в жизни сообщества, желательно поработать на open-source-проектах, с другими разработчиками, послушать замечания других о своём коде — это очень сильно помогает развиваться.

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

Код без комментариев

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

Ненужное усложнение

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

Неоттестированный код

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

Незнание алгоритмов и структур данных

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

Неумение пользоваться IDE

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

Неумение пользоваться Git

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

Неумение искать информацию

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

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

Самая плохая привычка — не вносить изменения в документацию. Проектное время должно расходоваться преимущественно на создание кода. И начинающие программисты часто задаются вопросом: зачем вообще нужна документация и строгая нумерация в ней, зачем нужны отметки об исполнении не только в Jira, но и на бумаге. По итогу человек, не придерживающийся технологии работы с кодом, может украсть 2–3 дня квалифицированной команды, которая, конечно, разберётся, что и как сделано, но слов ругательных скажет много.

Лечение — только в отстроенном технологическом процессе. Чем «махровей» энтерпрайз, тем меньше он доставляет головной боли. Кстати, хорошие продукты, производимые под свободными лицензиями, это давно поняли и тоже стремятся к разумному и документированному взаимодействию.

Ещё про костыли. Есть наборы продуктов, которые без костылей не запустить никак. Более того, сочетание версий костылей библиотеках Python 2 и 3 — отдельная тема на многих конференциях для разработчиков. Даже крупные вендоры выпускают патчи при смене парадигмы костылей. Поэтому исправление плохой привычки следующее: используешь костыль — отладь, оттестируй, выступи в группе или на форуме. Можешь создать бескостыльную систему — делай. И документируй. Не будь отрицательным примером!

Теперь касательно велосипедов. Конечно, на собеседовании и тестовых примерах можете демонстрировать хоть знание Кнута, Ахо, Страуструпа или иных гуру. Но как только написано «алгоритм должен/может/обязан», — конец творчеству, конец велосипедам. Берём мануалы по языку, библиотекам, на худой конец идём на курсы. Мы физически не можем закладывать логическую бомбу внутрь промышленного изделия. Иначе восьмёрки на колесах нашего велосипеда могут подорвать любой бэкенд. Пример: на ряде промышленных систем чёрный цвет на снимках фотограмметрии стал серым, так как никто не мог додуматься, что при смене архитектуры чипа может поменяться алгоритм закраски фона белым цветом. Тут нужна комплексная борьба — так как графические системы ваяются чуть ли не на коленках. И велосипед одних может врезаться в дерево других.

У большинства ошибок начинающего программиста общая причина — привычка сразу браться за работу без предварительного обдумывания задачи. Как это проявляется?

• Услышал задачу и сразу побежал делать. Позже выясняется, что заказчик пришёл с собственной идеей того, как решить некоторую проблему. Если бы разработчик спросил, что за проблему нужно решить, то сразу бы увидел, что есть более удачное и, при этом, более простое решение.
• Услышал задачу и побежал писать код. Через неделю мучений выясняется, что можно не писать своё решение, а найти и интегрировать готовую библиотеку.
• Услышал задачу, придумал решение и побежал реализовывать. Через пару дней наткнулся на проблему, наличие которой было бы очевидно через 10 минут размышлений о деталях придуманного решения.
• Получил задачу и побежал делать. А можно было бы подумать о том, что задача для компании типичная, её наверняка уже решали — и за полдня найти коллегу с опытом и готовым решением.
• Наткнулся на проблему при отладке, исправил — возникло две новых. Исправил их — возникло ещё несколько. И так много раз. Если немного подумать о причинах возникновения исходной проблемы, то можно было бы найти архитектурный дефект и разбираться уже с ним, а не с симптомами.
• Увидел плохой код — сразу начал его рефакторить. А потом связанный код. А потом код, связанный с кодом из предыдущего шага — до бесконечности, так и не получив полезный результат из-за невозможности стабилизировать изменения. А можно было бы подумать об актуальности рефакторинга в этом месте и лучшем способе его сделать — и спланировать такие изменения, на которые точно хватит времени.

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

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

Второе пагубное влечение — мы не любим читать требования. Они такие длинные, такие детальные, в них порой всё так подробно написано и разжёвано… но мы-то лучше знаем, как надо или просто лень… Ах да, если что — перепишем. Как следствие из этого недуга вытекает ещё один: «Я всё понял, завтра уже закончу и выдам код». Спешка в нашем деле лишняя, а постановка задачи не зря занимает столько страниц.

Ещё одно довольно странное явление встречается уже реже: не пользоваться средствами отладки и профилирования. Я не спорю, ошибки, конечно, можно найти, вдумчиво рассматривая код. Но всё же, все современные IDE обладают весьма богатыми средствами отладки. Это удобно и практично.

Следующая пагубная для окружающих привычка — «а я так привык» или «мой код правильнее»… Сначала я думал, что это бывает только «по молодости», но, к сожалению, встречаю такое и у более опытных коллег. Поэтому не принимать во внимание текущие стандарты и локальные практики заказчика становится той самой плохой привычкой.

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

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

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

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

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

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

Чтобы этого избежать, необходимо постоянно технически развиваться, изучать разные проекты с простой и сложной архитектурой. Применять best practices, паттерны. Думать о производительности с учётом мощностей пользовательских рабочих мест.

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

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

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

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

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

Итак, какие плохие привычки бывают у программистов и что с ними делать?

Программисты порой:

• Не документируют код и/или не вносят изменения в документацию.
• Пишут лишние велосипеды.
• Не практикуются в написании кода регулярно.
• Игнорируют физические активности.
• Пытаются продумать все детали программы перед её реализацией.
• Сразу пробуют решить задачу, не узнав о всех нюансах вроде своего видения решения задачи у заказчика.
• Не читают требования.
• Пытаются отрефакторить плохой код, не вникая, почему его написали именно так.
• Излишне усложняют код.
• Не умеют искать информацию.
• Не знают и доли возможностей своей IDE.
• Не общаются с единомышленниками и замыкаются в себе.
• Игнорируют общепринятые практики и делают всё в стиле «я так привык» или «я лучше знаю».
• Пытаются сделать всё сами.

Что с этими привычками делать? Не переставайте развиваться. Вам не обязательно писать на всех фреймворках, пихать в каждый проект все паттерны проектирования и т. д., но знание того, какие вещи вообще существуют в мире программирования и как их реализуют другие люди, может сильно вам помочь. Для каких-то привычек нужно просто перебороть и заставить себя сделать «как надо». Ну а если вы где-то работаете, то некоторые хорошие привычки вам привьют волей-неволей. Кроме того, в этом деле может помочь опыт коллег, которые проходили через то же самое.

Напоминаем, что вы можете задать свой вопрос экспертам, а мы соберём на него ответы, если он окажется интересным. Вопросы, которые уже задавались, можно найти в списке выпусков рубрики. Если вы хотите присоединиться к числу экспертов и прислать ответ от вашей компании или лично от вас, то пишите на experts@tproger.ru, мы расскажем, как это сделать.

Рефакторинг не для слабаков и требует двойных усилий: 1) нужно понимать код, который написал кто-то другой или ты сам в прошлом; 2) с умом упрощать или переносить куски кода (читай улучшать код). В рефакторинге, как и в программировании, есть свой свод правил и приёмов, который можно описать как смесь из техники, интуиции, опыта и риска.

Всё-таки программирование – это искусство.

Исходные данные

В качестве примера будем использовать сервис, предоставляющий API и отдающий данные в формате JSON, а именно список из элементов, как показано здесь:

После того, как мы преобразуем объект JSON в питоновскую структуру, то получим набор словарей, где коллекция age – целое число, остальные – строки.

Потом кто-то дописал класс, который рассчитывает некоторые статистические данные по исходным. Класс называется DataStats и содержит единственный метод stats(), входными параметрами которого являются данные, полученная от сервиса (JSON), и два целых числа iage и isalary. Согласно документации, эти параметры – исходный возраст и исходная зарплата, используемые для вычисления среднегодовой надбавки к зарплате.

Код класса:

Цель

Легко заметить некоторые проблемы в классе, описанном выше. Самые заметные:

• Класс использует один метод и не содержит __init__(). Его можно заменить на единственную функцию без потери функционала.
• Метод stats() слишком большой и выполняет много разрозненных задач, что усложняет последующую отладку.
• Много повторяющегося кода, по крайней мере несколько строк очень похожи. Например, две очень похожих операции '£' + str(max(salaries)) и '£{}'.format(str(min(salaries))), или две строки начинаются с salaries =, или несколько конструкторов списков.

Мы собираемся использовать этот код в нашем Amazing New Project™, так что хотелось бы исправить эти недостатки.
Однако класс работает идеально, используется в производстве долгие годы и не содержит известных багов. Мы хотим написать код лучше, сохраняя при этом функционал, то есть сделать рефакторинг.

Путь

Я хочу показать, как безопасно отрефакторить такой класс, используя тесты. Этот способ отличается от разработки через тестирование (TDD), хотя они похожи. Используемый класс разрабатывался без помощи TDD, и для него нет никаких тестов, но тем не менее их можно использовать, чтобы удостовериться, что работа класса осталась прежней. Такой способ стоит называть рефакторинг через тестирование (TDR – test driven refactoring).

Идея TDR проста. В первую очередь, разрабатываются тесты, которые проверяют работу какого-то кода, лучше маленькой части с чётко определённой областью деятельности и выходными данными. Позднее юнит-тестирование, которое симулирует, что автор кода должен был сделать (кхм, это же ты несколько месяцев назад…).

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

Предостережения

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

Второе: в чистом TDD не рекомендуется тестировать внутренние методы, которые не формируют публичные API объекта. В целом, мы выделяем такие объекты, добавляя нижнее подчёркивание перед названием. Причина в том, что TDD подразумевает, что объекты формируются исходя из ООП, которое рассматривает объекты как результат его работы, а не как структуру. Таким образом, в тестировании нас интересуют публичные методы.

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

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

Подготовка к тестированию

Клонируем этот репозиторий и создаём виртуальную рабочую среду. Активируем её и устанавливаем необходимые пакеты.

pip install -r requirements.txt

Репозиторий уже содержит конфигурационный файл для pytest, который нужно модифицировать, чтобы избежать ввода вашей виртуальной среды. В нём нужно поправить параметр norecursedirs, добавив имя виртуальной среды, которая только что была создана. Я обычно даю имя виртуальное среде с префиксом venv, поэтому её название имеет вид venv*.

На данном этапе из родительской директории репозитория, которая содержит pytest.ini, должна запускаться команда pytest -svv, результат будет походить на то, что представлено ниже:

Этот репозиторий содержит две ветки. В ветке master, в которой вы сейчас находитесь, содержится начальная настройка, в ветке develop – конечный результат рефакторинга. Каждый шаг из этого поста имеет свой коммит с соответствующими правками.

Шаг 1. Тестируем конечный результат

Коммит: 27a1d8c

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

Запросив данные у сервера, мы получаем следующее:

и, вызвав метод stats() с выходными данными, где iage = 20 и isalary = 20000, получим следующий JSON:

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

Тест:

Как было сказано ранее, тест явно проходит, так как был искусственно сконструирован из результатов работы неизменённого кода.
Ну что ж, этот тест очень важен! Сейчас мы знаем, что если своими изменениями кода мы нарушим его алгоритм работы, то хотя бы один тест не пройдёт.

Шаг 2. Избавляемся от JSON

Коммит: 65e2997

Метод возвращает данные в формате JSON и, посмотрев код, можно заметить, что форматирование происходит с помощью функции json.dumps().

Структура кода, где code_part_2 зависит от code_part_1:

Первый рефакторинг будет происходить следующим образом:

1. Мы напишем тест test__stats() для метода _stats(), который будет возвращать данные в формате питоновской структуры. Позже можно будет вручную сформировать JSON или выполнить json.loads() в питоновском скрипте. Тест не проходит.
2. Мы продублируем код метода stats(), который выводит данные в новый метод _stats(). Тест проходит.

Уберём дублирующийся код в stats() и заменим его вызовом _stats():

Сейчас мы сможем отрефакторить первоначальный тест test_json(), который мы написали, но это более сложные изменения, и я оставлю их для другого раздела.

Сейчас код нашего класса выглядит следующим образом:

И у нас есть два теста, проверяющих правильность его выполнения.

Шаг 3. Рефакторим тесты

Коммит: d619017

Очевидно, что список словарей test_data будет использован в каждом проводимом тесте, так что сейчас самое время перенести его в глобальную переменную. Нет смысла использовать фикстуру (fixture), так как тестовые данные статичны.

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

Теперь набор тестов выглядит так:

Шаг 4. Изолируем подсчёт среднего возраста

Коммит: 9db1803

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

Выходной словарь содержит пять ключей, которым соответствуют значения либо подсчитанные «на лету» (для avg_age и avg_salary), либо по коду метода (для avg_yearly_increase, max_salary и min_salary). Мы можем начать замену кода, который вычисляет значение каждого ключа выделенными методами, пытаясь изолировать алгоритмы.

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

Мы знаем, что метод должен вернуть 62, поскольку это значение возвращает оригинальный метод stats(). Обратите внимание, что нет смысла передавать переменные iage и isalary, поскольку они не используются в исправленном коде.

Тест не пройден, так что мы можем послушно пойти и продублировать код, используемый для подсчёта avg_age:

Как только тест проходит, мы можем заменить скопированный код в _stats() на вызов функции _avg_age():

Проверяем, проходит ли тест. Здорово! Мы изолировали первую функцию и написали уже три теста.

Шаг 5. Изолируем подсчёт средней зарплаты

Коммит: 4122201

Ключ avg_salary работает так же, как и avg_age с другим кодом. Таким образом, процесс рефакторинга такой же, как и в предыдущем шаге, а результатом будет новый тест test__avg_salary():

Новый метод _avg_salary():

Новый вид возвращаемого значения:

Шаг 6. Изолируем алгоритм ежегодного повышения зарплаты

Коммит: 4005145

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

Для среднегодового повышения зарплаты у нас новый тест:

Новый метод, который проходит тест:

Новая версия метода _stats():

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

Шаг 7. Изолируем подсчёт максимальной и минимальной зарплаты

Коммит: 17b2413

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

Новые тесты:

Новые методы в классе DataStats:

И метод _stats() сейчас очень короткий:

Шаг 8. Избавляемся от повторяющегося кода

Коммит: b559a5c

Сейчас, когда у нас есть главные тесты, мы можем изменять код различных вспомогательных методов. Они достаточно малы, что позволяет делать изменения без написания дополнительных тестов. Это применимо к данному случаю, но в общем нет такого понятия как «достаточно маленький» так же, как нет реального определения «юнит теста». Вообще, вы должны быть уверены, что изменяемая часть кода покрыта тестами. Если это не так, то следует добавить один или несколько тестов, пока вы не почувствуете себя достаточно уверенно.

Два метода _max_salary() и _min_salary() имеют много общего кода, хоть и второй более краткий.

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

Теперь очевидно, что функции, кроме min() и max(), одинаковы. Они до сих пор используют разные имена переменных и разный код для формирования порога, так что в первую очередь я их сравняю, скопировав код из _min_salary() в _max_salary() и изменив min() на max().

Теперь я могу создать ещё одну вспомогательную функцию _select_salary(), которая продублирует этот код и примет в качестве одного из аргументов функцию, используемую вместо min() или max(). Как я делал ранее, я сначала дублирую код, а затем убираю повторы, заменяя их на вызов новой функции.

Затем я заметил дублирующийся код в _avg_salary() и _select_salary():

Я решил вынести общий алгоритм в метод _salaries(). Как и раньше, я сначала написал тест:

Затем применил метод:

И в итоге заменил дублирующийся код вызовом нового метода:

Пока я делал изменения, я заметил, что функция _avg_yearly_increase() содержит такой же код и исправил её.

В этот момент было бы полезно входные данные поместить внутри класса и использовать как self.data, вместо того, чтобы передавать её во всех методах класса. Однако это нарушит API класса, так как в текущий момент DataStats инициализирован без данных. Позже я покажу, как вводить изменения, которые могут нарушить API и коротко обрисую проблему. Сейчас же я продолжу изменять класс без изменений внешнего интерфейса.

Похоже, что age имеет такую же проблему с повторением кода, как и salary, поэтому таким же образом я введу метод _ages() и изменю методы _avg_age() и _avg_yearly_increase().

Кстати, говоря о _avg_yearly_increase(), код данного метода дублируется в методах _avg_age() и _avg_salary(), так что стоит его заменить вызовами двух функций. Поскольку я перемещаю код между существующими методами, мне не нужны дальнейшие тесты.

Шаг 9. Рефакторинг повышенной сложности

Коммит: cc0b0a1

У начального класса не было метода __init__() и, таким образом, отсутствовала часть инкапсуляции ООП. Не было причин оставлять класс, так как метод stats() можно было легко извлечь и представить в виде простой функции.

Это стало более очевидно, когда мы отрефакторили метод, потому что сейчас у нас есть 10 методов, которые принимают data как параметр. Было бы неплохо загрузить входные данные во время инициализации метода, а затем получать доступ к ним как self.data. Это значительно улучшит читаемость класса и оправдает его существование.

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

Цель состоит в том, чтобы текущий класс сделать соответствующим новому API, а затем написать упаковщик, который адаптирует этот класс под требования старого API. Стратегия не очень отличается от той, что мы использовали ранее, только в этот раз мы будем работать с классами, а не методами. Огромным усилием моего воображения я назвал новый класс NewDataStats. Простите, но иногда нужно просто сделать работу.

Первым делом, как это часто бывает с рефакторингом, будет продублировать код, а когда мы вставим новый код, нам нужны будут тесты, которые его проверят. Тесты будут такие же, как и ранее, поскольку новый класс должен выполнять тот же функционал, что и раньше, так что я просто создал новый файл test_newdatastats.py и начал создавать первый тест test_init().

Этот тест не проходит, и код, реализующий класс, очень прост:

Теперь я могу начать повторяющийся процесс:

1. Я скопирую один тест из DataStats и адаптирую его для NewDataStats.
2. Я скопирую код из DataStats в NewDataStats, адаптируя его под новое API, и удостоверюсь, что он проходит тест.

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

Пример результата тестов для NewDataStats:

И код, который проходит тест:

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

Настало время заменить методы в DataStats вызовом из NewDataStats. Мы можем это сделать пошагово, метод за методом, но что нам на самом деле нужно, так это заменить метод stats().

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

Послесловие

Если вам интересна тема рефакторинга, то стоит почитать классику – Мартин Фаулер «РЕФАКТОРИНГ. Улучшение существующего кода», в этой книге собран набор шаблонов рефакторинга. Справочный язык – Java, но шаблоны легко применяются и на Python.

Я считаю, что комментарии относятся к признакам «кода с запашком» и должны использоваться крайне экономно и только там, где они на самом деле нужны.

Так что же нужно комментировать?

Вообще, я не сказал, что комментарии не нужны совсем, в программировании довольно редко используются какие-либо абсолютные соглашения. Вы должны быть уверены, что есть на самом деле весомая причина использования пояснений в коде. Я использую их как предупреждающие знаки о том, что программисту стоит обратить особое внимание на этот участок. Скорее всего, он чем-то опасен или делает какую-то неочевидную вещь. Можно ли сказать то же самое про любой кусок кода, который чем-то сложен и сильно запутан? Да, можно! По этой причине я часто использую комментарии в legacy-коде, над которым не ведётся активная работа. Т.к. из-за внешних бизнес-условий мы не всегда можем проводить рефакторинг так часто, как хотелось бы, да и иногда лучше просто не трогать то, что и так работает, то комментарии могут быть полезны. Я считаю, что в данном случае это необходимое зло.

Почему же комментарии — это зло?

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

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

Код никогда не лжёт, комментарии иногда делают это. — Ron Jeffries

Как писать код так, чтобы комментарии были не нужны?

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

Отрывок выше является хорошим примером выразительного кода. Даже ребёнок сможет понять, что это собака, и она может лаять. Конечно, в большинстве случаев реальный код намного сложнее и далеко не так очевидно, как написать его правильно, но общие принципы везде одинаковые. Старайтесь давать имена сущностям так, как будто вам надо будет объяснить это ребёнку. В данном примере мы можем описать код как «собака умеет лаять». Точно так же можно сказать «пользователь может залогиниться» или «пользователь может изменить данные своего профиля».

Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте. — Martin Golding

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

Внимательно относитесь к именам переменных, функций и классов

Нет ничего необычного в том, чтобы в процессе разработки изначальное название функции или переменной изменялось несколько раз. Особенно, если цикл разработки продолжается более, чем один день. Если мне пришла в голову мысль о том, как можно более правильно назвать что-либо, я вернусь к этому участку кода и потрачу время на его изменение. Всякий раз, когда мне кажется, что комментарий был бы здесь очень кстати, я возвращаюсь на шаг назад и еще раз смотрю на написанный код. Иногда даже консультируюсь с коллегой, чтобы понять, насколько комментарии всё-таки оправданы здесь. Иногда комментарии побеждают, но обычно, если это не какой-то очень специфичный участок кода, они всё-таки не нужны.

Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям. — Martin Fowler

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

В следующий раз, когда вы будете писать код, постарайтесь делать это без комментариев вообще. Затем, через некоторое время, взгляните на программу и подумайте, насколько легко её читать. Если возникают трудности и вы не можете понять, что вы сами же написали без комментариев, просто выкиньте всё и перепишите с нуля.

Перевод статьи «Don’t Comment Your Code – Rewrite It»