Разработчики недовольны TDD. Действительно ли TDD является проблемой, или это недостаток навыков начинающих практиков?

Question

(Это не вопрос для изучения достоинств TDD. Есть и другие места для таких обсуждений. Заранее спасибо.)

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

Я слышу негативные комментарии, такие как:

• " Мне не нравится NUnit. Я пробовал год назад, , но я забыл, как его использовать . Давайте просто использовать это приложение Windows Form, я просто вместо этого я написал ad-hoc как тестовый комплект. В любом случае, тестовый код - это одноразовый код, в чем разница? В любом случае, мой способ работал достаточно хорошо в прошлом. "

• " У меня есть оговорки по поводу TDD . По нашему последнему проекту (который был мой первый и единственный опыт работы с TDD , между прочим ), мы даже не знаем, что это за дизайн. "

• «Больше кодовых комментариев ПЛОХО? Вы с ума сошли? У меня действительно есть работа, если вы не против». (Из старой школы больше комментариев - лучшие комментарии, и вы никогда не можете иметь слишком много комментариев.)

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

И как я могу сообщить, что они не ненавидят меня за это?

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

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

Например, типично, что жалобы в сообществе разработчиков, с которыми я разговаривал:

• Никогда даже не пытался посмотреть или запомнить список запахов кода.

• Никогда даже не пытались изучать каталог рефакторингов, и они никогда не практиковали ни один из них ни в реальных проектах, ни в игрушечных проектах для обучения. Для некоторых людей там может быть гораздо больше ООП, чтобы просто научиться проводить рефакторинг очень хорошо. Рефакторинг - это гораздо больше, чем просто «метод переименования» и «переменная переименования», которые отображаются как элементы в меню рефакторинга Visual Studio 2005.

• Никогда даже не пытался изучать или участвовать в реальных проектах, реализованных с использованием Emergent Design (посредством рефакторинга), по сравнению с выполнением всего проекта с использованием дизайна заранее, по сравнению с целым проектом, написавшим модульные тесты только после написания кода и знание различий, компромиссов и применимости между ними.

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

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

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

И все же они ... Это самооборонительное поведение, я считаю. Или это лень. Если вы даже не можете назвать три рефакторинга из каталога книги Рефакторинга Фаулера, или если вы не можете назвать несколько запахов кода, вы новичок в рефакторинге, а также, вероятно, и вся методология TDD, и ваша так называемая 1 или 2 опыта проекта явно недостаточно.

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

• модульное тестирование,
• рефакторинг,
• шаблонов проектирования,
• ОО дизайн и анализ?

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

Кроме того, они идут вместе. Они не очень хорошо работают друг без друга. Модульное тестирование и рефакторинг идут вместе, как арахисовое масло и желе. Если вы не можете выполнить модульное тестирование, то с рефакторингом у вас наверняка не будет очень хороших результатов !! (Спросите меня, почему, если вы еще не знаете, я с удовольствием объясню это новым людям.)

Также жизненно важно, чтобы что бы я ни делал или говорил, чтобы оно не имело обратной силы:

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

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

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

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

Answer 1

Практически невозможно навязать свои идеи другим людям и принять их. Вы можете использовать свои собственные методы, и, возможно, другие захотят учиться, когда увидят хорошие результаты. Вы просто ожидаете, что такие вещи, как TDD, парное программирование и т. Д. Будут волшебным образом пожинать плоды?

Вы также не указываете свою роль. (или, по крайней мере, я его не нашел)

Вы можете попробовать другую тактику:

Проведите ланч-семинар по теме "TDDor nunit". Покажите преимущества, как вы их видите. Предоставьте РЕАЛЬНЫЕ примеры и реальные выгоды разработчикам / компании. Без них у вас не будет восприимчивой аудитории.

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

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

РЕДАКТИРОВАТЬ - из опыта

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

Вместо того, чтобы искать других, люди приходили, чтобы найти нас. (это был не мой план, но в ретроспективе это имеет смысл. Люди хотят результатов, а не горячего воздуха)

Answer 2

Чтобы вывести ваш вопрос в одну строку:

And how can I communicate that without them hating me for saying it?

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

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

Answer 3

Я думаю, что самая большая проблема с TDD состоит в том, что люди становятся сосредоточенными на этих тестах.

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

Разрыв между прохождением 100% ваших тестов и созданием отличных продуктов - это та часть профессии, которая называется ремеслом.

Плюс, TDD - это просто еще один способ указать дизайн. Это важная часть TDD, которая до некоторой степени блокирует дизайн.

Answer 4

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

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

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

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

Answer 5

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

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

• Пусть будет коллегиальное соревнование, чтобы узнать, кто может поддерживать покрытие кода на самом высоком процентном уровне. Людям нравится соревнование. По мере того, как они отстают или пишут код с непроверяемыми «карманами кода», возможно, они подумают о способах его рефакторинга, чтобы их тесты показали покрытие кода. Если им не нравится, когда их "обучают", пусть они сами обнаружат методы рефакторинга. Таким образом, они могут продолжать чувствовать себя умными.

• Или же есть обеды в коричневой сумке, на которых люди могут продемонстрировать какой-нибудь умный рефакторинг, который они сделали для достижения большей тестируемости. Людям нравится хвастаться! Больше, чем им нравится, когда им показывают свое невежество.

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

Как сказал Стивен Лоу в этой теме, Рим не был построен за один день.

Answer 6

Просто чтобы сыграть адвоката дьявола, почему вы так уверены, что TDD действительно эффективен? Личный опыт? Эмпирическое исследование?

Вот два исследования, которые сообщили о положительных результатах от TDD:

• http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/52/4455615/04455636.pdf?arnumber=4455636
• Последствия управляемой тестированием разработки, пилотное исследование

И два безрезультатных:

• http://www.springerlink.com/content/74145m974llj6678/
• http://cat.inist.fr/?aModele=afficheN&cpsidt=17344609

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

Answer 7

Ваш реальный вопрос: «Как убедить моих коллег попробовать что-то новое?»

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

Вы знакомы с технологическим усыновлением Lifecyle или Преодолевая пропасть ? Они касаются слоев населения и их мотивации к изменениям. Ключевая идея, которая имеет отношение к вашей ситуации, состоит в том, что только люди с левой стороны пропасти - новаторы и ранние последователи - заинтересованы в изменениях, чтобы попытаться улучшить ситуацию. Люди на правой стороне пропасти - большинство людей - более устойчивы к изменениям, и когда они действительно меняются, это не по той же причине, что и люди на левой стороне. В результате две группы, как правило, говорят друг за другом.

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

Что убедит их попробовать что-то новое, так это если оно даст надежное обещание облегчить некоторую текущую боль, которую они чувствуют.

Поговорите о том, как лучше TDD и что вы должны делать, и вы говорите мимо них.

Поговорите о том, как TDD может исправить некоторые текущие боли, вам будет их внимание.

А убийственная часть? Если в настоящее время нет боли, вы вряд ли заставите их измениться, точка.

Вот почему есть варианты «изменить свою организацию или изменить свою организацию».

Удачи!

Answer 8

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

Если вы еще не являетесь одним из наиболее уважаемых членов команды, вам нужно либо стать одним из них (продемонстрировав превосходство), либо сосредоточиться на одном или нескольких технических лидерах и привлечь их к твоя сторона.

Конечно, все люди разные, и вам придется выяснить, как представить TDD различным вождям племен, чтобы они были максимально открыты для этой идеи.

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

Answer 9

Первое, что бросилось в глаза, было: «Тестовый код в любом случае является одноразовым». Я имею в виду, вау.

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

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

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

Удачи с этим.

Answer 10

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

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