Часто мы становимся свидетелями того, как разработчики существенно опережают тесты -- предыдущий релиз все ещё тестируется, а уже ведётся разработка следующего. Такой запас непротестированного кода выльется в длинные списки дефектов, множество ветвей кода, нетестируемую функциональность и продукты, которые нельзя интегрировать или должным образом протестировать перед следующим релизом.
Это замкнутый круг бесконечных списков ошибок, проблем с регрессионным тестированием и дефектов в готовых продуктах и т.д.
Цель состоит не в том, чтобы быстрее писать код. Цель - быстрее выпустить значимый, работающий, протестированный и отлаженный код. Дороже всего обойдётся написание кода, который не приносит необходимую ценность (например, не влияет на конечный продукт). На втором месте - написание кода, который нельзя протестировать сразу.
Недавно Дерек Хютер из LeadingAgile писал о том, как добиться от команды прогнозируемых поставок (http://www.leadingagile.com/2013/05/getting-teams-to-deliver-predictably/). Он показывает, как чрезмерный объем работ в очереди тормозит производительность. Очень быстро система переполняется, приводя к увеличению времени задержки и неопределённости в потоке задач.
Итак, мы понимаем, что разработчикам невыгодно писать код, который нельзя протестировать. Даже понимающие это выражают несогласие. Они заявляют, что разработчики должны быть заняты/работать - а бездеятельность программистов экономически нецелесообразна.
Существует по меньшей мере 6 видов деятельности, которые - в отличии от написания непротестированного кода - стоят усилий и времени разработчиков.
http://www.leadingagile.com/2013/09/stop-writing-code-cant-yet-test/
Подготовится к предстоящей работе. В сложных проектах неспособность брать и выполнять обязательства приводит к задержкам, которые дорого обходятся. Вместо того, чтобы писать код, который нельзя протестировать в рамках спринта, разработчикам следует определить, какие вопросы нужно прояснить для следующих (или будущих) спринтов. В любом случае, рано или поздно им придётся это сделать. Выяснив это до начала спринта, они смогут обдуманней брать на себя обязательства.
Помочь завершить текущие задания. Разработчики могут (и должны) объединятся с тестерами, чтобы находить и исправлять ошибки, или помогать другим разработчикам в команде выполнять обязательные задания в спринте.
Расширить возможности и будущую производительность. Всегда найдутся редкие умения или знания, которыми обладают лишь несколько человек в команде. Нежели писать нетестируемый код, разработчики могут объединиться с остальными, чтобы расширить возможности и производительность команды. Даже если новичок не столь ловко использует подобные навыки или знания, как опытный участник команды, в финансовом плане такая деятельность более выгодна.
Увеличить эффективность тестирования. Максимально используя свои уникальные навыки, разработчики могут существенно увеличить эффективность тестирования путём улучшения автоматизации тестирования, установки инструментов управления тестовыми данными и работая над автоматизацией сборки. Если тестирование представляет собой “ограничение” - это превосходный вклад для команды. Таким образом, она может добиться постоянного увеличения производительности.
Рефакторить сложный код. Если код содержит запутанные участки, которые часто служат источником неумышленных ошибок, разработчики могут рефакторить такой непротестированный код. Стоит также параллельно увеличить возможность тестировать отрефакторенный код. Рефакторинг вызывает особую заинтересованность, если выполняется над участком кода, связанным с текущей работой команды.
Практика. Развивайте потенциал команды, практикуя новые навыки с помощью “code kata” (специальные упражнения в программировании). Быть продуктивным разработчиком - целое искусство. Комплекс знаний - огромный, включая шаблоны, новые функции языков программирования, приёмы тестирования и разработки, API и интерфейсы, с которыми разработчики имеют дело. Время, потраченное на практику и новые умения не считается утерянным, если помогает улучшить возможности разработчиков.
Нам нужно сосредоточиться на экономической отдаче от разработчиков. Написание ненужного кода - это пустая трата средств. Как и написание кода, который нельзя протестировать. На самом деле, выгодней вообще не писать код. Помните, цель - не в быстром написании кода, а в быстром производстве значимого, работающего, протестированного и исправленного кода. Принимайте обдуманные и эффективные экономические решения - написание нетестируемого кода таковым не является.
Источник
Комментариев нет:
Отправить комментарий