Поговорим о плохих проектах. Как понять, что проект плохой, а команда не профессиональна? Я собрал несколько признаков, которые прямо или косвенно говорят об этом. С каждым из них я борюсь много лет и вот решил написать. Если вы узнали свою команду, на вашем месте я бы встревожился.

Проект не подготовлен к старту

К сожалению, не каждый проект готов к старту после того, как вы скачали его код. И редко когда в проекте есть скрипт или Make-файл, который подготовит все нужное. Хотя технически это возможно.

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

Причина кроется в лени и неуважении к коллегам. Если ты проделал рутинную подготовку, то почему бы не скопировать команды терминала в файл? Разве не очевидно, что следующий разработчик пойдет по тем же граблям?

В каждом проекте я держу Makefile и наполняю его разными задачами. Это база знаний о том, что можно сделать с проектом. Иногда коллега что-то спрашивает, а я отвечаю с именем Make-задачи, которую нужно запустить.

Если проект стартует только после часовой ручной подготовки, это плохой проект. Плох не код, а команда, которая его поддерживает. У них не принято думать об удобстве коллег, что критично в повседневной работе.

Нет инфраструктуры

Все проекты опираются на сторонние системы — базы данных, очереди, кэш. Хороший проект предлагает способ запустить машинерию одной командой. Десять лет назад это был Vagrant, а теперь Docker. И не просто запустить, но и подготовить — создать таблицы, прогнать миграции, посеять основные данные.

Когда я скачал исходный код, то первым делом ищу docker-compose.yaml. Этот файл несет много полезной информации. Он отвечает на важные вопросы. С чем взаимодействует проект? Какова его топология?

Удивительно, но иногда этого файла нет, даже если проект цепляется за три-четыре подсистемы. На вопрос “как же вы, ребята, поднимаете проект” мне отвечают дичь вроде “у нас Линукс, все ставится из пакетов”. Это просто днище и повод задуматься о том, стоит ли дальше работать в фирме.

Первое, что я делаю с новым проектом — добавляю конфиг Докера, чтобы все заводилось одной командой. И не просто заводилось, а подготавливалось. Делайте так и вы.

Например, каждый наш проект нуждается в Кафке и Кассандре. Файлы docker-compose устроены так, что при старте образа запускается его подготовка. Для Кафки создаются нужные топики, для Кассанды прогоняются CQL-файлы. При старте compose система полностью готова.

Нет комментариев и ссылок

Признак новичка — бесконечная простыня кода без комментариев и ссылок. Беда в том, что новичок где-то услышал мантру: код должен говорить сам за себя. А я пожинаю плоды этой мантры.

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

Комментарии нужны. Докстринги нужны. Обязательны ссылки на внутренние документы и обсуждения. Если код работает с большой структурой данных, пример такой структуры надо вынести в gist и приложить ссылку. Все это нужно.

Пожалуйста, не думайте, что вы пишете понятный код. Скорее всего, вы пишете обычный посредственный код, который понятен только первую неделю. Не думайте, что я пытаюсь кого-то унизить. Это легко проверить — если хотя бы трое коллег сказали, что ваш код понятен, это знак. Не сказали? Значит, кто-то возомнил о себе.

Только мастер

В отдельных фирмах не пользуются Git-ветками. Об этом смешно писать, но все же. Народ просто поливает мастер, мешает друг другу, конфликтится, но продолжает так жить. Я просто не мог работать по такой системе.

Почему так? Не знаю. Однажды я выслушал тираду на этот счет, но смысл ушел как вода сквозь пальцы. Я смутно подумал о том, что просто в фирме не знают, как работать с ветками и решать конфликты слияния. Это косвенно подтвердилось в разных ситуациях.

Зачем брать инструмент и отбрасывать главное его свойство? Это банальное дикарство и архаика.

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

Велосипеды

Это про то, когда в фирме пишут велосипеды, игнорируя промышленные решения. Увы, такое все еще случается. Свои миграции. Своя конфигурация. Своя хитрая система сборка ошибок. Своя очередь задач. Свой веб-роутинг.

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

Мне возразят, что многие библиотеки вышли из закрытых решений, великов. Это правда, но решение легко проверить на проф-пригодность. Выложите его на Гитхаб и посмотрите на звездочки, число issues и пулл-реквесты. Если решение слабое, то единственным потребителем будет сама фирма.

Не могу вспомнить, сколько я выкинул самописных костылей и заменил на нормальные библиотеки. С документаций и примерами, поддержкой и сообществом. Велик становится либо ракетой, либо гирей, которая тянет на дно. Пограничного состояния не бывает.

Харизматичный лидер

Худшее, что может быть в проекте — харизматичный человек, который запрещает те или иные практики. С таким подходом проект скатывается в карго-культ.

Помню, на мое предложение о библиотеке X мне ответили буквально “нет, потому что X говно”. Замечательно. Хоть я такого же мнения о ваших велосипедах, но ожидал более взвешенной точки зрения.

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

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

Если вы нашли в своем проекте что-то из перечисленного, это не значит, что он плохой. Скорее, следует подсуетиться и исправить это. Уважайте коллег и всегда думайте о том, кто придет на ваше место. Этот принцип решит проблемы, о которых я рассказал.

← Слайды

Слабые фильмы →