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

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

Когда воспроизвести дефект синтетически нельзя, остаётся пассивная телеметрия в продакшене и последовательное отсечение гипотез данными.

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

Вежливый тест, который шлёт запрос и ждёт ответа, скрывает целый класс ошибок пакетирования. Пачечный тест их обнажает.

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

Случай первый: запись, которой не могло не быть

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

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

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

Почему он не поддавался обычным приёмам

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

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

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

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

Улика: транзакция, которой не стало

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

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

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

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

Шестнадцатилетняя гонка

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

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

Журналы показали редкую гонку данных (race condition) между контрольной точкой и пишущей транзакцией. Если запись происходит в определённый момент работы контрольной точки, та сбивается: считает часть страниц перенесёнными в основной файл, хотя перенос не состоялся. Данные теряются навсегда, а страницы, которые на них ссылаются, например индексные, записываются как ни в чём не бывало. Файл становится структурно повреждённым, что проверка целостности всё это время и фиксировала.

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

Ложная тревога, чуть не сорвавшая исправление

Исправление вышло в версии 3.52.0, и Tailscale раскатывала его осторожно, начав с нескольких канареечных шардов. После общей раскатки монитор резервных копий немедленно покраснел, сообщив о повреждении в тринадцати базах.

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

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

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

Как доказали, что дефект действительно исправлен

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

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

Случай второй: три процента, терявшиеся только на чистой машине

Второй сюжет проще по масштабу и полезнее в быту. Сервис представлял собой небольшой пересыльщик TCP: принять соединение, читать текстовые строки, передавать дальше. На тестовом стенде входило 97 004 строки, а выходило 94 183. Ни ошибок, ни исключений, просто пропавшие сообщения.

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

Сменить машину раньше, чем код

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

Считать, а не логировать

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

Сервер разобрал всё до последней строки, а ответов отправил меньше, чем разобрал. Это отпечаток пальца конкретного дефекта, и дальше оставалось найти его в коде ответа.

read() ничего не обещает про сообщения

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

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

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

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

Вывод автора расследования:
Локальный тест это не нагрузочный тест, ноутбук это не сервер, а одно чтение из сокета это не одно сообщение.

Третий сюжет: гонки, которые видит только поддержка

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

Классический двойной расход

Наивная версия, которую пишут первой:

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

Инвариант переезжает в условие запроса

Общее решение — сделать проверку и запись одним оператором, перенеся условие корректности в WHERE:

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

Вебхук, доставленный дважды

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

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

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

Что из этого складывается

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

Что забрать с собой

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

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

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

Три постмортема, на которых строится разбор: разбор Tailscale о поиске шестнадцатилетнего бага в SQLite, ретроспектива потери трёх процентов сообщений и четыре гонки в биллинге на бессерверном Postgres.

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

Речь пойдёт не о теории reconcile-алгоритма, а о практике: что проверять первым делом, как изолировать проблему через Suspense, куда смотреть в production-логах и как писать тесты, которые ловят регрессии до попадания к пользователям.

Что такое hydration mismatch

Гидратация — это процесс, при котором React берёт серверный HTML и навешивает на него обработчики событий, после чего страница становится интерактивной. React ожидает, что дерево, которое он отрендерил на клиенте, точно совпадёт с тем, что пришло с сервера. Если строки, атрибуты или структура различаются, возникает hydration mismatch.

В development-режиме React покажет предупреждение, текст расхождения и стек компонента. В production всё сводится к коротким кодам вроде #418 или #425. Без телеметрии вы не узнаете, на каком маршруте, в каком компоненте и из-за каких данных произошёл сбой.

Почему это больно именно в RSC

В классическом SSR обычно один серверный рендер и один клиентский проход гидратации. App Router добавляет Server Components, Client Components, потоковую передачу, Suspense-границы, динамические данные маршрута и RSC payload, который едет рядом с HTML.

Когда несовпадение происходит вне Suspense-границы, React может отбросить весь серверный HTML и перерендерить дерево на клиенте. Приложение заплатило цену серверного рендера, а пользователь не получил ни производительности, ни преимуществ стриминга. Это не просто предупреждение в консоли, а реальная потеря производительности.

Ключевые выводы

• Hydration mismatch в production без телеметрии почти невозможно локализовать: нужна инструментация на клиенте.
• Основные причины: browser-only API, дата/время/локаль, состояние авторизации, невалидный HTML, расширения браузера, CSS-in-JS.
• Граница 'use client' — это не только маркер сборки, но и граница гидратации: серверный рендер должен быть детерминирован.
• Suspense-границы помогают изолировать сбой и не давать ему сломать всё дерево.
• Проверяйте hydration только на production-сборке: next dev ведёт себя иначе.
• Добавьте Playwright-smoke-тесты на критичные маршруты, чтобы ловить регрессии в CI.

Самые частые причины

Перед тем как копать RSC payload или сравнивать HTML, стоит проверить шесть типовых сценариев. Они покрывают подавляющее большинство production-инцидентов.

• Browser-only API во время рендера: window, document, localStorage, navigator — сервер не знает об этих значениях.
• Дата, время и локаль: Date, Intl.DateTimeFormat, относительное время — сервер обычно в UTC, пользователь в своей зоне.
• Состояние авторизации: сервер рендерит выклогнутый UI, клиент сразу видит авторизованного пользователя.
• Невалидный HTML: браузер чинит DOM до гидратации, а React сравнивает с исходным деревом.
• Расширения и middleware: браузерные плагины и edge-переписывания меняют HTML.
• CSS-in-JS и порядок классов: styled-components и Emotion могут генерировать разные имена классов при стриминге.

Browser-only API и сторонние провайдеры

Самая частая причина — не ваш собственный код, а сторонний провайдер, который читает localStorage, window или navigator при инициализации. Под это попадают аналитика, фичер-флаги, A/B-тесты, session replay и персонализация.

Проблемный вариант: провайдер читает localStorage прямо при рендере.

Исправление: серверные флаги передаются в Client Component, а локальные оверрайды применяются после гидратации.

Принцип: серверный и первый клиентский рендер должны получить одинаковый результат. Браузерные оверрайды включаются в useEffect после монтирования.

Дата, время и локаль

Сервер часто работает в UTC, а пользователь — в своей зоне. Date.toLocaleString(), Intl.DateTimeFormat и функции вроде formatDistanceToNow() дают разные строки в зависимости от часового пояса и времени между рендером и гидратацией.

Проблемный вариант: относительное время считается на сервере.

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

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

Состояние авторизации

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

Решение — читать куки на сервере через cookies() из next/headers.

С cookies() маршрут становится динамическим — это обычно правильный компромисс для UI, зависящего от авторизации. Начиная с Next.js 15, cookies() асинхронный и требует await. В Next.js 16 синхронный доступ к request-time API полностью уходит.

Невалидный HTML

Браузер молча чинит невалидную вёрстку. React же гидратирует не исходную строку, а DOM, который построил браузер. Классический пример — внутри

Браузер превратит это в примерно такую структуру:

Если HTML приходит из CMS или редактора, валидируйте и нормализуйте его на сервере. Для собственных компонентов следите за предупреждениями validateDOMNesting в DevTools.

Расширения браузера и middleware

Менеджеры паролей, переводчики, грамматические плагины и другие расширения могут вставлять или переупорядочивать узлы до гидратации. Edge middleware и CDN-трансформации тоже могут переписывать HTML в пути.

Если несовпадение затрагивает только <html> или <body>, сначала подозревайте расширения. React 19 стал терпимее к инъекциям в head/body, но на старых версиях такие ошибки особенно шумные.

suppressHydrationWarning на корневых элементах — документированный escape hatch, но он работает только на один уровень вглубь и не должен использоваться для сокрытия неизвестных расхождений в продуктовом UI.

CSS-in-JS и порядок классов

В проектах со styled-components или Emotion имена классов могут зависеть от порядка рендера. Стриминг и Suspense меняют этот порядок, поэтому нужен registry с useServerInsertedHTML.

Production workflow для отладки

Не начинайте с diff-а огромных HTML-документов. Работайте по порядку, сужая область поиска.

1. Настройте клиентскую телеметрию: перехватывайте console.error и отправляйте hydration-ошибки на свой endpoint.
2. Воспроизводите баг на production-сборке: next build && next start, а не next dev.
3. Используйте Suspense-границы, чтобы изолировать проблемный участок и понять, в каком поддереве ошибка.
4. Сравнивайте серверный HTML (curl) и клиентский DOM после гидратации.
5. Когда найдёте расходящийся элемент, проверьте: browser-only API, дата/время, авторизацию, HTML-вложенность, расширения, стили.

Инструментация: instrumentation-client.ts

Файл instrumentation-client.ts в Next.js запускается после загрузки документа, но до гидратации React. Это удобная точка для лёгкой клиентской телеметрии.

Если используете LogRocket, Sentry или другой инструмент, прикрепите тот же payload к текущей сессии — тогда можно будет увидеть, как выглядела страница в момент сбоя.

Изоляция через Suspense

Suspense-границы не только показывают fallback при загрузке. Если hydration mismatch случается внутри границы, React может ограничить восстановление этим поддеревом, а не переключать весь root на клиентский рендер.

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

Сравнение HTML и DOM

Получите серверный HTML через curl с нужными куками:

В Chrome DevTools после загрузки страницы скопируйте живой DOM:

Сохраните результат в /tmp/client-render.html и сравните:

Этот метод хорошо ловит HTML-слой, но может пропустить расхождения на уровне reconciler-а и RSC payload. Если raw HTML совпадает, проверяйте Client Components и браузерное состояние.

Профилактика

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

1. Server Component должен быть детерминированным: одни и те же входные данные дают одни и те же выходные HTML и RSC payload.
2. Все browser-only API, куки, заголовки, локаль и время должны оставаться за границей 'use client' или читаться через request-time API на сервере.
3. Для клиентского UI сначала рендерите стабильный baseline, а улучшения добавляйте в useEffect после гидратации.
4. Валидируйте HTML из внешних источников до того, как React его увидит.
5. Тестируйте hydration на production-сборке в CI.

Пример: стабильный baseline + клиентское улучшение

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

Smoke-тесты в CI

Ручное тестирование пропустит регрессии. Добавьте Playwright-тест на критичные маршруты.

Запускайте такой тест только против production-сборки, никогда против next dev. Сделайте его обязательной проверкой для маршрутов, где hydration failure критичен: продуктовые страницы, дашборды, чекаут, личный кабинет.

FAQ

Выводы

Hydration mismatch — не придирка React, а реальный баг производительности и корректности. Каждое несовпадение означает, что приложение могло отбросить серверный HTML, за который уже заплатило ресурсами.

В приложениях с React Server Components, где цель — меньше клиентского JavaScript и более ранний стриминг полезного UI, hydration failures тихо отменяют эти преимущества. Поэтому важно держать браузерную логику за границей 'use client', рендерить стабильные серверные baseline и проверять гидратацию в production-условиях до того, как ошибку найдут пользователи.

Hydration errors should be fixed, not ignored — официальная позиция React.

Источник: LogRocket Blog — How to fix RSC hydration mismatches in Next.js.

Проверьте свои критичные маршруты на production-сборке, настройте телеметрию и не давайте hydration-ошибкам копиться в консоли.

Последнее октябрьское обновление системы — KB5066835 — нарушило работу localhost, что фактически лишило разработчиков возможности тестировать веб-приложения локально.

Проблему активно обсуждают на Microsoft Support Forums, Stack Overflow и Server Fault: серверы перестали отвечать на запросы, отвалилась отладка в Visual Studio, а ASP.NET-приложения не компилируются.

По оценкам экспертов, сбой затронул миллионы веб-разработчиков и инженеров, использующих Windows 11 в качестве локальных серверов и рабочих станций.

Что пошло не так

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

После установки апдейта, localhost перестал отвечать на запросы, а соединения по HTTP/2 начали обрываться.

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

Microsoft пока официально не подтвердила проблему, но сообщество уже нашло обходное решение:

1. Удалить октябрьское обновление KB5066835.
2. Если не помогло — удалить и предыдущее KB5065789.
3. После этого localhost начинает работать штатно. Однако это временная мера и пользователи рискуют остаться без последних исправлений безопасности.

Неудачи Microsoft продолжаются

Это уже второй крупный сбой за неделю. В понедельник компания случайно «сломала» Media Creation Tool — утилиту для установки Windows — всего за день до окончания поддержки Windows 10.

А на прошлой неделе Microsoft окончательно обязала пользователей входить в Windows 11 только через онлайн-аккаунт, что вызвало волну критики.

WebAssembly в браузере: как всё начиналось

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

Ярче всего успех этого подхода демонстрирует Figma — популярный редактор для дизайнеров интерфейсов. Для многих стало неожиданностью, что редактор Figma, будучи веб-приложением, написан на C++.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

До WebAssembly разработчики Figma использовали технологию asm.js — предшественника WASM. Специальный компилятор преобразовывал (транспилировал) код C++ в высокооптимизированный JavaScript, который браузерные движки могли выполнять с близкой к нативной производительностью. У этого подхода были недостатки: большой размер получаемого кода и затраты на его парсинг и компиляцию в браузере.

Переход на WebAssembly стал переломным моментом. Поскольку WASM — это бинарный машинно-ориентированный формат, он гораздо компактнее и требует меньше ресурсов для обработки браузером. В результате миграции с asm.js на WebAssembly, Figma получила трёхкратный прирост производительности.

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

Почему WebAssembly выходит за пределы браузера

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

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

Главным катализатором этого процесса стал стандарт WASI (WebAssembly System Interface), разработанный при участии Mozilla, Fastly и других компаний. WASI предоставляет стандартизированный интерфейс, где WebAssembly-модули взаимодействуют с операционной системой и решают проблему переносимости между различными платформами.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Открытая «кроссплатформенная» обертка WASI — это довольно большой прорыв в разработке, так как в текущем состоянии все современные продукты, выпускающиеся для разных ОС с одной кодовой базой, имеют большие, подчас legacy модули совместимости, или же запускаются внутри особых песочниц, сильно увеличивающих размер бандла. Например, браузерный движок Electron или React Native.

Как WebAssembly работает вне браузера

Вне браузера WebAssembly исполняется в специальных средах выполнения (runtimes), которые взаимодействуют с операционной системой через WASI. Известные примеры — Wasmtime от Mozilla, Lucet от Fastly и Wasmer.

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

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

Безопасность как фундаментальное преимущество

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

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

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

Важность такого подхода к безопасности сложно переоценить в свете общих трендов защиты данных. К 2025 году безопасность и конфиденциальность стали ключевыми приоритетами для индустрии. Это особенно актуально на фоне растущих рисков при работе с большими языковыми моделями (LLM), которые могут невольно запоминать и воспроизводить конфиденциальные данные из тренировочных наборов.

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

Серверные применения WebAssembly

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

Микросервисы и бессерверные архитектуры

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

Кейс: компания Fastly использует WebAssembly для исполнения пользовательского кода на серверах. Их технический директор Тайлер МакМаллен отмечает: «Мы рассматриваем WebAssembly как платформу для быстрого и безопасного кода в облаке на границе сети».

Безопасные расширения приложений

Многие приложения позволяют пользователям запускать собственный код через плагины и расширения. Но это создаёт риски для безопасности. В WebAssembly пользовательский код выполняется с минимальными рисками.

Веб-сервер Angie использует WASM для безопасности пользовательских модулей. Это решает проблему совместимости, характерную для традиционных модулей, написанных на C.

Экономическая эффективность таких вариантов становится решающим фактором. По данным на 2025 год, глобальный рынок больших языковых моделей (LLM), чьи backend-системы часто используют микросервисные архитектуры, демонстрирует колоссальный рост. Прогнозируется, что к 2033 году он достигнет $140,8 млрд.

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь все закономерно: бизнес всегда выбирал решения, где можно было написать код один раз и поставить его сразу на несколько платформ. Даже если сами решения сырые и небезопасные, дешевле было увеличить поддержку пользователей и настроить аудит безопасности, чем реализовать фичу для каждой платформы отдельно. Так на рынок вышли Python, Node.js, React Native, стремительно обгоняя конкурентов за счет скорости разработки.

WebAssembly в embedded-системах

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

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

Удаленные интерфейсы и централизованный мониторинг

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

Согласно исследованию Qt Company, более 77% респондентов из промышленной автоматизации считают удалённое управление и централизованный мониторинг критически важными в ближайшие десять лет. WebAssembly предоставляет экономичный способ реализации таких решений.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

А это, пожалуй, самая продающая фича: обычно у компаний, которые выходят на рынок со своими железками, базами данных и прочими продуктами, все продажи буквально построены на том, что программисты у клиента знают, как это быстро встроить. Так, бизнес готов платить деньги. Обычно у них есть проблемы с API для разных языков программирования, ОС и девайсов: либо хорошо все в JS, а в мобилках не заводится, либо наоборот. А то и вообще: стоит забросить поддержку платформы хоть на полгода, сразу всёперестает работать. Потому поставлять модуль для WASI должно быть дёшево, при этом потенциально можно закрыть даже платформы будущего. Это инновация сродни изобретению стандарта USB.

Прототипирование и сотрудничество

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

Компания Qt использует этот подход в Qt Design Viewer, позволяя разработчикам делиться интерактивными дизайнами, созданными в Qt Design Studio, с коллегами по всему миру.

Примеры внедрения: история ByteFog

Компания Inetra из Новосибирска разработала технологию peer-to-peer для доставки видео ByteFog. Система работает на множестве платформ: Windows, Linux, Android, iOS, Web и Tizen.

Изначально веб-версия использовала Netscape Plugin API, но когда основные браузеры прекратили поддержку этой технологии в 2015 году, компания осталась без веб-версии на два года. Поэтому в 2017 году они обратились к WebAssembly.

Используя компилятор Emscripten, разработчики перенесли существующее C++-приложение в браузер. Главной сложностью было разграничить транспортный слой и бизнес-логику через интерфейсы. Основной канал доставки видео заменили на AJAX, а P2P-слой — на WebRTC.

Результат компиляции — двоичный.wasm-файл и «клеевой код» на JavaScript, взаимодействующий с браузерными API. Это позволило запускать сложную P2P-систему Peers.TV напрямую в браузере без плагинов.

Fastly Terrarium: экспериментальная платформа для WebAssembly-приложений

В 2021 году инженеры Fastly выпустили Terrarium — экспериментальную платформу для запуска WebAssembly-модулей на периферийных устройствах (edge devices), над которой работали несколько лет. Сейчас проект всё ещё в демо-версии.

Terrarium показывает, как можно запускать пользовательский код в изолированных средах с минимальной задержкой. Платформа использует рантайм Lucet, разработанный инженерами Fastly, и поддерживает компиляцию из Rust, C++ и AssemblyScript.

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

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

