Дата публикации: 13.06.2025
Драйв-бай разработка: 10 багов, 1 час, поехали!
Содержимое статьи:
В мире разработки программного обеспечения существуют различные подходы к решению задач. Один из, скажем так, мотивирующих подходов можно описать следующим образом:
Суть метода "Драйв-бай"
"Драйв-бай разработка" – это когда скорость и количество превалируют над качеством и устойчивостью кода. Основные принципы:
- Таймер как мотиватор: Остался час до конца рабочего дня? Отлично, время "ускориться".
- Приоритет – количество: 10 багов до конца дня - это не просто цель, это указ.
- "Работает? Значит, хватит!": Поверхностная проверка достаточно хороша, главное – закрыть задачу.
- Кофе (энергетики) как топливо: Без комментариев.
Тактика "Драйв-бай" в действии
Вот как это может выглядеть на практике:
- Получение списка багов:
- "Срочные" (на самом деле, просто попались под руку тестировщику).
- "Незначительные" (но сильно раздражающие менеджера).
- "Потенциальные" (которые, возможно, когда-нибудь проявятся).
- Метод "скорой помощи":
- Быстрое исправление кода без глубокого понимания.
- Копирование и вставка кода из Stack Overflow (с минимальными изменениями).
- Игнорирование code review (времени нет!).
- Тестирование (минимальное):
- Проверка, что баг "вроде бы" исчез.
- Отсутствие юнит-тестов (кто их вообще пишет?).
- Надежда на то, что все будет хорошо (или хотя бы до завтра).
Возможные последствия
Этот подход может привести к:
- Техническому долгу: Код становится сложным и трудноподдерживаемым.
- Новым багам: Исправление одного бага может вызвать несколько других.
- Снижению мотивации разработчиков: Постоянный стресс и отсутствие времени на качественную работу.
- Разочарованию пользователей: Продукт становится нестабильным и ненадежным.
- Желанию разработчика поискать другую работу: В более спокойной обстановке.