Может показаться, что проекты — это что-то сложное, и за такое могут браться только опытные крутаны. На самом деле нет. Если вы знаете, как создать цикл, условие или функцию на вашем языке программирования — вы готовы писать первый проект.

Мне никогда не нравилось учиться по видео на YouTube или лекциям. Я и сейчас считаю такой подход бесполезным. Чтобы чему-то научиться, нужно этим заниматься.

Мои первые проекты предполагали работу с другими сайтами. Почти у любого популярного сайта есть API: это специальный интерфейс, через который вы можете сделать что-нибудь на этом сайте. Например, в VK через API можно отправить сообщение другому человеку, запостить картинку на стену или забанить пользователя в группе. Достаточно установить библиотеку для запросов в интернет и можно что-то придумывать: написать штуку, которая выводит в консоль всех ваших друзей онлайн. Или скачать базу фильмов от TMDB и написать свою рекомендательную систему.

Самое сложное в обучении на проектах — это найти пересечение между «хочу» и «могу». Можно придумать довольно много проектов, которые хочется сделать, но >90% из них окажутся невыполнимыми на текущем уровне. И наоборот, если смотреть на проекты, которые вы можете сделать, то >90% из них окажутся неинтересными.

Мне повезло, в вузе мне дали задачку, которую хотелось решить, и при этом было по силам.

Во время занятий в вузе студентам нужно знать расписание занятий. С этим была проблема: чтобы узнать расписание, нужно было заполнить онлайн-форму:

Заполнять форму из 4 полей каждый раз не хотелось, тем более с телефона, и когда до пары осталось 3 минуты, а ты в коридоре вуза пытаешься понять, в какую аудиторию нужно попасть.

Студенты находили свои обходные пути: кто-то скриншотил расписание и смотрел его на картинке в галерее. Кто-то копировал его в чатик с одногруппниками. Но общий дискомфорт и напряжение оставались.

Я заметил эту проблему и решил избавить себя и одногруппников от боли, а заодно потренироваться программировать. Нехитрой магией удалось собрать расписание с сайта, а затем и обернуть его в виде Telegram-бота.

Студент объяснял боту где он учится только один раз, а после этого получал кнопочный интерфейс:

Я показал бота одногруппникам, и ссылка на него начала расползаться по сарафанному радио. Мне стало интересно, кто пользуется ботом. А вдруг он понадобился кому-нибудь и из других групп?

Пришлось разбираться, потратить время, чтобы запилить дашборд, на котором можно посмотреть, кто и как пользуется ботом.

Вскоре появились и первые отзывы от одногруппников:

> У меня не работает расписание по воскресеньям!
> А сделай вот такую штуку?
> Я что-то нажал и всё пропало. Почему бот не показывает расписание?
> В боте почему-то не показывается третья пара!

Сразу дал о себе знать недостаток тестирования. Я тестировал бота на одной неделе расписания, но чем больше ботом пользовались — тем больше нюансов всплывало. Например, оказалось, что занятие английского проводится сразу в двух кабинетах (а иногда и в трёх), потому что группа разделялась на подгруппы. Или, что неожиданно, данные на сайте вуза были «грязноватыми», из-за чего бот иногда не мог понять, что сообщает сайт.

Следующие 2 месяца я кодил всё больше и больше: каждый день всплывали новые хотелки и новые баги.

Например, стало понятно, что интерфейс бота ужасен. Частью кнопок никто и никогда не пользовался. Вот улучшенная версия:

Ещё одна находка: оказывается, пользователи не всегда рады, когда я что-то добавляю. Новичку наивно кажется, что улучшить продукт можно, если добавить в него как можно больше функционала. Например, я хотел выводить погоду возле вуза, чтобы студенты знали, что будет дождь и стоит взять зонт.

Но довольно быстро я понял, что мир так не работает. Вариации этой цитаты приписывают всем, от Линуса Торвальдса до Стива Джобса:

> Хороший продукт – это не когда ты добавляешь фичи в продукт, а когда из продукта нечего убрать.
(с) Много умных людей

Я тоже пришёл к этому, своей дорогой. Хорошие идеи приходят многим людям :)

Студенты объединяются в группы не по соцсети, к которой привыкли сами, а по соцсети, которой принято пользоваться в выбранном вузе. Так что среди студентов ВКонтакте — это до сих пор вполне валидный вариант. А ещё это огромная платформа с множеством пользователей.

Бот для Telegram — это удобно, но многие студенты пользовались другими мессенджерами.

Новая прорва работы: теперь нужно было научиться работать с ВК, интегрировать свой код на новую платформу. На чтение документации библиотек и самого ВК потратил несколько дней и наконец запустил бота.

