Перевод статьи Жан-Поля Делима «Essential skills every developer should master (besides coding)».
Вне зависимости от того, учитесь ли вы писать код, ищете новую работу или просто хотите усовершенствовать свои навыки разработчика, вам нужно работать над инструментами командного сотрудничества. Это так же важно, как уметь писать код.
Именно командная работа создает или разрушает проекты разработки программ.
В конечном итоге ваш код заработает. Если вы хотите, чтобы он работал, как часы, и был хорошего качества, вы и ваша команда должны быть организованы.
- Каждый должен знать, что он должен делать и когда.
- Работа одного члена команды не должна перекрываться или противоречить чьей-то еще.
- Все должны следовать общим правилам.
Достичь этого можно с помощью правильных процессов и инструментов. Вы хотите, чтобы 90% времени команда была сосредоточена на написании кода (оставшиеся 10% — на кофе-брейки и обновления Windows).
Вот три основные вещи, над которыми следует работать.
Git и запросы на внесение изменений (Pull Requests)
Конфигурационное управление это основа командной работы в сфере разработки ПО. Для этого существует много инструментов, но к счастью, один из них стал абсолютным чемпионом, и это Git.
Документация по основным вопросам хорошо описана в Git Book.
Есть множество готовых сервисов, с которых вы можете начать: GitHub, пожалуй, самый популярный, но есть еще и BitBucket или GitLab.
SourceTree – прекрасный графический инструмент, с которым также можно работать. Но я рекомендую сначала научиться пользоваться командной строкой, а уж потом переходить на UI-инструменты.
Ниже представлены вопросы, ответы на которые вы должны знать:
- Слияние: в чем разница между merge и rebase?
- Как разрешать конфликты? Например, мое/их/manual merge.
- Что такое feature branch?
- Что такое pull request?
- Какие различные рабочие процессы совместной работы есть в Git?
Это довольно просто. Почитав теорию и немного попрактиковавшись вы быстро станете специалистом по Git.
Совещания Agile
Первое, что делается в команде, когда начинается новый проект или работа над крупной задачей, – разделение работы. За последнее десятилетие методология Agile заменила традиционное waterfall-планирование. С манифестом Agile можно ознакомиться здесь.
В общем, там говорится «давайте не планировать слишком много наперед, потому что вводные данные и заключения по проекту, которые у нас есть сегодня, все равно изменятся». Это почти всегда правда, и сегодня вряд ли вы найдете хоть одну команду, которая не работает по методологии Agile (по крайней мере, многие о себе так думают).
Вот некоторый практический опыт:
- Самый популярный способ работы в Agile это Scrum. Делите ваш проект на двухнедельные «спринты» и помещаете «задачи» в содержимое спринта. Весь последующий процесс это “backlog”. Это полезно для отслеживания прогресса, корректировки планирования в будущем и улучшения скорости команды с течением времени.
- Другой Agile-подход это Kanban. Идея в ограничении количества задач, находящихся «в прогрессе». Таким образом вы обеспечиваете полное закрытие одной позиции перед переходом к другой. Здесь нет спринтов или временных рамок, как в Scrum. Вы просто перемещаетесь от задачи к задаче, пока не выполните их все.
В Agile программный проект разбивается на десятки или даже сотни задач. Вам нужен инструмент, чтобы управлять ими. Тут можно посоветовать JIRA.
Конечно, есть и другие инструменты, но вам, скорее всего, придется работать с JIRA рано или поздно. Поэтому, если все инструменты для вас одинаково в новинку, лучше начните с JIRA. Там есть бесплатная пробная версия на 7 дней. Этого более чем достаточно чтобы понять, как все работает. Опять же, инструмент довольно прост и очень хорошо документирован.
Тестирование и непрерывная интеграция
Git и Agile позволяют команде быстро продвигаться. Но скорость неизбежно связана с ошибками и багами. Представьте команду из пяти разработчиков, каждый из которых независимо работает над своим куском кода. Каждый из них сделает pull request в репозиторий. Могут возникнуть две проблемы:
- Как только код «первого» разработчика попадет в Git-репозиторий, код остальных станет невалидным или перестанет работать, потому что что-то изменилось. Это не ошибка «первого», это жизнь, а потому так будет случаться.
- Как только все разработчики запушат свой код в репозиторий, шансы, что все будет работать как ожидалось прямо «из коробки», довольно малы. И снова, это не потому, что команда плохо работает. Просто так бывает.
Поэтому программное обеспечение нужно тестировать. И что, каждый раз, как кто-то запушит свой код? В идеале – да, но это отбирало бы слишком много времени впустую.
Не лучше ли протестировать один раз, когда уже все запушат? Тоже вариант, но так можно обнаружить баги на более поздней стадии, и это задержит весь проект. Так что же делать?
Решение в автоматизированных тестах и непрерывной интеграции.
Автоматизированное тестирование это тема, по которой можно написать не одну книгу. В каждом языке и фреймворке есть собственный набор инструментов. Перечислять их все здесь бессмысленно. Просто учтите, что тестирование занимает время, и не всегда только запланированное.
В любом случае, вы должны знать, как писать юнит-тесты для своего кода и быть проактивными в их написании. Если у вас нет времени на это, вы должны хотя бы осознавать, что это неправильно.
Непрерывная интеграция это процесс, при котором каждый пуш в ваш репозиторий запускает автоматизированную сборку и тестирование. При поступлении дефектного коммита появляется красный флаг. Pull request-ы тоже должны тестироваться автоматически перед слиянием чтобы избежать багов, которые могут повлиять на всю команду.
Непрерывная доставка это расширение непрерывной интеграции. Если тесты пройдены успешно, протестированная версия автоматически пушится в среду продакшн.
Пример: в Quora отслеживают время между пушем в репозиторий и развертыванием этого кода на рабочих серверах. Последний контрольный показатель, о котором я читал, составлял 15 минут… и это примерно для 100 разработчиков. Это самая мощная система, на которую может надеяться команда.
Популярны такие серверы непрерывной интеграции как Jenkins, Travis, CircleCI, а также несколько других. Вам не нужно знать, как настраивать все, включая сервер, но нужно быть в курсе, что такие инструменты существуют, и если ваша команда таким не пользуется, в вашей голове должен прозвучать тревожный звоночек.
Заключение
Основное в работе разработчика это написание кода. Когда вы из одиночки/любителя становитесь членом команды, правильное использование ключевых инструментов совместной работы становится важным для написания чистого кода. Надеюсь, эта статья дала вам примерное представление о подобных инструментах и о том, в каком направлении копать дальше, чтобы стать лучшим в своем деле!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]