Веб-индустрия переполнена историями о пет-проектах, которые переросли в успешный бизнес. Вот и я нередко увлекаюсь какими-нибудь идеями после основной работы. И хотя это определённо заманчивая перспектива, работа над личным проектом не всегда столь лучезарна – порой они просто не выгорают. Если вы читаете эту статью, то есть вероятность, что вы недавно отказались (или подумываете отказаться) от своего пет-проекта. В таком положении находились многие из нас. Да что тут говорить, заброшенные личные проекты даже стали своего рода мемом в среде разработчиков.
Тем не менее ко мне часто обращаются начинающие программисты за советом, и в последнее время их всё чаще беспокоит то, что у них не получается реализовывать пет-проекты так быстро или так часто, как хотелось бы. И такая тревожность абсолютно понятна. Когда в среде разработки господствует культура сверхактивности и концепция «непрерывной поставки», а на технических собеседованиях кандидатов зачастую оценивают на основе результатов их «внештатного программирования» (имеются в виду хакатоны, клубы программистов и прочее, — прим. пер.), заброшенные пет-проекты перестают казаться чем-то забавным. И мне это не нравится.
Мы слышим столько историй об успешных личных проектах, но что, если более открыто говорить о тех, которые провалились? Многие из нас проводят ретроспективный анализ на работе, но не в отношении пет-проектов. А почему бы нам не пролить свет на всё то время, которое было вложено в начинания, которые так и не ожили? На заброшенное ПО, которое в своё время казалось хорошей идеей. По нашим средам разработки до сих пор скитаются духи захороненных каталогов node_modules.
И здесь я хочу рассказать о своём недавнем пет-проекте, который забросил в тот же день, в который запустил.
▍ Предыстория
Моя партнёрша – латышка, и несколько лет назад я занялся изучением их языка. Поскольку Латвия страна не столь значительная, хорошие обучающие курсы по этой теме найти сложно, но я всё равно делал приличные успехи. Так было, пока я не узнал, что в латвийском языке есть падежи. Если вы ранее не сталкивались с понятием «падеж», то немного поясню.
В таких языках, как английский, нужное грамматическое значение словам в предложении придаётся с помощью их правильной расстановки и предлогов типа «для», «к» или «в». Если порядок расстановки нарушить или упустить предлог, то смысл предложения может исказиться. Например, «Tom gives the book to Anna» (Том даёт книгу Анне) звучит естественно, а вот «Tom the book to Anna gives» уже нет. И падежи эту ситуацию несколько меняют. При их использовании мы уже не опираемся на порядок слов и предлоги, а раскрываем смысл предложения, изменяя окончания существительных. Возьмём то же предложение на латвийском: «Toms dod grāmatu Annai» (для большей наглядности окончания выделены жирным). Если перевести это предложение на английский буквально, то получится «Tom-субъект gives book-объект Anna-кому».
В лингвистическом смысле падежи – это очень крутая система, которая избавляет от необходимости следить за порядком слов. Но вот для учащегося это создаёт проблему, поскольку тебе приходится следить за всеми окончаниями изучаемых слов. Всего в латышском семь падежей, два грамматических рода (каждый с тремя отдельными склонениями), и существительные могут быть единственными либо множественными. Короче, всего нужно запомнить 84 окончания.
Так что падежи для человека, чьим родным языком является английский, это непросто. Но, к счастью, я также ещё и разработчик, поэтому во мне прошита твёрдая уверенность, что я могу решить всё с помощью кода. Что, если я создам приложение-тест, которое поможет мне изучить окончания существительных? Попахивало началом пет-проекта. 🚀
▍ Подход
Я хотел сделать приложение простым. Несмотря на то, что мне предстояло освоить много другой грамматики, я сосредоточился только на склонениях существительных, и это должно было упростить доведение изначальной идеи до минимального жизнеспособного продукта (minimum viable product, MVP). Механизм теста будет последовательно выдавать латвийские существительные, а пользователю нужно будет склонять эти существительные, используя подходящие окончания. Чтобы получилось более интересно, пользователю будет позволено совершить три ошибки, и я реализую простую систему рекордов, чтобы отслеживать результаты своих тестов.
Технологии я тоже использую простые. Когда я всё это планировал, только вышла версия Svetle 3.0, поэтому для UI я решил задействовать именно этот фреймворк. Я планировал разместить всё на Netlify, так что в качестве бэкенда решил написать пару бессерверных функций для вывода вопросов и проверки ответов. Основной список существительных будет подаваться из статического файла JSON, а поскольку я буду единственным пользователем, можно спокойно сохранять предыдущие результаты и таблицу рекордов в локальном хранилище. База данных не потребуется.
А вот для создания механизма проверки ответов нужно было погрузиться в тему. После подробного прочтения материалов по склонению существительных и классификации их различных типов я решил, что проще всего будет создать систему, которая на основе регулярных выражений будет вычленять корни существительных и добавлять нужные суффиксы.
Продумав сей прекрасный план, я приступил к коду.
▍ Реализация
Спустя неделю вечерних трудов над своим проектом, я уже вносил финишные штрихи в его MVP-версию. Готовое приложение я развернул на Netlify и начал своё первое тестирование.
Интерфейс был очень прост, но вполне сносен и работал на мобильных устройствах. Как я и планировал, приложение поочерёдно выдавало вопросы, и сеанс завершался после трёх ошибочных ответов. Между тестами корректно отображалась статистика правильных/неправильных ответов для каждого слова и сохранялся общий результат. Радуясь, что всё исправно работает, я открыл банку пива и начал обучаться.
Но довольно быстро стало ясно, что в приложении есть проблема, которую я не предвидел. Тест был слишком простым. Хуже того, если я не допускал трёх ошибок, то он продолжался бесконечно. Работать с ним было не интересно.
Я задумался, как можно сделать его более увлекательным и, в конечном итоге, меня осенило: эту проблему не получится решить с помощью кода. Как оказалось, продумывая и программируя всю логику, необходимую для тестирования окончаний, я пассивно изучил все сопутствующие правила.
В течение недели я долгими вечерами трудился над изучением темы и созданием приложения, чьей целевой аудиторией должен был стать единственный человек, и в результате оно оказалось мне не нужно. М-да…
▍ Возможно, реальная польза в написанном коде
Из всех моих заброшенных пет-проектов именно этот заставил меня взглянуть на всё иначе. Даже если бы я никогда не использовал конечный продукт, сама работа над проектом всё равно косвенно вела к достижению поставленной цели. И тут я понял одну важную вещь: мы часто описываем заброшенные проекты как «провалы», но по факту всё зависит от того, как на это посмотреть.
Несмотря на те убеждения, которые могут навязывать вам работодатели, успех пет-проекта не обязательно должен определяться красивым выведенным в продакшен продуктом. Мы работаем в практической среде, и любой опыт разработки – будь то успешной, неудачной или заброшенной – всё равно опыт. Если вы сможете избавиться от гнетущего стремления поскорее поставить готовое решение, подойдя к задаче как к созданию одноразового прототипа, то пет-проекты станут отличным плацдармом для экспериментов. В результате создания своего обучающего приложения я понял, что даже сам процесс написания кода может стать полезным инструментом для решения задачи.
И я не хочу сказать, что следует игнорировать причины, по которым подобные проекты забрасываются – интроспекция по-прежнему важна – но считаю, что акцент на достигнутом прогрессе в долгосрочной перспективе будет восприниматься более конструктивно. Забросив своё приложение, я вернулся к другим полузабытым пет-проектам, томящимся у меня на ноутбуке. Там, где до этого я жаловался на череду неудач и потраченное время, теперь мне удалось переключить внимание на то, что действительно удалось. В одном из таких проектов я увидел, что именно в нём впервые научился создавать API на Go. В другом меня впечатлило то, как я освоил работу с данными карт ГИС (географическая информационная система) в Postgres. Ещё в одном заброшенном каталоге я не нашёл ничего, кроме нерабочей анимации – к которой позже вернулся и развил в этот сайт (имеется в виду сайт оригинала статьи, – прим. пер.).
▍ Выводы
Я до сих пор регулярно работаю над пет-проектами, но теперь уже с другим отношением и мотивацией. И разработчикам, которые сильно переживают за свои личные проекты, советую всегда убеждаться, что вы делаете их именно для себя и по веским причинам. Вместо того, чтобы подходить к своему первому проекту чисто из амбициозных соображений или чтобы впечатлить работодателя, взгляните на него в первую очередь как на способ изучить новые возможности. Как только вы наберётесь достаточно опыта (то есть заброшенных пет-проектов), остальное придёт само. Личные проекты должны быть креативными и интересными. Если вы заметите, что вас начинает беспокоить срок готовности вашего начинания или, хуже того, если вы из-за него начнёте выгорать, то не мешкая бросайте. Велика вероятность, что при внимательном рассмотрении вы заметите немало ценности, которую он вам уже принёс.
Автор: Дмитрий Брайт
