Как я убеждаю программистов в своей команде делать TDD? [закрытый]
5 ответов
I не знаю, что можно рассказать людям многое, чтобы убедить их в ценности TDD. Вы можете процитировать то, что нам рассказали об этом эксперты, и свой личный опыт, но если люди не хотят попробовать, шансы на то, что вы поделитесь с ними этой информацией, очень малы.
Мой опыт работы с TDD заключался в том, что это звучало как действительно хорошая идея, но так и не сработало так, как предполагалось. Затем однажды я попробовал это снова для новой задачи и в итоге получил решение проблемы, которое было проще, чем я мог подумать, полностью из-за того, что я использовал TDD. Я думаю, что когда у разработчиков появляется такой опыт, это меняет их взгляд на вещи и заставляет их с большей готовностью попробовать это в других ситуациях.
Задача состоит в том, чтобы продемонстрировать это другим разработчикам. Один из способов сделать это - использовать TDD Kata, например этот от Роя Ошерова (он использует его в своем мастер-курсе TDD). Он разработан специально, чтобы продемонстрировать ценность работы небольшими шагами, реализуя только тот код, который необходим для прохождения каждого теста. Это может показать людям, как работает процесс, и сделать их более удобными, если они попробуют.
Было также упражнение по кодированию, о котором я слышал, когда вы дали двум группам / командам разработчиков достаточно простую задачу и попросили одну из групп использовать TDD и убедиться, что они следуют «простейшей вещи, которая может сработать» правил, в то время как другая команда делала то, что хотела. Затем, как только это будет сделано, команды поменяются задачами, но выбросят код, написанный каждой командой, оставив только тесты. Затем команды должны воссоздать код для задачи. Обычно вы обнаружите, что команде, которая наследует код TDD, намного проще это сделать.
Однако, учитывая все это, я думаю, что лучшее , что вы можете сделать лично, - это начать выполнять TDD самостоятельно в максимально возможной степени. Это может дать вам некоторые очень конкретные ссылки на то, где и как TDD оказался полезным в контексте текущего проекта. В частности, если вы проводите анализ кода, ваши коллеги могут заметить, что код, который вы пишете TDD, более краток и проще в обслуживании, чем код, который был написан без TDD. Ваша команда QA может также заметить разницу в качестве кода, что является одной из вещей, которые вы часто слышите о компаниях, которые переходят на TDD.
Возможно, поможет примерное руководство:
Начните работать так же самостоятельно
Возможно, создайте учебник \ скрипт для настройки среды (IDE), которая не добавит накладных расходов на TDD process:
- Запуск тестов с помощью одного сочетания клавиш
- Графический интерфейс тестовой системы должен присутствовать в представлении разработки (а не только в представлении тестирования, поэтому вам не нужно перемещаться между ними)
Я предполагаю, что через некоторое время люди будут интересоваться и спросить вас, действительно ли эта вещь TDD работает, у вас должен быть готовый ответ на этот вопрос: -)
Пара предложений. Ваша практичность может варьироваться:
- Привлечь на свою сторону одного или двух человек: вашего босса, стажера и т. Д. В первую очередь. Ваш первый последователь сделает вас лидером.
- Начать парное программирование или наставничество. Даже если это всего лишь один или два стажера, тесное сотрудничество с кем-то может быть хорошим способом повлиять на его стиль.Если хотите, можете попробовать стать менеджером.
- Сделайте техническую презентацию по теме. Сосредоточьтесь на том, почему и на какой проблеме вы решаете, а не на TDD. Вы хотите, чтобы люди купились на проблему, а не на ваше конкретное решение. Включите пару других альтернатив, чтобы не казалось, что вы просто пытаетесь продвигать то, что работает для вас.
- Пройдите внешнее обучение у Наставник по объектам или тому подобное. Лучше всего работает, если вы можете убедить своего босса и команду не из кучки закаленных бездушных циников.
Честно говоря, вы должны всегда просто использовать цикл разработки/тестирования, который работает.
Многим людям нравится TDD, и многие крупные игроки, такие как Google, приняли его; из-за высокого тестового покрытия.
Однако, похоже, что вы и ваша команда прекрасно обходитесь без него - и помните, что изменение стиля разработки снижает производительность, по крайней мере, на время. Так что помните старую пословицу: не меняйте то, что работает.
Однако, если вы и ваши клиенты обнаруживаете, что все еще существует множество ошибок, которые тесты не покрывают, TDD - идеальный способ решить эту проблему, поэтому вы должны сказать руководству, что TDD - это способ повысить удовлетворенность клиентов и тем самым заработать деньги. (Это для вас язык руководства!)
.Вы вообще сталкивались с BDD? Там есть изменения в словаре, которые, как мне кажется, очень помогают новичкам в TDD. Вот изменение лексики:
http://lizkeogh.com/2009/11/06/translating-tdd-to-bdd/
Я обнаружил, что использование этого языка помогает людям сосредоточиться на том, почему полезно сначала писать тесты (или примеры). Я перевел еще один пример в комментариях.
Даже в этом случае иногда полезно узнать, как структурируются тесты. Если людям трудно научиться писать их сначала, то их написание после - хороший шаг в обучении. Вы правы насчет преимуществ дизайна. Это может занять некоторое время, чтобы понять.
В прошлом я обнаружил, что лучший способ освоить TDD - это иметь безопасную среду для практики. Наличие собственного игрушечного приложения или проведение/посещение семинаров, основанных на игрушечном приложении, очень помогли мне.