Поскольку в январе 2017 года начался новый семестр программы Master for Digital Media (MDM), я начал проект с новой задачей: работать в Agile-команде с несколькими разработчиками из разных колледжей.

В команде из 6 человек я отвечал за создание хорошей среды разработки и конвейера для 3 программистов с разным уровнем опыта в методологии Agile. Для меня это, безусловно, было большим испытанием, хотя я не впервые сталкиваюсь с такой ответственностью. Благодаря моему опыту работы в Agile-команде, я предложил некоторые решения, а также правила игры для этой команды программистов. Это играет важную роль в создании согласованной среды и мышления среди программистов, поэтому помогает нам избежать конфликта и ускорить процесс разработки.

До сих пор наша команда хорошо работала с конвейером и правилами, которые мы установили. Вот несколько рекомендаций о том, как создать эффективную команду программистов.

Правило №1: Иметь общее окружение

Прежде чем мы начали работать вместе, мы все согласовали и подписали устав команды. Я обнаружил, что устав команды - важный документ для каждой Agile-команды, который помогает определить роль каждого члена, а также то, как команда будет работать вместе, чтобы удерживать всех на одной странице в течение всего проекта. Устав команды еще более важен, когда в команде несколько членов, выполняющих одну и ту же роль. В нашем случае это помогает нам определить руководящие принципы, которым должны следовать все программисты при кодировании, которые включают:

  • Контроль версий:
    Контроль версий (или контроль версий), который обычно считается обязательным для любой команды программистов, представляет собой инструмент управления, который помогает всем разработчикам и другим участникам отслеживать изменение и обновление программного обеспечения. В настоящее время обычно используются три основных элемента управления версиями: GitHub, BitBucket и GitLab (это инструмент, который наша команда использует для проекта). Базовый рабочий процесс этих трех инструментов точно такой же. Таким образом, устав команды должен определять инструмент, который вся команда будет использовать для разработки.
    Однако не каждая команда знает, как эффективно использовать контроль версий. О том, какой рабочий процесс мы используем, я расскажу в следующей части статьи.
  • Соглашение об именах:
    Хорошее именование значительно поможет вашей команде сократить время на чтение и понимание сценария, который пишут другие. Распространенная ошибка, которую допускают многие программисты, - это использование бессмысленного имени для переменной или объекта, например, именование всего одной буквой. Просто помните, что если вы работаете в команде, вы не единственный, кто читает и исправляет ваш код. Следовательно, имена файлов, классов, функций и переменных всегда должны быть значимыми, что может четко выражать ваше намерение во время кодирования. Вот правила именования, которые мы включили в устав нашей команды:
    - Имя для классов: имя класса должно быть существительным в соответствии с соглашением PascalCase, в котором первая буква каждого слова пишется с заглавной буквы. Например, «PlayerController».
    - Имя для методов: имя метода должно быть глаголом в соответствии с соглашением PascalCase, в котором первая буква каждого слова пишется с заглавной буквы. Например, «StartCoroutine ()».
    - Имя для переменных: имя переменной должно быть коротким существительным в соответствии с соглашением CamelCase, в котором первая буква первого слова находится в нижнем регистре. , первые буквы последующих слов в верхнем регистре. Например, «absolutePosition». Имя логической переменной должно иметь форму вопроса Да / Нет. Например, «isEnabled».
    - Имя для константы: все буквы в имени константы должны быть в верхнем регистре. Например, «PI».
    - Имя для файлов: имя файла следует правилам PascalCase, в которых первая буква каждого слова пишется с заглавной буквы. В случае, если существует несколько копий элемента (например, мы хотим сохранить копии более старых версий файла), добавьте «-copy [номер копии]» в конец имени файла. Например, «ThisThing-copy1»
  • Комментарий:
    Комментарий в коде всегда недооценивается программистами, которым не хватает опыта работы в команде. Опять же, комментарий может значительно улучшить читаемость вашего кода, что затем может помочь другим, с кем вы работаете и которые могут унаследовать код (если вы работаете вне проекта), гораздо быстрее понять ваш фрагмент кода.

Правило № 2: эффективно используйте контроль версий

Для тех, кто никогда раньше не работал с системой контроля версий, эта инфографика с git-tower.com даст вам общее представление об ее основном рабочем процессе.

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

Кроме того, вот некоторые правила, которым наша команда следует, чтобы держать нас на одной странице и избежать конфликтов:

  • Всегда загружайте, прежде чем начинать работу, чтобы быть в курсе того, над чем работают другие. После прочтения всех внесенных изменений потяните за собой.
  • Не работайте с одним и тем же файлом одновременно. В нашем проекте каждый программист работает только с одной функцией за раз, поэтому мы можем избежать ситуации, когда нескольким программистам нужен доступ к одному и тому же скрипту. В случае, если кому-то нужно изменить чей-то скрипт, просто извлеките, поймите сообщение фиксации и спросите у автора разрешения на его изменение.
  • Будьте ответственны за то, что вы делаете. К каждому отправляемому обновлению или модификации должно быть приложено соответствующее сообщение фиксации, в котором четко объясняется, как скрипт изменился по сравнению с последним обновлением.
  • Работайте с несколькими ветвями вместо одной главной. Если кому-то нужно работать над новой функцией, мы создадим новую ветку в системе контроля версий, которая отслеживает только эту функцию. В конечном итоге ветвь будет объединена после того, как мы рассмотрим все возможные конфликты слияния.

Правило № 3: Пишите код для всех

Одно важное правило, которое я всегда напоминаю себе и другим программистам, - это писать чистый код. Написание функционального кода никогда не бывает достаточно. Я часто считаю программиста писателем, чьей аудиторией является не только компьютер (которому наплевать на ваш беспорядок), но и другие программисты (которые могут тратить часы только на чтение и понимание вашего кода). Таким образом, каждый программист в нашей команде несет ответственность за написание осмысленного, описательного и читаемого кода, чтобы другие участники команды могли его прочитать. Это правило чрезвычайно важно, когда мы работаем в небольшой команде, где каждый должен иметь в виду всю картину проекта и понимать, что делают другие.

Распространенная ошибка, которую мы часто совершаем в начале проекта, - это слишком быстрое стремление к новому прототипу и, как следствие, беспорядочное создание сценария с тоннами нечитаемых строк кода. Обычно это происходит, когда команде программистов приходится работать под большим давлением процесса спринта и, таким образом, пренебрегать своим собственным кодом. Тем не менее, организованный код на самом деле значительно ускоряет работу для долгосрочного проекта, чем написание беспорядочного кода с самого начала.

Нам нужно помнить один факт, который Роберт С. Мартин указывает в своей книге Чистый код: руководство по созданию гибкого программного обеспечения: «Отношение времени, затрачиваемого на чтение и на письмо, значительно превышает 10 к 1. Мы постоянно читаем старый код, чтобы написать новый код ». Мы можем писать сотни строк кода в день в начале проекта, но по мере того, как он начинает расти, темп значительно замедлится, так как будет появляться больше ошибок и ошибок, которые потребуют от нас постоянного чтения. и исправьте перед написанием любого нового кода. На этом этапе плохо написанный код станет кошмаром для всех программистов, что может занять у команды не несколько часов, а несколько дней на чтение и отладку.

Это два примера плохого и чистого кода, которые ясно показывают большую разницу в уровне описания, которое дается читателю:

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

Правило №4: Уважайте других и учитесь у них

У всех разный стиль письма, есть разные способы подойти и решить каждую проблему. Если они не напишут плохой код, который может замедлить весь прогресс, всех программистов в нашей команде уважают и поощряют к созданию своего собственного способа кодирования.

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

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

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