Test Driven Development и парное программирование
=================================================

Я в команде, где я пытаюсь убедить моих товарищей по команде принять TDD (как я видел его работу в моей предыдущей команды и установка аналогична). Кроме того, мое личное убеждение в том, что, по крайней мере, в самом начале, это действительно помогает, если оба TDD и парное программирование выполняются совместно. Таким образом, два неопытные (в TDD) разработчики могут помочь друг другу, обсудить, какие тесты, чтобы написать и сделать хороший прогресс.

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

Как я его убедить, что оба они дополняют друг друга и не ортогональными. Или я ошибаюсь?

 

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

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

 

Предполагают, что они читают эти книги по TDD:

[Рабочая Майкла Feather Эффективное с унаследованным кодом](http://rads.stackoverflow.com/amzn/click/0131177052)   

[классический тест-Driven Development Кента Бека - на собственном примере](http://rads.stackoverflow.com/amzn/click/0321146530)   

[Patterns XUnit Test Gerard MÉSZÁROS - Рефакторинг Код проверки](http://rads.stackoverflow.com/amzn/click/0131495054)   

[Test-Driven Development в Microsoft .NET](http://rads.stackoverflow.com/amzn/click/0735619484)  

или эти сайты в парном программировании:

[Пара программирования (Википедия)](http://en.wikipedia.org/wiki/Pair_programming)   

[Corey Haines](http://www.coreyhaines.com/)   

[Pair Программирование Световая](http://rads.stackoverflow.com/amzn/click/0201745763)

 

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

 

Вы абсолютно правы, что пара-программирование поможет очень при изучении чего-то новое. Я согласен с вами, что вы должны нажать трудно делать одновременно.

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

 

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

Я хотел бы предложить вам подойти к нему постепенно, в том, что спаривание будет только с целью выяснить, TDD, как и любые совместные усилия на новой сложной проблемой, не то, что «все развитие производства будет осуществляться в пар.»

 

В то время как одна практика не требует другого, есть «подлый» способ представить как немного в то время.

Начинайте с целью внедрения TDD с использованием одного из доступных рамок XUnit. Найти совместимый КОЛЛЕГА и спросить, если в течение приблизительно часа в день они будут готовы работать с вами. «Шон, я пытаюсь этот новый инструмент, вы бы помочь мне, чтобы убедиться, что я делаю это правильно?» работает очень хорошо.

Через пару дней с Шоном, повторить со Сьюзен ...

 

Сделай это все равно. Если менеджер ловит вас спаривание, скажем волшебные слова «Кодекс обзор»   

*Предположение: Очевидно , что пара должна быть дисциплинированной / сфокусированы достаточно и производят рабочий код в конце сессии*

 

Лично я нашел парное программирование лучше всего работает с одним опытным и один неопытный. 

Т.е. я бы стремиться к разнице в квалификации / ехре программистов, а не пытаться соответствовать равномерно умелым.

более опытный получает больше из него от объяснения и вынуждены структурировать мысли в то время как неопытный получает возможность отскочить идеи и подобрать «лучшие практики».

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

Юнит-тесты необходимы имо ... Afterall, некоторые сотрудники не будут там 2 лет. Как вы можете изменить существующий код, если нет ничего, чтобы проверить свою функцию против?

 

**Пара progamming эффективен при изучении новой практики, особенно TDD**

Таким образом, вы можете иметь и компромисс. Делайте это в гибкой манере, постепенно. Возьмите на парное программирование первым. Это легче из двух. Все практики после парного программирования станут намного легче учиться и будут приняты командой более быстро и с большим consistentcy. Парное программирование является одним из первых, если не первая engineerring практика, которая должна быть принята. Убедитесь, что это сделано эффективно. Ниже приводится описание того, как сделать парное программирование.

Соединенное программирование является одним из наиболее эффективных методов команда разработчиков может использовать при разработке программного обеспечения. Спаривание происходит с два разработчиком активно развивать сюжетную карту с помощью одного компьютера и клавиатуры. Менеджеры обеспокоены тем, что с помощью парного программирования удвоят свои затраты на программирование. На первый взгляд, это вполне понятно, почему они могли бы думать, что - после того, как все --two разработчики просят работать вместе на одной и той же задачи. На практике, однако, Проворные команды, использующие эту методику развития обнаружили, что небольшое увеличение расходов на начальное развитие (15% по данным Университета штата Юта исследования) более чем компенсированы сокращением числа дефектов, короче и дешевле тестирования цикл и уменьшить потребность в поддержке производства.

Хотя это может показаться нелогичным, что наличие программистов пары и работать вместе повышает производительность труда, существует целый ряд причин, почему этот метод действительно работает (Think старой поговорке, «Две головы лучше, чем одна.») Вот почему:

* Улучшение качества - Сопряжение поощряет обзор кода. Многие ошибки пойманы, как они набираются. Соединенное программирование означает непрерывный обзор кода сделаны два людей, которые стремятся к качеству кода и работают вместе, чтобы выявить и исправить ошибки в любое время. Исследование, проведенное в Университете штата Юта обнаружило, что конечное количество дефектов, обнаруженных в коде было снижено на 15% в среднем для кода, написанного парами.
* Чем меньше времени тратится «Штука» - Программирование трудно. Часто разработчики пытаются найти решение и тратить больше времени, чем они должны «застряли». Наличие партнера для обсуждения идей с и согласен обратиться за помощью в случае необходимости уменьшить количество непроизводительного времени, затрачиваемого застрял, пытаясь найти решение.
* Чем меньше времени тратится на Дистрактионс - разработчик, менее вероятно, проводить время на личные телефонные звонки или веб-серфинг, или по электронной почте каникул, когда он или она работает с партнером.
* Две перспектив применяются к проблеме - различные уровни опыта, различные решениям проблем стилей, различные вспомогательные навыки все увеличивают шансы решить проблему быстрее. Исследование, проведенное в Университете штата Юта также определили лучшую общую конструкцию и меньшую длину кода для программного обеспечения, написанного парами.
* Меньше страха перед неизвестностью - При сопряжении с другим разработчиком, легче решить проблему или попытаться получить ручку на новой технологии, чем она при работе в одиночку. Они также получают, в течение долгого времени, гораздо лучшее понимание всего приложения. В конце концов, проект заканчивается несколько людей понимания каждой части системы в результате спаривания.
* Менее вероятно, чтобы построить в Scope - Часто разработчики охотно добавляют функциональности не адресованную в требованиях. При работе с парой, второй разработчик, скорее всего, чтобы держать его / ее партнер по задаче.
* Улучшенная динамика команды - Из-за парной подход, люди учатся работать вместе. Они говорят чаще и опыт лучшего потока информации. Динамика команд улучшения в результате. На самом деле, мы обнаружили, что лучший тимбилдинг опыт вокруг работают вместе, чтобы программное обеспечение ваш клиент в восторге. Каждый любит быть частью успешной команды.
* Устранение Силос знаний - знаний о предметной области, знание кода или практики быстро распространяются по команде и разработчиков пары друг с другом на основе ротации.

После того, как команда с комфортным спариванию, а затем взять на TDD. Destription следующим образом:

Test-Driven Development (TDD) является инженерная практика разработки программного обеспечения, состоящий из короткого пакета развития, когда новый тест покрытия желаемого улучшения или новые функциональные возможности написано первым, то производственный код необходимо пройти тест выполняется, и, наконец, программное обеспечение переработано с учетом изменений. Наличие тестов до фактического развития обеспечивает быструю обратную связь после каких-либо изменений. Практикующие подчеркивают, что тест-разработка на основе представляет собой метод разработки программного обеспечения, а не просто метод тестирования. Тест-разработка на основе является мощной практикой и одной из основных причин снижения найденных дефектов в конце жизненного цикла. Новая команда настоятельно рекомендуется в паре с опытом TDD практиком или иным образом получить TDD coaching.e

Тест-разработка на основе требует, чтобы испытания автоматизированного узла, определяющее требование коды, записываются перед каждым аспектом самого кода. Эти тесты содержат утверждений, которые либо истинными, либо ложными. Запуск тестов дает быстрое подтверждение правильного поведения, как код развивается и переработан. основы тестирования на основе концепции XUnit обеспечивают механизм для создания и запуска комплектов автоматизированных тестов. Тест-Driven Цикл разработки: Следующая последовательность основана на книге Test-Driven Development по примеру, который многие считают канонический исходный текст на концепции в ее современном виде.

1. Написать тест. В тест-разработки на основе, каждая новая история карта начинается с написания теста. Этот тест потерпит неудачу, потому что она написана до того, как функция была реализована. Для того, чтобы написать тест, разработчик должен понимать спецификации и требования функции четко. Это может быть достигнуто путем История карт с критериями приемлемости, чтобы определить, когда требования были встретиться. Это может также означать, инвариантную, или модификацию существующего теста. Это дифференцирующий признак тест-разработки на основе против написания модульных тестов после того, как код написано: он делает акцент разработчиков на требования, прежде чем писать код, тонкое, но важное различие.
2. Выполнить все тесты и посмотреть, если новый один выходит из строя. Это подтверждает, что тест Подвесной работают правильно, и что новый тест не по ошибке проходит без какого-либо нового кода. Новый тест должен также не для ожидаемой причины. Этот шаг проверяет сам тест, в негативе: это исключает возможность того, что новый тест всегда будет проходить, и, следовательно, ничего не стоят.
3. Написать код. Следующий шаг должен написать код, который заставит тест пройти. Новый код, написанный на этом этапе не будет совершенным и может, например, пройти тест в безвкусном способе. Это вполне приемлемо, поскольку последующие шаги будут улучшать и совершенствовать его. Важно, что код, написанный предназначено только для прохождения теста; не далее (и, следовательно, непроверенная) функциональность должна быть предсказана и «позволил» на любой стадии.
4. Запуск автоматизированных тестов и увидеть их успех. Если все тестовые случаи Переходят, программист может быть уверен, что код отвечает всем испытанные требования. Это хороший момент, с которого начинается заключительный этап цикла.
5. Рефакторинг кода. Теперь код может быть очищены по мере необходимости. При повторном выполнении тестов, разработчик может быть уверен, что рефакторинг не повреждая любую существующую функциональность. Концепция удаления дублирования является важным аспектом любого дизайна программного обеспечения. В этом случае, однако, это также относится и к устранению дублирования между тестовым и кода производства - например, магические числа или строки, которые повторяются в обоих, для того, чтобы сделать тест пройти в шаге 3.

Повторение

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

Стиль развития Существуют различные аспекты использования разработки тестами, например принципы «Keep It Simple, Stupid» (ПОЦЕЛУЙ) и «ты не собираешься это нужно» (YAGNI). Сосредоточив внимание на написание только код, необходимый, чтобы пройти тесты, проекты могут быть чище и чище, чем часто достигается другими методами. Тест-Driven Development требует от программиста первого провала тестов. Идея заключается в том, чтобы гарантировать, что тест действительно работает и может поймать ошибку. После того, как это показано, нормальный цикл начнется. Это был придуман «Test-Driven Development Мантра», известный как красный / зеленый / рефакторинг, где красный цвет означает сбой и зеленый является проход. Тест-разработки на основе постоянно повторяет этапы добавления тестовых случаев, которые не, передавая их, и рефакторинга. Получение ожидаемых результатов испытаний на каждом этапе усиливает ментальную модель программиста кода, повышает доверие и увеличивает производительность

 

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