English Version

Воркшоп: Инновационные игры в управлении требованиями

Вскоре мы проводим интереснейший воркшоп: "Инновационные игры в управлении требованиями".

Дата и время: 3 ноября, 2011, 18:00.
Продолжительность: 2 часа.
Место проведения: нас приютит Учебный Центр компании "Люксофт" по ул. Радищева 10/14.

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

Проводить воркшоп будут Александр Якима и Филипп Дзюба.

Воркшоп является открытым, однако мест есть только 20, поэтому просьба ко всем желающим принять участие - написать на alex[at]yakyma.com, указав свое имя, роль, компанию, моб. телефон.

До встречи!

Юнит-тесты: до или после кода

Когда писать юнит-тесты: до или после того, как написан код?

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

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

Действительно, (проблема 1) если тесты пишутся через достаточно длительный промежуток времени после того, как написан код - значит в код (даже если он свой) прийдется снова "въезжать". Тогда нормальное покрытие займет очень много времени или, как это случается чаще - быстренько покроется только малая часть кода.

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

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

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

Тесты желательно писать до кода, или же после кода, но чередуя код и тесты небольшими порциями, так чтобы код не успевал устаревать.

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

Наконец, не будет лишним напомнить, что любая из вышеописанных практик работает значительно лучше при общем владении кодом и тестами, а также взаимодействию разработчиков при написании юнит-тестов в отличие от индивидуальной работы.
Newer Posts Older Posts Home
Powered by Blogger