В свободное от работы время, я предпочитаю вообще не трогать код, но делать что-то интересное. Чтобы делать что-то интересное, нужна фантазия, а мне с ней повезло не очень, но помогает супруга: она делает изделия из керамики и фарфора, а я выступаю своего рода техническим ассистентом и беру на себя технические задачки, вроде изготовления молдов для литья и всяческих шаблонов, упрощающих производство. Иногда мы делаем что-то другое, но основная наша совместная деятельность — магазинчик керамики.
Проблема
Когда мы показываем людям что-то новое и интересное, порой насыпается много заказов, все заказы нужно обработать: записать доходы, пробить чек в ЛК самозанятых, отправить трек-номер и собрать сам заказ. Порой одна только упаковка занимает несколько часов к ряду, но нужно ещё и не перепутать коробки, напечатать наклейки со штрих-кодами, не забыть пробить чеки для отчётности и постараться корректно вести учёт для статистики.
В этом процессе слишком большую роль играет человеческий фактор, приходится кропотливо проходить процесс раз за разом, и моя техническая душа страдает от того, что рутина не автоматизирована.
Так я решил убить разом двух зайцев: реализовать pet-проект, который было бы не влом писать во внерабочее время (потому что код кодом, но делается с душой и для решения насущной проблемы) и за одно сделать процесс более быстрым и менее подверженным ошибкам.
Основная идея простая:
Первая итерация
Так как это пет-проект, можно за одно и попробовать поработать с технологиями, с которыми довелось работать мало: построить красивую микросервисную архитектуру, настроить общение между сервисами через очереди, задеплоить это на домашний сервер и радоваться.
Быстро нарисовалось общее понимание желаемой архитектуры:
Звучит как план, но на практике всё оказалось сложнее: нужно было написать кучу кода, чтобы всё имело смысл именно как проект, на котором можно учиться новому: нужно описать всю инфру, DTO, чистый REST API где он нужен и так далее...
В таком виде проект очень затянулся, потому что было много более важных дел по мастерской (да и ремонт дома не двигается уже больше года). Времени уделялось проекту всё меньше, а проект оброс желаемыми фичами: ведь если мы делаем стройную систему, хочется сделать её гибкой и максимально полезной, чтобы, например, валидировать заказы (в СДЭК прописаны позиции с корректными ценами) и тому подобное.
Вторая итерация: переезд на монолит
Из-за того, что первоначальный скоуп проекта неприлично разросся, было принято решение всё бросить и переписать на монолит. Здесь уже я просто демотивировался из-за того, что сам проект перестал представлять собой хоть какой-то новый челлендж, а часть задач (пробивание чеков) стала решаться побочным продуктом: скриптом, который позволил раз в месяц просто вкинуть список ID заказов и пробить все чеки. Идея была заброшена в зародыше.
Третья итерация: прекрасный n8n
В какой-то момент мне захотелось узнать, что же это за зверь такой, n8n, о котором всё чаще пишут прямо в вакансиях.
Сначала я реализовал на нём другую свою полезную утилитку: cron-скрипт, который проверяет слоты на запись в общественные мастерские, где я использую лазер с ЧПУ. Туда порой непросто записаться вовремя, поэтому он отправляет мне слоты, как только они появляются, в Telegram.
Когда удалось собрать несложный алгоритм за 20 минут, я втянулся и понял, что это идеальный инструмент, чтобы решить мою основную задачу.
За один вечер я реализовал большую часть основного функционала, который мне был нужен.
За второй вечер я реализовал максимально простой микросервис, который генерировал и печатал этикетки на термопринтере. Я использую для этикеток принтер Niimbot B21 и нашёл на гитхабе библиотеку, которая позволяет использовать его не через мобильное приложение, а через USB-соединение. Дело было за малым: реализовать http API-обвязку и научиться генерировать картинки со штрих-кодом и списком артикулов, которые указаны в заказе в СДЭК.
Весь флоу помещается на о��ин экран и легко поддаётся изменениям и доработкам (чего в коде можно было достичь лишь тщательным продумыванием архитектуры и кучкой скучного бойлерплейта).
Вот так за два вечера получилось базово изучить n8n и реализовать штуку, на которую не хватало времени несколько месяцев.
Что я понял
Раньше мне казалось, что пет-проекты это удел либо начинающих разработчиков, либо огненных фанатов программирования, которые хотят писать код больше восьми часов в день. Я никогда не писал ничего серьёзного, если это не решало проблемы, для которых не было готовых решений, и это решалось одним небольшим скриптом.
Однако, когда ты уже много где поработал, много чего видал: разные процессы разработки, разные архитектурные решения, разные инструменты, но пока ещё не вылез за пределы, собственно, разработки, то у тебя ещё остаётся неизученная область навыков, которую редко удаётся познать "изнутри" команды разработки. Эта область — управление проектами, владение продуктом.
Когда ты пишешь не одноразовый скриптик, а систему, которую ты хочешь использовать долгосрочно и дорабатывать, то это становится проектом, где уже появляются затраты. И в первую очередь я говорю про затраты собственного свободного времени, которое очень-очень хочется потратить на что-то более разнообразное, чем сидение перед экраном с открытой IDE. Приходится не только писать код, но и принимать решения о скоупе фичей и о том, чтобы использовать не самый технически интересный стек и подход, а тот, который позволит твоему продукту эффективнее развиваться и приносить пользу сразу, а не когда он будет допилен до идеала. Конечно, какое-то ощущение продукта можно получить в команде, если не стремиться закопаться в код, а слушать и слышать своих лидов, продактов и аналитиков, но самостоятельный опыт редко удаётся получить, если не прыгать с места в обрыв, переходя на менеджерскую позицию сразу.
