Основные навыки, которыми должен обладать каждый разработчик (кроме кодировки)

osnovnye navyki kotorymi dolzhen obladat kazhdyj razrabotchik krome kodirovki

Независимо от того, учитесь ли вы кодировать, ищете новую работу или просто хотите усовершенствовать свои навыки разработчика, вам нужно овладеть основными инструментами командного сотрудничества. Это так же важно, как и знание кодировки.

Именно командная работа создает или разрушает проекты программного обеспечения.

Ваш код со временем заработает. Если вы хотите, чтобы это работало «вовремя» и было качественно, вы и ваша команда должны быть организованы.

  • Каждый должен знать, что и когда он должен делать
  • Работа людей не должна совпадать или совпадать
  • Общие правила должны соблюдать все

Вы можете добиться этого, используя правильные процессы и инструменты. Вы хотите, чтобы ваша команда сосредоточилась на кодировке 90% времени (остальные 10% приходится на перерывы на кофе и обновление Windows).

Вот три главных вещи, которые вам необходимо освоить.

Запросы Git и Pull

Управление конфигурацией является основой командного сотрудничества в программном обеспечении. Для этого существует много инструментов, но, к счастью, один стал абсолютной и окончательной ссылкой: Git.

Документация по ключевым аспектам хорошо описана в книге Git.

Есть много готовых услуг для начала: GitHub, пожалуй, самый популярный, но также BitBucket или GitLab.

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

Ниже приведены вопросы, на которые вы должны знать, как ответить:

Вот и все, и это достаточно просто. Прочтя теорию и немного попрактиковавшись, вы мгновенно станете мастером Git.

Доска Agile

Первое, что должна сделать команда, начиная проект или более масштабную задачу, это разделить работу. За последние 10 лет методология «Agile» заменила традиционную водопадную планировку. Манифест Agile здесь.

Практически говоря, это говорит «не будем слишком много заранее, потому что входящие данные и предположения, которые мы имеем сегодня по проекту, изменятся». Это почти всегда правда, и в наше время вряд ли найдется команда под солнцем, которая не была бы (иногда самопровозглашенной) «Agile».

Вот практичные вещи, которые вам нужно знать:

  • Самым популярным способом работы Agile является Scrum. Разделите свой проект на спринты по две недели и добавьте задачу к содержанию спринта. Все остальное – это на будущее и называется «бэклог». Это полезно для отслеживания прогресса, коррекции планирования на будущее и повышения скорости работы команды со временем.
  • Еще один гибкий подход – Kanban. Идея состоит в том, чтобы ограничить количество «разрабатываемых» задач. Таким образом вы точно закроете один элемент, прежде чем переходить к следующему. Здесь нет спринтов или временных рамок, как у Scrum. Вы просто выполняете задание одно за другим, пока не закончите.

В Agile программный проект будет разбит на десятки или сотни задач. Для управления ими требуется инструмент. Справочным инструментом является JIRA.

Другие инструменты, конечно, существуют, но вам, вероятно, когда-нибудь придется работать с JIRA. Итак, если вы новичок во всех этих инструментах, просто выберите JIRA. Есть бесплатная 7-дневная пробная версия. Этого предостаточно, чтобы получить общее представление о том, как все работает. Опять же это довольно просто и очень хорошо задокументировано.

Тестирование и постоянная интеграция

Инструменты Git и Agile позволяют командам быстро работать. Со скоростью неизбежно появляются ошибки и ошибки. Рассмотрим команду из пяти разработчиков, работающих над достаточно независимыми фрагментами кода. Каждый из них запросит подключение к хранилищу. Могут возникнуть две проблемы:

  • Когда код первого разработчика попадает в репозиторий Git, код других больше не действителен и не работает, поскольку некоторые вещи изменились. Это не ошибка «первого разработчика», это просто жизнь и она будет.
  • После того, как все разработчики поместят свой код в хранилище Git, все заработанные шансы, как ожидалось, будут достаточно низкими. Опять же, это не отражение плохой командной работы. Это просто произойдет.

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

Когда другие разработчики будут продвигать свой код, нам придется повторить эту задачу. Следует ли тестировать, когда каждый введет свой код? Тоже отлично, но вы найдете ошибки на позднем этапе процесса, что может задержать весь проект. Итак, как вы можете это решить?

Автоматизированные тесты и непрерывная интеграция здесь в помощь.

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

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

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

Continuous Delivery является расширением Continuous Integration. Если тесты прошли правильно, проверенная версия автоматически отправляется в рабочую среду.

Как пример: в Quora они отслеживают время между отправкой в ​​репозиторий и развертыванием этого кода на рабочих серверах. Последний тест, о котором я читал, был 15 минут… для примерно 100 разработчиков. Это мощная установка, на которую может надеяться команда.

Популярными серверами непрерывной интеграции являются Jenkins, Travis, CircleCI и некоторые другие. Вам не нужно знать, как настроить сервер и все такое, но вы должны знать, что такие инструменты существуют, и если ваша команда не использует ни одного, в вашей голове должно сработать красное предупреждение.

Вывод

Основой работы разработчика является кодировка. Когда вы переходите от соло/хобби к члену производительной команды, правильное использование ключевых инструментов для сотрудничества так же важно, как написание чистого кода. Надеемся, эта статья дала вам общее представление о том, что это за инструменты и как копать дальше, чтобы быть лучшим в том, что вы делаете!

Спасибо за чтение! Если вы считаете статью полезной, нажмите кнопку «хлопать» ниже. Для меня это будет очень важно, и это поможет другим увидеть историю!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *