ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 358
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Парное программирование
189
Однако обе причины не являются дополняющими . Сложные тре- бования можно упростить за счет усложнения структуры про- граммы . Часто предпочтительнее найти компромисс . Программу можно упростить, подобрав подходящую конструкцию под задан- ный набор функций .
Уравновешивание сложности конструкций и функций является целью «простоты проектирования» . Применяя этот метод, про- граммисты постоянно перепроектируют структуру кода, чтобы сохранялось равновесие между требованиями и достижением наи- более высокой производительности .
ПАРНОЕ ПРОГРАММИРОВАНИЕ
Метод парного программирования за годы своего существования оброс противоречиями и кривотолками . Многие отрицательно воспринимают мысль о том, что два (и больше) человека могут плодотворно работать над одной и той же задачей .
Во-первых, работа в паре не обязательна . Никого нельзя к ней принуждать . Во-вторых, работа в паре не обязательно постоянна .
Существует много веских причин, почему иногда лучше писать код в одиночестве . Желательно, чтобы доля программистов, ра- ботающих в паре, в команде была 50 % или около того . Но это не так важно . Она может быть лишь 30 %, а может и все 80 % . Право выбора принадлежит членам команды .
Что такое парное программирование?
Парное программирование — это совместная работа двух програм- мистов над одной задачей . Напарники могут работать на одной ма-
Глава 5. Технические методы
190
шине, с одним монитором, клавиатурой и мышью . Или они могут работать на двух машинах по сети, пока могут видеть один и тот же код и обращаться с ним . Последнее прекрасно можно осуществить с помощью систем доступа к рабочему столу . Такое ПО позволяет напарникам находиться далеко друг от друга, если у них хорошая пропускная способность и голосовая связь .
Программисты, работающие в паре, выполняют разную работу .
Один будто водитель, а другой — штурман . У водителя в руках инструменты — клавиатура и мышь . Штурман же внимательно всматривается в монитор и дает советы . Другой вариант: один программист пишет тест, а второй добивается его прохождения, после чего пишет ответный тест первому программисту . Иногда этот метод называют «пинг-понг» .
Но чаще всего никакого разделения нет . Программисты просто си- дят за одной машиной и занимаются одним и тем же и по очереди используют клавиатуру и мышь .
Пары не назначаются . Они выбирают друг друга в зависимо- сти от желания совместной работы над одной задачей . Менед- жеры не должны вмешиваться со своими расписаниями или матрицами .
Чаще всего напарники быстро меняют партнера . Сессия парного программирования может длиться день, но чаще всего они длятся от силы час-два . Даже работа в паре в течение лишь четверти-полу- часа может принести пользу .
Истории не распределяются по парам . За истории отвечают от- дельные программисты, а не оба напарника . Продолжительность выполнения истории длится, как правило, гораздо дольше, чем работа с одним напарником .
Парное программирование
191
В неделю каждый программист будет тратить около половины своего времени на выполнение своих собственных задач, привлекая к помощи некоторых других программистов . Оставшуюся полови- ну времени, проводимого в паре, он потратит на помощь другим программистам с их заданиями .
Опытным программистам следует стараться как можно чаще рабо- тать в паре с младшими . Младшим программистам нужно просить помощи чаще у опытных, чем у других младших . Программисты со специализацией должны тратить значительное количество времени, работая в паре с программистами над задачами вне своей специализации . Цель состоит в том, чтобы распространять знания и обмениваться ими, а не накапливать их в одиночку .
Зачем работать в паре?
Работая в паре, мы укрепляем командный дух . Члены команды не изолируются друг от друга, а ежесекундно сотрудничают . Когда член команды не может работать, другие закрывают образовав- шуюся брешь и двигаются к цели .
Работа в паре — однозначно лучший способ обмениваться зна- ниями в команде и избегать сокрытия информации отдельными членами . Это лучший способ организовать команду так, чтобы в ней не было незаменимых сотрудников .
Многие команды сообщали, что парное программирование сокра- щает количество ошибок и улучшает качество проектирования .
Это верно в большинстве случаев . Как правило, во время работы над задачей лучше, если на нее смотрит не одна пара глаз . Дей- ствительно, во многих командах перешли от разбора кода к работе в парах .
Глава 5. Технические методы
192
Парное программирование
как анализ кода
Парное программирование представляет собой вид анализа кода
(Code Review), но имеет значительное преимущество . Работая в паре, программисты пишут код в соавторстве . Они видят уже написанный код и, как само собой разумеющееся, проводят его анализ с целью создания нового кода . Таким образом анализ кода — это не просто статическая проверка, которая проводится, чтобы убедиться в том, что код соответствует нормам, принятым в ко- манде . Скорее это динамический обзор текущего состояния кода с прицелом на то, каким код должен быть в ближайшем будущем .
А каковы издержки?
Сложно измерить издержки, возникающие при парном программи- ровании . Прямая издержка — это то, что над одной задачей работа- ет два человека . Очевидно, что на решение задачи не затрачивается двойного усилия, но, вероятно, какие-то издержки все же есть .
В разных исследованиях установлено, что издержки составляют примерно 15 % . Другими словами, потребуется 115 программистов, работающих в паре, чтобы выполнить работу 100 программистов, работающих индивидуально (без анализа кода) .
Если считать упрощенно, получается, что в команде, где в паре работают половину от всего времени, потери в производительно- сти составят менее 8 % . С другой стороны, работа в паре снимает необходимость анализа кода, и тогда нет никакой потери произ- водительности .
Затем рассмотрим преимущества — обмен знаниями, взаимное обу чение и глубокое взаимодействие . Эти преимущества невоз- можно просчитать, но они также весьма важны .
Парное программирование
193
По моему опыту и опыту многих других, программирование в паре, если оно происходит непринужденно и по желанию самих програм- мистов, приносит довольно много пользы всей команде .
Только два?
Слово «пара» подразумевает, что в сессии парного программи- рования работают только два программиста . Хотя чаще всего это так, это не строгое правило . Иногда для решения задачи может собраться группа из трех, четырех или большего количества про- граммистов (опять же на усмотрение программистов) . Это явление иногда называют «совместное программирование»
1
Менеджеры
Программисты часто опасаются, что менеджеры не одобрят работу в парах или даже потребуют разойтись и не заниматься ерундой, чтобы не тратить драгоценное время . Я с таким не встречался . За все полвека, что я занимаюсь написанием кода, я никогда не видел, чтобы менеджеры вмешивались . В большинстве случаев, по моему опыту, они только рады видеть, что программисты сотрудничают, работая вместе . Это создает впечатление, что работа кипит .
Если же вы менеджер, который хочет разогнать программистов, работающих в паре, опасаясь, что такая работа неэффективна, то отбросьте свои опасения и дайте программистам возможность решить самим . В конце концов, они профессионалы . А если вы программист и ваш менеджер требует прекратить работу в паре,
1
https://en.wikipedia.org/wiki/Mob_programming, https://mobprogramming.org/mob- programming-basics/.
Глава 5. Технические методы напомните ему, что специалист здесь вы, поэтому только вы, а не менеджер, отвечаете за то, как будет вестись работа .
И наконец, никогда в жизни не просите разрешения на работу в паре . На проведение тестирования . На рефакторинг . И прочее .
Вы профессионал . Вам решать .
ЗАКЛЮЧЕНИЕ
Технические методы Agile — наиболее важная составляющая всей методологии . Любая попытка применить Agile без технических методов обречена на провал . Причина проста: Agile — действенный механизм при работе в большой спешке, образующей большой бес- порядок . Без использования технических методов, позволяющих поддерживать высокий уровень качества кода, команда начнет стремительно и неумолимо утопать в бесконечной пучине низкой производительности .
6
ВНЕДРЕНИЕ AGILE
Глава 6. Внедрение Agile
196
Когда я впервые услышал об экстремальном программировании, то подумал: «Что может быть проще? Просто соблюдать простые правила и применять методы . Вот и все» .
Но судя по тому, сколько организаций безуспешно пытается вне- дрить Agile, реализация Agile сопровождается огромными слож- ностями . Возможно, причина всего этого в том, что во многих компаниях принимают за Agile что-то, что им не является .
ЦЕННОСТИ AGILE
Еще давно Кент Бек сформулировал четыре ценности Agile . Это смелость, взаимодействие, обратная связь и простота .
Смелость
Первая из ценностей — это смелость, или, по-другому, разумная степень принятия рисков . Члены команды, работающей по Agile, в первую очередь сосредоточены на качестве и возможностях, а не на каких-то политических мотивах . Они понимают, что лучший способ вести проект по разработке ПО в течение долгого срока — проявлять некоторую напористость .
Есть разница между смелостью и безрассудством . Чтобы раз- вернуть наименее достаточный набор функций, нужна смелость .
Смелость нужна и для того, чтобы поддерживать высокое качество кода и добросовестно применять методы . При этом безрассудно развертывать программу с неустойчивой структурой или такую, в качестве которой вы не до конца уверены . Безрассудно идти в ногу с графиком, принося в жертву качество .
Ценности Agile
197
Верить в то, что качество и дисциплина повышают скорость — смело, поскольку это убеждение будут постоянно оспаривать вли- ятельные, но наивные спешащие коллеги .
Взаимодействие
Мы ценим прямое и частое взаимодействие, которое воздвигает мосты между людьми . Члены Agile-команды хотят общения друг с другом . Программисты, клиенты, тестировщики и руководители не против находиться рядом друг с другом, часто общаться, и не только на встречах . Не только через электронную почту, сообще- ния и заметки . Они ценят личные непринужденные разговоры тет-а-тет .
Так команда становится сплоченной . Это происходит в быстром хаотичном потоке легкого и частого взаимодействия . Рождается огненная буря, несущая озарение, зажигающая лампочки в голо- вах людей . Когда вся команда в сборе, а ее члены находятся рядом и постоянно общаются, то происходят чудеса .
Обратная связь
Методы Agile, которые мы изучили, все как один направлены на отдачу быстрой обратной связи ребятам, принимающим важные решения . Игра в планирование, рефакторинг кода, разработка через
тестирование, непрерывная интеграция, небольшие и частые рели-
зы, коллективное владение, одна команда и другие методы повыша- ют частоту обратной связи и количество передаваемых сведений .
Они позволяют нам своевременно понять, что что-то идет не так, чтобы внести исправления . Они дают важные уроки того, что все
1 ... 10 11 12 13 14 15 16 17 ... 20
Глава 6. Внедрение Agile
198
решения, принятые ранее, влекут за собой последствия . Команды, применяющие Agile, успешны за счет обратной связи .
Именно обратная связь помогает команде работать столь плодо- творно и приводит проект к благоприятному исходу .
Простота
Следующая ценность Agile — это простота, другими словами, чест-
ность . Часто говорят, что каждую проблему в разработке можно решить, добавив еще один слой неясности . Но такие ценности, как храбрость, взаимодействие и обратная связь, существуют для того, чтобы свести количество проблем к минимуму .
Таким образом, неясность можно свести к минимуму . Решения могут быть простыми .
Это касается ПО, но также относится и к команде . Пассивная агрессия — это неясность и уклончивость . Когда вы видите про- блему, но молча перекладываете ее решение на кого-то другого, вы ведете себя нечестно . Когда вы соглашаетесь с требованиями менеджера или клиента, зная о губительности последствий, вы нечестны .
Простота — это честность . Честность при написании кода и чест- ность во взаимоотношениях и поведении . При написании кода в некотором количестве неясности есть необходимость . Неяс- ность — это механизм, посредством которого мы снижаем слож- ность взаимозависимости . При работе в команде в неясности куда меньше необходимости . Большую часть времени нужно быть чест- ным, насколько это возможно .
Сохраняйте простоту кода . Не усложняйте отношения в команде .
Методологический бестиарий
199
МЕТОДОЛОГИЧЕСКИЙ БЕСТИАРИЙ
В огромном количестве существующих методик Agile легко запу- таться . Я понимаю, что их тьма-тьмущая, но не обращайте на это внимания . В конце концов, независимо от того, на какие методики падет ваш выбор, вы будете подстраивать и отлаживать модель разработки под свои нужды . Таким образом, начни вы с экстре- мального программирования, Scrum или других 5328 методик, относящихся к Agile, вы придете к одному и тому же .
Настоятельный совет, который я могу вам дать, — это полностью перенять жизненный цикл, главным образом, технические методы .
Огромное количество команд переняли лишь внешнее кольцо, определяющее взаимоотношения с клиентами, и угодили в ловуш- ку, которую Мартин Фаулер назвал «дряблый Scrum»
1
. Признаки этой болезни: производительность медленно падает с высокого уровня в начале проекта до крайне низкого, когда проект подходит к концу . Причиной такой потери в производительности является искажение и ухудшение качества самого кода .
Оказывается, что методы взаимодействия с клиентами, предлага- емые Agile, — очень действенный способ создать огромный беспо- рядок . Кроме того, если вы не позаботитесь о чистоте структуры, которую выстраиваете, беспорядок будет замедлять ход работ .
Итак, выбирайте одну из методик или вообще не выбирайте . Убе- дитесь, что вы учитываете все дисциплины жизненного цикла .
Согласуйте с командой . И вперед . Помните, что смелость, взаи- модействие, обратная связь и простота позволяют с постоянством отлаживать дисциплины и методы . Не просите разрешений . Не
1
https://martinfowler.com/bliki/FlaccidScrum.html.