Искусство Agile-разработки. Теория и практика гибкой разработки ПО. Шэйн Уорден
Чтение книги онлайн.

Читать онлайн книгу Искусство Agile-разработки. Теория и практика гибкой разработки ПО - Шэйн Уорден страница 23

СКАЧАТЬ инвестиции обычно не проблема, но если они вдруг становятся проблемой, то могут затормозить вас намертво. Так что уделите им внимание, особенно если вы работаете в индустрии, имеющей повышенную чувствительность к безопасности.

      Проблема в том, что работающие очно команды, которые используют такие практики, как парное программирование и групповое програмирование (моб-программирование) (см. соответствующие разделы главы 12), работают вместе за одним компьютером. Это может беспокоить с точки зрения безопасности, поскольку человек, который вошел в систему, не всегда тот же, кто сейчас сидит за клавиатурой. Фактически человек, который авторизовался в системе, может ненадолго отойти, чтобы поговорить с кем-то или посетить уборную. Набирая код, люди часто меняются (буквально каждые несколько минут), поэтому выходить из системы каждый раз, когда вводить код должен другой человек, и затем снова входить нереально.

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

      С этим связана проблема возможности отслеживания. Некоторые компании требуют, чтобы каждое внесенное изменение (commit) можно было отследить до его автора. Это требование можно выполнить, добавив инициалы или адрес электронной почты в коммит-комментарий команды. У Git есть соглашение о том, чтобы добавлять строку Co-authored-by в конце каждого коммит-сообщения[13].

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

      Если требования безопасности не допускают гибкости…

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

      Кроме того, команды могут использовать инструменты, предназначенные для совместной удаленной работы, вместо СКАЧАТЬ



<p>13</p>

Спасибо Джею Базузи за то, что обратил мое внимание на эти соглашения о commit-сообщениях (https://oreil.ly/7vSmz).