Хотя Terrarium не стал коммерческим продуктом, его наработки повлияли на другие решения Fastly. Компания развивает направление WebAssembly-вычислений далее — экосистема постоянно обновляется.

Технические вызовы и ограничения

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

Эти компромиссы особенно заметны в embedded-среде, где каждое решение напрямую влияет на энергопотребление, стоимость и надежность системы.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

Доступ к аппаратным ресурсам

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

Сообщество WebAssembly уже решает проблемы. Стандарт WASI продолжает развиваться, и в будущем появятся более гибкие способы работы с оборудованием.

Размер файлов и производительность

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

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

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

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

Инструменты и экосистема

Экосистема WebAssembly вне браузера всё ещё развивается. Поддержка различных языков программирования неравномерна: лучше всего дела обстоят у C/C++ и Rust, с интерпретируемыми языками всё сложнее.

Отладка WebAssembly-модулей ограничена в сравнении с традиционными средствами. Разработчикам часто приходится использовать косвенные методы и работать с преобразованным кодом. Это особенно важно в контексте другой быстрорастущей тенденции — переносить выполнение ИИ-моделей с серверов на сами устройства пользователей (edge computing).

Например, современные компактные LLM, такие как Phi-4-mini-flash, демонстрируют впечатляющую производительность на мобильных чипах ARM, обрабатывая запросы за 90–100 мс прямо на устройстве без облака. Для подобных сценариев WebAssembly с его переносимостью и низким потреблением ресурсов выглядит идеальной средой, если сможет предложить более прямой и эффективный доступ к специфическим возможностям железа.

Будущее WebAssembly вне браузера

Перспективы WebAssembly вне браузера выглядит многообещающим. Стандарт WASI совершенствуется, поддерживая новые системные интерфейсы и возможности. Разработчики получают всё более мощные инструменты для создания и отладки WASM-модулей.

В embedded-сфере WebAssembly может стать стандартом для безопасного выполнения кода на различных устройствах IoT (интернета вещей). Его способность работать на ресурсо-ограниченных устройствах при изоляции делает инструмент привлекательной альтернативой традиционным подходам.

Майлз Боринс, технический директор руководящего комитета Node.js, видит потенциал WebAssembly в решении одной из наибольших проблем фреймворка: «Это способ достичь скорости, близкой к нативной, и повторно использовать код, написанный на других языках (C и C++), сохранять портативность и безопасность».

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Как я понял, под фундаментальными проблемами имеется в виду ограничение на кол-во операций с потоками и файлами в текущий версиях Node.js, что не дает серверам на «ноде» тягаться с Nginx на равных.

Итоги

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

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

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

Как отмечает Шон Уайт, директор Mozilla по R&D: «WebAssembly уже меняет способы доставки людям новых видов привлекательного контента. С WASI преимущества WebAssembly получат больше пользователей и больше устройств в разных местах».

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

Код считался устаревшим, его удалили из ядра в версии 2.6.20 (в 2006 году), а теперь воскресили с помощью ИИ-помощника.

За проект взялся разработчик из Wikimedia — Дмитрий Брант, который сначала не рассчитывал на быстрый успех. Но благодаря Claude Code (ИИ-помощник от Anthropic), старый код удалось привести в рабочее состояние всего за два вечера.

Что за драйвер и зачем он нужен?

ftape — это драйвер для лент, использующих QIC-картриджи. Такие накопители были популярны в 1990-х для резервного копирования, особенно в малом бизнесе и домашних системах.

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

ftape умел снимать полные дампы картриджей в raw-режиме, которые потом можно было расшифровать. Это важно для тех, кто хочет восстановить архивы со старых лент, даже если файловая система повреждена.

Как ИИ помог воскресить драйвер

Работа велась в три этапа:

1. Миграция под новое ядро. Claude Code получил старый код, совместимый только с ядром 2.4, и на основе подсказок заменил устаревшие вызовы ядра на актуальные API, устранил ошибки компиляции, адаптировал структуры данных.
2. Преобразование в модуль. Драйвер был встроенным, а теперь работает как загружаемый модуль (.ko), что делает его удобнее и безопаснее.
3. Отладка на современных системах. Разработчик подавал ИИ ассистенту dmesg-логи и сравнивал с поведением старого драйвера. После нескольких итераций и ручных правок модуль заработал — ленты определяются, данные считываются.

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

Почему это важно

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

Но не все заслуга ИИ

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

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

Где это можно использовать

• В архивных лабораториях — для восстановления старых данных.
• В проектах по реставрации ретро-компьютеров.
• Для системных экспериментов и исследований истории хранения информации.

Модуль работает на Ubuntu 24.04 и других дистрибутивах с ядром 6.8+, но требует контроллер флоппи-дисков на материнской плате.

Одно из главных новшеств — container-aware GOMAXPROCS: теперь по умолчанию значение GOMAXPROCS учитывает лимиты CPU в cgroup.

На Linux это позволит процессам внутри контейнеров (например, в Kubernetes) автоматически адаптировать использование процессорных ресурсов к выделенной квоте.

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

Новый сборщик мусора — до 40% быстрее

В экспериментальном режиме появился garbage collector нового поколения с улучшенной локальностью и масштабируемостью.

Он особенно эффективен в приложениях с большим количеством мелких объектов, снижая накладные расходы на GC на 10–40%. Включается через GOEXPERIMENT=greenteagc.

Trace Flight Recorder: отладка по горячим следам

Введен runtime/trace.FlightRecorder — «черный ящик» для приложений на Go.

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

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

Другие изменения в рантайме и инструментах

• Исправлена ошибка компилятора с отложенной проверкой nil, из-за которой некорректный код мог выполняться без паники.
• Добавлена поддержка DWARF5 — меньше отладочной информации и быстрее линковка.
• Улучшено выделение памяти для слайсов — быстрее в ряде сценариев.
• В Linux теперь можно видеть имена анонимных VMA ([anon: Go: heap]) в отладочных инструментах ядра.
• Новый пакет testing/synctest для тестирования конкурентного кода с виртуальным временем.
• Экспериментальный пакет encoding/json/v2 с ускоренным парсингом и расширенной конфигурацией маршалера.
• Новый метод WaitGroup.Go для удобного запуска горутин с учетом синхронизации.

Платформенные изменения

Go 1.25 требует macOS 12 и выше. 32-битная Windows/ARM-платформа будет удалена в следующем релизе.

На RISC-V появился режим сборки плагинов и поддержка профиля RVA23U64.

Новички, когда сталкиваются с пет-проектами, бросаются в две крайности. Создают очередной To-Do list, который ничем не выделяется, либо пытаются сделать что-то слишком сложное, например, убийцу Notion, и забрасывают работу на полпути. Так как же выбрать идею, которую получится довести до конца?

Ключевые нюансы при выборе идеи пет-проекта

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

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

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

Как-то я пришёл на хакатон — занимался рекомендательными системами. Тогда был пик популярности Word2Vec — это модель, которая переводит слова в векторы и позволяет находить между ними смысловую близость. Я посмотрел на статистику и увидел: на одном из сайтов 25% запросов не давали результатов. Тут возникла идея, как это улучшить.

Решил собрать демку и сделал прототип: например, на запрос «кресло из крокодиловой кожи» модель показывала зелёные кожаные кресла. Не крокодиловые, но всё равно релевантные запросу.

За неделю допилил прототип до презентабельного состояния, показал коллегам и руководителю. Они дали «зелёный свет», через 2 месяца была первая MVP, которую уже начали продавать существующим клиентам. Ещё через месяц — первый клиент, интеграция, запуск.

Спустя ~5 лет количество клиентов уже измерялось сотнями :)

Подумайте, какие навыки хотите показать

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

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

Не затягивайте со сроками

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

Выбирайте несложный и интересный проект, который вы не затяните и который будет вам по силам.

Основная ошибка — это незаконченные, «сырые» решения. HR смотрят на проекты, в том числе, как на способность завершать начатое. Если в портфолио много таких работ, это наводит на мысли, что разработчик быстро теряет интерес, плохо планирует время или бросает задачи при первых трудностях.

Не используйте учебные работы, либо используйте их правильно

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

1. У вас и ваших одногруппников эти работы одинаковые. Представьте лицо HR, когда он увидит несколько похожих проектов в разных резюме.
2. Учебные проекты не совсем ваши, ведь вы повторяли код и основные конструкции за преподавателями. Работодателю важно, как вы пишете сами, а не копируете.

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

Всё равно не могу ничего придумать, что делать?

Если самостоятельно не получается что-то придумать, то можно спросить у ИИ.

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

Пример промпта для идеи пет-проекта:

Возьмите задачу с фриланса

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

Спросите друзей или аудиторию в соцсетях

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

У меня был разработчик, уставший от хаоса в списках фильмов, которые он хочет посмотреть. Сделал пет-проект — личный медиапланировщик с нейтральным UI. Проект не стал стартапом, но в портфолио смотрелся отлично. Если сложно — можно взять существующую идею и улучшить. Например, сделать привычный To do-лист с уклоном в UX, нейросети или интеграции. Главное — показать свою силу, а не сделать ещё один клон.

Как довести пет-проект до конца и не забросить его

Вы выбрали идею для проекта, прикинули стек, сроки, пошли писать код и… забросили. Часто бывает, что вначале полны энтузиазма, а под конец либо ничего не получается, либо появляются мысли, что проект — пустая трата времени. Чтобы такого не было, лучше соблюдать следующие правила:

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

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

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

Разбейте проект на задачи и подзадачи. Например, дизайн плеера, его вкладок, основная логика, подключение API, отладка.

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

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

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

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

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

Если очень грубо, то ориентир выглядит так: 80% кода — это знакомый нам стек, 20% — место для экспериментов и обучения. Такой подход позволяет прокачать новые навыки и довести проект до финала без выгорания.

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

Лучше постараться выработать привычку и заниматься петом, например, каждый день по 30 минут. Не можете соблюдать эту привычку по каким-то причинам? Не проблема, вместо 30 минут найдите 5. Да, за это время вы ничего не успеете, но сохраните «регулярность» — на следующий день будет проще.

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

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

А вот ещё несколько советов от Анастасии Егоровой — фронтенд-разработчика, автора программы курса SkillBox по Vue 3 и ведущей ютуб-канала CosyFrontend.

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

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

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

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

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

P.S. Когда мы обсуждали тему пет-проектов и их забрасывания в одном из айтишных чатов, один из разработчиков отметил: «А никак не нужно доводить их до конца — пет-проекты для того и существуют, чтобы попробовать на них новую идею и забросить». Так что такое мнение тоже есть, но справедливо ли оно для вас — решайте сами 😀

Как оформить пет-проект

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

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

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

Упакуйте проект в GitHub. Если у вас пустой репозиторий, который называется my project, то проект никто не оценит. У HR большой поток откликов, иногда они принимают решение за пару секунд, поэтому очень важно, чтобы по вашему репозиторию как можно быстрее можно было понять, что вы сделали, как это работает и какие технологии вы использовали.

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

Добавьте скриншоты, гифки, видео работы сервиса. А ещё лучше его демоверсию.

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

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

Опишите результаты по конкретным метрикам, если, конечно, это возможно. Опубликовали приложение в Google play и получили хорошее удержание пользователей? Расскажите об этом. Вашу фичу оценили в социальных сетях? Поделитесь приятным фидбеком. Метрик нет, делали проект только под себя? Расскажите, как он помог вам решить проблему.

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

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

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

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

Главное, не делайте проект ради проекта, старайтесь принести какую-то пользу и здраво оценивайте свои возможности.

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

Ошибки в программах неизбежны, но ключ к качественной разработке — умение быстро их находить и исправлять. Исследования показывают, что разработчики тратят 35–50% рабочего времени на тестирование и отладку, а эти этапы поглощают 50–75% бюджета проекта.

В этой статье мы разберем современные инструменты и подходы к поиску и устранению багов.

1. Трекеры багов

История инструментов для отслеживания ошибок уходит корнями в прошлое. Ещё в 1970-х разработчики Bugtraq в AT&T Bell Labs использовали физические баг-тикеты, прикрепляя их к пробковым доскам. Знаковый скачок произошёл в 1998 году, когда Mozilla открыла доступ к первому веб-трекеру — Bugzilla. Дальнейшая эволюция привела к появлению Jira от Atlassian в 2002 году и прототипа Sentry на GitHub в 2008-м.

Зачем нужен баг-трекер ?

Исправление ошибки начинается с её фиксации. На небольшом проекте с одним разработчиком запомнить пару багов возможно. Но по мере роста числа дефектов ручное отслеживание становится неэффективным. Баг-трекер — это специализированная система, где для каждой ошибки создаётся запись (тикет, задача). В тикете должны быть ответы на самые важные вопросы:

• Что пошло не так?
• Что должно было происходить?
• Как вызвать ошибку?
• Какой контекст у ошибки ?

Баг-трекеров существует великое множество, ведь по сути это автоматизированные цифровые записные книжки. Баги можно отслеживать с помощью Jira, Redmine, Битрикса, Yandex Tracker, GitHub Issues, Sentry, BugHerd и др.

Баг-трекеры выбираются исходя из потребностей команды. В больших компаниях популярны решения внутри их корпоративного трекера; часто в open-source проектах баг-трекером для комьюнити выступает GitHub Issues, а в небольших командах таковым выступает закреп в чатах TG-группы.

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

2. Отладчики

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

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

Основная задача отладчика — это предоставить информацию о ходе выполнения программы.

Как эффективно использовать ?

Сформулируйте гипотезу и не одну

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

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

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

Идите по шагам и следите за переменными с неправильными значениями

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

Меняйте значения переменных по ходу выполнения

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

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

3. Профилировщики

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

Как эффективно использовать ?

Определите метрики и точки измерения

Подумайте и поймите, какой именно показатель у вас проблемный (тестировать загрузку CPU, искать утечку памяти, следить за нагрузкой на процессор) и какие процессы вам нужно контролировать.

Воссоздайте проблемную ситуацию

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

Оцените вызываемую нагрузку

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

Изучите алгоритмы и структуры данных

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

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

4. Логгеры

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

Как правило, это первый инструмент поиска ошибок у всех разработчиков, который они реализуют через функции типа print().

Как эффективно использовать ?

Структурируйте логирование

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

Выстройте иерархию логирования

Стандартная такая: DEBUG, INFO, WARN, ERROR, FATAL.

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

Добавляйте в логи контекст

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

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

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

Пользуйтесь ИИ

Все современные популярные модели достаточно умны, чтобы проанализировать код и добавить в него логи. Главное — заранее объяснить ей стратегию логирования. Воспользуйтесь для этого Cursor, WindSurf, Codex и иными ИИ-ориентированными IDE, чтобы они знали контекст.

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

5. Авто-тесты

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

Даже если вы не тестировщик — пишите автотесты. Вы значительно сократите себе часы жизни на ручной проверке результатов. Чем больше проект, тем важнее писать автотесты, чтобы избежать фразы: «А раньше работало?».

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

Какие бывают тесты ?

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

Модульные тесты (Unit Tests)

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

Интеграционные тесты (Integration Tests)

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

Сквозные тесты (End-to-End / E2E Tests):

Тестируют всю систему целиком с точки зрения пользователя, имитируя его действия в реальной среде (браузер, мобильное приложение). Воспроизводят сценарии использования, например, покупку товара или загрузку Excel-файла из БД. Нужны, чтобы проверить работоспособность всей системы. Могут быть очень затратны.

Как эффективно использовать ?

Пишите тесты по принципам FIRST

• Fast – тесты должны быть быстрые, иначе замедлят разработку.
• Independent – тесты должны быть изолированы друг о друга, чтобы не падать, как домино.
• Repeatable – воспроизводимые, при одинаковых вводных давать одинаковый результат.
• Self-Validating – результат строго бинарный: успех/не успех.
• Timely – тест нужно писать заранее, чтобы сэкономить себе часы жизни в будущем, а не писать их после того, как тысячу раз рукам сам проверял, что всё ок.

Следуйте Пирамиде тестирования

Тесты должны выполняться в порядке от простых и быстрых к наиболее сложным и долгим, так, чтобы 90% ошибок попадали в первые и быстрые тесты, экономя вам время в ожидании окончания тестирования.

Следите за покрытием тестов

Отслеживайте, насколько ваш код покрыт тестами — так, чтобы минимальным количеством тестов покрыть максимальное количество кода.

Настройте CI/CD сами или попросите вашего DevOps

Интегрируйте запуск тестов в процесс сборки (CI/CD-пайплайн). Тесты должны запускаться автоматически при каждом коммите и пулл-реквесте. Это же всё-таки АВТО тесты.

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

6. Статический анализ кода

Статический анализ кода — это процесс автоматической проверки исходного кода без его выполнения. Инструменты статического анализа (линтеры, SAST — Static Application Security Testing) сканируют код, ищут потенциальные ошибки, уязвимости безопасности, нарушения стиля кодирования, сложные для понимания конструкции.

По умолчанию есть во всех популярных IDE.

Как эффективно использовать ?

Изучите их

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

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

Настройте их

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

Запускайте их как авто-тесты

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

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

Итог

Баги — неизбежные спутники разработки, но их цена растет как снежный ком с каждым этапом жизненного цикла ПО.

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

Это финальная стадия перед полноценным релизом, который запланирован на 7 октября 2025 года. Версия 3.14.0rc1 уже доступна для загрузки на официальном сайте Python.

Что важно знать

Python 3.14 RC1 — это максимально приближенная к финалу сборка. Отныне в код ядра будут вноситься только багфиксы, прошедшие ревью. Следующий и последний релиз-кандидат — 3.14.0rc2 — выйдет 26 августа.

Важно: с этого момента не будет изменений ABI, а бинарные сборки, созданные под RC1, будут совместимы с финальной версией 3.14.

Разработчиков библиотек призывают начать адаптацию своих пакетов под 3.14 и публиковать .whl-сборки на PyPI.

Главное в Python 3.14

Список нововведений в 3.14 впечатляет — это не просто минорный апдейт. Вот ключевые фичи:

Улучшения производительности и инфраструктуры

• Экспериментальный JIT-компилятор включён в официальные сборки для macOS и Windows.
• Новый тип интерпретатора, обеспечивающий ускорение кода (для некоторых компиляторов).
• PEP 779: Free-threaded Python — полная поддержка свободных потоков.
• Улучшенные сообщения об ошибках.
• Оптимизация генерации UUID v3–v5 (ускорение до 40%).

Новые языковые возможности и модули

• PEP 750: шаблонные строки t"..." — аналог f-строк, но для кастомной обработки.
• PEP 649: отложенное вычисление аннотаций типов.
• PEP 765: теперь return, break, continue нельзя использовать так, чтобы они покидали finally.
• PEP 734: изоляция интерпретаторов в stdlib.
• Новый модуль compression.zstd для поддержки алгоритма Zstandard.
• Цветной вывод в CLI-инструментах (unittest, argparse, json, calendar).
• Обновление uuid, pdb, поддержка подключения к удалённым процессам.

