«Делайте изменения, когда всё хорошо». Интервью с создателем Ruby on Rails
Мы взяли интервью у Дэвида Хейнемейер Ханссона, создателя веб-фреймворка Rails и побеседовали с ним о мире разработки в целом и его подходе к написанию хорошего кода. Так же мы ждем Дэвида на предстоящую конференцию RubyRussia 2020.
Введение
Дэвид Хейнемейер Ханссон — создатель Ruby on Rails, сооснователь и технический директор Basecamp, автор бестселлеров, автогонщик (призёр LeMans), семьянин, частый гость подкастов и вдохновляющий спикер технических конференций.
Ruby on Rails был создан в 2003-м. В 2008-м появился Evrone, где мы каждый день используем этот open-source веб-фреймворк. RoR сотни раз помогал писать по-настоящему красивый код для наших проектов.
Кроме создания одного из самых полезных, на наш взгляд, инструментов разработки, за Дэвидом числится много других подвигов: от написания книг «REMOTE: Офис не обязателен» и «REWORK: Бизнес без предрассудков» до участия в чемпионате мира по автогонкам на выносливость. В 2014 году он пришёл первым и победил в классе LMGTE Am в 82-м ежегодном 24-часовом заезде на выносливость «Le Mans» — самой престижной endurance-гонке в мире.
В 2020-м мы пригласили Дэвида стать спикером RubyRussia, 11-ой ежегодной конференции Evrone по Ruby в Москве. Перед мероприятием у нас была возможность поговорить с Дэвидом о мире разработки программного обеспечения и его подходе к написанию потрясающего кода.
Интервью
Evrone: Дэвид, мы очень рады пообщаться с тобой. Давай начнём. Что выбрать обычному разработчику: начать с подхода «минимального содержания JavaScript», а потом улучшать своё приложение, или сразу использовать Angular, React или Vue? Какую стратегию ты бы рекомендовал?
Дэвид: Я думаю, если вы создаёте что-то похожее на «классическое веб-приложение», вроде Basecamp, GitHub, Shopify или подобное, то минимальное количество JavaScript — это то, что нужно. Это не значит — вообще никакого JS, просто чуть-чуть.
Если же вы делаете что-то супер-интерактивное, вроде игры, фоторедактора или чего-то в духе «один экран — тысяча состояний», то стоит посмотреть в сторону «полностью SPA» подхода.
Evrone: Какие части Rails-приложений ты бы посоветовал перенести в микросервисы, когда и кодовая база, и команда значительно разрастаются? В ситуации, когда бизнес хочет хорошей организации разработки, но переписывать продукт с нуля — не вариант.
Дэвид: Это иллюзия, что если софт не получилось написать хорошо с первого раза, то со второй попытки получится лучше. Разработчикам нужно вырабатывать привычки и практиковать их в том коде, где они «живут».
Сара Мей классно рассказала про это на RailsConf 2018. Она сказала, что кодовая база — больше не штука, которую мы просто строим. Это место, в котором мы «живём», и наша цель — сделать его пригодным не только для себя, но и для других «живущих» в нём разработчиков. Когда мы все пишем код, нам надо не просто завершить проект и перейти к другому. Наша цель — сделать его устойчивым, пригодным для жизни «обитающей» в нём команды.
Вы можете сколько угодно переписывать ваш код. Но, если вы не поменяете тот подход, который привел вас к такому коду, то точно так же получите спутанный клубок микросервисов, как до этого получили спутанный клубок классов в вашем монолите. Код, который мы пишем, — это аналог пространства, населённого людьми. Важной частью создаваемых нами программ является взаимодействие между людьми и кодом, которых нельзя отделить друг от друга. Чем больше мы будем думать о программах, как о взаимосвязанной системе кода и людей, тем ближе мы к прорыву. Ближе к революции, сдвигу парадигмы. Но, пожалуй, самое важное — мы будем ближе к тому, чтобы создавать код, с которым по-настоящему приятно работать.
Evrone: Нельзя не согласиться. Но можно задать следующий вопрос! На что бы ты рекомендовал обратить внимание разработчикам, которые выбирают между monkey patching и другими подходами композиции кода? Чтобы в результате «freedom patching» не превратился в месиво конфликтующих друг с другом переопределений?
Дэвид: То, что мы называем «freedom patching» — это возможность создавать диалекты языка Ruby. Например, как это делает Active Support. И такая возможность не предназначена для прикладных программ.
Evrone: Ты наверняка видел огромное количество Ruby кода. В чём, по-твоему, отличие хорошего кода от ужасного? Что-то, что сразу бросается тебе в глаза?
Дэвид: Если код паршивый, это видно еще до изучения логики работы. Не соблюдается выравнивание, стили перемешаны, по коду видно, что о нём никто не заботится.
Мы, разработчики, учимся писать действительно хороший код всю нашу жизнь. Как я говорил в своём выступлении на RailsConf 2014, мы не инженеры, которые разрабатывают софт, а, скорее, писатели, которые софт пишут. «Написание» — более подходящее название тому, что мы делаем, нежели «разработка». Это история про ясность, про представление информации так, чтобы любой мог её понять.
Не существует какого-то списка принципов и практик, простое следование которым делает человека хорошим писателем. Чтобы хорошо писать, недостаточно выучить содержимое толкового словаря. Точно так же знание синтаксиса языка программирования и приемов организации кода не сделают из вас хорошего разработчика. Нужно набить руку. Чтобы это сделать, надо осознать, что самое важное в создаваемом вами коде — это его понятность. А потом начать набивать руку, делая код понятным.
Есть только один способ стать хорошим программистом (под хорошими я понимаю тех, кто пишет понятный код) — читать много кода и писать много кода.
Evrone: Для многих владельцев бизнеса без технического бэкграунда трудно понять такие штуки как «технический долг», «архитектура» или необходимость время от времени переписывать приложения для создания лучшего кода. Как бы ты порекомендовал «продавать» подобные идеи бизнесу?
Дэвид: Я не сторонник больших переделок софта именно по техническим причинам. Выступление Сары Мей объясняет почему. Зато я поддерживаю такое переписывание, если нужно обучить приложение делать что-то фундаментально отличное от его текущего поведения. Я много говорил об этом на Business of Software Conference USA.
Мы переписывали код Basecamp не раз, и не два, запуская новые версии приложения. Конечно, это прекрасно — взрослеть вместе со своими пользователями. Но такое взросление софта приносит не только опыт, но и багаж недостатков. Должно быть какое-то обновление, потому что иначе всё замедляется, и в один момент ты просто имеешь пожилую базу пользователей, крайне мало новых пользователей и ситуацию «ведра». Старые пользователи меняют работу и прекращают пользоваться вашим решением.
Проблема в том, что если не «доливать воды», то ведро станет пустым. Делать изменения надо тогда, когда всё хорошо. И это, по иронии судьбы, самое тяжёлое время для внесения изменений.
Никто не будет вечно заинтересован воплощением своих идей пятнадцатилетней давности. Это так не работает. Но если ты обновляешь их, позволяешь выйти наружу своим лучшим замыслам в их чистейшей форме, то у тебя будет прекрасное зелёное поле, маленький красивый домик на нём и «жизнь удалась». Так что, пожалуйста, переписывайте свой софт.
Evrone: Ну и наш классический вопрос про путешествия во времени! Если бы ты мог вернутся в прошлое, в тот момент, когда начал отделять Rails от Basecamp, какой единственный технический совет ты бы дал юному себе?
Дэвид: Никакой. Я бы ничего не хотел знать. Неведение — это счастье.
Мы с нетерпением ждём выступления Дэвида на RubyRussia 2020. Наша команда также очень ждёт дальнейшего развития Basecamp и, конечно же, Ruby on Rails. Чем мощнее фреймворки, тем лучше становятся решения, которые мы создаём для наших клиентов и партнёров. Если у вас есть идея проекта, использующего Ruby on Rails, наши разработчики будут счастливы обсудить с вами все возможности. Неважно, на какой стадии ваш проект, просто заполните форму ниже и мы свяжемся с вами, чтобы узнать, как можем помочь достигнуть вашей цели.