Константин Астапов, «Рамблер»: Наличие серьезного вклада в open-source выделяет вас на общем фоне разработчиков

CNews: Вы уже более 12-ти лет занимаетесь разработкой ПО и проработали в крупных и известных ИТ-компаниях, а также развиваете свои open-source проекты. Расскажите, какое значение вклад в open-source имеет для развития карьеры разработчика?

Константин Астапов: Это безусловно привлекает работодателей, поскольку показывает, что кодинг для вас это не просто способ заработка, но и деятельность, которая доставляет вам радость. Это показывает, что вы стремитесь делать какие-то, пусть и не очень большие, но все же улучшения для сообщества разработчиков и индустрии в целом. К этому я бы отнес не только вклад в open-source как таковой, но также и выступления на конференциях и публикацию статей на актуальные темы в разработке. Некоторые работодатели могут найти вас прямо из вашего профиля в GitHub или наткнувшись на вашу публикацию в блоге на Habr, например. Наличие серьезного вклада в open-source выделяет вас на общем фоне разработчиков, показывает, что вы не только пользуетесь технологиями, но и создаете их. Такие люди уникальны на рынке ИТ-кадров.

CNews: У вас больше 50-ти открытых проектов на GitHub, сейчас вы активно ведете разработку трех крупных библиотек. Расскажите, как вы начали свой путь в open-source разработке?

Константин Астапов: Хорошо, начну немного издалека. Изначально я работал в научно-исследовательском институте, где создавать что-то новое и инновационное было моей естественной ежедневной работой. Такова суть работы ученого. В составе группы я занимался различными актуальными научными задачами. Конкретно моя работа заключалась в написании специальных вычислительных программ для моделирования процессов в физике частиц. На основе результатов этой работы публиковались научные статьи, а весь написанный для решения задач код выкладывался на GitHub. По сути это и был мой первый вклад open-source. Позже, когда я уже стал работать в ИТ-компаниях, ситуация стала немного другой. Известно, что для компаний первоочередная цель — это разработать нужный продукт, который бы закрывал потребности пользователей и приносил прибыль, поэтому разработка open-source не стоит в приоритете для ИТ-бизнеса. Поэтому большинство разработчиков не находят время и мотивацию, чтобы заниматься этим. Тем не менее, в индустрии для решения тех или иных задач инженеры почти всегда используют готовые open-source решения. Однако с использованием популярных open-source библиотек в крупных enterprise проектах есть определенные проблемы. Эти библиотеки, фреймворки или инструменты зачастую рассчитаны на универсальное использование и поэтому часто им не хватает возможностей в узкоспециализированных ситуациях. Ведь как известно, популярные open-source библиотеки стараются закрыть более широкий спектр потребностей и тем самым они делаются более технически сложными и зачастую менее эффективными в плане производительности. Но можно преодолеть эту проблему путем создания своих технических решений, которые, во-первых, идеально подходили бы под конкретную проблему и поэтому были бы более легкими в устройстве и менее затратными в конфигурировании. Во-вторых, поскольку это собственные решения, они были бы более простыми и удобными в плане технической поддержки и возможных доработок. Поэтому те, которые могут себе это позволить, занимаются созданием собственных фреймворков, которые затем иногда попадают в open-source. Примерно так и начинался мой путь в open-source — я писал небольшие библиотеки, которые использовал для решения задач в компаниях.

CNews: Какую цель вы преследуете, когда создаете свои open-source решения?

Константин Астапов: Как я уже сказал, в мире open-source много различных решений, которые имеют большую известность, однако в больших enterprise продуктах эти решения не всегда находят применение. Зачастую разработка сложных продуктов внутри компаний и open-source решения идут разными путями. Создатели многих проектов с открытым исходным кодом идут на поводу потребностей массового пользователя, что часто идет вразрез с потребностями сложных проектов. Лично я никогда не стремился сделать что-то хайповое, не стремился делать в угоду массовой публики и трендов. Я всегда хотел решить конкретную задачу по созданию продукта для конечного пользователя, а различные ИТ-решения, которые я потом выкладывал в open-source, являлись побочным продуктом. Моя основная цель — сделать так, чтобы продукт для компании разрабатывался быстрее, работал быстрее и требовал меньше сил и средств для поддержки. Для достижения этих стратегических целей нужно решить ряд операционных задач, в частности, сделать процесс создания приложения комфортным для разработчика. Так, например, в компании Рамблер я разработал библиотеку Reflexio, нацеленную на улучшение процесса создания клиентской части веб-приложений. На основе данной библиотеки строится ядро приложения, таким образом, что оно получается хорошо масштабируемым при росте кодовой базы приложения и количества функционала.

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

Константин Астапов: Если не сильно углубляться в технические детали, то Reflexio — это по сути полноценный фреймворк, созданный на базе стейт-менеджера. Он является ядром всей концепции, а также включает расширяемую экосистему плагинов, которые, используя ядро, реализуют различный универсальный функционал, необходимый в большинстве проектов. Основное преимущество Reflexio в том, что это не просто стейт-менеджер, а скелет, на котором можно выстраивать и легко масштабировать сложные enterprise проекты. Также неотъемлемой частью концепции фреймворка Reflexio, помимо самой библиотеки и плагинов, является и специальный набор правил — конвенции. Следуя им создание приложения представляет собой последовательность понятных и предсказуемых шагов. Так весь процесс, по сути, идет как по проложенным рельсам и не требует от разработчика прибегать к сложным и нестандартным приемам. Это делает разработку более быстрой, понятной и с меньшим количеством потенциальных ошибок.

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

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

CNews: Сформулируйте основные принципы, которыми вы руководствуетесь при создании своих ИТ-решений?

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

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

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

Короткая ссылка на материал: //cnews.ru/link/a20900