Разработка и отладка

• PEP 768: интерфейс внешней отладки без накладных расходов.
• Новый CLI для анализа запущенных Python-процессов.
• HMAC теперь реализован внутри Python с формально верифицированной библиотекой HACL*.

Что убрали или изменили

• Подписи PGP для артефактов релиза больше не предоставляются. Вместо них — поддержка Sigstore.
• Установщик для Windows заменяется новым Python Install Manager (доступен в Microsoft Store).

Внимание: несмотря на стабильность RC1, использовать его в продакшене пока не рекомендуется. Но для тестов и подготовки библиотек — самое время.

Рассказываем про 7 команд, влияющие на скорость работы в терминале. Вы узнаете:

• про встроенные bash-операции, которые заменяют пайплайны,
• про способы работы с файловыми дескрипторами,
• про wildcards, которые избавляют от сложных конструкций с find.

Каждая команда в подборке решает конкретную проблему:

• массовая обработка файлов,
• отладка скриптов,
• работа с длинными путями.

1. Bash variable expansions

Вместо basename, cut для простых операций со строками можно использовать встроенные возможности Bash:

% режет справа до первого совпадения, %% — до последнего. Символ # работает слева направо.

В реальной работе это помогает при массовой обработке файлов. Например, есть 1000 логов, и нужно каждый переименовать.

Если использовать basename, запустится 1000 отдельных процессов. Variable expansions работают без fork/exec, без задержек на создание процессов.

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

2. Here-string (<<<)

Here-string упрощает передачу строковых данных в команды без создания временных файлов или использования echo с пайпом.

Реальная экономия времени проявляется при отладке и модификации скриптов. Например, когда SQL-запрос или конфигурация зашиты в here-документ. С here-string данные собраны в одном месте, легко редактируются и переиспользуются.

Работает не только с базами данных. Отправка в API, конфигурирование сетевых устройств через expect, передача команд в Docker — через <<< код будет понятнее, а сопровождение проще.

3. /proc/$$/fd

Каждый процесс имеет стандартные дескрипторы 0 (stdin), 1 (stdout), 2 (stderr), которые представлены как символические ссылки. Директория /proc/$$/fd предоставляет доступ к файловым дескрипторам текущего процесса:

Переменная $$ содержит PID текущего процесса, поэтому /proc/$$/fd ведет к дескрипторам именно вашего шелла.

Практическое применение — отладка перенаправлений и работа с дескрипторами в сложных скриптах:

4. Wildcards с диапазонами

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

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

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

5. sudo !!

Набрали длинную команду, нажали Enter, получили «Permission denied». Рука на рефлексе тянется к стрелке вверх и Home, чтобы добавить sudo в начало.

Вот способ в разы быстрее:

Двойное восклицание !! — это ссылка на предыдущую команду целиком. Bash подставит всю строку со всеми аргументами и ключами. Кажется мелочью, но для админа, который 10 раз в день забывает sudo, это серьезная оптимизация.

Двойное восклицание универсально и работает не только с sudo:

• time !! для замера времени выполнения,
• nohup !! & для запуска в фоне,
• strace !! для отладки.

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

6. ^старое^новое

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

Символ ^ ищет первое вхождение слова и заменяет его. Работает с последней командой.

Заменяется только первое вхождение. Если ошибочное слово встречается несколько раз, способ не сработает. В таких случаях придется использовать классическое редактирование или history expansion.

7. Alt+.

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

Комбинация Alt+. (Alt + точка) вставляет последний аргумент предыдущей команды в текущую позицию курсора. Повторное нажатие перебирает аргументы из более ранних команд.

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

Еще этой комбинацией вставляются:

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

Alt + точка работает в большинстве шеллов. Привыкнув к ней, начинаешь использовать на автомате.

Что запомнить

• ${filename%.*} и встроенные операции со строками работают быстрее внешних утилит. % режет справа, # — слева. Полезно при работе с циклами для массовой обработки файлов.
• <<< — here-string удобен для передачи коротких строковых данных в команды. С многострочными данными лучше использовать here-document или переменные.
• /proc/$$/fd — доступ к файловым дескрипторам текущего процесса. Ускоряет отладку перенаправлений и работу с дескрипторами.
• file[1-5] и [^b]* — диапазоны в wildcards для точного отбора файлов. Кавычки нужны только для передачи литеральных символов.
• sudo !! — повторяет последнюю команду с sudo. Также работает с time !!, nohup !! &. Если между нужной командой и !! выполнялись другие операции, используйте !строка для поиска конкретной команды в истории.
• ^старое^новое — заменяет первое вхождение в предыдущей команде. Работает только с последней командой и заменяет первое совпадение.
• Alt+. — вставляет последний аргумент предыдущей команды. Повторное нажатие перебирает аргументы из истории команд. Экономит время при работе с длинными путями.

1. Pandas

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

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

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

Почему это меняет карьеру

Работа с Pandas становится границей между знанием Python и умением решать задачи бизнеса. Для джуна это шанс сразу показать практическую пользу: выгрузки, отчёты и базовый анализ можно делать в десятки раз быстрее и аккуратнее, чем вручную в эксельке.

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

Для ML-инженера владеть Pandas — значит уметь готовить датасеты качественно; быстро очищать и приводить данные к нужному виду, что напрямую влияет на результат моделей. Без этого работа над проектами машинного обучения часто превращается в бесконечную возню с данными.

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

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

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

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

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

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

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

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

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

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

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

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

Polars меняет карьеру, потому что даёт преимущество в скорости и эффективности при работе с данными. Там, где Pandas уже не справляется, полярный медведь приходит на помощь.

Для дата-инженеров Polars полезен при построении ETL и пайплайнов обработки данных, где важна скорость и предсказуемое потребление ресурсов. Его можно использовать в продакшен-скриптах, для подготовки данных к ML и для автоматизации отчётности.

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

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

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

Вместо долгой настройки, как у Flask или Django, в FastAPI многое готово изначально: удобная работа с запросами и ответами, декларативная валидация, документация Swagger, асинхронность и высокая производительность без лишних усилий.

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

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

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

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

Typer меняет карьеру тем, что открывает путь к созданию удобных CLI-инструментов, которые автоматизируют рутину и повышают продуктивность.

С Typer можно быстро превращать свои Python-скрипты в надежные утилиты, которыми удобно пользоваться и другим разработчикам, и сотрудникам из других отделов. CLI-приложения часто становятся клеем инфраструктуры: они позволяют автоматизировать деплой, миграции БД, сбор данных, интеграцию с внешними API и локальную разработку.

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

Кроме того, работа с Typer улучшает навык структурирования кода, понимание CLI, использования type hints и разработки инструментов, которые делают работу проще для других. А это, очевидно, ценится в любой команде и повышает востребованность специалиста.

7. Rich

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

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

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

Почему это меняет карьеру

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

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

Кроме того, Rich позволяет быстро создавать CLI-интерфейсы, которые выглядят как продакшен-продукты, даже если это внутренние инструменты. Руководство будет радоваться и думать о вас как о крутом разрабе.

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

LangChain предоставляет удобный слой абстракции над вызовами LLM и ускоряет разработку чат-ботов, RAG-приложений, агентов с инструментами, систем анализа документов и других AI-сервисов.

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

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

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

Работа с LangChain погружает в практическую LLM-инженерию: вы начинаете создавать RAG-приложения, которые умеют искать и анализировать данные перед генерацией ответа и строить агентов. Это востребовано в продуктах, где нужно подключать ИИ к базам знаний, автоматизировать задачи и разрабатывать интерактивные системы, которые реально используют модели в продакшене.

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

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

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

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

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

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

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

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

Библиотека тесно интегрируется с Pandas DataFrame, позволяя использовать колонки данных напрямую для построения графиков, что делает её идеальной для EDA (разведочного анализа данных) и подготовки визуализаций для отчётов и презентаций.

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

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

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

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

Почему это меняет карьеру

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

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

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

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

1. МояДоска

«МояДоска» — это российский SaaS-сервис для совместной работы и визуализации идей. У онлайн-доски бесконечный размер: это значит, что вы можете размещать сколько угодно элементов и никогда не упретесь в границу. Так, команды, преподаватели и креативные специалисты могут проводить брейнштормы, планирования, презентации и обучение в одном пространстве.

Что под капотом

Фронт написан на React + PixiJS, а бэк — Node.js + PostgreSQL. Это обеспечивает быстрый и понятный интерфейс и стабильную работу даже при большом объёме объектов на доске. Команда выпускает обновления несколько раз в месяц, а о новинках можно узнать в Telegram-канале сервиса. Например, в недавнем апдейте появилась возможность превратить фрейм в таблицу или тетрадь за пару кликов, а еще задать нужное число столбцов, колонок, толщину границ и цвет.

Из главных функций:

• Понятный интерфейс
• Совместная работа в реальном времени
• Привычные инструменты: фигуры, стрелки, стикеры, текст, загрузка файлов, маркер, карандаш
• Обрезка фото прямо на доске, воспроизведение аудио, поддержка PDF
• Гибкое управление доступом
• Возможность повторного использования шаблонов
• Поддержка фреймов и создание логичных пространств для разных задач

Переезд на сервис

«МояДоска» интегрируется в процессы на разных этапах, упрощая жизнь команде. Например, сама команда сервиса перешла с Miro на свою доску для стратегического планирования. С помощью стикеров и стрелок они построили дерево решений, чтобы лучше расставить приоритеты. А одно маркетинговое агентство перевело все документы и сессии планирования на доску, отказавшись от Google Docs и таблиц. Это ускорило принятие решений: сотрудники работали с данными в одном формате, точно собрались в одном кабинете перед маркерной доской.

2. METEOR

METEOR — инструмент управления проектами. Это трекер задач с дашбордами, досками канбан, диаграммами Ганта и API, который работает в виде веб-приложения как в облаке, так и на своих серверах. Продукт создавался как универсальный центр управления задачами: он объединяет в себе все — от разработки и тестирования до маркетинга и поддержки. Сейчас его используют более 250 команд и свыше 2000 пользователей ежедневно.

Что под капотом

В основе — стек Ruby on Rails, React и TypeScript, PostgreSQL и Redis, плюс современная инфраструктура на Docker и Kubernetes.

Система разбита на микросервисы — за фоновую обработку, нотификации и работу с файлами отвечает отдельный функционал. Авторизация построена через OAuth 2.0 (Google, Yandex), а для аналитики используется Posthog и ELK-стек. Мониторинг реализован на Prometheus + Grafana. Обновления выходят каждую неделю, а обратная связь приходит разработчикам METEOR через Telegram-бот.

Вот главные функции:

• Гибкие доски задач (Kanban, Scrum) — 6 видов.
• Списки задач с группировками и иерархией.
• Автоматические отчеты (ежедневные/еженедельные сводки).
• Умные напоминания (Telegram-бот, email).
• Глубокая аналитика (время выполнения задач, загрузка команды).
• Потоковая автоматизация процессов

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

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

Разработчики используют METEOR для линковки задач с pull-requests и контроля бэклога. Менеджеры получают отчеты автоматически и не тратят часы, чтобы собрать всю информацию вручную. QA ведут тест-кейсы и баги в удобных досках, а DevOps отслеживают инциденты и шаги деплоя. Даже HR подключаются — через систему проходят кандидаты и стажеры.

Переезд на сервис

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

• скорость выполнения задач увеличивается в среднем на 25% — благодаря автоматическим напоминаниям и чётким процессам;
• количество потерянных задач снижается на 70% — исчезают хаотичные чаты и забытые письма;
• на составление отчетов и сбор метрик уходит не 5 часов, а всего 30 минут в неделю;
• а экономия времени — около 75 часов в месяц на команду из 10 человек.

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

3. Gitlife

GitLife — это универсальная платформа для хостинга репозиториев и построения полного DevOps-процесса внутри компании. Разработана с прицелом на закрытые контуры, импортозамещение и гибкость — подходит как для современных Git-проектов, так и для инфраструктур, где все еще используется SVN.

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

Что под капотом

Внутри Gitlife собраны модули для:

• Кода — репозитории, ветвление.
• Задач — бэклоги, спринты, дашборды.
• Документации — совместное редактирование документов, управление правами.
• Аналитики — карты потока ценности, качество кода, метрики по инженерам.
• Пайплайны — модуль «Конвейер» управляет сборками и CI/CD.

Gitlife используется ИТ-отделами и R&D-подразделениями в компаниях с высокими требованиями к информационной безопасности. Подходит как для небольших команд, так и для распределённых корпораций с десятками проектов.

Что решает:

• Безопасный и полностью локальный хостинг исходного кода (Git + SVN)
• Управление задачами и CI/CD в одном месте
• Централизованный доступ, права, аудиты и история изменений
• Полная поддержка DevOps-процессов на российском ПО
• Альтернатива GitHub, GitLab и Bitbucket в условиях ограниченного доступа и санкционных рисков

Переезд на сервис

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

4. Cerebro

Cerebro — профессиональная система для совместной работы и управления проектами. Она помогает ставить задачи, планировать этапы, следить за выполнением, обмениваться файлами и комментировать их прямо в системе. Особенно полезна для команд, которые делают VFX, 3D, анимацию или дизайн — но при этом легко адаптируется и под другие команды.

Платформа охватывает полный цикл — от первых идей и планирования до комментирования финальных шотов (отдельных сцен или кадров в видео/анимации) и соблюдения дедлайнов. Такой подход помогает команде ускорить работу на 20%, сократить время на правки и держать весь процесс под контролем — от начала до сдачи проекта.

Cerebro подходит для команд от 1 до 1000+ человек с задачами на проекте от 1 до 10000+. Сервис работает с 2009 года, сейчас им пользуются более 400 команд в России и СНГ.

Что под капотом

Cerebro поддерживает десктоп (Windows, Mac и Linux), веб-версию и мобильное приложение, локальное, облачное и гибридное развертывание. Инструмент построен на клиент-серверной архитектуре — она гибкая, поэтому можно настраивать конфиги исходя из потребностей бизнеса.

Из технологий:

• Backend: C, C++, Python, SQL
• Frontend: JS, TypeScript, ReactJS, Qt, PyQt
• Мобильные клиенты: React Native
• БД: PostgreSQL с проприетарными расширениями + SQLite
• Файловое хранилище: Cargador
• Плагины: Tentaculo (встраивается в производственные программы)

Cerebro покрывает весь пайплайн — от идеи до финала. Вот основные возможности сервиса:

• Множественные уровни вложенности задач — подходит для сложных иерархий продакшена
• Планирование с помощью диаграммы Ганта и специального инструмента «План»
• Канбан-доска для визуального контроля задач
• Инструмент «Моё пространство» — для персонализированной фильтрации и отбора задач
• Уровни доступа и ролевое управление
• Расширенная статистика по проектам, командам, сотрудникам
• Совместная работа над большими файлами (видео, изображения, 3D) — Mirada позволяет комментировать, делать подрисовки, оставлять голосовые заметки
• Интеграция с пакетами Adobe, Autodesk и мессенджерами, возможность встраивать в любые пайплайны
• Удобное подключение фрилансеров

Переезд на сервис

Обычно внедрение начинается еще на этапе препродакшена — во время разработки концепции и четкого плана действий. Затем система сопровождает проект на всех стадиях, вплоть до постпродакшена (финального тестирования и релиза), где она закрывает 80-100% задач. Cerebro позволяет собирать всё в одном месте: задачи, правки, сроки, бюджеты, загрузку сотрудников и статус проекта в целом.

После переезда снимается много рутинных задач: больше не нужно вручную назначать исполнителей, комментировать медиаконтент, передавать файлы между программами и так далее. В среднем проекты выполняются на 20% быстрее, без потери качества. В больших студиях объем выпускаемых шотов может вырасти до 20+ тысяч — это уже работает у других клиентов, среди которых СберМаркетинг, Sinners, Black Point и другие. Cerebro также помогает переехать с других такс-трекеров и систем для управления проектами.

5. Replit Teams

Replit Teams — это платформа для совместной разработки в реальном времени. По сути, это интегрированная IDE + git-репозиторий + система управления задачами — и все доступно через браузер. Подходит как для командной работы в стартапах, так и для образовательных проектов, хакатонов и небольших продуктовых команд.

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

Что под капотом

Внутри Replit Teams есть интерфейсы для:

• Кода — редактор с автокомплитом, подсветкой синтаксиса, терминалом и интеграцией с Git.
• Задач — встроенный таск-менеджер с распределением задач по участникам.
• Общения — встроенные комментарии в коде, возможность ревью и обсуждений.
• CI/DevOps — запуск и отладка приложений без настройки окружения.
• Доступа — гибкие роли, приглашения по ссылке, настройки приватности.

Переезд на сервис

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

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

Рассказывайте в комментариях, какими сервисами пользуетесь вы.

Так случалось, пока не появились инструменты вроде TanStack Query и не родились «обертки», которые уменьшают объемы рутины. Как перестать тонуть в запросах на разработку API и начать дышать свободно, рассказывает Дмитрий Скляр, старший разработчик компании Axenix.

API: нервная система цифрового мира

В современном ИТ-ландшафте API давно перестал быть просто техническим термином. Теперь он — один из столпов, на котором держится цифровая цивилизация.

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

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

Но настоящую революцию API совершил в бизнесе, создав целые экосистемы цифровых услуг. Такие компании, как Stripe, Twilio или Plaid построили свои империи именно на API, предоставляя другим разработчикам готовые «кирпичики» для создания финансовых, коммуникационных или аналитических сервисов.

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

Боль, которую никто не замечает

Но не все так просто и далеко не так радужно.

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

Типичный сценарий: вы пишете код для запроса списка товаров, все типизируя и описывая модели — 50 строк. Добавляете фильтрацию — еще 30 строк. А через месяц бэкенд меняет структуру ответа, забывает предупредить — и вы тратите день на поиск багов в трех разных местах. И самое обидное: 80% этого кода — копипаст. Проверка ошибок, трансформация данных, инвалидация кэша — все одно и то же, но плодится как вирусы.

Сюда можно добавить также сложность поддержки — API меняется, код устаревает.

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

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

Спасение — в системе

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

Тогда и родилась идея фабрики API — слоя абстракции, который скрывает рутину. Для этого мы привлекли возможности TanStack Query, семейство библиотек для управления состоянием данных (data fetching) в клиентских приложениях. Помимо TanStack Query (ранее React Query), к этому классу инструментов также относятся: RTK Query (из Redux Toolkit), Apollo Client (для GraphQL) и SWR.

Их общая философия: «делать рутину невидимой для разработчика». Рассмотрим Конкретные проблемы и их решения.

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

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

