От переводчика: публикуем для вас статью разработчика Джека Финлея. Джек рассказывает о собственном кейсе — попытке организовать работу командой джуниоров, где все равны и нет технического руководителя. Статья будет полезна для начинающих программистов.
Некоторые проекты могут зайти в тупик, завершиться ничем по ряду причин. Техническое руководство — то, чего частенько не хватает. Эта проблема может привести к фиаско. Однажды так случилось с проектом, в разработке которого я принимал участие.
Skillbox рекомендует: Двухлетний практический курс «Я – веб-разработчик PRO».
Напоминаем: для всех читателей «Хабра» — скидка 10 000 рублей при записи на любой курс Skillbox по промокоду «Хабр».
Время может научить вас многому. К сожалению, опыт мы получаем в результате работы не только с успешными проектами, но и с неудачными.
Личный опыт и руководство
Точнее, отсутствие такового. В нашем проекте не было лида или кого-то с должностью senior developer. В принципе, уже было понятно, что будет с нашей работой, но на тот момент мы этого не понимали.
У команды не было опыта. Почти все мы были студентами, и не было никого, кто бы смог нами руководить. Тогда нам это не казалось необходимым.
В течение одного лета количество участников команды увеличилось в пять раз. Проблема? Все были примерно на одном профессиональном уровне. У всех не хватало опыта. Мы разбились на несколько групп, каждая из которых за что-то отвечала.
Причем практически все участники проекта были хорошими людьми, ответственными. Но это был наш первый коммерческий проект. Моя команда была очень хороша, работали мы отлично, но результатом оказалась неудача.
Инструментарий
Ключевой компонент работы любого профессионала — инструменты. Без нужных инструментов нормальный ход процессов невозможен. У хорошей команды обычно есть лидер, который знает, кому какие инструменты нужны и где их взять.
Базы данных
В этом проекте у нас был доступ к общей базе данных, размещенной на виртуальной машине, одной из самых медленных, которые можно было получить. Естественно, мы испытали на себе все «удовольствия» такой работы: потери данных, падающие таблицы, одновременные действия над одними и теми же элементами. Все это здорово тормозило нашу работу.
У нас не было возможности воспроизвести базу данных ни локально, ни в облаке, не выполнив операцию резервного копирования и восстановления. Не было никакого способа получить «чистую» базу данных в том же состоянии, в котором мы хотели бы развернуть ее в разных средах. База данных могла быть создана только как клон с БД нашего сервера.
Но проект работал лишь с БД, которая располагалась на рабочем сервере. Это означало, что мы не могли тестировать базу и проект, зависящий от нее, локально. Несколько раз возникала ситуация, когда нам приходилось откатывать базу до определенного момента, поскольку ночью кто-то разрушил ее неосторожными действиями. Это очень сильно тормозило процесс разработки.
Миграция и обновление БД производились вручную. Это означало… да, мы снова теряли время.
Сейчас кажется очевидным, что у разработчиков должны быть локальные БД на своих машинах. Кроме того, необходимо использовать автоматические инструменты для миграции. Это дает разработчикам свободу и возможность маневра в определенных ситуациях.
Производительность
Разработчикам нужна высокая производительность как локальных машин, так и сервера, где тестируется проект. Но поскольку у нас были медленные инструменты, об этом и мечтать не приходилось.
У многих были чрезвычайно медленные устройства, которые использовались уже много лет. Клавиатуры, трекпады — все это несло на себе печать времени.
Серверы также были медленные, о чем я уже говорил выше. Как результат, весь процесс разработки тормозил. Тесты тоже продвигались медленно.
Вывод простой, в стиле КО, —- дать разработчиком оборудование и ресурсы, которые им нужны для нормального процесса девелопмента.
Контроль исходников
Это вообще был сплошной хаос. Мы использовали корпоративную систему контроля исходников, но проблема заключалась не в софте. Просто не было стратегии. Отдельные группы разработчиков работали каждый «в своем болоте», и у нас не было договоренности о том, когда мы будем сливать отдельные бранчи вместе. В итоге получилось то, что получилось: конфликты, конфликты при слиянии повсюду. Приходилось тратить немало времени на решение проблем и правильную синхронизацию.
Интеграция и деплоймент
У нас вообще не было никаких решений CI/CD. Деплоймент был простым: мы копировали ресурсы из built-папки и вставляли их на сервер посредством Remote Desktop. Если вы делали нечто похожее, вы можете понять мою боль.
Для тех, кто не сталкивался с проблемой: если у вас в буфере есть что-то, кроме нужных файлов, это убьет заливку файлов на сервер. Если кто-то еще из команды присоединится к серверу для заливки файлов, у вас будут проблемы. Кроме того, некоторые файлы могут передаваться поврежденными.
Мой совет — выбрать CI/CD-решение для себя.
Контроль качества
Еще один важный элемент процесса разработки — контроль качества.
Рецензирование
Эта работа заключалась у нас в том, что члены команды собирались вместе и просматривали проделанную работу. Причем в код мы иногда даже не смотрели, так что огромное число моментов проходило мимо внимания. Еще одна проблема крылась в том, что у нас не было опыта, а значит, понимания того, что является хорошим кодом. Мы не могли сразу вычленить ошибки в коде, которые опытный разработчик видит сразу.
Если бы в команде был senior developer, он бы сразу смог дать нам знать, где проблемы и как с ними бороться. Но его не было, мы работали самостоятельно.
Тестировщики
Их у нас тоже не было. Мы проводили тесты своими силами. Снова без опыта. В результате уходило драгоценное время, которое мы тратили на вылавливание багов и их ликвидацию.
Если вы хотите хороший код — нужны тестировщики, причем профессиональные. Разработчики далеко не всегда справляются с проблемой тестирования ПО.
Качество кода
Многие из нас в начале пути являются представителями “copy-past”-культуры. Это означает, что необходимые проекту решения разработчик ищет на Stackoverflow и вставляет найденный кусок без зазрения совести. Результат — не слишком хороший код, который практически нечитаем и который разработчики затрудняются объяснить полностью. Даже тот человек, кто скопировал определенный участок, часто не может разобраться в своей работе.
Посоветовать могу лишь одно: если вы копируете код, должны полностью его понимать. Без этого нельзя реализовать нормальный проект.
Спагетти-код
Плохое понимание архитектуры проекта привело к полному хаосу. Спагетти-код — мягкое описание того, что получилось в итоге.
Некоторые участки проходили через разные руки, разных разработчиков, каждый из которых добавлял что-то свое. Финальный код проекта представлял собой набор идей и «костылей».
У нас не было системы внедрения зависимостей, и мы не использовали какие-либо общие шаблоны проектирования. Это привело к большому количеству плохого кода, который просто начал «гнить».
Что я могу сказать? Читаемость кода так же важна, как и правильная работа, и эти две вещи идут рука об руку. Ясный, согласованный стиль и целостный код обеспечивают максимально эффективный результат.
Вывод
Многие проблемы возникли по причине отсутствия у нас опыта. Мы просто не знали, как правильно работать над проектом. Мы не могли правильно реализовать окружение. У нас не было нужных инструментов и технологий.
Хороший лидер команды решил бы все эти проблемы. Он бы предвидел многое заранее.
Кстати, сам по себе проект не был худшим из того, что могло случиться. Я встретил многих будущих коллег, с которыми общаюсь до сих пор. Получил необходимый для работы в качестве профи опыт. И понял, что без нормального руководства даже самая способная команда не реализует свой потенциал полностью. Никогда.
Skillbox рекомендует:
- Практический курс «Мобильный разработчик PRO»
- Онлайн-курс «Профессия веб-разработчик»
- Онлайн-курс «Профессия Frontend-разработчик».
Автор: fokus-lop
