Владислав Малахин о задачах разработчика
Владислав пришёл в XIAG с фриланса, чтобы научится правильным подходам в разработке, и с удивлением обнаружил, что здесь люди работают, поэтому решил остаться. К тому же Владиславу, как и его коллегам, нравится дисциплинированность в работе и нацеленность на реальные задачи. Благодаря этим качествам он стал одним из ведущих разработчиков.
За что ты зацепился, когда в первый раз пришёл в компанию?
Начну с начала. Я спокойно сидел на фрилансе. У меня в месяц выходило очень неплохо — был один заказчик с несколькими большими проектами. Всё было хорошо, пока не понадобилось глобально всё переделать: начинала расти нагрузка, появились проблемы. Я попробовал и понял, что не могу это сделать, получается какая-то ерунда. Я подумал, что самый простой способ научиться — пойти куда-нибудь, где тебя научат. Я хотел услышать: «Парень, ты очень-очень глупый. У нас в компании все гораздо лучше». Я думал, что вот туда надо идти, там меня всему научат. В этот момент я начал искать работу. Даже не с целью уйти из фриланса, а просто посмотреть, чем закончится.
Пошёл искать работу с требованиями по зарплате на уровне джуниора. К сожалению, оказалось, что найти работу за эти деньги очень тяжело: никто не хочет платить белую зарплату и чтобы ты работал только 8 часов . В итоге, оказывалось, что ты должен был работать 6 дней в неделю и больше 8 часов. При этом в таких компаниях собеседования обычно проводят директора и в то время, когда у всех раздолбанные компьютеры — у него макбук. И судя по виду, он забежал только на собеседование. Очень плохие впечатления от таких компаний. Решил изменить подход и написал зарплату в три раза больше. Это была очень хорошая зарплата на тот момент, но предложения стали гораздо более адекватные. Удивительно, но в этих компаниях никто не назвал меня дебилом. Через пару месяцев работы в XIAG решил, что фрилансить больше не хочу.
Тяжело было перейти с фриланса?
Вообще нет, мне понравилось. Приходишь, народ работает в определённое время. Хороший рабочий процесс — я вообще терпеть не могу раздолбаев, которые не работают и мешают остальным. А в XIAG все работают, адекватно себя ведут. Очень приятно было. В других местах, где я был — там раздолбаи. А тут решают задачи, живое общение, динамичный процесс — людям нравится, что они делают. У всех хотя бы подсознательно должна быть цель — сделать хорошо, а не просто приходить на работу и в конце месяца получать деньги. Нужно радоваться своей работе, в которой можно увидеть результат. Например, отрефакторил, нагрузка стала меньше — это же здорово. Если тебе нет до этого дела, то скорее всего ты не будешь у нас работать.
После фриланса изменилось почти всё, здесь мне открылись совершенно другие подходы. Каждый программист проходит в своей жизни тот момент, когда он пишет свой фреймворк или собственную CMS. В какой-то момент я начал подозревать, что не надо было этого делать, наверное, есть более хорошие решения. И здесь я окончательно от этого отошёл, понял, как надо. На тот момент тут уже было тестирование, которым я не занимался до XIAG. Выглядит так, что как будто я даже не подозревал об этом.
На что смотришь на собеседованиях и какие люди вам подходят?
У меня очень плохо с теорией. Но у меня достаточно много опыта — не смогу объяснить красивыми словами, но знаю, какие бывают проблемы, как их решать. На собеседовании я задаю вопросы, исходя из тех проблем, которые сам решал. Я не буду просить расшифровать принципы SOLID. Когда даёшь конкретную проблему, сразу видно, куда человек начинает копать. Кто-то сразу останавливается на PHP: можно использовать эту функцию, или эту. И дальше PHP не уходит, а то, что может тормозить диск, базы данных, сеть — им неизвестно. Они не в курсе в принципе об этом. Абсолютные единицы говорят, что может быть эта задача — косяк менеджера. «Проверьте, что действительно тормозит» — с этого надо начинать. Потому что есть менеджеры, которые не представляют вообще как прокси работают. Им сказали «всё плохо», они пишут: «Всё плохо — сделайте хорошо». Надо начинать с проверки задачи: удостовериться, что проблема есть. Единицы, кто про это вспоминает с самого начала и обычно эти люди работают у нас на высоком уровне.
Часто приходят люди, которые знают только свою технологию и вокруг ничего не знают — это странно. Обычно наша оценка уровня таких людей не совпадает с их внутренним ощущением. Язык они знают на отлично, но забывают о необходимости знания окружения и соседних технологий. Часто дают однобокие ответы — вокруг одной темы. Проблема в том, что у нас не бывает таких задач. В большинстве случаев ты должен понять задачу, поговорить с менеджером, получить полное описание проблемы. Возможно это будет связано и с бэкендом, и с фронтендом, и с дизайном. Если ты не знаешь фронтенд, то хорошо, но ты всё равно должен будешь разобраться с тем, кто знает, чтобы он помог. У нас задачи включают всё. Очень плохо, если ты вообще не знаешь окружение: Git, Vagrant, NPM, RabbitMQ и так далее.
Как выбираете технологии и на что делаете акцент?
Менеджер ставит цели, сроки. Мы ищем подходящий инструмент. Совсем новые технологии мы не берём в production. Во внутреннем проекте ещё можем побаловаться, но клиентам на необкатанной технологии писать не будем.
У нас есть проект, где менеджер нам рассказывает, что для решения этой задачи отлично подходит первая Magento, плюс у нас куча готовых модулей. Грубо говоря, у нас уже почти всё готово — берите, делайте. Мы так подумали: «Мы не будем это брать. Технология уже не поддерживается, лучше потратить больше времени и сделать нормально». Есть ещё один большой проект, которому уже больше 10 лет. В какой-то момент приходилось много переделывать, но у нас никогда не было задачи его переписать. Скорее появлялись задачи, когда мы понимали, что легче уже написать с нуля. Но когда появляется большая задача, где надо либо разработать с нуля, либо значительно изменить функционал — всегда думаем, какую технологию можно использовать. Возможно, в этом месте следует использовать уже другой подход, а не тот, что был много лет назад.
У нас есть рефакторинг и тесты. Плюс XIAG в том, что это обязательно и сразу закладывается в задачу. У тебя тут нет возможности писать плохой код — его не примут. Клиент это оплачивает и знает об этом. Ни раз клиент сначала отказывался, а потом возвращался. Говорил: «Мы нашли гораздо дешевле. И они нам не за год, а за два месяца сделают». Через 2 месяца возвращался: «Год так год».