Например, для каждого ресурса вроде пользователей, продуктов, заказов и т.д. приходится повторять одну и ту же конструкцию. Если нужно изменить поведение запроса (например, добавить retry или staleTime), правки необходимо делать в десятках мест.

Решение: Универсальная обёртка над хуками TanStack Query

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

Такой подход:

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

Хрупкость при изменении API

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

Решение: Централизованная трансформация данных + class-transformer.

С помощью class-transformer можно объявить классы сущностей и задать правила преобразования один раз.

Плюсы:

• Все данные автоматически приходят в нужном виде;
• Компоненты работают с гарантированно типизированными данными;
• Один источник правды: при изменении API – правим только Entity-класс;
• Удобно масштабируется, особенно если API большое и сложное.

«Мусор» в данных и отчётах

Решение: Валидация данных при трансформации (например, через class-validator); автоматическая синхронизация кеша (актуальные данные во всём приложении).

Почему это лучше ручного подхода? Смотрите: строк кода на 1 endpoint при ручном управлении потребуется 30+, а с фабрикой — 5-10. Времени для добавления нового поля — 1 час вручную, с фабрикой — 5 минут. Количество мест для правки при изменении API — вручную их много, с фабрикой — лишь одно.

Реальный кейс: в проекте с 50+ endpoint’ами переход на фабрику сократил код на 70%. Разработчики перестают быть «переводчиками» между API и интерфейсами сервисов и приложений, а сосредотачиваются на бизнес-логике. Как сказал один тимлид: «Теперь мы не фиксим баги данных, а делаем фичи, которые нравятся пользователям».

Еще пример: вместо пяти отдельных хуков для CRUD-операций фабрика дает одну функцию createApi(). Вместо ручного парсинга — автоматическую трансформацию данных через class-transformer. А главное — единые правила игры для всего проекта.

Как это работает? Представьте, что вы говорите системе: «Вот endpoint для товаров, вот их модель данных, вот правила валидации» — а все остальное она делает за вас. Хотите получить товар по ID? Пишете useGetByIDQuery. Нужно обновить? — useUpdatetMutation. И никакого шаманства с ручным описанием каждого хука.

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

Как договориться и не сойти с ума

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

Решение? Четкий контракт. Простой, прозрачный, однозначный. В нем должны быть:

1. Единые правила именования — если бэкенд отдает snake_case, фронтенд не должен гадать, будут ли остальные поля в camelCase, или, например, если в одной модели данных full_name , в другой не будет fullname и так далее.
2. Единый формат запросов и ответов.
3. Договоренности о структуре URL, формате данных и кодах ошибок.
4. Строгая типизация — TypeScript-интерфейсы, которые знают, какие поля обязательны, а какие могут отсутствовать.
5. Документация, которая не врет — если Swagger говорит, что поле email есть, оно должно быть. Всегда.

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

Но, как правило, контракт сделать тяжело. Каждый видит REST по-своему: разные URL, форматы данных, обработка ошибок. Модели данных непоследовательны — поля то есть, то их нет, вложенность меняется. Документации либо нет, либо она устарела, так что API изучаем методом проб и ошибок. От такого надо отказываться сразу и стараться договорится на берегу.

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

Что получаем в итоге?

Когда контракт есть, а обертка API готова, магия начинает работать:

• Простота использования: вместо десятков хуков — единая фабрика createApi(). Меньше boilerplate-кода.
• Мощные возможности: данные приходят уже в нужном формате без ручных проверок. Кэш, инвалидация и оптимизации — TanStack Query делает за вас всю грязную работу.
• Новички влетают в проект: больше не нужно объяснять, почему useGetEntity в одном компоненте работает не так, как в другом.
• Активное сообщество: TanStack Query — тысячи разработчиков, готовых ответить на вопросы. Здесь можно найти примеры для любых кейсов: от интеграции с Next.js до кастомного кеширования.
• Нет ограничений по использованию: TanStack Query — не только для React, есть версии для Vue, Svelte и даже Solid.js. Также работает с любым API — REST, GraphQL, WebSockets.
• Работа с SSR без боли: готовая интеграция с Next.js, Remix и другими фреймворками. При этом данные, полученные на сервере, автоматически передаются на клиент. TanStack Query синхронизирует серверный и клиентский рендеринг.

Но есть и ложка дегтя. Отладка усложняется, если что-то сломается внутри обертки — придётся копать глубже. Возникает зависимость от библиотек: class-transformer, axios и сам TanStack Query становятся обязательными.

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

Сравнительные примеры

GET /products — Список продуктов

GET /products/:id — Один продукт по id

POST /products — Создание продукта

PUT /products/:id — Обновление продукта по id

DELETE /products/:id — Удаление продукта по id

Как это выглядит в обертке

Все свойства и возвращаемые хуки и конфиги из фабрики:

Пример использования в компонентах:

Использование конфигов:

Для сравнения с классическим решением:

Когда стоит переходить на обертку?

Не каждый проект нуждается в таком подходе к API. Если у вас два-три endpoint’а и они никогда не меняются — возможно, обертка будет избыточной. Но представьте стартап, где каждый месяц добавляются новые сущности: сначала товары, потом отзывы, потом промокоды, рекомендации, аналитика.

Вот где система раскрывается на полную! Новая сущность? Пять минут на добавление — и готовы все CRUD-операции. Изменился бэкенд? Правим в одном месте — и все работает. Пришел новый разработчик? Он не тратит неделю на изучение особенностей API.

Правда, если бэкенд живет в мире хаотичных endpoint’ов (например, GET /fetch_items, но DELETE /removeProduct), обертка не спасет.

Но как навести порядок?

Главный секрет — общаться. Не ждать, пока API сломается, а сразу договориться:

• Какие будут названия полей (created_at vs createdAt);
• Как структурированы ошибки;
• Когда и как можно менять контракт.

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

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

Но правда в том, что это решение подходит далеко не всем компаниям. В 90% ситуаций микросервисная архитектура (она же MSA) — избыточность, а не необходимость. Это не просто сложно, а очень сложно. Микросервисы требуют мощной инфраструктуры, глубоких знаний DevOps, тонкой настройки мониторинга и отказоустойчивости. И самое главное — они редко нужны на старте проекта.

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

Почему все говорят про микросервисы

Архитектура микросервисов — прогрессивная модель для создания ПО, при которой приложение состоит из автономных, почти не связанных друг с другом модулей. Это упрощает разработку проектов и управление ими, поэтому подход применяют известные крупные бренды типа PayPal и Netflix.

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

Маркетинг на волне хайпа

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

Микросервисы — не просто архитектура, это целая индустрия. Компании вроде Google и AWS активно продвигают Kubernetes, Istio и прочие сложные инструменты. Им это выгодно: чем больше людей верят, что без этого стека нельзя, тем больше подписок, лицензий и консультаций продаются.

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

Ориентированность на резюме

Многие разработчики (особенно начинающие) учат микросервисы не потому, что столкнулись с их необходимостью, а потому, что это круто звучит. В итоге в вакансиях пишут «знание Docker/K8s — огромный плюс», а на собеседованиях спрашивают про «опыт работы с распределенными системами», даже если у компании всего лишь сайт-визитка.

Это создает порочный круг:

• новички учат Kubernetes, потому что это востребовано;
• компании требуют Kubernetes, потому что так делают конкуренты;
• в итоге люди тратят месяцы на сложные технологии, которые никогда не применят.

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

Завышенные ожидания по проекту

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

Что происходит на практике:

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

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

Нужны ли вашему проекту микросервисы

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

Чтобы понять, стоит ли внедрять в ваш проект микросервисы, ответьте на три важных вопроса.

Действительно ли ваш проект настолько масштабен?

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

Сразу проверьте себя:

• Если ваш сервис — это один API, который обслуживает 5 конечных адресов, микросервисы вам не нужны.
• Если вы не можете четко объяснить, какие части системы могут жить автономно (например, платежи без каталога товаров), значит, у вас монолит. И это нормально.

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

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

Действительно ли вам необходимо масштабировать части приложения автономно?

Типичный аргумент за микросервисы: «У нас нагрузка только на платежи, а не на каталог — выгодно масштабировать их по отдельности». На самом деле 99% стартапов никогда не сталкиваются с такой нагрузкой, где это критично. Кроме того, современные облака (AWS, GCP) умеют масштабировать отдельные модули монолита.

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

Если вы не Amazon — вам, скорее всего, хватит вертикального масштабирования (+1 сервер) или модульного монолита.

Есть ли у вас услуги, связанные с транзакциями?

В монолите транзакция — это пара строк кода. В микросервисах — сложный квест.

Вот как это выглядит:

1. Платежный сервис списал деньги.
2. Инвентарный сервис не ответил (упал или залагал).
3. Теперь у пользователя списаны деньги, но заказ не создан.

Микросервисы создают проблемы согласованности. В монолите вы обновляете данные одной транзакцией, в MSA это стоит в 10 раз дороже.

7 причин не лезть в микросервисы

Значительная часть начинающих прогеров по умолчанию считает, что микросервисы — это прогрессивно и круто. Но они просто не видят подводных камней. На самом деле MSA — это компромисс со сложностью, деньгами и нервами. И не нужно считать, что монолит — это отсталая технология. Решения, касающиеся архитектуры продукта, нужно принимать, основываясь на объективных данных, а не хайпе.

Рассмотрим главные причины, по которым вам не стоит связываться с микросервисами.

Сложность съедает пользу

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

На практике получается следующее:

• Kubernetes (или иной подобный инструмент) становится источником проблем. Вместо написания кода вы теперь разбираетесь, почему поды (базовые строительные блоки) не стартуют, настраиваете контроллеры, обновляете Helm-чарты. Это занимает 30-50% рабочего времени.

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

Команда тратит полгода на переход. Но сервис получает те же 100 запросов в секунду. Только теперь он становится медленнее, сложнее в поддержке, дороже в эксплуатации.

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

Микросервисы не лечат плохой код

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

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

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

Нужна подготовленная команда

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

• Без полноценного DevOps или SRE-инженера вы быстро утонете в бесконечной настройке и мониторинге. Это не та работа, которую можно взвалить на бэкендера — она требует специфических знаний и постоянного внимания.
• Когда сервисов становится много, появляется новая головная боль — согласование контрактов между командами. Кто за что отвечает? Как тестировать изменения? Что делать, если один сервис ломает другой? Без четких договоренностей и CI/CD-культуры это превращается в хаос.
• В большинстве стартапов два бэкендера, один стажер и горящие сроки. Они едва успевают пилить фичи, не то что разбираться с продвинутыми практиками DevOps.

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

Деньги тратятся быстрее

Когда речь заходит о микросервисах, многие почему-то забывают простую истину — за все надо платить:

• Без профессионального DevOps-инженера (а хорошие специалисты стоят дорого) ваш «распределенный рай» быстро превратится в ад. Кто будет настраивать Kubernetes, разбираться с падающими подами и оркестрировать логи?
• Базовый мониторинг вроде Prometheus + Grafana — это только начало. Когда сервисов станет много, вам понадобятся системы трассировки и еще десяток инструментов, каждый из которых требует времени и денег.
• Главная скрытая цена микросервисов — время инженеров. В монолите проверка занимает минуты. В мире микросервисов вам сначала придётся поднять пол-инфраструктуры, чтобы просто удостовериться, что код вообще работает.

Для проектов с нагрузкой меньше 100k пользователей микросервисы обходятся в 2-3 раза дороже монолита. И это без учета скрытых затрат — нервов, задержек и упущенных возможностей.

Отладка микросервисов — это головная боль

Отладка в микросервисной архитектуре требует серьезных затрат времени и финансов. В монолите все просто — есть трассировка стеков (список вызовов), есть логи, и обычно проблема лежит где-то между ними.

Но в мире микросервисов ошибка может прятаться где угодно: в сервисе А, который не так ответил сервису Б, который передал кривые данные сервису В, а тот и вовсе решил ничего не отвечать. И все это с таймаутами, повторными запросами и загадочными HTTP-статусами.

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

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

Легкого масштабирования не будет

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

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

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

Когда микросервисы все же нужны

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

Вот три реальных ситуации, когда MSA имеет смысл.

Независимые продукты под одной крышей

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

Здесь микросервисы — не прихоть, а необходимость.

Огромные масштабы

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

Технический стек из разных компонентов

Иногда часть системы логичнее писать на Go (где важна скорость), часть на Python (для ML), а часть оставить на JVM (для legacy).

Микросервисы позволяют:

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

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

Итоги

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

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

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

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

TinyGo, MIPS и странности платформы

PS2 построена на процессоре MIPS R5900 (архитектура MIPS-III с расширениями), который не поддерживается стандартной сборкой Go. Проблему частично решает TinyGo, который компилирует Go-код в LLVM IR.

Но даже с ним возникли сложности: ни LLVM, ни сам TinyGo не умеют работать с особенностями PS2 «из коробки». Пришлось вручную описывать платформу через ps2.json, определять baremetal-окружение, runtime и заглушки под прерывания.

Первые успехи: «Hello from Go»

Чтобы код TinyGo можно было линковать с библиотеками из ps2dev (а они скомпилированы под ABI N32), автору пришлось добиваться совместимости: целиться в MIPS-III, использовать hard-float, отключать abicalls и собирать IR с последующей ручной сборкой объектника через Clang с нужными флагами.

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

Собственный main() и отладка

Дальше автор отказался от загрузчика на C и написал полноценный main() на Go, вручную выделяя память под кучу и завершая программу через exit() из ps2dev. Он добавил простую обёртку над scr_printf() — теперь можно печатать текст прямо из Go.

DDIVU и проклятие деления

Серьёзным багом стал сбой fmt.Sprintf: PS2 не поддерживает инструкцию DDIVU, которую LLVM генерирует при делении uint64.

Автор обошёл это, подключив функции __udivdi3, __divdi3 и прочие, а затем пропатчил компилятор TinyGo, чтобы он использовал их при делении int64 и uint64.

Что дальше

Демо работает. Go-код запускается напрямую, выводит текст и корректно делит числа.

Впереди — системные вызовы, inline-ассемблер, поддержка прерываний и, возможно, новая цель в LLVM для процессора r5900.

Что вообще такое context collapse

Есть вероятность, что вы слышите этот термин в первый раз. Немного лирики: в мире микросервисов есть два понятия: технический контекст и доменный контекст (Bounded Context).

Технический контекст

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

Без технического контекста микросервисы не могут:

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

Доменный контекст (Bounded Context)

Доменный контекст происходит из методологии Domain-Driven Design (DDD) — это про четкое разделение бизнес-логики между микросервисами. У каждого сервиса должна быть своя «ограниченная область» (Bounded Context), где термины, данные и правила имеют уникальное значение.

Например, в интернет-магазине слово «заказ» может означать разные вещи для сервиса оплаты (финансовая транзакция) и сервиса доставки (отправка покупателю). Если границы контекста не определены четко, возникает путаница: сервисы начинают дублировать логику или интерпретировать данные по-разному.

Без доменного контекста:

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

Вернемся к коллапсу контекста

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

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

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

Что на самом деле происходит

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

Сервис теряет важное состояние, например:

• «Это корзина Пети»
• "Этот платеж уже прошел"

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

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

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

Как понять, что контекст вот-вот может «коллапснуться»

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

• Всплеск пинга: сервисы запрашивают данные, которые должны бы уже знать, создавая огромное количество лишних вызовов и перегружая API.
• Дублирующиеся действия: повторные списания, задвоенные отправки писем, неожиданные повторные заказы. Пользователи возмущены, рейтинг падает.
• Мистические баги: логи говорят «всё в порядке», но результат явно неверный. Код не видит проблему, а отладка превращается в кошмар.

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

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

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

Опрос CNCF за 2024 год показал, что 68% команд, которые используют микросервисы, сталкиваются с необъяснимыми проблемами производительности. И всему виной в том числе контекстный коллапс.

5 решений, как бороться с контекстным коллапсом

Да, контекстный коллапс — крайне неприятный баг. Главное — чтобы все сервисы работали слаженно и «знали» друг друга.

1. Правильно передавайте контекст

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

Вот пример реализации middleware автором на Go:

2. Кэшируйте с умом

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

Это позволяет поддерживать контекст во всех вызовах, не перегружая вашу базу данных. А еще TTL (time-to-live) Redis сам за собой убирает — устаревшие данные не скрываются.

3. Используйте Event-Driven Architecture

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

Здесь также можно использовать RabbitMQ. В общем, больше никаких отговорок со стороны сервиса из разряда «я забыл».

4. Проверяйте логи

Когда контекст теряется, логи — ваше место преступления. Настройте Grafana Loki или Datadog для поиска «потерянных контекстов». Вот пример с Grafana:

Тэгните логи с помощью request_id или user_id, а затем вызовите Loki:

5. Тестируйте на коллапсы

Профилактика лучше, чем лечение. Добавьте хаос-тестирование с помощью, например, Chaos Mesh, чтобы моделировать потери контекста.

Хаос-тестирование — это метод преднамеренного введения сбоев в систему, чтобы проверить, насколько она устойчива и надежна. Обычное тестирование и мониторинг могут выявить проблемы, но хаос-тестирование (Chaos Engineering) помогает увидеть, как система поведет себя в случае неожиданных отказов.

Прервите mid-requests к сервисам — сможет ли система восстановится в таком случае? Если нет, значит, ваша передача контекста недостаточно надежна.

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

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

Основные компоненты AJAX

Термин AJAX используется в программировании с 2005 года, хотя подобные способы обмена данными применялись и ранее. Это универсальное решение для веб-приложений, которое объединяет несколько компонентов. Именно благодаря AJAX реализованы такие проекты, как современные соцсети, Google Maps, Gmail, Google Docs и многие другие.

Основная задача AJAX — запросы к серверу в обход перезагрузки страницы. Это уменьшает время отклика и позволяет веб-приложению работать в интерактивном режиме. Несмотря на присутствие в названии отсылки к XML, использовать этот язык разметки не обязательно.

Технология реализуется через JavaScript — происходит заданный скриптом асинхронный обмен данными между сервером и браузером. Именно на JS создаются запросы для коммуникации с сервером и динамического изменения страницы.

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

Код на JavaScript — не единственный компонент AJAX. В него также входят форматы хранения данных XML или JSON. При этом JSON для отправки запросов AJAX используется чаще, поскольку код у этого формата короче, что существенно упрощает передачу данных.

Важнейший компонент технологии — объект XMLHttpRequest, который отвечает за все запросы AJAX. Этот API предоставляет клиенту полноценный функционал для взаимного обмена данными с сервером. Раньше XHR поддерживали не все браузеры — разработчикам приходилось дополнительно подключать библиотеку jQuery с встроенным объектом. Сейчас большинство популярных браузеров, включая Chrome и Firefox, работают с XMLHttpRequest напрямую.

