Обновление от 26 января 2019 г .: Мне стало известно, что утверждение «исправление производственной ошибки может стоить в 100 раз больше, чем исправление ошибки во время разработки». апокрифический. Я по-прежнему поддерживаю положительную рентабельность инвестиций и экономию времени TDD, но вы должны воспринимать это как субъективное мнение, а не как научный факт. Наша отрасль остро нуждается в улучшенном сборе данных о влиянии TDD и других мер контроля качества. Это было бы отличным предметом для исследовательского сотрудничества между университетами и крупными организациями, занимающимися разработкой программного обеспечения.

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

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

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

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

Эти менеджеры должны знать, что TDD снижает количество ошибок в производстве на 40–80%, и в этом вся разница. Увеличение количества ошибок в производстве приводит к резкому увеличению затрат на обслуживание.

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

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

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

В нашем вымышленном примере мы сэкономили 623 человеко-часа, или, для команды из 4 человек, около месяца разработки. Если мы заплатим каждому разработчику в среднем по США (95 тыс. Долларов) и добавим в среднем 30% к зарплате для покрытия льгот, то получим экономию почти в 37 000 долларов.

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

Вот сделанные предположения:

  • Ошибок производства без TDD: 100
  • Производственные ошибки с TDD: 40 (на 60% меньше, средний уровень между 40% - 80%)
  • Среднее время исправления ошибки на этапе реализации (TDD): 1 час (это число используется только для определения стоимости исправления ошибки в производственной среде)
  • Среднее время исправления производственной ошибки: ~ 15 часов

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

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

Кодовые рецензии имеют схожие эффекты

Проверки кода имеют аналогичный эффект. Фактически, некоторые исследования показали, что обзоры кода более эффективны, чем TDD. Согласно исследованию 1988 года, каждый час, потраченный на проверку кода, экономит 33 часа на обслуживании.

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

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

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

Стоимость перерывов

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

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

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

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

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

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

Заключение

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

Дальнейшие действия

Получите лучшее представление о TDD и его роли в процессе разработки программного обеспечения:

Повышайте уровень своих навыков с живым наставничеством 1: 1

DevAnywhere - это самый быстрый способ повысить уровень навыков JavaScript:

  • Живые уроки
  • Гибкий график
  • 1: 1 наставничество
  • Создавайте настоящие производственные приложения

Эрик Эллиотт является автором Программирования приложений JavaScript (O’Reilly) и соучредителем DevAnywhere.io. Он участвовал в разработке программного обеспечения для Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC и ведущие музыканты, включая Usher, Frank Ocean, Metallica и многие другие.

Он работает где угодно с самой красивой женщиной в мире.