Перевод статьи «If you want to ship a side project, start with unlearning the best practices».
Два года назад была моя последняя рабочая неделя в Toptal, где я был тимлидом в команде из 12 человек. С тех пор я полностью посвятил себя собственным проектам. И это были мои самые продуктивные и приносящие глубокое удовлетворение годы за всю мою чуть больше чем десятилетнюю карьеру. И хотя я по-прежнему далек от достижения своей цели – создания собственного жизнеспособного бизнеса – я уже успел многое узнать о разработке продукта, маркетинге и продажах. В этой статье я поделюсь тем, чему я научился, работая над дюжиной собственных проектов. Если вы, как и я, любите что-то создавать и стремитесь к независимости, эта статья для вас.
Изучение лучших подходов
Мой первый год в профессиональной разработке был сложным. После того как я провалился, пытаясь стать разработчиком игр, я несколько лет был фрилансером и брался за разнообразные веб-проекты. Я был разработчиком, которого вы точно не захотели бы видеть в своей команде. Я работал сверхурочно над малобюджетными проектами, пытаясь уложиться в нереальные сроки. В результате и я сам, и мои клиенты часто бывали разочарованы результатами (если результаты вообще были). Баги, пропущенные дедлайны, функционал, не соответствовавший ожиданиям, – я видел всё. Я не был знаком с положительными примерами, но был уверен, что есть и лучшие способы работать над проектами.
После очередного проекта, потерпевшего фиаско, я открыл для себя мир Ruby – и будто попал в другую реальность. Сообщество очень сильно повлияло на мои взгляды на разработку, менеджмент проектов и бизнес. Я прочел «Getting Real» и все книги о бизнесе и управлении проектами, которые смог найти. С религиозным рвением я изучал и испытывал все известные методологии, которые должны были улучшить качество моего кода и продуктивность работы. SOLID, TDD, BDD, GTD, SCRUM, <вставьте-что-угодно>. У меня ушло несколько лет на то, чтобы стать разработчиком, которого вы захотели бы видеть в своей команде.
На протяжении этого времени я постоянно работал над сторонними проектами. Я начинал эти проекты десятками, среди них были и списки задач, и трекеры тикетов, и социальные сети. Они занимали все мое свободное время, но мне никогда не удавалось завершить ни один из них. Поначалу я увлекался какой-то идеей, брался за новый стек технологий, затем приступал к разработке с применением лучших методологий, которые с таким трудом изучал. А затем я застопоривался, терял интерес к проекту или же увлекался новой, лучшей идеей. Когда я ушел с работы и стал вкладывать в проекты собственные деньги, я быстро понял, что мои подходы были ошибочными.
Старайтесь сделать как можно хуже
Подходы, жизненно необходимые в командах, могут быть настоящим ядом, когда вы работаете в одиночку. Парадоксально, однако, чтобы сделать как можно лучше, нужно делать как можно хуже!
Когда над одной кодовой базой работают десятки людей, необходимо следить за тем, чтобы система была хорошо спроектирована, чтобы код хорошо читался и имел достаточное покрытие тестами. Пул-реквесты должны проверяться и вливаться в кодовую базу только тогда, когда соответствуют всем стандартам команды. Вариант «Я сделаю рефакторинг позже» не проходит в командной работе, потому что все очень быстро меняется и велика вероятность, что следующим человеком, заглянувшим в этот код, будете уже не вы.
А когда вы работаете самостоятельно, следование лучшим практикам только замедляет вас. Будучи единственным владельцем кода, вы можете откладывать написание тестов, аж пока не дойдете до какой-то критической части, которая ни в коем случае не должна сломаться. И даже тогда пары сквозных тестов будет достаточно. Это не значит, что я вообще избегаю тестов. Я их делаю, если мне нетрудно написать парочку модульных тестов или если что-то сложно протестировать вручную.
Нет ничего хуже в дизайне кода, чем плохо подобранная абстракция. Работая над своими продуктами, я предпочитаю делать копипаст кода дважды, трижды и даже большее количество раз, пока не увижу повторяющийся шаблон и пока мне не приходится что-то менять в этом коде, причем достаточно часто. В конечном итоге, весь смысл рефакторинга в том, чтобы код было проще модифицировать. Я думаю, в командах тоже можно поступать таким образом, но нужно подходить к делу системно и помещать соответствующие тикеты в бэклог или делать примечания в комментариях.
Фокус на производительности это еще одна ошибка, которую я постоянно допускал. Мы всё время видим твиты и статьи о важности времени ответа, малого потребления памяти и т. п. Разработчики часто стыдят компании за то, что у тех грязный код, и вы можете подумать, что вашему маленькому бизнесу вообще не выжить, если вы не будете все делать идеально.
Но на самом деле все это вообще не важно, если ваш проект так и не выйдет в производство. Люди не будут покупать ваш продукт лишь потому, что он загружается меньше, чем за секунду. Однако, если этот продукт решает их проблемы, они подождут и 5 секунд, и даже больше. Если у вашей страницы плохая производительность из-за того, что пользователь добавил на нее слишком много контента, это прекрасно. Значит, вашим продуктом кто-то пользуется.
Используйте стек, который уже знаете
Всю карьеру я гонялся за лучшими языками программирования, новейшими фреймворками и самыми эффективными способами управлять инфраструктурой. Я испытывал как минимум одну новую технологию в каждом начатом мной стороннем проекте. Вот из-за того, что большую часть времени я был занят освоением новых концепций, я так и не сумел ничего завершить.
Несомненно, для моей карьеры это все равно было полезно, ведь я изучил намного больше всего, чем средний инженер. Это сделало меня настоящим full-stack разработчиком, который умеет делать все: от инфраструктуры до фронтенда. Это также помогало мне удовлетворять свою страсть к новым технологиям без вреда для работодателей (каковой мог бы быть, если бы я экспериментировал с кодом, идущим в продакшен).
Но когда я начал свой путь инди-разработчика, я хотел поставлять продукты, а не учиться, поэтому я решил придерживаться стека, который знаю лучше всего, – JavaScript, как для фронтенда, так и для бэкенда. Несмотря на то что я сумел бы управлять инфраструктурой самостоятельно, я предпочел платформу Firebase, предоставляющую всё необходимое, от хостинга статических сайтов и серверов до управления базами данных. Это решение не было оптимальным, самым эффективным или элегантным, но оно помогло мне начать и быстро сфокусироваться на своем продукте.
В конечном итоге, я не использую большую часть изученных мною технологий. Но есть множество отличных примеров, когда основатели компаний вовсе не имели опыта в программировании и учились всему самостоятельно в ходе работы и зарабатывания денег. В результате они начали зарабатывать куда больше и куда быстрее, чем я. Эти истории заставляют меня сомневаться, а стоило ли вообще учить так много.
Если ваша цель – учеба, вы можете игнорировать мой совет, но если вы хотите поставлять готовые продукты, старайтесь без необходимости не использовать новые технологии.
Будьте экономны
Многие годы я работал в компаниях, где качество было в приоритете. Выпустить продукт, не соответствующий стандартам на всех уровнях, от основного функционала до мельчайших деталей, было неприемлемо. Если пользователь вводит свое имя, для этого должны быть настройки. А если есть список, то должна быть и разбивка на страницы. И так далее.
Когда вы еще «маленькие», даже стандартный функционал вроде настроек имени или восстановления пароля может занять время, необходимое для более важных вещей. Работая над дизайном своего первого крупного проекта – виджета для веб-сайтов – я заметил, что трачу слишком много времени на детали, которые не нужны для первого релиза. И я начал обрезать функционал, пока не дошел до того, который решал основную задачу. В ходе разработки я решил пойти еще дальше и пропустить некоторые вещи, поначалу казавшиеся необходимыми, вроде возможности удаления созданных сайтов. Я планировал представить их после релиза, но, к моему удивлению, пользователи вообще отнеслись к ним безразлично. Они хотели совершенно другой функционал, чем тот, что я представлял себе изначально.
В другом случае я провел недели за написанием системы оплаты – и лишь для того, чтобы узнать, что люди вообще не готовы платить за решение проблемы, под которое был заточен мой проект. В следующем проекте я попросил пользователей слать мне деньги на PayPal, и это сработало. Позже я добавил кнопку «Активировать Pro план», которая ничего не делала, кроме вывода сообщения «Мы свяжемся с вами вскоре» и отсылки мне сообщения (с использованием Zapier) с подробностями о пользователе. В результате я получил возможность поговорить с каждым заинтересованным клиентом индивидуально. В ходе этих разговоров я мог или продать свой продукт, или услышать причины, по которым люди не готовы за него платить. Это не только сэкономило мне время, но и помогло доработать проект, чтобы он лучше отвечал нуждам пользователей.
Вашим главным приоритетом должно быть скорейшее получение обратной связи и изменение продукта в соответствии с ней. Поэтому следует как можно быстрее начинать поставки. Сокращайте функционал, как только можете, а затем сокращайте еще.
Спасибо за то, что прочитали мою статью. Надеюсь, она будет вам полезной. Я старался осветить все самое важное, что я, как разработчик, узнал в ходе разработки собственных проектов.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]