Примечание. В современных программных веб-продуктах вместо XHR нередко используют Fetch AP, но говорить о массовом тренде преждевременно.

Передача данных выполняется через стандартный протокол взаимодействия клиента и сервера HTTP. Браузер инициирует запрос, получает в ответ HTML-страницу, либо сообщение об ошибке (если в запросе есть неточности). Используются стандартные методы получения данных — GET и POST. Первый (GET) применяется при получении данных от сервера, второй (POST) используется для отправки данных на сервер в теле HTTP-запроса.

Благодаря способности AJAX работать с разными форматами, типами данных и серверными API, эта методика универсальна. Асинхронный обмен позволяет веб-приложениям быстро загружаться, плавно работать и не перезагружаться после каждого запроса пользователя к серверу. Это особенно актуально для приложений, требующих постоянного взаимодействия с сетевым устройством — социальных сетей, онлайн-магазинов, браузерных версий мессенджеров.

Как работает AJAX

Магия асинхронных запросов AJAX базируется на взаимодействии с DOM-объектами браузерной страницы. Процесс выглядит следующим образом:

1. С помощью JavaScript браузер отправляет HTTP-запрос на сервер, где происходит обработка данных и отправка ответа. Чтобы отправить запрос, потребуется создать объект XMLHttpRequest — без него отправлять запросы и получать ответы без перезагрузки не получится.
2. При этом запрос необходимо настроить — указать метод GET/POST, URL и перейти на асинхронный режим работы.
3. Сервер возвращает данные, с которыми начинает работать JavaScript. Когда браузер принимает исходный код страницы, он выстраивает множество виртуальных элементов на базе этого кода — сюда входят заголовки, изображения, текст, ссылки и прочее.
4. При этом к каждому компоненту виртуальной модели можно обращаться отдельно с целью изменить его свойства или содержание. JavaScript позволяет поменять фон страницы, изменить заголовок и внести другие изменения, не перегружая страницу.

Простой пример запроса AJAX выглядит следующим образом (используется метод получения данных GET):

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

В следующем примере показан код для отправки формы с использованием запроса AJAX:

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

Отладка AJAX-запросов

Для эффективной разработки и поддержки приложений программистам важно научиться отлаживать и тестировать запросы AJAX. Для этого необходимы встроенные инструменты браузеров Chrome, Firefox, Edge и других.

Эти инструменты позволяют:

• просматривать отправленные на сервер запросы во вкладке Network;
• проверять атрибуты запросов/ответов и их содержимое;
• следить за временем выполнения отправленных запросов, выявлять узкие места и оптимизировать процессы.

Для тестирования запросов полезно создавать фейковые API или проверять работу реальных интерфейсов вне контакта браузера с помощью библиотек MSW или Postman.

Прогерам будут полезны ценные советы по оптимизации процессов при работе с запросами:

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

Преимущества AJAX

Перечислим основные плюсы технологии:

• Обновление данных без необходимости перезагружать страницу. Это улучшает опыт пользователей и делает взаимодействие с приложением более плавным и быстрым. Юзерам гораздо удобнее видеть обновление на той же странице, чем загружать новую.
• Уменьшение трафика. Поскольку браузер получает от сервера не всю страницу полностью, а только ограниченную запросом информацию, тратится меньше ресурсов на передачу данных.
• Снижение нагрузки на сервер. Если приложение открывает страницы «на лету», достаточно один раз прогрузить стандартные элементы (шапку, меню, подвал), а остальные части загружать по необходимости.
• Быстрота и отзывчивость приложений. Чем меньше данных в запросе AJAX, тем быстрее придет ответ от сервера. В современных продуктах скорость и удобство — ключевые конкурентные преимущества.
• Экономия ресурсов. Безлимитный интернет есть не у всех и не везде, а запросы AJAX используют ресурсы в минимальном режиме.

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

Недостатки AJAX

В числе основных минусов AJAX:

• Потенциальные проблемы с SEO-контентом. Содержание страниц, которое подгружается с помощью AJAX, часто недоступно для поисковиков, что негативно сказывается на индексации. Поисковые системы видят исходный ход, но не данные с серверов. Это может быть проблемой для сайтов, которые нуждаются в привлечении пользователей. Для сеошников работа с сайтами на AJAX — головная боль.
• Кэширование. Динамическое содержание может создать сложности с кэшированием, что приводит к загрузке неактуальных данных.
• Зависимость от JavaScript. Пользователь может отключить JavaScript, что ограничит функциональность сайта. Данные не смогут прийти с сервера, интерактивного обновления не получится.
• Усложнение проекта. Работа с запросами AJAX требует от разработчиков определенной квалификации. Они должны предвидеть различные внештатные ситуации, связанные с асинхронными запросами, и заранее прописать скрипты на такие случаи. Потребуется также продумать бэкенд — ответы сервера на различные запросы.

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

Где используется AJAX

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

• Динамическое обновление. С помощью AJAX обновляются отдельные элементы страниц — таблицы, списки, графики. Это особенно удобно на сайтах, где применяются фильтры — например, на страницах онлайн-магазинов.
• Автозаполнение и поиск. AJAX используется для мгновенной выдачи результатов поиска. Юзер только начинает вводить текст в поисковую строку и уже видит релевантные варианты. Это удобно для формирования точных и подробных поисковых запросов.
• Отправка формы. Чтобы отправить данные заполненных форм, пользователю не нужно ждать обновления, что делает работу более плавной. Например, можно залогиниться после просмотра сайта, оставшись на той же странице.
• Загрузка данных для конкретного пользователя. В соцсетях или на сайтах с интерактивными опциями новые сообщения, уведомления и комментарии подгружаются без обновления страницы.
• Динамические интерфейсы. Этот процесс вы можете наглядно наблюдать на Гугл-картах и в подобных приложениях — по мере прокрутки подгружаются новые части территории. Аналогичная опция реализована на сайтах с интерактивными прогулками по гостиницам, музеям и другим локациям.

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

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

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

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

Разбираемся на практике

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

Структура проекта:

Library_project/

├── Library/

│ ├── models/

│ │ ├── book.py

│ │ └── catalog.py

│ ├── utils/

│ │ ├── search.py

│ │ └── reports.py

│ └── tests/

│ └── test_catalog.py

└── main.py

Код проекта:

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

Шаг 1: Поймите, что в принципе делает код

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

Давайте посмотрим на файл main.py:

Из него понимаем, что:

1. Проект связан с библиотекой (судя по названию модуля);
2. Есть тестовый сценарий, в котором видно основную функциональность;
3. Код организован в пакеты и модули.

Если запустим тесты, увидим следующее:

Теперь мы знаем, что система как минимум умеет:

• Выдавать книги;
• Искать книги по названию;
• Показывать статус.

Шаг 2: Изучите общую структуру кода

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

Вопрос 1: Как организованы данные?

Помним, что у проекта есть четкая структура:

Library_project/

├── Library/

│ ├── models/

│ │ ├── book.py # Данные о книгах

│ │ └── catalog.py # Управление каталогом

│ ├── utils/

│ │ ├── search.py # Поиск

│ │ └── reports.py # Генерация отчетов

│ └── tests/

│ └── test_catalog.py # Тесты

└── main.py # Точка входа в приложение

Она говорит нам о том, что:

• Данные о книгах и каталоге разделены;
• Дополнительные функции лежат в отдельном модуле;
• Есть модуль для тестов;
• Система в целом следует принципам модульности.

Вопрос 2: Как взаимодействуют компоненты?

Посмотрим на импорты в catalog.py:

Это показывает, что:

• Каталог зависит от класса Book;
• Приложение подтягивает даты (чтобы проверять сроки).

Вопрос 3: Какие главные операции выполняются в системе?

В классе LibraryCatalog видим:

Отсюда понятно, что система может:

• Выдавать книги на конкретный срок;
• Возвращать книги;
• Делать поиск по каталогу.

Шаг 3: Изучите документацию и комментарии

При чтении чужого кода документация и комментарии — ваши лучшие друзья. Например:

Здесь мы видим docstring, который кратко описывает назначение класса. Более наглядный пример — метод borrow_book из файла /models/catalog.py:

Шаг 4: Проанализируйте главную точку входа в программу

Точка входа — место, с которого начинается выполнение программы. В нашем случае это main.py, но давайте посмотрим внимательнее, на что он ссылается:

Из этого кода видно, что первым делом импортируются классы: LibraryCatalog из файла /models/catalog.py, BookSearch из файла /utils/search.py и класс ReportGenerator из файла /utils/reports.py.

Далее — функция run_basic_tests, в которой создается экземляр класса LibraryCatalog. В переменную status записывается значение вызова метода borrow_book, который возвращает статус выдачи книги.

Затем выводится информация о тесте выдачи книги. По аналогии, в переменные search_results, return_status, overdue_report записываются значения вызова методов search_by_title, return_book и generate_overdue_report соответственно.

Шаг 5: Определите ключевые функции и классы

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

LibraryCatalog — центральный класс. В нем реализованы основные методы управления библиотекой, такие как: добавление новой книги (add_book), выдача книги читателю (borrow_book), возврат книги в библиотеку (return_book), получение списка всех выданных книг (get_borrowed_books) и поиск книги (find_book).

BookSearch — утилитный класс. В нем реализованы методы поиска книги по автору и по названию.

Шаг 6: Используйте инструменты IDE для навигации и анализа

В современных IDE есть мощные инструменты для анализа кода. Рассмотрим несколько основных на примере нашего «чужого» кода.

• Find Usages:

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

• Go to Definition — видим, как создается объект:

• Structure View — позволяет увидеть все методы и свойства классов в одном месте:

Шаг 7: Отладка и запуск — пошаговое выполнение кода

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

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

1. Установим breakpoint в методе borrow_book:

2. Запустим тест и пошагово посмотрим:

Этот скриншот показывает значения переменных:

3. Затем можно посмотреть пошаговое выполнение кода с помощью функций Step Over, Step Into, Step Out:

4. Теперь можно попробовать выдать 2 раза одну книгу разным людям и запустить отладку:

На этом скриншоте мы видим, что книга с этим id доступна для выдачи. Продолжим выполнять код, нажимаем на кнопку Resume Program:

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

Несколько советов, чтобы не сойти с ума, читая чужой код

Рисуйте диаграммы

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

Создайте мини-документацию для себя

Представьте, что ведете личный дневник по горячим следам. Если в коде вы наткнулись на нечто неочевидное, сделайте краткую запись: что это за модуль, зачем он тут, и как он связан с другими частями. Через неделю, когда вы снова откроете проект, сами себе скажете: «Ого, какой я молодец, всё прописал!».

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

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

Оставайтесь в контексте

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

Не забывайте про библиотеки

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

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

Кстати! Хочешь разбираться в коде быстрее и эффективнее? Собрали для тебя полезные советы тут.

Типы ошибок в Node.js и основные подходы к их обработке

Синхронные ошибки

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

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

Ошибки типа (TypeError, ReferenceError)

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

Ошибки парсинга JSON

Если переданный JSON-строковый объект невалиден, JSON.parse() выбросит исключение.

Деление на ноль или некорректные математические операции

JavaScript допускает деление на ноль, но оно может приводить к логическим ошибкам.

Но как правильно обрабатывать синхронные ошибки?

Используем try...catch

Классический способ перехвата ошибок в синхронном коде — использование конструкции try...catch.

Генерируем пользовательские ошибки

Можно явно выбрасывать ошибки с пояснением:

Используем process.on('uncaughtException', callback)

Node позволяет перехватывать необработанные ошибки глобально:

Синхронные ошибки в Node могут возникать по разным причинам: неверный тип данных, ошибки в логике или работе с JSON и т.д.. При работе важно помнить, что их можно перехватывать try...catch, выбрасывать вручную с пояснениями и даже обрабатывать глобально с помощью process.on(). Это снижает вероятность неожиданного завершения работы сервера и повышает надежность приложений.

Асинхронные ошибки

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

Асинхронные ошибки в Node могут проявляться в трёх основных сценариях:

1. Ошибки в коллбэках;
2. Ошибки в промисах;
3. Ошибки в async/await.

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

Ошибки в коллбэках

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

Пример: ошибка внутри коллбэка

Здесь, если файл nonexistent.txt отсутствует, в err передается ошибка, и программа не падает, а просто выводит сообщение. Однако, если бы в коде не было проверки if (err), приложение завершилось бы при попытке обработать data.

Как правильно обрабатывать ошибки в коллбэках?

1. Всегда проверять аргумент err;
2. Передавать ошибки дальше, если не знаем, как с ними работать.

Пример обработки ошибки и её проброса:

Ошибки в промисах

Промисы — более современный способ работы с асинхронностью в Node. Они позволяют избежать глубокой вложенности (callback hell) и обеспечивают удобный механизм обработки ошибок.

Пример: промис с ошибкой

Здесь, если в fetchData произойдёт ошибка (reject вызывается с new Error()), она будет перехвачена в .catch().

Как правильно обрабатывать ошибки в промисах?

1. Использовать .catch() для перехвата ошибок;
2. Использовать .finally(), если нужно выполнить код в любом случае;
3. Не забывать возвращать промисы из функций.

Пример корректной обработки:

Ошибки в async/await

async/await — современный способ работы с асинхронным кодом, который позволяет писать его в стиле синхронного. Однако ошибки в таком коде не всегда очевидны, особенно если промисы не обернуты в try...catch.

Пример ошибки в async/await:

Если getUser() выбросит ошибку, программа аварийно завершится. Чтобы избежать этого, нужно использовать try...catch.

Как правильно обрабатывать ошибки в async/await?

1. Оборачивать вызовы await в try...catch;
2. Использовать catch() для перехвата на уровне вызова.

Пример правильной обработки:

Или можно обработать ошибку прямо в .catch():

Асинхронные ошибки в Node могут проявляться в коллбэках, промисах и async/await. Каждый из этих подходов требует своей стратегии обработки ошибок:

• В коллбэках всегда проверяйте err;
• В промисах используйте .catch() и .finally();
• В async/await оборачивайте код в try...catch.

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

Чек-лист для новичков: как правильно обрабатывать ошибки в Node.js

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

Всегда обрабатывайте ошибки, даже если они маловероятны

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

Пример ошибки без обработки:

Этот код вызовет исключение SyntaxError и остановит выполнение программы.

Правильный вариант с обработкой:

Даже если кажется, что JSON всегда будет корректным, лучше обработать его парсинг в try...catch, чтобы избежать сбоев.

Используйте централизованный обработчик ошибок (middleware в Express)

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

Что делать с централизованным обработчиком ошибок в Express?

1. Определите middleware для обработки ошибок;
2. Все ошибки передавайте через next(error);
3. Express автоматически передаст ошибку в обработчик.

Пример:

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

Логируйте ошибки (например, с помощью Winston или Pino)

Логирование ошибок помогает отслеживать сбои и анализировать их причины. В продакшен-приложениях нельзя ограничиваться console.log() — лучше использовать специализированные библиотеки.

Как работает Winston?

Winston — это гибкий логгер для Node.js, поддерживающий сохранение логов в файлы, базу данных и удалённые сервисы.

Установка:

Настройка логгера:

Использование в коде:

Теперь ошибки будут логироваться как в консоли, так и в файле errors.log.

Генерируйте пользовательские ошибки через Error (или свои классы ошибок)

Вместо простых строковых сообщений об ошибках используйте объекты Error или создавайте собственные классы ошибок для лучшей структуризации.

Простой пример с Error:

Создание собственного класса ошибок:

Использование классов ошибок делает код более читаемым и удобным для отладки.

Не забывайте про process.on('unhandledRejection') и process.on('uncaughtException')

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

• unhandledRejection — когда промис отклонён (Promise.reject()), но у него нет обработчика .catch();
• uncaughtException — когда код выбрасывает исключение, но оно не обрабатывается try...catch.

Чтобы защититься, добавьте обработчики для глобальных ошибок:

Эти обработчики помогут отлавливать неожиданные ошибки и предотвращать аварийное завершение программы.

Добавьте тесты для проверки поведения вашего кода при ошибках

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

Пример теста на обработку ошибок с Jest:

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

Резюмируем:

• Обрабатывайте ошибки, даже если они маловероятны — лучше перестраховаться, чем допустить неожиданный сбой.
• Используйте централизованный обработчик ошибок (middleware) в Express — это упростит код и улучшит поддержку.
• Логируйте ошибки (Winston, Pino) — так вы сможете отслеживать и анализировать сбои.
• Создавайте собственные классы ошибок — это сделает код чище и понятнее.
• Обрабатывайте глобальные ошибки (unhandledRejection, uncaughtException) — чтобы сервер не падал неожиданно.
• Пишите тесты на обработку ошибок — так ваш код будет надёжнее.

Практические примеры: обработка ошибок в Node.js

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

Обработка ошибок в API с использованием Express

Для примера создадим маршрут, который вызовет ошибку, и настроим обработчик:

Что здесь важно?

• Передача ошибок через next(error) — это стандартный способ уведомить Express о том, что произошла ошибка;
• Централизованный обработчик (middleware) позволяет управлять ошибками в одном месте.

Пример пользовательского класса ошибок

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

Что здесь важно?

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

Как настроить глобальный обработчик ошибок

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

Глобальная обработка unhandledRejection и uncaughtException

Глобальные обработчики защищают приложение от аварийных завершений:

Что здесь важно?

• unhandledRejection — позволяет обрабатывать промисы без catch;
• uncaughtException — защищает приложение от ошибок, не пойманных в try...catch.

Пример с промисом:

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

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

Частые ошибки при обработке ошибок в Node.js

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

Пропуск ошибок в асинхронных функциях

Асинхронный код в Node.js требует особого внимания, поскольку ошибки в промисах и async/await могут не перехватываться автоматически.

Ошибка: нет обработки ошибок в промисах

Если файл не существует, программа завершится с ошибкой UnhandledPromiseRejectionWarning.

Правильный вариант: обработка через try...catch

Теперь даже если файл отсутствует, приложение не вылетит, а отобразит сообщение об ошибке.

Запоминаем:

• Всегда используйте try...catch внутри async-функций;
• При использовании промисов добавляйте .catch(), чтобы предотвратить unhandledRejection;
• Используйте глобальный обработчик process.on("unhandledRejection"), если работаете с большим количеством промисов.

Логирование конфиденциальных данных

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

Ошибка: логирование чувствительных данных

Ошибка здесь в том, что в логи попадает пароль пользователя.

Правильный вариант: фильтрация логов

Запоминаем:

• Не логируйте req.body, req.headers, req.query без фильтрации;
• Используйте безопасные библиотеки для логирования, например, winston или pino, с возможностью маскировки данных;
• Избегайте передачи ошибок клиенту без обработки — error.message может содержать внутренние данные системы.

