Не Ruby единым

Новость:

Ведущий разработчик Александр Бугаев – один из Ruby-евангелистов в EPAM. Ему нравятся сложные задачи, он готов работать по ночам, творить дома или на хакатонах. Александр рассказал о своем авантюрном пути в программировании. О новых Ruby on Rails-проектах уровня enterprise, которым нужны разработчики. А также о том, почему не бывает универсальных решений.

Как люди становятся хорошими инженерами? Давай на твоем примере вспомним все предпосылки.

В деревне у бабушки, куда меня часто «ссылали» на все лето, было скучно. Поэтому я развлекался тем, что строил космические корабли из Lego. Собственный компьютер появился только в 19 лет в качестве бонуса за поступление на мехмат БГУ по специальности «Банковское дело». До этого родители из принципа не покупали никакой техники.

В университете постиг основы программирования на C++ и Java – правда, только на уровне написать цикл и вывести на экран. Такие задачи не вызывали у меня большого интереса, поэтому сначала  совсем не планировал уходить в программирование. Но перспектива работать по профилю и заниматься финансовыми просчетами тоже не вдохновляла: дресс-код, закрученные гайки – все это казалось унылым. Однажды случайно услышал об open source-проектах и Linux-системах как альтернативах Windows. Концепция меня сильно заинтересовала, и я начал самостоятельно изучать это направление.

Ввязался в авантюру – стал учить Python по руководству Google. Рассуждал так: на Python написано много софта под Linux, его использует столь крутая корпорация, а это значит, есть источник материалов о языке, на котором можно создавать собственные программы.

Как ты оказался в EPAM?

Написал наивное письмо рекрутерам на адрес почты, найденный прямо на главном сайте. Это было что-то из разряда: «Всем привет! Хочу к вам программистом на Python. Знаю кое-что по языку, но опыта нет, готов работать бесплатно и в любое время за стаж». Меня пригласили на интервью, где сказали: «Python у нас нет, зато есть Ruby – тебе понравится». До этого в других компаниях мне уже предлагали позиции .Net-разработчика, но ни фреймворк, ни рабочая атмосфера не убедили настолько, чтобы согласиться.

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

Почему, имея большой выбор языков программирования, ты больше всего заинтересовался именно Ruby?

Этот язык позволяет сконцентрироваться на задачах, а не на синтаксисе. Open source-проекты на RoR читабельны и понятны всем людям, которые им владеют. Если судить по рубистам из белорусского сообщества, которых я постоянно встречаю на конференциях и хакатонах, это просто космические люди. С ними как-то проще: может быть, синтаксис, лаконичность и динамика Ruby передается самим инженерам на генном уровне?

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

На первом проекте я работал три с половиной года. Это была крупная система, которая строилась на базе Ruby, Java, Perl и JavaScript. Все процессы были систематизированы, большие системы поставлялись на «железяках», с творчеством особо не разгонишься. Затем около полугода я писал на NodeJS фронтэнд для консольной тулзы для анализа трафика при работе с Network File System, которую EPAM «заоупэнсорсила». Был и внутренний проект EPAM University на основе открытой стэндфордской платформы по обучению, когда я работал в основном с Python, Django и базами данных. За ним следовал крупный проект на Python.

Несмотря на то, что следущих полтора года я писал только на Python и Node, на своих проектах дома и во время хакатонов активно использовал Ruby. Мне нравится настоящий мозговой штурм, когда команда не просто делает красивую презентацию в PowerPoint, а создает продукт за 24 часа. Например, на белорусском этапе хакатона LG Smart TV удалось разработать интерактивное приложение для занятий спортом. Кстати, для участия в таких ивентах даже получилось собрать небольшую команду рубистов-«хакатонеров» Crazy Lemurs.

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

Это те проекты, на которых сейчас нужны опытные RoR-разработчики?

Да. На одном из них я сейчас занят, и, пожалуй, это самая интересная инициатива на RoR за все 6 лет работы в компании. Проект связан с разработкой системы внутренней безопасности для американского заказчика. Конечные пользователи этого продукта – крупнейшие софтверные компании США. Несмотря на то, что клиент очень серьезный, атмосфера на проекте стартаперская. Сильная команда решает интересные задачи, но при этом пока нет четко выработанных процессов, а это только добавляет динамики в твою работу. Ты не просто клепаешь формы или создаешь типичные модели. Нам приходят задачи, которые до этого никто не решал, и тебе нужно самостоятельно найти разгадку, продумав все возможные последствия и проработав архитектуру. Во многом это напоминает работу Solution Architect. Поэтому мы ищем профессионалов уровня D2 и выше. Поскольку сейчас на проекте используются Ruby, RoR, Lua, Go, Java (Spark, Spring), Docker, AWS и многое другое, желательно знать все эти технологии, как бы фантастически это ни звучало. Или, если спуститься с небес на землю, иметь хотя бы широкое представление о них.

Проект имеет большую сложную структуру, куда входят микросервисы. Вопреки расхожим стереотипам, многое написано на Ruby. Кроме меня, на белорусской стороне есть еще несколько ведущих RoR-разработчиков, всего нас 5. На американской стороне RoR-команда из 8 человек еще сильнее: среди них имеется главный программист и архитектор, у которого есть патенты. Каждый день ты общаешься с такими «космонавтами», а они еще и прислушиваются к твоим советам! Это фантастика.

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

Еще один новый RoR-проект в EPAM – встраиваемая банковская система для одного из немецких заказчиков, который в свою очередь предлагает этот продукт банкам во всем мире. Насколько мне известно,  там уже есть интеграция с аравийским и немецким банками. Крупные компоненты этого проекта, например, система дашборда, написана на RoR. Сейчас это проект-монолит, который будут разделять на несколько частей, а затем синхронизировать их работу. Согласитесь, не каждый день вы распиливаете банковскую систему, чтобы при этом она еще и стабильно работала. И дело тут совсем не в Ruby. Не одним языком единым. Если человек хочет развиваться как программист, он должен уметь решать нестандартные задачи разными способами.

Есть ли правило, которому ты всегда следуешь в работе?

Не верь в универсальные решения и борись с «костылями». Приведу пример. У нас был проект, который касался сканирования уязвимости Windows-машин. Система для Windows была написана по аналогии с Linux, работала нестабильно, медленно и «выжирала» всю память. Это была классическая ошибка, когда люди смотрят на похожие решения и пытаются создать что-то подобное. То, что отлично работало для Linux, для Windows стало скрипеть колесами.

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

Кем ты видишь себя через пару лет?

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