Ведущий разработчик Александр Бугаев – один из Ruby-евангелистов в EPAM. Ему нравятся сложные задачи, он готов работать по ночам, творить дома или на хакатонах. Александр рассказал о своем авантюрном пути в программировании. О новых Ruby on Rails-проектах уровня enterprise, которым нужны разработчики. А также о том, почему не бывает универсальных решений.
Как люди становятся хорошими инженерами? Давай на твоем примере вспомним все предпосылки.
В деревне у бабушки, куда меня часто «ссылали» на все лето, было скучно. Поэтому я развлекался тем, что строил космические корабли из Lego. Собственный компьютер появился только в 19 лет в качестве бонуса за поступление на мехмат БГУ по специальности «Банковское дело». До этого родители из принципа не покупали никакой техники.
В университете постиг основы программирования на C++ и Java – правда, только на уровне написать цикл и вывести на экран. Такие задачи не вызывали у меня большого интереса, поэтому сначала совсем не планировал уходить в программирование. Но перспектива работать по профилю и заниматься финансовыми просчетами тоже не вдохновляла: дресс-код, закрученные гайки – все это казалось унылым. Однажды случайно услышал об open source проектах и Linux системах как альтернативах Windows. Концепция меня сильно заинтересовала, и я начал самостоятельно изучать это направление.
Ввязался в авантюру – стал учить Python по руководству Google. Рассуждал так: на Python написано много софта под Linux, его использует столь крутая корпорация, а это значит, есть источник материалов о языке, на котором можно создавать собственные программы.
Однажды случайно услышал об open source проектах и Linux системах как альтернативах Windows. Концепция меня сильно заинтересовала, и я начал самостоятельно изучать это направление.
Как ты оказался в EPAM?
Написал наивное письмо рекрутерам на адрес почты, надейденный прямо на главном сайте. Это было что-то из разряда: «Всем привет! Хочу к вам программистом на Python. Знаю кое-что по языку, но опыта нет, готов работать бесплатно и в любое время за стаж». Меня пригласили на интервью, где сказали: «Python у нас нет, зато есть Ruby – тебе понравится». До этого в других компаниях мне уже предлагали позиции .Net-разработчика, но ни фреймdорк, ни рабочая атмосфера не убедили настолько, чтобы согласиться.
На стажировке мне дали 500-страничную книгу по Ruby, поставили задачу и периодически проверяли, как идет прогресс. Через несколько месяцев меня, практиканта-самоучку, подпустили к настоящему проекту: разрешили поработать с простенькими багами. Вскоре я прошел собеседование у заказчика и стал полноправным разработчиком. Помогла математическая база и усидчивость.
Почему, имея большой выбор языков программирования, ты больше всего заинтересовался именно Ruby?
Этот язык позволяет сконцентрироваться на задачах, а не на синтаксисе. Open source проекты на RoR читабельны и понятны всем людям, которые им владеют. Если судить по рубистам из белорусского сообщества, которых я постоянно встречаю на конференциях и хакатонах, это просто космические люди. С ними как-то проще: может быть, синтаксис, лаконичность и динамика Ruby передается самим инженерам на генном уровне?
Если судить по рубистам из белорусского сообщества, которых я постоянно встречаю на конференциях и хакатонах, это просто космические люди.
За шесть лет в компании из стажера ты превратился в ведущего инженера. На каких проектах ты приобрел опыт?
На первом проекте я работал три с половиной года. Это была крупная система, которая строилась на базе Ruby, Java, Perl и Javascript. Все процессы были систематизированы, большие системы поставлялись на «железяках», с творчеством особо не разгонишься. Затем около полугода я писал на NodeJS фронтэнд для консольной тулзы для анализа трафика при работе с Network File System, которую EPAM «заоупэнсорсила». Был и внутренний проект EPAM University на основе открытой стэндфордской платформы по обучению, когда я работал в основном с Python, Django и базами данных. За ним следовал крупный проект на Python.
Несмотря на то, следущих полтора года я писал только на Python и Node, на своих проектах дома и во время хакатонов активно использовал Ruby. Мне нравится настоящий мозговой штурм, когда команда не просто делает красивую презентацию в Power Point, а создает продукт за 24 часа. Например, на белорусском этапе хакатона LG Smart TV удалось разработать интерактивное приложение для занятий спортом. Кстати, для участия в таких ивентах даже получилось собрать небольшую команду рубистов-«хакатонеров» Crazy Lemurs.
Мне нравится настоящий мозговой штурм, когда команда не просто делает красивую презентацию в Power Point, а создает продукт за 24 часа.
Благодаря участию в таких активностях, я ничуть не забыл язык, а сейчас дождался своего звездного часа: недавно в 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 стало скрипеть колесами.
Не верь в универсальные решения и борись с «костылями».
Взял и переписал систему за выходные «на коленках» как демо-версию. Затем команда стала ее улучшать и постепенно довела до продакшна. Мы получили экспертизу, за которую заказчик был благодарен.
Кем ты видишь себя через пару лет?
У меня страсть к новым проектам, архитектурным концепциям и решению проблем разными методами, совмещению инструментов. Поэтому в будущем вижу себя в качестве архитектора.
Автор: Volgafe87