Попытка поглощать ошибки вместо их корректной обработки

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

Ошибка: пустой catch-блок

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

Правильный вариант: логирование и повторная обработка

Запоминаем:

• Не подавляйте ошибки, если они могут повлиять на логику приложения;
• Логируйте ошибки и передавайте их на следующий уровень обработки, если они критичны;
• Используйте автоматический перезапрос при сбоях, если это возможно (например, с помощью retry-механизмов).

Обработка ошибок в Node.js — не просто техническая деталь, а критически важная часть разработки. Проблемы могут возникнуть в любом месте кода: от синхронных операций до асинхронных вызовов, API-запросов и работы с базами данных. Следование простым правилам поможет разработчику (будь то джун или сеньор) писать более устойчивый код, избегать критичных багов и создавать по-настоящему надёжные приложения в Node.js.

Сбой длился 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, но и для любого языка программирования.

Делите код на небольшие модули

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

Пишите автоматические тесты

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

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

Комментируйте код

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

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

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

По итогам 2023 года JetBrains публиковали статистику, в которой основная версия Python 3.11 во многих компаниях всё еще использовалась с долей 27%. На втором месте Python 3.10 с долей 26%. Свежих данных по итогу 2024 года еще нет, но по моим скромным опросам 3.11 всё еще лидирует во многих компаниях. Обновляться на 3.12 и 3.13 никто не спешит. Почему?

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

Python 3.12 — ключевые изменения

Улучшенные f-строки

Теперь внутри выражений f-строк можно использовать практически любые валидные конструкции Python:

• Многострочные выражения;
• Те же кавычки, что и у f-строки;
• Бэкслэши и юникод-escape-последовательности;
• Комментарии внутри выражений.

Это снимает многие ограничения, упрощает написание f-строк и улучшает читаемость кода.

Изменения описаны в PEP-701

«Персональный» GIL для каждого сабинтерпретатора

Добавлена (на уровне C-API) возможность создавать субинтерпретаторы, у каждого из которых свой собственный GIL. Это прокладывает путь к полноценному параллелизму в Python за счёт использования Sub-Interpreters API (в будущем ожидается удобный Python-интерфейс).

Изменения описаны в PEP-684

Новая система мониторинга исполнения

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

Изменения описаны в PEP-669

Оптимизации comprehension

Списковые, словарные и множественные (set) генераторы теперь «инлайнены» (ранее генерировалась скрытая функция). Это позволяет ускорить comprehension почти в 2 раза.

Изменения описаны в PEP-709

Удаление distutils

Модуль distutils, долгое время используемый для управления сборкой и дистрибуцией Python-проектов, наконец-то полностью удалён из стандартной библиотеки в Python 3.12. Это решение было запланировано заранее и сопровождалось подробным руководством по миграции.

Другие важные моменты

• typing: появились новые возможности (PEP-692 и PEP-698) — более гибкая аннотация **kwargs через TypedDict, а также декоратор @override;
• Внутри asyncio улучшена производительность (например, отправка данных через сокеты без лишнего копирования и др.);
• В sqlite3 добавлен CLI-режим, теперь можно запускать python -m sqlite3;
• Улучшены ошибки типа NameError: «Did you forget to import ‘sys’?» и т. д.

Итого: 3.12 сфокусирован на удобстве (f-строки), оптимизации (comprehension, asyncio) и на дальнейшей подготовке к «многопоточному» Python за счёт независимых GIL.
Подробнее: What’s New In Python 3.12

Python 3.13 — ключевые изменения

Новый интерактивный интерпретатор

По умолчанию запускается «улучшенная» REPL (наработки из PyPy):

• Многострочное редактирование;
• История (F2) с пропуском вывода и префиксов >>>/...;
• «Paste mode» (F3);
• Цветные трейсы (traceback) и подсветка ошибок.

Экспериментальное отключение GIL

Добавлена опция сборки CPython без GIL. Пока что это экспериментальная опция падения производительности в однопоточном режиме и несовместимость с большинством пакетов, которые еще не адаптированы для работы без GIL.

Изменения описаны в PEP-703

JIT-компилятор

Экспериментальный JIT в CPython (доп. опция сборки) пока отключён по умолчанию и даёт лишь небольшой прирост производительности, но ожидаются улучшения в будущих версиях.

JIT-компилятор (Just-In-Time) в Python ускоряет выполнение кода, превращая часто исполняемые части в машинный код прямо во время работы программы. Это даёт прирост производительности, особенно в интенсивных вычислениях, без необходимости переписывать код. В отличие от стандартной интерпретации, JIT оптимизирует «горячие» участки, сохраняя совместимость с Python, но пока остаётся экспериментальной функцией.

Изменения описаны в PEP-744

Улучшения в стандартной библиотеке

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

• Новые модули и функции: dbm.sqlite3, base64.z85encode()/z85decode();
• copy.replace() для быстрого создания «копий с изменениями» (аналог dataclasses.replace(), но для большинства встроенных типов);
• random теперь имеет CLI: python -m random;
• Массовое удаление старых (deprecate) модулей (PEP 594) — убраны cgi, telnetlib, imp, aifc, audioop и др.

Изменения в typing

• TypeVar, ParamSpec и TypeVarTuple теперь могут иметь значения по умолчанию (PEP 696);
• warnings.deprecated() (PEP 702) для единого способа помечать устаревшие функции и классы (как на уровне типов, так и в рантайме);
• ReadOnly для TypedDict;
• Прочие полезные мелочи.

Продление срока поддержки

PEP-602 теперь даёт новым релизам (начиная с 3.13) 2 года фича-апдейтов и 3 года security-апдейтов.

Итого: 3.13 продолжает курс на эксперименты с полной «многопоточностью» (free-threading CPython), вводит JIT, улучшает REPL и продолжает чистить стандартную библиотеку от «мертвых» модулей.

Подробнее: What’s New In Python 3.13

Python 3.14 — ключевые изменения

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

Отложенная оценка аннотаций

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

Изменения описаны в PEP-649

Новая Python Configuration С-API

Расширяет функциональность PEP 587, упрощает и унифицирует процесс конфигурирования Python и его встроенного использования.
Проще — лучше, но для обычных разработчиков на Django/FastAPI это пройдет максимально незаметно.

Изменения описаны в PEP-741

Новые возможности языка

• map() теперь имеет флаг strict=True по аналогии с zip(strict=True) — проверяет, что все итерации одной длины;
• Добавлены методы float.from_number() и complex.from_number() для конверсии чисел (но не строк!);
• Возможность установить уровень detail для dis (например, --show-positions, --specialized) и т. д;
• Поддержка UUID v8 (uuid.uuid8()) и SHA-256 digest auth в urllib.request.

Улучшение ошибок

• При неправильном распаковочном присваивании теперь показывается фактическое число элементов «got X»;
• Расширены диагностические сообщения в разных участках (например, в ImportError);

• Убран ряд deprecated методов и функционала в модулях ast, asyncio, itertools, pkgutil и т. д.

Оптимизация

• Точки останова и отладка (breakpoint) переиспользуют один экземпляр Pdb;
• Улучшен механизм auto-слежения за процессом (profiling, trace). Меньше накладных расходов при профилировании;
• Множество мелких доработок в модулях и стандартных функциях (например, io, random, multiprocessing).

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

Подробнее: Python 3.14 Changelog

Кратко о том, что изменилось:

• 3.12 — крупные шаги в сторону удобства (f-strings, классные улучшения asyncio), чистка старья (distutils) и подготовка к независимым GIL;
• 3.13 — экспериментальный free-threading (полное отключение GIL), базовый JIT, улучшенный REPL, удаление целого набора древних модулей, новые возможности в typing;
• 3.14 — отложенная оценка аннотаций, дальнейшие улучшения C API, новые фичи в базовых функциях (map(strict=…), и т. д.), подчистка долгих депрекейтов.

Можно сделать только один вывод. Если вы сейчас работаете на версии 3.11, то особого смысла обновляться всё еще нет. Большая часть нововведений лишь готовит почву для более серьезных изменений. Для внедрения NoGIL как полноценного инструмента может понадобиться больше 5 лет.

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

С точки зрения безопасности — для 3.11 патчи будут выходить до октября 2026 года, так что имеет смысл периодически «накатывать» новые минорные версии, чтобы закрыть известные уязвимости. До появления проблем с версиями пакетов, которые будут сбрасывать поддержку 3.11, ждать еще как минимум пару лет.

Итого, самым разумным решением будет дождаться релиза 3.14 в октябре. К тому времени подтянется и поддержка этой версии у большинства популярных пакетов, а еще станет понятней судьба всех «экспериментальных» нововведений. Больше про разработку рассказываю в своем Telegram-канале.

Black

Это инструмент, который одновременно выявляет ошибки и форматирует код на Python. В сообществе питонистов уже давно есть PEP8, оформляющий код в едином стиле, и пойти против него — практически преступление. Black менее красивый, но при этом более консистентный, плюс его нельзя конфигурировать. Об этом даже написано в readme.md пакета:

By using it, you agree to cede control over minutiae of hand-formatting. In return, Black gives you speed, determinism, and freedom from pycodestyle nagging about formatting. You will save time and mental energy for more important matters.

Используя его, вы соглашаетесь больше не контролировать форматирование вручную. Взамен Black «обещает» скорость, определенность и свободу от придирчивого отношения к стилю pycodestyle. Тем самым вы экономите свое время и силы для более важных дел.

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

Для установки вводим в командную строку:

А чтобы сразу приступить к работе с дефолтными настройками, прописываем:

MyPy

MyPy — инструмент статической проверки типов, который поддерживает и динамическую типизацию (duck typing). Он помогает выявлять ошибки несоответствия типов в коде до его выполнения, повышает надежность программы, а еще — поддерживает другие библиотеки и разные режимы проверки типов.

Для установки вводим:

Пример кода с ошибками, который проверяет работу MyPy:

Вывод будет такой:

Pydantic

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

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

Вот простой пример, как работает Pydantic:

Здесь можно увидеть, как использование библиотеки Pedantic уменьшило размер кода и сделало его более понятным за счет того, что в нежелательном кастомном методе validate() особо нет необходимости.

Hypothesis

Это мощная библиотека Python для property-based тестирования, которая генерирует тестовые данные в соответствии с определенными правилами (strategies). Основная идея заключается в том, чтобы задать общие свойства программы, а Hypothesis автоматически сгенерирует множество входных данных для проверки этих свойств.

Библиотека интегрируется со многими популярными утилитами для тестирования, например, с pytest и unittest.

Установка:

Вот пример простого кода с ошибкой деления на 0, которую проверяет «Гипотеза»:

Тест выдаст следующее:

Pre-commit

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

Для установки:

Вот как это работает:

• Создаем файл .pre-commit-config.yaml в корневой структуре проекта:

• Устанавливаем скрипты Git-хуков:

• Сам коммит-код:

Pre-commit автоматически проверит код на ошибки и исправит их.

Vulture

Пакет Python, который выявляет мертвый код в ваших проектах и выдает подробный отчет.

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

Устанавливаем:

Работает это так:

Isort

Утилита командной строки и одновременно библиотека, которая упрощает жизнь разработчикам. Она сортирует import Python — упорядочивает и делает его более читабельными, группируя по типу (стандартная библиотека, сторонние и локальные) и выстраивая в алфавитном порядке внутри каждой группы.

Для установки:

Пример до и после использования Isort:

PyDocstyle

Утилита проверяет, соответствует ли ваши docstrings стандарту PEP 257. Это стиль, который упорядочивает высокоуровневую структуру таких строк — что они должны содержать и как их писать (при этом он не затрагивает синтаксис в самих строках).

Для установки:

Затем пишем это и проверяем свой код:

Вывод будет следующий:

Bandit

Программа проверяет безопасность кода. Она ищет наиболее частые проблемы в приложениях на Python.mlt, анализирует AST (абстрактное синтаксическое дерево) и запускает набор плагинов для выявления ошибок.

Код, который проверял автор статьи на ошибки безопасности:

Вот какой результат выдал «Бандит»:

Radon

Пакет Python, который анализирует исходный код и вычисляет различные метрики, включая Cyclomatic Complexity (CC), Maintainability Index (MI), Raw metrics (SLOC, комментарии, пустые строки), и Halstead metrics. Radon помогает найти слишком сложные части кода, которые можно упростить, а также выдает отчеты для документирования и проверки кода. Пакет особенно полезен в больших проектах, когда код должен быть качественным, отлаженным и системным.

Устанавливаем:

Код, который автор статьи тестировал на сложность:

Для теста: random cc code.py

Чтобы эффективнее использовать Radon, можно создать файл конфигурации random.cfg — так будет проще управлять действиями пакета:

Эта конфигурация исключает определенные каталоги и устанавливает минимальные пороговые значения для Cyclomatic Complexity and Maintainability Index.

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

Intro

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

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

Давайте посмотрим на процесс изнутри. Я привёл немного странный пример, но он достаточно связан с ежедневной рутиной и отлично опишет большинство кейсов. Этот код вычисляет высоту ячейки таблицы. Высота зависит от некоторых констант и параметров. Допустим, в некоторых случаях высота рассчитывается неверно. Наша задача — изучить эту функцию, например узнать значение флага showTitle в момент вычисления. Что первым приходит на ум? Правильно, поместить print() для отладки.

Запускаем проект — он у нас большой, да и Xcode неидеальный. Чаще всего происходит всем знакомая ситуация: добавили одну строчку и ждём минуту, пока соберётся. А ведь кроме сборки и запуска нужно ещё и восстановить условия, добраться до нужного экрана, воспроизвести проблему и только после этого посмотреть вывод свежедобавленного print‘a.

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

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

Breakpoints

Мы уже выяснили, что отладка через добавление вывода в консоль не совсем эффективна и нам нужен какой-то инструмент, который облегчит нам жизнь. Таким инструментом являются брейкпоинты. Все мы любим этот механизм, который представлен практически в любой среде разработки на любых платформах и языках, и пользуемся им. Где-то он реализован лучше, где-то хуже, но в целом Apple предоставила нам мощный и гибкий механизм точек останова. Однако, работая с разными людьми, я заметил, что пользуются ими в большинстве случаев исключительно для остановки программы — просто чтобы убедиться, что её выполнение пошло по запланированному сценарию. Иногда люди пользуются консолью отладки и командой po, но лишь в тех случаях, когда нужно разок выяснить состояние переменной. Я предлагаю рассмотреть дополнительные возможности отладчика, встроенного в нашу IDE, и привести примеры ситуаций, в которых они могут пригодиться.

Conditional breakpoints

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

Skipping

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

Actions

Но самое интересное дня нас кроется за кнопкой Add Action. Эта кнопка позволяет добавить дополнительное действие, которое будет вызвано в момент срабатывания брейкпоинта. Как вы видите, есть 6 типов действий, которыми можно дополнить брейкпоинт:

1. Apple script. Позволяет запустить скрипт на одноименном языке.
2. Capture GPU Frame. Для отладки приложений, использующих движок Metal, может потребоваться эта опция.
3. Debugger command. Позволяет выполнить команду отладчика. О ней мы поговорим позже.
4. Log-message. Позволяет вывести текстовое сообщение в лог.
5. Shell command. Позволяет выполнить произвольную команду в среде, дефолтной для системы командной оболочки, sh/bash/zsh.
6. Sound. Позволяет проиграть звук из динамиков компьютера, на котором запущен Xcode.

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

Log message

Рассмотрим чуть более подробно тип дополнительного действия «Log message».

Если мы его выберем, к нашим услугам окажется строка ввода формата сообщения. Обратите внимание, что в строке можно указывать полезные плейсхолдеры, два из которых позволяют подставить информацию о брейкпоинте и одно, самое полезное, позволяет подставить результат вычисления произвольного выражения. Таким выражением может быть переменная или любая другая конструкция используемого вами языка программирования. Но это не имеет никакого смысла, если не поставить галочку «Automatically continue after evaluating actions». Именно она в паре с любым из действий позволит нам экономить время на дебаге. Больше не нужно писать print(), пересобирать проект и ждать вечность. В любой момент времени, без перезапуска проекта вам доступен вывод в консоль отладки любой информации о ходе выполнения программы. А для знающих толк в извращениях дебаге Apple предусмотрела возможность воспроизвести выражения, используя встроенный синтезатор речи.

Shell command

Нетрудно догадаться, что этот экшен позволяет запустить произвольную команду в стандартной оболочке терминала ОС. Как и «Log message», она позволяет вычислить результат выражения в текущем контексте и дополнить им аргументы вызова команды. Для чего это может быть полезно? Примеров использования можно придумать массу. Из реальной жизни: запуск троттлинга через Charles. Необходимо было замедлять запросы из определённой точки, при этом в остальное время соединение должно было быть полноценным. Я не успевал включать-выключать троттлинг вручную и ещё совершать действия в симуляторе. Такой трюк с брейкпоинтом и «Shell command» отлично меня выручил. В другой раз мне понадобилось изменять информацию на сервере прямо параллельно с запросом, чтобы отловить довольно странный баг. Тут тоже был кстати этот вид брейкпоинта. Особые извращенцы могут собрать конструкцию на Arduino с электрошокером и бить себя током при каждом срабатывании нежелательного кода. Шучу. Не пытайтесь это воспроизвести в реальной жизни.

Debugger command

Одним из самых интересных видов экшенов я считаю «Debugger command». Этот экшен позволяет действительно безгранично влиять на отлаживаемую программу. Debugger command — это команды отладчика LLDB, а LLDB — это отладчик для проекта LLVM, который сейчас используется Apple и Xcode для сборки программ. Отладчик LLDB позволяет подключаться к процессу, прерывать выполнение программы и воздействовать на её память. Для этого отладчик имеет множество команд, некоторые из которых станут героями сегодняшнего повествования. Именно благодаря отладчику LLDB у нас в принципе есть такая замечательная возможность отлаживать программу, в частности устанавливать брейкпоинты. Начнём мы с самой известной команды — po. Наверняка многие из вас уже не раз использовали эту команду при отладке, но для меня в своё время это стало открытием, хотя я уже имел некоторый опыт в разработке под iOS на тот момент. Po — это сокращение от print object. Команда позволяет вычислить выражение из правой части от команды и распечатать в консоли результат выполнения. При этом у объекта запросится его debugDescription, если он определён, или просто description, если нет. У po существует команда-прародитель — print, или p, которая точно так же вычислит выражение и распечатает результат, но только в этом случае вам будет доступна сырая информация об объекте или скалярном типе. Обе эти команды будут компилировать введенное выражение в текущем контексте, что неминуемо замедлит выполнение кода при срабатывании брейкпоинта. К счастью, в Xcode 10.2 Apple добавили ещё одну команду отладчика — v, которая работает значительно быстрее. Она позволяет вывести в консоль значение переменной из текущей области видимости, но, в отличии от p и po, без компиляции выражения. Естественное ограничение, накладываемое этой особенностью, — вывод в консоль возможен только для хранимых свойств.

