Home

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

Лучшие практики помогают обеспечивать долгосрочное здоровье ваших проектов. Но будьте осторожны и не дайте им помешать вам завершить свою работу.

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

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

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

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

Мой ответ прям и краток – в 99% случаев я не занимаюсь TDD.

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

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

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

Причина 1: время ограничено

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

В идеальном мире у разработчиков и тестировщиков достаточно времени на то, чтобы выполнить свои обычные задачи и полностью их протестировать – неважно, автотестами или старым добрым ручным тестированием. Но в реальности компании составляют сверхамбициозные расписания для большинства проектов, бросая команду разбираться со сжатыми сроками. У нас едва хватает времени на завершение задач, и командам приходится чем-то жертвовать.

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

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

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

Причина 2: ни один план не проходит проверку огнем

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

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

Кусочки паззла будут неминуемо перемещаться, добавится что-то новое, а о чем-то мы забудем навсегда. Изначальная концентрация на лучших практиках вроде TDD или тест-планов может привести к зря потраченному времени и силам. В скоростном мире разработки ПО иногда стоит быстро что-то сделать и посмотреть, как оно смотрится в проекте. Мы всегда можем что-то улучшить, как только у нас повысится уверенность в том, что необходимо для успешности проекта.

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

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

Разработка ПО – это сплошные компромиссы на пути к цели

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

В карьере разработчика я получил трудный урок: надо уметь прощаться со своим идеализмом. На заре карьеры я гордился, что следую лучшим практикам везде и всюду. Само по себе стремление выполнять работу наилучшим образом – это не проблема. Однако эта гордость вредила команде. Я иногда срывал расписание, потому что больше беспокоился о своей работе, а не о том, что делают остальные. Я возражал, как только видел что-то противоречащее моим понятиям о "правильном", чем бы это правильное ни было.

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

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

Один из самых популярных сайтов, StackOverflow, недавно опубликовал статью "Лучшие практики могут замедлить ваше приложение". Статья, в частности, объясняет, как команда намеренно пожертвовала тестируемостью ради скорости, создавая сайт. Учитывая, что сайт выдерживает десятки миллионов посещений ежедневно, это демонстрирует, что что угодно может стать компромиссом в разработке и тестировании. Как метко подмечено в статье, это лучшие, а не обязательные практики.

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

Заключение

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

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

У проектов по разработке ПО должна быть единая глобальная цель – передать заказчикам полезный продукт. Распространенные лучшие практики могут помочь, но они не обязательны. Практически каждый аспект разработки ПО – это компромисс. Это нужно понимать и быть готовым делать наилучший выбор в конкретной ситуации, даже если это идет вразрез с вашими идеалистическими представлениями.

Обсудить в форуме