Ответственность за код

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

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

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

Георгий Клюковкин: Меня всегда привлекали CRUD-сервисы. Это приложения, которые представляют собой четыре основные операции для управления файлами: создание, чтение, обновление и удаление (от английского create, read, update, delete). Такие сервисы служат основой для всех сетевых приложений и систем управления данными. Затем к ним начали добавляться задачи с более высокими требованиями, такие как нагрузка, отказоустойчивость и масштаб. Мне было интересно, как это все работает изнутри и связано друг с другом. По сути, каждая такая задача - это вызов для программного инженера. Я рос профессионально и получал удовольствие от процесса. В итоге это стало моей основной сферой деятельности.

Большой пласт вашей работы посвящен асинхронным тестам. Расскажите о ней подробнее.

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

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

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

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

Сегодня много говорят о всевозможных багах и ошибках на релизе того или иного программного продукта. Изменился ли в связи с этим подход к обучению разработчиков?

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

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

Вы являетесь автором более 30 статей в научных журналах и на тематических медиа-платформах. Как выбираете темы для публикаций?

Георгий Клюковкин: Я пишу о том, чего мне самому не хватало. Если я столкнулся с проблемой, потратил день на разбор и нигде не было нормального объяснения, значит, что пора писать. Самый сильный отклик был у статей про гонки, конкурентные вызовы в языке программирования Golang и практику записи событий в файлах-журналах (логах). Люди пересылали это коллегам, ссылались в коде, включали в документы для новичков, которые только пришли в компанию.

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

Какой личный проект вы считаете наиболее важным и почему?

Георгий Клюковкин: Если говорить о прикладной пользе для бизнеса, то это разработка модели оценки медицинских рисков. Она основана на ретроспективных данных, системе весов и кубических сплайнах. Разработку применяли при количественной и финансовой оценке рисков, в сфере страхования и медицинского прогнозирования. Она стала реальным помощником для финансистов и работников системы здравоохранения. Если говорить о значении для профессионального сообщества, то это вклад в открытое программное обеспечение (open source) и технологическое просвещение.

Сейчас я работаю над инфраструктурой машинного обучения (ML) - это системы, которые масштабируют и запускают модели на финальной версии приложения. Но хочется идти глубже: в математику, в архитектуру нейросетей, в саму механику обучения. Хочу расти в сторону ML-инженерии и системной разработки в ИИ, совмещая мой опыт в распределенных системах с будущим, в котором ИИ становится неотъемлемой частью продакшена.