Affecting execution flow

Такая комбинация (брейкпоинт + debugger command po + автоматическое продолжение) заменит нам описанную ранее Log message. Что же ещё мы можем сделать с помощью такой комбинации? Например, с помощью дебаггера мы можем пропустить выполнение нескольких строчек кода, будто они закомментированы. При этом вам не нужно пересобирать программу и заново воспроизводить условия. Для этого достаточно ввести thread jump --by 1 для скачка вперёд на одну строчку или же thread jump --line 44 для перехода, как вы уже могли догадаться, к 44 строчке. Но будьте осторожны — вы не можете на 100% безопасно перепрыгивать по строчкам. Дело в том, что вы можете перепрыгнуть через инициализацию некоторой переменной, и это вызовет краш. Дело осложняется тем, что Swift «ленив» по своей природе, и инициализация может происходить не там, где вам кажется. Плюс компилятор при сборке вашей программы вставляет дополнительные инструкции, например для управления памятью, пропуская которые вы рискуете получить в лучшем случае утечку, в худшем — краш.

Affecting debugger

Кроме влияния на вашу программу, с помощью отладчика вы можете влиять на сам отладчик. Например, мы можем поставить брейкпоинт из брейкпоинта. Вы спросите, зачем это нужно? Бывают методы общего назначения, которые срабатывают по ряду триггеров. Например функция по отправке сообщения в аналитику может вызываться сотню раз в секунду, а нам нужно отловить именно ту отправку, которую породит нажатие на кнопку. В этом случае мы можем поставить брейкпоинт на метод нажатия кнопки и добавить команду установки брейкпоинта на произвольной строке программы в произвольном файле. Команда bp s -o -f Calc.swift -l 44 расшифровывается как breakpoint set one-shot на файл Calc.swift на строку 44. Модификатор -o или --one-shot создаст специальный тип брейкпоинта, который «живёт» ровно до момента своего срабатывания, а после исчезает. Таким нехитрым способом мы можем создавать интересные алгоритмы установки брейкпоинтов для отладки нетривиальных багов.

Other breakpoints types

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

Это позволяет использовать 6 дополнительных типов брейкпоинтов:

1. Swift Exception брейкпоинт — брейкпоинт, останавливающий программу при срабатывании не перехваченного throw для Swift кода.
2. Exception брейкпоинт — то же самое, но для мира ObjC. Может показаться, что это не актуальный в современном мире брейкпоинт, но это не так. Стоит помнить, что нам пока всё ещё нужен UIKit, написанный на ObjC, ошибки которого мы можем отловить с помощью такого вот брейкпоинта.
3. Symbolic breakpoint — позволяет останавливать процесс выполнения программы при выполнении кода, ассоциированного с некоторым идентификатором, который Apple называет символом. О символах я расскажу чуть позже.
4. OpenGL ES Error брейкпоинт — брейкпоинт, останавливающий программу при возникновении ошибки OpenGL при разработке соответствующих приложений.
5. Constraint Error breakpoint — очевидно, остановит вашу программу при возникновении ошибки автолейаута.
6. Test Failure breakpoint может вам помочь при отладке тестов.

Так как уместить в этой сессии обзор всех типов точек останова не представляется возможным, я остановлюсь только на самых часто используемых. По своему опыту — я всегда использую Exception breakpoint. Довольно часто при разработке программ я сталкиваюсь с перехваченными системными исключениями, отладить которые порой проблематично из-за крайне неинформативного call stack’а. Думаю, вы сталкивались хоть раз с такой или подобной ошибкой:

Exception breakpoint

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

1. Проект.
2. Воркспейс.
3. Пользователь.

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

Symbolic Breakpoint

Вторым часто используемым типом брейкпоинтов является Symbolic Breakpoint. Ранее я уже писал, что этот брейкпоинт позволяет останавливать программу при выполнении кода, ассоциированного с каким-то символом, и обещал рассказать подробнее про символы. Так вот, символы — это человекопонятные идентификаторы, которые ассоциируются с тем или иным адресом в памяти. LLDB умеет маппить известные ей символы в адреса функций и наоборот. При каждой сборке проекта система создаёт особый бандл из специальных файлов в формате dSYM, которые расшифровываются как Debug Symbols. Эти файлы хранят что-то вроде таблицы, содержащей в себе некоторые адреса методов и некоторые идентификаторы, среди которых сигнатуры методов, имена файлов, смещения и номера строк. Именно благодаря этим файлам мы можем поставить брейкпоинт на строку файла, получить читаемый стек вызова или расшифровать crashlog приложения из AppStore.

Благодаря этому механизму мы можем поставить брейкпоинт на любом методе класса, зная только его название. При этом нам не нужно достоверно знать, где этот метод объявлен и доступны ли вообще нам исходные файлы. Давайте рассмотрим реальный пример. Вас перевели на новый проект, и первая задача — исправить непонятное поведение на форме ввода данных кредитной карты, когда посреди набора фокус вдруг перепрыгивал на поле ввода имени. Сходу ничего не понятно, кода много, но симптомы ясны. Для расследования необходимо понять, кто и почему инициирует смену фокуса. Можно долго читать код, искать логику в неочевидных расширениях классов, а как надоест — сделать наследника UITextField, переопределив там метод becomeFirstResponder(), поменять реализации и уже там поставить брейкпоинт. А можно за 10 секунд создать символьный брейкпоинт -[UITextField becomeFirstResponder], и программа остановится в момент смены фокуса. По цепочке бэктрейса мы сможем легко восстановить последовательность событий, которые приводят к нежелательным результатам.

У тех, кто пользуется таким видом брейкпоинта в первый раз, наверняка возник вопрос: а что это за символ -[UITextField becomeFirstResponder]? Это ObjectiveC-сигнатура метода установки текста для лейбла. Использование ObjectiveC обусловлено тем, что UIKit написан именно на этом языке. Пара слов для тех, кто имел мало опыта с ObjectiveC. Знак минуса обозначает, что нас интересует инстанс-метод, а не метод класса, далее в квадратных скобках записывается название класса и через пробел метод, двоеточие указывает на то, что этот метод принимает параметр. Тут можно возразить, что пример притянут за уши. Я согласен — в хорошем коде не будет десятка мест с установкой текста лейбла, но моя цель — показать, как это может работать. Давайте рассмотрим более реальный пример. Допустим, для целей отладки нам может понадобиться распечатать последовательность показа вью контроллеров. Добавляем брейкпоинт с символом -[UIViewController viewDidAppear:], указываем дополнительное действие po NSStringFromClass([instance class]) и, конечно же, не забываем поставить галочку «Automatically continue after evaluating actions».

Мы снова вынуждены использовать ObjC, даже в дополнительной команде, так как находимся в его контексте. Что касается Swift, то символы записываются как название ClassName.methodName(param:). Прописывать параметры не обязательно, LLDB попытается разрешить неоднозначность, если есть методы с одинаковым названием, но разными параметрами.

Рассказывая о символьных брейкпоинтах, я не могу не рассказать о возможности искать символы. Остановив программу любым способом, с помощью брейкпоинта или же просто нажав на пиктограмму паузы, мы можем воспользоваться командой image lookup -r -n и найти интересующие вас символы в вашей программе и во всех загруженных библиотеках. Это действительно делает вас чуть ли не богом дебага, потому как вы властны искать символы везде, скажем в UIKit’e, искать приватные методы, останавливать и изучать внутреннее устройство системных библиотек. Надеюсь, я убедил в вас в силе этого метода и он не раз поможет вам сэкономить время.

Watchpoints

Вотчпоинты позволяют останавливать программу, когда изменяется значение переменной. Корректнее будет сказать, что этот механизм позволяет следить за изменениями памяти по заданному адресу с заданным размером, но благодаря LLDB и Xcode разработчику достаточно сделать несколько кликов. Использование вотчпоинтов будет удобным, когда за изменением переменной не следует никакого сайд-эффекта прямо после изменения, но её состояние важно для отложенных вычислений. В ряде случаев может быть непонятно, что инициирует это изменение, и вотчпоинты позволят быстро узнать это. Достаточно приостановить выполнение программы в контексте нужного класса и воспользоваться окном Variables View. Тут будут перечислены переменные в текущем фрейме, доступные к отлаживанию. В крупных проектах вычисление доступных переменных и их типов может занимать некоторое время, поэтому иногда нужно подождать несколько (десятков?) секунд перед тем, как переменные будут доступны к манипуляциям над ними. Приятным бонусом является возможность «заглянуть» внутрь объектов Objective-C: функциональность Variables View позволяет увидеть приватные переменные этих объектов. По клику правой кнопки мыши по переменной нам доступно не так много опций — мы можем изменять значение переменных скалярных типов и, собственно, добавлять вотчпоинты.

Конечно же, вотчпоинт можно установить и командой LLDB: watchpoint set variable <variable_name>, или, пользуясь функцией сокращения команд LLDB, просто: w s v <variable_name>, но помните, что переменная должна быть видна отладчику, то есть находиться в текущем фрейме. Помимо установки брейкпоинта на изменение переменной, нам доступна установка вотчпоинта на область памяти: watchpoint set expression -- 0x0d78ab5ea8. В обоих случаях при изменении содержимого памяти по отслеживаемому адресу произойдет прерывание программы. Установленные точки останова можно посмотреть командой watchpoint list или в Debugger navigator. Так как любые вотчпоинты в итоге следят за адресом памяти, они становятся неактуальны после перезапуска и не сохраняются между перезапусками приложения. Даже если вы установили брейкпоинт на изменение переменной, под капотом механизм lldb вычислил её адрес и поставил вотчпоинт по этому адресу.

Affecting state

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

Memory graph

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

На самом деле — всё, что угодно. Тут нам на помощь приходит мощь ObjC. Мы можем написать [0x7fafffa54a5 setValue:[UIColor redColor] forKey:@"switchedOffColor"] — и мы уже поменяли значение цвета выключенной лампы на красный, используя стандартные методы NSObject, доступные нам из коробки. Но что, если нам недостаточно этих методов, а нужно «дёрнуть» за свои рычаги? Всё просто — мы можем использовать кастинг: [(MyLamp *)0x7fafffa54a5 powerOff]. Используя подобные техники можно воздействовать на любые сервисы, менеджеры и вью модели вашего приложения в любой момент времени. Мы можем сохранить значение этого адреса в переменную для удобства: (MyLamp *)$lamp = 0x7fafffa54a5. Важно, что название переменной должно начинаться со знака доллара. Это переменная будет жить до полной остановки программы, то есть ей можно пользоваться не только в текущем сеансе отладки, но и при следующем прерывании программы в рамках одного запуска. ObjectiveС предоставляет поистине широкие возможности для того, чтобы похакать текущее состояние и обойти многие ограничения, но что делать с классами, доступными только в Swift? Конечно же, при попытке кастинга Swift-класса в ObjC-контексте ничего не произойдёт. К счастью, в Swift есть подобный механизм. Точнее, функция, имя которой — unsafeBitCast. Мы вправе использовать его с адресом: unsafeBitCast(0x7fafffa54a5, to: MySwiftLamp.self) и получить экземпляр класса MySwiftLamp по адресу. Помните, её использование небезопасно, о чём нам намекает её имя, и её крайне осторожно нужно применять в коде приложения. Хотя, когда вам осознанно нужно будет использовать эту функцию, вы будете достаточно опытны для таких предупреждений.

View Hierarchy

Рядом со инструментом Debug Memory Graph соседствует другой, не менее полезный инструмент, — View Hierarchy. Он позволяет быстро найти нужную View, посмотреть её параметры и лейаут, посмотреть активные и неактивные констрейнты. С iOS 11 этот инструмент ещё научился отображать ViewController’ы в иерархии, таким образом находить нужную View стало легче. Неочевидным тут является возможность фильтрации по имени и возможность отключить/включить отображение View, скрытых за экраном. Также я обратил внимание, что редко кто пользуется панелью управления внизу окна визуального отображения View.

Кроме того, что она может регулировать глубину просмотра иерархии, она позволяет указать «включить отображение обрезанного контента» и «включать отображение констрейнтов». Обязательно поиграйтесь со всеми инструментами, я уверен — вы найдете полезное для себя применение для некоторых из них. Но в рамках этого рассказа нам нужна только возможность найти нужную View и узнать её адрес. Далее действуем по накатанной: po unsafeBitCast(0x7fafffa54a5, to: UIView.self), но в таком случае мы получим ошибку. Мы сейчас находимся в контексте ObjectiveC и не можем использовать po со Swift-кодом. Мы вынуждены использовать команду expession, или просто e с указанием языка: e -l Swift -- unsafeBitCast(0x7fafffa54a5, to: UIView.self), но и тут наши попытки не увенчаются успехом, мы получим ошибку error: <EXPR>:3:35: error: use of unresolved identifier 'UIView'. Это произойдет из-за модульной природы Swift’а. Для успешного выполнения операции нам потребуется сделать импорт модуля UiKit: e -l Swift -- import UIKit, и после этого мы наконец добьёмся результата: e -l Swift -- unsafeBitCast(0x7fafffa54a5, to: UIView.self).

Ура! Мы получили описание в консоли. Теперь давайте попробуем поменять, скажем, цвет её бэкграунда. Для начала сохраним View в переменную, чтобы облегчить процесс доступа к ней. Как и в случае с ObjectiveC, при создании переменной в LLDB контексте её название должно начинаться со знака доллара: e -l Swift -- let $view = unsafeBitCast(0x7fafffa54a5, to: UIView.self), далее мы можем применить необходимые изменения: e -l Swift -- $view.backgroundColor = .red. Чтобы увидеть изменения, необходимо продолжить выполнение программы. Но есть способ увидеть изменения и без этого, находясь в режиме «паузы». Дело в том, что мы не видим изменения не потому, что приложение приостановлено, а потому, что все изменения UIView копятся в транзакцию CALayer и применяются только в конце «вращения» текущего RunLoop’а с помощью вызова CATrasaction.flush(). Когда приложение приостановлено для отладки, операционная система всё ещё живёт своей жизнью, вы можете свернуть это приложение и открыть другое. Операционная система всё ещё опрашивает состояние UI вашего приложения и отрисовывает ваше приложение несколько десятков раз в секунду, только RunLoop приостановлен, CATrasaction.flush не вызывается, изменения не применяются. Да, достаточно сделать вызов e -l Swift -- CATrasaction.flush(), и мы увидим изменения.

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

Свойство не определено

Этот код выдаёт ошибку «Uncaught TypeError: Cannot read property ‘lucky’ of undefined». Дело в том, что объект girl не имеет свойства named, хотя у него есть свойство name. Поскольку свойство girl.named не определено, мы не можем получить к нему доступ, то есть оно просто не существует. Если мы заменим girl.named.lucky на girl.name, то код вернёт нам «Lucky».

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

Отладка ошибок TypeError

Ошибки типа TypeError появляются, когда вы пытаетесь выполнить действия с данными, которые не соответствуют нужному типу, например применяете .bold() к числу, запрашиваете свойство undefined или пытаетесь вызвать как функцию что-то, не являющееся функцией. Например, вы увидите такую ошибку, если вызовете girl(), поскольку это объект, а не функция. В последнем случае вы получите «Uncaught TypeError: yourVariable.bold is not a function» и «girl is not a function».

Для отладки этих ошибок надо разобраться с переменными. Что такое girl? И что такое girl.named? Вы можете понять это изучая код, выводя переменные с помощью console.log, используя команду debugger или просто напечатав имя переменной в консоли. Удостоверьтесь, что вы можете манипулировать содержащимся в переменной типом данных. Если тип данных не подходит, модифицируйте его нужным образом, добавьте условие или блок try..catch, чтобы контролировать выполнение операции, или используйте эту операцию на другом объекте.

Переполнение стека

Если верить авторам песни «Baby One More Time», слово «hit» в строчке «Hit me baby, one more time» означает «позвони», то есть Бритни хочет, чтобы её бывший позвонил ей ещё раз. Это, возможно, приведёт к ещё большему количеству звонков в будущем. По сути это рекурсия, которая может вызвать ошибку в случае переполнения стека вызовов.

Конкретные сообщения об ошибке зависят от браузера, но выглядят они примерно так:

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

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

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

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

Исправить это можно примерно так же, как и предыдущий пример.

Отладка бесконечных циклов и рекурсий

Для начала, если возникла проблема с бесконечным циклом, закройте вкладку, если вы пользуетесь Chrome или Edge, или окно браузера, если у вас Firefox. Затем просмотрите код: есть ли там что-то, что создаёт бесконечный цикл или рекурсию. Если ничего не обнаружили — добавьте в цикл или функцию команду debugger и проверьте значение переменных на нескольких начальных итерациях. Если они не соответствуют ожидаемым, вы это обнаружите.

В приведённом выше примере стоило бы добавить debugger самой первой строкой функции или цикла. Затем нужно открыть отладочную вкладку в Chrome и изучить переменные в Scope. С помощью кнопки «next» можно проследить, как они меняются с каждой итерацией. Обычно это помогает найти решение проблемы.

Здесь можно найти руководство на английском языке по отладке с помощью Chrome’s DevTools, а здесь — для Firefox.

Ошибка синтаксиса

SyntaxError — вероятно самая распространённая разновидность ошибок в JavaScript. Эти ошибки возникают, если вы не соблюдаете правила синтаксиса языка. Копируя посыл песни Бритни «Everytime», JavaScript говорит отсутствующим скобкам и кавычкам: «Вы нужны мне, крошки».

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

Теперь, вооружившись новыми навыками отладки, вы станете немного сильнее в JavaScript, чем были вчера.

Группировка логов

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

У этого приёма есть три метода: console.group('name') отмечает начало группировки, console.groupEnd('name') отмечает окончание, а console.groupCollapsed() создаёт группу в виде скрытого дерева.

Трассировка стека

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

Счётчик вызовов

Функция console.count() возвращает количество раз, когда её вызывали. Учтите, что если вы измените строку лога, отдаваемую функции, счётчик обнулится и начнёт отсчёт для новой строки. Также есть функция сброса счётчика console.countReset().

Таймер в консоли

Команды console.time() и console.timeEnd() позволяют соответственно начать и остановить отсчёт времени. В основном это нужно для проверки производительности. Также можно передать функциям строку для создания специфического таймера.

Работа с логическими выражениями

Допустим, вам нужно проверить, приняло ли какое-то выражение значение false и записать это в лог. В обычной ситуации можно использовать условный оператор if, но в нашем случае куда лучше подойдёт функция console.assert(). Функция принимает в качестве аргумента выражение, а также сообщение либо объект.

