Ребятки, всем привет!
Я сейчас читаю очень замечательную книжку "Как тестируют в Гугл". Вот здесь ее анонс, для тех, кто еще не видел. Электронная версия стоит всего 100 рублей, за такое содержание это просто копейки, друзья мои, очень советую. Позже я обязательно напишу ее краткий обзор. Но даже сейчас могу сказать, что она О-ФИ-ГЕН-НАЯ!!! =)
Так вот, встретилось мне в этой книге такое понятие, как DDD, которое расшифровывается не как "Domain-driven design", и даже не как "Deadline-driven development", а как "Defect-driven development".
Так что же это такое?
Defect-Driven Development — разработка через дефекты. Принцип следующий. Мы выпускаем продукт и объявляем его бездефектным. Когда пользователь находит баг, мы исправляем его и снова объявляем продукт бездефектным. Таким образом, исправляются только по-настоящему значимые баги для пользователей. Этот процесс идеален для доработки существующего продукта. Вы исправляете только важные баги, а не возитесь с дефектами, до которых никому нет дела.
Нельзя отрицать, что здравый смысл в этом подходе есть, особенно, как указано в книге, при доработке существующего продукта.
Я бы даже уточнил, что не при доработке, а на поддержке. При разработке это очевидно порочная практика, Купер во всех своих книгах ее шиббко ругает.
ОтветитьУдалитьОбратно же, исходный продукт должен быть высокого качества - см. всю остальную книгу. И только после этого - DDD. А никак не наоборот.
А также это работает при наличии эффективной обратной связи. ВебДрайвер, который пилит человек, рассказывающий о ддд - продукт для разработчиков. Они пишут в саппорт и даже сами регают тикеты. С корпоративным ПО или массовым эта акробатика может не взлететь.
Спасибо за такой подробный комментарий! Полностью согласна со всем написанным! Мне просто сама практика показалась необычной. Я думаю, пользу от нее можно также получить при бета-тестировании продукта. Чтобы расставлять приоритеты для багов более точно.
Удалить