Как с помощью репозитория кода уменьшить затраты на онбординг в проект
Включение новых разработчиков в проект — это трудоемкий и дорогостоящий процесс, согласны? Просто найти хорошего специалиста недостаточно. Все мы знаем, что каждая компания по разработке программного обеспечения имеет свои собственные методы и использует свои собственные инструменты. И эти инструменты могут быть даже собственной разработки.
Поэтому неважно, насколько квалифицирован и опытен ваш новый член команды, ему нужно будет многому научиться. Иногда им требуется довольно много времени, чтобы узнать все о проекте, над которым они начинают работать (например, чтобы начать работу над новыми функциями), о корпоративной культуре компании и общепринятых практиках и процессах. Излишне упоминать обширную документацию и тому подобное.
В большинстве случаев вы можете даже не быть уверены, что новые члены вашей команды смогут справиться со всем объемом новой информации самостоятельно. Значит, нужен кто-то более опытный, чтобы помочь им, провести через лабиринт новой информации. Этот «кто-то» — один из ваших более опытных разработчиков, и он также потратит свое время на процедуры адаптации, руководство и обучение своих новых коллег. А значит больше расходов.
В Mad Devs мы стремимся снизить затраты на адаптацию. Для этого мы предоставляем новым разработчикам обширную документацию, тесты и высококачественный код. Нет, мы не устраняем необходимость обучения и руководства со стороны более опытных членов команды. Но упомянутые предпосылки позволяют нам обеспечить сокращение кривой обучения для новых разработчиков. Поэтому они могут быстрее перейти к реальной работе. Вот некоторые из наших практик, которые помогают нам сделать процесс адаптации дешевле и быстрее.
Понятная документация ReadMe
Для нас онбординг — это передача знаний. В данном конкретном случае это подталкивает нового сотрудника от полного незнания наших практик перейти к внедрению кода в производство. Мы делаем это, создавая и поддерживая четкую документацию ReadMe.
Позвольте мне пояснить, что означает понятная документация ReadMe.
Прежде всего, понятный ReadMe-документ должен быть простым для понимания (для начинающего разработчика) и простым в написании и сопровождении (для опытного специалиста, того, кто его пишет). Документ ReadMe может стать отличным путеводителем по проекту, если он:
- Объясняет, как работает команда;
- Определяет правильный код и код, на который ваш новый разработчик должен обратить внимание;
- Отвечает на вопросы, которые могут возникнуть у вашего нового разработчика;
- Является асинхронным, что означает, что разработчик может прочитать его и найти всю необходимую информацию без привлечения кого-либо.
Здесь все может быть понятно, кроме последнего пункта: вопросы, которые могут возникнуть у вашего нового разработчика. Давайте разбираться. Что это могут быть за вопросы, если человек только собирается заняться новым проектом? Я выбрал самые важные из них, но вы можете добавить свои, в зависимости от специфики вашей компании и принятых практик:
Вопросы о продукте
- Как развернуть и запустить продукт локально? Разработчик может запускать тесты локально, чтобы убедиться в их успешном прохождении
- Как это программное обеспечение может быть использовано?
- Как его настроить?
Вопросы об организации кода
- Как организован код и как найти нужный?
- Как пишется код (процесс, шаблоны)?
Вопросы о процессах в команде
- Как я могу отправить PR?
- Как я могу развернуть код?
По сути, четко написанная документация ReadMe позволяет новому разработчику понять, о чем проект, запустить его локально, протестировать и развернуть.
Обширное покрытие кода тестами
Здесь особенно не о чем говорить. Тесты, охватывающие более 50% кода, позволяют новому разработчику понять бизнес-логику проекта. Если тесты понятны, правильно написаны, поддерживаются и обновляются, и если разработчик может их запустить, это значительно снизит затраты на адаптацию.
Диаграмма архитектуры инфраструктуры программного продукта
Если вы видели пример диаграммы архитектуры инфраструктуры, то знаете, зачем она нужна и чем может помочь. Она показывает новому разработчику составляющие проекта и то, как они связаны между собой.
Я бы сравнил диаграмму архитектуры инфраструктуры с дорожной картой. Также, как и подробная дорожная карта, она объясняет, куда и как вы должны двигаться, что также позволяет уменьшить руководство со стороны более опытных разработчиков.
CI/CD конвейер (непрерывная интеграция / непрерывная доставка)
Конвейер CI/CD автоматизирует процесс доставки программного обеспечения пользователю. Он создает код, тестирует его и развертывает новую версию приложения.
В CI каждое изменение в коде запускает последовательность сборки и тестирования. Затем система передает отзыв разработчику, внедрившему изменения в код.
CD выполняет подготовку и развертывание инфраструктуры.
Любой сбой на любом этапе — повод для отправки уведомления ответственному разработчику. Если все проходит гладко, вся команда получает уведомление об успешном развертывании программного обеспечения для пользователя.
Как можно использовать конвейер CI/CD для снижения затрат на адаптацию?
Он помогает новому разработчику понять из чего проект состоит, какие этапы разработки проходит и как разворачивается для конечного пользователя.
Ведение задач в таск-трекере и среда разработки IDE
Все запросы на обновление кода и коммиты мы прикрепляем к конкретной задаче в баг-трекере. Пересматривая задачу, новый разработчик может видеть процесс работы над ней в процессе:
- Как была описана задача и какая цель поставлена;
- Кто работал над ней;
- Какие действия были совершены и кем;
- Кто тестировал задачу и какие тесты запускались;
- Какие исправления были реализованы, если были, и тому подобное.
Наряду с организацией работы команды среда разработки IDE (Integrated Development Environment) позволяет исключить необходимость ручной настройки и интеграции множества утилит. Каждая утилита, которая обычно используется командой, уже интегрирована в рабочую среду команды. Это также позволяет новым разработчикам как можно скорее начать использовать утилиты и инструменты команды и разрабатывать новые функции.
Вам может быть интересно, что произойдет, если некоторые артефакты недоступны в репозитории кода или не соответствуют требованиям? Что ж, в таком случае будьте готовы к долгой и затратной адаптации каждого нового разработчика.