Как-то раз в пятницу, ближе к полуночи, я решил выложить на сервер новую версию кода. И… он не запустился. Попытался откатить код обратно, но не получилось, с базой данных что-то случилось.

Пульс участился: что делать? Может, просто код и раньше был поломан? Попробую откатить код ещё раньше. Лишь к двум ночи я понял, в чём проблема. Пришлось основательно покопаться, прочесть пару «умных» статей и так далее. Но бота надо было писать срочно. Появилась идея: «Выключить и включить обратно» :D

Я скачал БД, достал из неё данные, удалил старую БД, создал новую и написал несколько скриптов, которые залили старые данные в новую БД.

К шести утра субботы я наконец всё починил и лёг спать. А в 8 сработал будильник: было пора собираться на пары.

Так я узнал сразу о двух программистских мемах в одну ночь: пятничный деплой и бэкапы.

1) Не стоит вносить крупные изменения в свой код вечером в пятницу, потому что у тебя не будет времени на реакцию и починку перед выходными.

2) Существует только два типа программистов:

• те, кто делают бэкапы
• те, кто теперь делают бэкапы

Все выходные ушли на бэкапы, чтобы ситуация больше никогда не повторилась…

Через какое-то время я нашёл работу. Изменения в боте остановились: им больше некогда было заниматься. Да и в общем-то ничего менять было и не нужно, он работал и без моего вмешательства.

Ещё через какое-то время я окончил вуз. Появились вопросы: зачем я плачу по 6$ за сервер ради бота? Но всё же терять его не хотелось: было приятно, что моя работа кому-то нужна.

А ещё через какое-то время сотрудники вуза поменяли сайт. Бот больше не смог получать расписание от сайта. Я мог это починить, но по оптимистичным прогнозам нужно было поработать около недели по 5-8 часов.

И я просто не стал. Написал пользователям, что в связи со сменой дизайна бот будет сломан, и чинить его снова я уже не буду. Предложил также доступ к коду, если найдётся энтузиаст, который подхватит эстафету и воскресит бота снова.

Энтузиасты нашлись, но их энтузиазм мгновенно закончился, как только они получили на руки код. Бот так и угас, больше им никто не занимался.

Пусть всё и закончилось провалом, но в процессе я получил крутой опыт. Я был ответственен за данные тысяч пользователей и понимал, что если их потеряю — не каждый захочет разбираться и большая часть аудитории просто перестанет пользоваться ботом.

А ещё я узнал многое о коде. Например, благодаря одной архитектурной идее однажды мне удалось выбросить около двух тысяч строк кода из проекта всего за один вечер, ничего не потеряв. Бот работал как и прежде. А ещё позже я понял, что сделал это зря :D Я получил более «сухую» кодовую базу, но вместе с этим потерял в гибкости: код стало очень сложно менять и поддерживать. Для маленького проекта гибкость изменений куда важнее «сухости» кодовой базы. О том, как и зачем я нарушаю принцип DRY, читайте другой мой материал в блоге «Девмана».

Будучи новичком, я пытался писать как можно более «сложный» код. Он будто кричал: «Мой создатель столько всего умеет! Возьмите его на работу!». Но со временем понял, что простой код лучше, чем сложный. Со сложным кодом тяжело работать, его тяжелее поддерживать и в нём выплывают неожиданные ошибки. И к чему сложность, если от неё только хуже? Оказывается, к этому заключению пришёл не только я, но и многие другие опытные разработчики, о чём я узнал уже позже — в своих первых рабочих командах.

Бот дал крутой буст моему резюме. Разработчик, который уже делал продукты и на вопросы об архитектуре отвечал не выученными формулировками из гугла, а выстраданными часами личного опыта, выглядел сильнее других кандидатов. Опыт чистоты кода, набитый на своих ошибках, а не на книге Роберта Мартина «Чистый код», выглядел убедительнее.

А ещё это было интересно. Я получал удовольствие от развития своего продукта, какое не получишь ни на какой лекции или вебинаре.

Спустя время я работаю на онлайн-курсе по Python, который учит начинающих программистов на практике. Мы решаем ту самую проблему, о которой я говорил в начале: предлагаем ученикам интересные, но при этом посильные проекты. А чтобы ученик не упустил «шишки», которые должен был набить, в конце его код смотрит опытный программист. Понятно, что, если ученик прислал задачу на проверку, код уже должен работать. Ревьюер смотрит на качество кода и указывает ученику на ошибки, подобные тем, что я описал в этой статье.