Профилирование

Как часто вам приходило в голову, что стоило приступить к профилированию сразу, вместо оттягивания до последнего и ручного поиска той функции, с которой и стоило начать? console.profile() призвана помочь с этим. После завершения профилирования просто вызовите эту функцию.

Метка времени

Функция console.timeStamp() добавляет событие в таймлайн во время записи. Можно использовать, например, по окончании процесса обработки данных или для того, чтобы поймать момент возвращения вызова API. В качестве аргумента функция принимает название какого-либо события.

Очистка консоли

Простейшая функция console.clear() очищает консоль.

Чтение размера буфера

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

Пользовательская таблица

Функция console.table(), принимающая в качестве аргумента массив, выводит небольшую удобную таблицу, с которой можно взаимодействовать. Для вызова нужно передать ей массив объектов.

Заключение

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

Порядок работы SapFix

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

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

• вызывает ли оно ошибки компиляции;
• продолжаются ли сбои;
• вызывает ли решение новые сбои.

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

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

Развитие инструмента

Facebook пока еще дорабатывает эту технологию, поэтому не рекомендует ее применять в тех же масштабах, что и Sapienz. Однако команда разработчиков доложила, что в процессе тестирования инструмента, с августа 2018 года, система SapFix уже успешно создала и внедрила несколько патчей.

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

Технологию Sapienz Facebook представила в мае 2018 года на конференции F8, но для тестирования Android-клиента Facebook ее применяли с осени 2017 года. По словам разработчиков, система уменьшает время на исправление ошибок до нескольких часов и даже минут.

Исходники доступны на GitHub. Всё написано и скомпилировано на Linux x86_64.

Прим.перев. В этой статье используется устаревшая версия Python 2.

Подготовка

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

Здесь используется системный вызов ptrace для присоединения к дочернему процессу и его остановки. Теперь process содержит много удобных методов. Идея была заимствована из примера в документации python-ptrace.

Считываем значения

Начнём с простого. Получаем регистры:

Считываем байты из памяти:

Ассемблерный REPL

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

Одиночный шаг:

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

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

process.singleStep() неблокирующий, поэтому для удобства мы добавим блокирующую версию:

Так делать не стоит, но пусть process пока побудет глобальной переменной.

Пишем в память. В ассемблере выполнение ассемблерной инструкции int3 приводит к тому, что процессу отправляется сигнал SIGTRAP. Её можно записать в виде одного байта 0xCC:

Также мы можем сравнить регистр rip до и после, чтобы проверить, что значение увеличилось ровно на 1.

Устанавливаем регистр:

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

Здесь мы перезаписываем байты перед указателем на инструкцию с помощью instr, делаем шаг и возвращаем перезаписанные байты и позицию указателя инструкции. Последнюю часть делаем, только если указатель на инструкцию не изменялся (как в случае с jump или call).

При помощи таблицы преобразования ассемблерных инструкций в байты мы можем поместить это в цикл и сделать REPL.

Вызов функции, первая попытка

Что делать, если мы хотим вызвать ассемблерную функцию и приостановить выполнение после возвращения из неё?

Напишем для этого func_call(func_addr) (запустите её пошагово, чтобы посмотреть на промежуточные состояния). Сначала сохраним часть текущего состояния:

Мы могли бы просто использовать run_asm с инструкцией call. Это байт 0xE8, за которым следуют 5 байт little endian, описывающих разницу между текущим и целевым значениями rip.

Чтобы приостановить дочерний процесс после вызова, мы можем записать int3 (байт 0xCC) после инструкций вызова:

Мы можем перепроверить, что вызов был совершён:

Теперь пусть процесс работает, пока не будет получен сигнал SIGTRAP (желательно тот, что мы установили):

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

Получаем адрес функции

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

А теперь сам вызов:

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

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

Пока что мы можем это сделать следующим образом. С регионами памяти и /proc/pid/maps разберёмся чуть позже:

Ставим точки останова

Теперь у нас есть адреса функций и мы можем поставить точку останова, просто написав int3 (байт 0xCC) в начале функции:

И восстановить перезаписанное значение после прохождения точки останова:

Эти функции можно использовать следующим образом:

Вызов функции, вторая попытка

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

Слишком большое расстояние вызова. call (0xE8) принимает в качестве аргумента только 5 байт, однако для описания адреса (diff) может потребоваться 8 байт. Мы можем либо подождать, пока не окажемся в пределах функции, которую хотим вызвать (это работает только в том случае, если нам не нужно вызывать функцию сразу же), либо поместить целевой адрес в регистр, например, rax, и воспользоваться инструкцией call rax (байты FF D0).

Перезаписанные байты. Так как мы перезаписываем 7 байт (6 для call, один для int) и восстанавливаем их только после возвращения из функции, то в случае попытки их чтения из другого места можно получить неожиданные значения. Например, если мы совершили вызов внутри тела функции и выполнение программы снова доходит до old_rip.

В теории мы могли бы восстановить 6 из 7 байт после одного шага, оставив только 0xCC. Однако это не решает проблему, а только уменьшает её размер.

Ещё мы могли бы вручную создать стековый кадр.

Вместо этого мы зарезервируем новый участок памяти и запишем наши инструкции туда.

Выделяем память

Мы можем использовать системный вызов mmap() (номер вызова 9) для резервирования памяти. Ему требуются некоторые магические константы, часть которых можно найти в ptrace.syscall:

С помощью следующей функции мы можем вызвать mmap. Здесь syscall представлен байтами 0F 05:

Данная стратегия была позаимствована из этого примера. Для справки, вот константы:

Адрес зарезервированной памяти находится в rax после вызова, поэтому мы его извлекаем и возвращаем.

Это позволяет нам изменить вызов функции, сделав его немного безопаснее:

Тем не менее, в этой функции по-прежнему могут возникать ошибки сегментации.

Получаем следующие инструкции

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

Воспользуемся методом PtraceProcess.disassemble для получения итератора по следующим десяти инструкциям:

Запуск этой функции даст примерно следующий результат:

Метод PtraceProcess.dumpCode работает похожим образом, но с другим форматированием.

Итог

На этом пока всё. В следующей статье мы разберёмся с чтением/записью Си-переменных, запуском одиночных Си-команд, библиотеками общего пользования, динамической загрузкой и картами памяти (/proc/pid/maps).

Отладка Python-кода с помощью print

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

Но самая большая проблема в использовании print() – это необходимость вносить изменения в код и перезапускать приложение, чтобы увидеть изменения. Давайте разберёмся, почему отладчики эффективнее.

Команды Python-отладчика

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

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

Python есть встроенный отладчик под названием pdb. Это простая консольная утилита, которая обладает основной функциональностью для отладки кода. Но если вы ищете что-то более продвинутое, то стоит обратить внимание на ipdb – отладчик с функциональностью из IPython.

Проще всего вызвать отладчик pdb из кода, где вы работаете:

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

list()

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

up(p) и down(d)

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

step() и next()

Другая пара не менее важных команд. С их помощью можно выполнять код построчно. Единственное различие между ними в том, что next() перейдёт к следующей строке вне зависимости от вызываемых функций, а step() перейдёт в вызванную функцию, если это возможно.

break()

Эта команда позволяет создавать брейкпоинты без внесений изменений в код. Ниже разберём этот этап более детально.

Краткий список команд отладчика pdb:

• args() — выводит аргументы функции;
• continue() или (cont) — продолжит выполнение до первого брейкпоинта или до завершения программы;
• help() — выводит список доступных команд или подсказки по определённой команде;
• jump() — перепрыгивает к выполнению указанной строчки кода;
• list() — выводит исходный код программы вокруг выбранной строки;
• expression() — выводит значение выражения;
• pp — выводит значение в «красивом» виде;
• quit или exit() — отменяет выполнение программы;
• return() — завершает выполнение текущей функции.

Продолжаем изучать Python-отладчик

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

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

Давайте разберём на примере. Есть простое приложение, которое отслеживает рабочее время. Для её работы используется библиотека requests, отвечающая за выполнение HTTP-запросов. Попробуем прервать выполнение во время запроса. Как это сделать? Запустим приложение через отладчик и установим брейкпоинт внутри библиотеки requests.

Как можно заметить, не нужно указывать полный путь до библиотеки. Можно указать относительную ссылку от sys.path. Таким же образом можно отлаживать и ваше приложение.

Теперь куда проще отлаживать код. Не надо вносить изменения в приложение или во внешние библиотеки.

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

В данном примере прерывание произойдёт только в случае, если json будет иметь в себе ключ time_entry.

Отладка кода Django

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

Если вы хотите прокачать отладчик, то установите django-extensions и используйте команду runserver_plus для запуска сервера. Также можно указать пароль для доступа к отладке следующей командой:

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

Если вы используете django-extensions, то получите страницу со всеми вызовами, кодом и окном отладчика.

Процесс отладки осуществляется с помощью WSGI библиотеки Werkzeug.

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

Зачем нужен Sonar?

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

Новый отладчик позиционируется как средство объединения знаний о структуре приложений. На его создание команду Facebook вдохновил Stetho, входящий в состав средств разработки Chrome. Создатели Sonar снабдили новый продукт более понятным интерфейсом, поддержкой плагинов и платформ Android и iOS.

Facebook выделила три полезные возможности Sonar:

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

Как устроен отладчик?

Sonar состоит из двух частей: настольного клиента и мобильного SDK. Первый основан на open source проектах React.js, Flow, Metro, RSocket и Yarn, второй — на Folly и RSocket. Пользователи взаимодействуют с настольным клиентом, а SDK внедряется в разрабатываемое приложение и передает данные для отладки.

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

Для расширения возможностей Sonar необходимо написать плагин для обеих частей. Клиентская часть требует только компонент React для связи с SDK. Мобильный плагин для iOS разрабатывается на языке Swift или Objective-C, а для Android — на Java или Kotlin. Он выполняет роль серверного приложения для обработки клиентских запросов: регистрирует набор обработчиков и определяет ответы для них.

Более подробную инструкцию по использованию Sonar можно найти в документации.

Facebook часто открывает для разработчиков новые инструменты. В марте 2018 года она представила программный интерфейс Games SDK для создания игр с поддержкой С++ и Unity.

Создание простого приложения

Примечание В качестве примера рассматривается простое Node-приложение. Представленные здесь принципы могут быть легко адаптированы к другим языкам программирования, например, Python, Go или .NET Core.

Создаем директорию проекта и в терминале перемещаемся в нее. Выполняем команду:

На вопрос о точке входа (entry point) вводим server.js и на вопрос о тестовой команде (test command) отвечаем jasmine-node spec . Остальные вопросы можно пропустить, оставив значение по умолчанию. По завершении работы этой команды будет создан файл package.json, который должен выглядеть примерно так:

Наше приложение будет использовать Express JS. Установим пакет командой:

Теперь создаем файл server.js, который будет содержать следующий код:

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

Добавляем Dockerfile

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

Обратите внимание, что в строке 3 мы устанавливаем jasmine-node, который нужен для запуска тестов. Также мы открываем не только порт 3000, но и порт 5858. Последний будет использоваться для присоединения отладчика. Также обратите внимание на то, что мы сначала копируем package.json в образ и запускаем npm install, и только после этого копируем оставшуюся часть папки приложения. Это помогает нам оптимизировать сборку Docker-образа.

Запуск приложения в контейнере

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

Примечание Не забудьте указать точку в конце команды.

Теперь мы можем получить контейнер из этого образа:

Мы должны увидеть длинный ID (хеш-код), который выводится в терминал. Чтобы повторно убедиться, работает ли контейнер, мы можем использовать команду docker ps, и должны увидеть следующее:

Если по какой-либо причине контейнер не создался, мы можем просмотреть логи создания командой docker logs my-app:

Добавляем тесты

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

Теперь настроим несложный тест. Создайте папку spec и добавьте в нее файл primes-spec.js со следующим содержимым:

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

Как только мы определили тест, выполним эту команду в терминале:

Эта команда вызывает Jasmine-node, который мы определили в package.json. Вывод будет примерно такой:

Также мы можем добавлять новые тесты в приложение. Для этого нам нужно добавить модуль require:

Теперь добавьте файл с именем server-spec.js в папку spec. Он должен иметь такое содержание:

Теперь мы можем снова запустить все тесты: npm test.

Давайте запустим тест в контейнере. Для этого используется docker-compose. Добавим файл docker-compose.test.yml в проект:

Этот yaml-файл содержит инструкции по созданию образа контейнера с использованием Dockerfile, открытии порта 3000 и сопоставлении его с портом 3000 на хосте. Наконец, переопределяем значение entrypoint. Теперь в терминале введите следующую команду:

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

Здесь создается Docker-контейнер и выполняются все тесты. Тесты, которые прошли успешно, возвращают код 0. Мы можем остановить тестирование командой:

Отладка приложения

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

Примечание В данном примере используется Visual Studio Code. Но эти действия можно совершить в большинстве современных редакторов.

Для начала нам нужно узнать, на каком IP-адресе находится хост Docker. Выполним команду:

Добавим в проект файл docker-compose.debug.yml со следующим содержимым:

Подобно файлу docker-compose для тестирования, мы используем Dockerfile для создания образа, открываем порт 3000 и порт 5858, сопоставляем их с теми же портами на хосте. Наконец, мы переопределяем точку входа node --debug = 5858 server.js. То есть запускаем узел в режиме отладки, прослушивая порт 5858. Мы можем начать сеанс отладки, используя эту команду:

В качестве последнего шага нам необходимо настроить Visual Studio Code для присоединения к Node-приложению, запущенному в контейнере. Добавим папку .vscode в наш проект. Внутри этой папки мы добавляем файл launch.json.

Содержимое файла должно быть следующим:

Обратите внимание на раздел с именем Attach. Вы должны убедиться, что в поле address командой docker-machine ip default указан IP-адрес вашего Docker-хоста.
Как только была добавлена конфигурация запуска, мы можем щелкнуть по кнопке отладки. Убедитесь, что выбрана настройка Attach, а затем нажмите кнопку запуска.

Теперь добавьте точку останова в строку 7 файла server.js. Откройте браузер и перейдите к 192.168.99.100:3000 (замените IP-адрес своим, если у вас другой). Отладчик должен остановиться в строке 7:

В окне отладки мы видим всю отладочную информацию:

Итог

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

Прежние технологии устарели

Предыдущий отладчик базировался на XML User Interface Language (XUL) — собственной разработке Mozilla. Со временем стало ясно, что архитектура приложения построена так, что даже малейшие изменения отладчика требуют серьёзных усилий. В результате его было решено переписать с использованием React и state-контейнеров Redux. Новый отладчик разбит на модули, которые удобно тестировать и поддерживать.

От XUL же Mozilla стремится избавиться как можно скорее. В настоящий момент все дополнения для Firefox используют именно его, однако начиная с версии 51 (стабильный релиз намечен на 24 января 2017) у разработчиков появится возможность использовать в качестве альтернативы API WebExtensions. Постепенно возможности использования XUL будут урезаться, и к концу 2017 года в Firefox уже не будут поддерживаться дополнения, базированные не на WebExtensions. Хорошая новость в том, что благодаря этому все дополнения будут совместимы с браузером Chrome.

Захват новых рынков?

В отличие от старого отладчика, новый может использоваться как самостоятельный продукт, Firefox ему не нужен. Уже сейчас в качестве экспериментальной возможности отладчик поддерживает работу с Chrome и Node.js.

Но всё же пока сыровато…

Как отмечают пользователи в комментариях на reddit, до стабильной и удобной в использовании версии отладчику пока ещё далеко. Так, например, в нём отсутствует следующий необходимый любому JS-разработчику функционал:

• остановка по событиям с элементами страницы;
• подсветка и исследование элементов страницы;
• Проверка, изменение, и отслеживание переменных;
• black box a source — сокрытие части исходного кода (например, библиотечного);
• поиск по всем файлам;
• переход к указаной строке;
• фильтрация отображаемых переменных.

Разумеется, в последующих выпусках все эти возможности планируется добавить, но пока отладчик Mozilla совсем не конкурентоспособен. Стоит помнить, однако, что актуальная версия Firefox сейчас — 50.0.1, а релиз 52-й версии назначен на март 2017 года — мы надеемся, что к тому времени отладчик будет выглядеть более привлекательно.

Скачать Firefox 52 Developer Edition можно с официального сайта, а посмотреть исходный код отладчика — на GitHub.

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

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

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

Это было странно. Почему не видно красный куб? Я проверил фрагментный шейдер. Я проверил режимы рендеринга. Я даже проверил настройки шаблона. Всё было хорошо. Но почему тогда мой куб не видно?

Я сделал его опять красным, и знаете что? Он появился! Я вернулся в самое начало, но теперь куб было видно! Ошеломленный, я отвел взгляд от монитора. Когда я посмотрел обратно, он опять исчез. Потом появился. Потом опять исчез. И тут меня осенило.

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

Новые технологии и простота изменений

Одна из причин выпуска нового дебаггера — сложности с выпуском обновлений для старого. Причиной этому является использование в нём XML User Interface Language (XUL), который в итоге сделал добавление даже малозначительных изменений непростым делом. В новой версии было решено использовать более современную архитектуру, основанную на компонентах React и state-контейнере Redux. В итоге новый отладчик разбит на множество модулей, которые легко поддерживать, дорабатывать и тестировать.

Возможность использования без Firefox

Mozilla планирует, в первую очередь, использовать дебаггер в браузере Firefox (и отладчик уже включён в ночные сборки). Однако использование новых технологий, которые поддерживаются везде (в отличии от XUL, который был разработан Mozilla и фактически только ими и поддерживался), позволило добавить в отладчик поддержку работы с Chrome и даже Node.js (сейчас это является экспериментальной возможностью).

Удобный интерфейс

Интерфейс отладчика разделён на три основные части: панель с деревом проекта, панель редактора и вертикальное меню справа. Дерево проекта отображает все части проекта, которые отлаживаются в настоящий момент. Панель редактора отображает код, который рассматривается в настоящий момент, и позволяет устанавливать точки остановки (breakpoints). Меню справа позволяет просматривать точки остановок, которые назначены в настоящий момент, просматривать стек вызовов и список переменных.

Свободное программное обеспечение

Код отладчика доступен на GitHub и распространяется по свободной лицензии Mozilla Public License v2.0.

Больше технических деталей вы можете узнать из поста Брайана Кларка (технического менеджера Mozilla) или из документации в репозитории.

Отладка программ очень похожа на работу следователя. Выследить ошибку по косвенным признакам, поставить эксперимент, доказать вину и устранить. Программист — как Шерлок Холмс!

Прим. редакции.: в 2004 году вышла отличная книга Debugging by Thinking: A Multidisciplinary Approach (HP Technologies), в которой описываются этот и многие другие «стили» отладки.