Что будешь делать, если придет пустая задача

Работа с пустыми или неполными задачами

Когда приходит пустая, неясная или неполная задача — это частое явление в разработке. Как опытный разработчик, я знаю, что правильный ответ на такую задачу критичен для успеха проекта.

Мой подход

Шаг 1: Не принимаю задачу как есть

В первую очередь я НЕ буду гадать и писать код. Пустая задача — это не задача, это проблема, которую нужно решить до разработки.

// НЕПРАВИЛЬНО: Писать код на основе предположений
public void unknownMethod() {
    // Что это должно делать? Я не знаю...
}

// ПРАВИЛЬНО: Сначала уточнить требования
throw new TaskException("Требуется уточнить требования перед началом разработки");

Шаг 2: Собираю информацию и задаю вопросы

Я немедленно обращаюсь к тому, кто дал задачу (Product Owner, Team Lead, Manager) с конкретными вопросами:

1. Что именно нужно реализовать?

   • Какой функционал?
   • Какое поведение?
   • Какой результат?

2. Зачем это нужно? (Бизнес-контекст)

   • Какую проблему решает?
   • Кто это использует?
   • Какова бизнес-ценность?

3. Какие требования к качеству?

   • Покрытие тестами?
   • Производительность?
   • Масштабируемость?
   • Безопасность?

4. Какие ограничения?

   • Deadline?
   • Технологические ограничения?
   • Совместимость с существующим кодом?

5. Приемочные критерии

   • Как понять, что задача готова?
   • Какие тесты нужны?
   • Какие метрики успеха?

Пример диалога

Таск: "Добавить аутентификацию"

Мой ответ:
"Спасибо за задачу! У меня есть вопросы для уточнения:

1. Какой тип аутентификации? JWT, OAuth2, Basic Auth, Session-based?
2. Какие источники данных? (База данных, LDAP, SSO)?
3. Какой срок разработки?
4. Нужно ли поддерживать refresh tokens?
5. Какие требования к безопасности? (HTTPS, CORS, CSRF protection)
6. Как тестировать? Интеграционные или unit тесты?
7. Какой процент код-кавериджа требуется?
8. Нужно ли логировать неудачные попытки входа?
9. Как обрабатывать просроченные токены?
10. Какие HTTP status codes возвращать при ошибках?"

Документирование уточнений

Когда я получу ответы, я документирую их:

## Задача: Добавить аутентификацию

### Требования (согласовано с Product Owner)
- Тип: JWT с refresh tokens
- Источник: PostgreSQL база данных
- Deadline: 5 дней
- Coverage: >=90%

### Приемочные критерии
- [ ] POST /auth/login возвращает JWT токен
- [ ] POST /auth/refresh обновляет токен
- [ ] GET /protected требует валидный токен
- [ ] Все endpoints покрыты тестами
- [ ] Документация обновлена

### Технические детали
- Framework: Spring Security
- Library: jjwt
- Expiration: 15 минут для access token, 7 дней для refresh

Исследование контекста

Если задача дана, но контекст неясен, я исследую:

// Смотрю на существующий код
// Есть ли похожие функции?
// Какой паттерн используется в проекте?

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    // Есть User сущность - значит нужна аутентификация пользователя
    Optional<User> findByEmail(String email);
}

// Смотрю на зависимости
// Spring Security есть? значит нужно использовать его
// JWT library есть? значит возможно JWT аутентификация

// Смотрю на другие задачи
// Есть ли связанные задачи? (Registration, Password Reset, etc.)

Если информации нет, но нужно действовать

Создаю минимальный план на основе best practices:

@Configuration
@EnableWebSecurity
public class SecurityConfig {
    // Реализую базовую SecurityFilterChain
    // С минимально достаточным функционалом
    // Оставляю TODO с вопросами для Product Owner
    
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        // TODO: Уточнить, какие endpoints требуют аутентификацию
        // TODO: Уточнить, какой тип аутентификации использовать
        
        http
            .authorizeHttpRequests(authz -> authz
                .requestMatchers("/public/**").permitAll()
                .anyRequest().authenticated()
            );
        
        return http.build();
    }
}

Коммуникация с командой

Я создаю Jira ticket с вопросами:

Эпик: Аутентификация
Таск: TASK-123 - Определить требования к аутентификации
Приоритет: High

Описание:
Для реализации аутентификации требуется уточнить:
- [ ] Какой механизм аутентификации?
- [ ] Какой срок жизни токенов?
- [ ] Какие endpoints защищены?
- [ ] Какие требования к безопасности?

Доп. comments: Ожидаю ответ перед началом разработки

Риск-ориентированный подход

Если задача критична и срок спешит:

// Вариант 1: FAST TRACK (если deadline критичен)
// - Реализую базовое решение
// - Создаю техдолг для уточнений
// - Документирую предположения

// Вариант 2: BLOCKING (если неясность критична)
// - Не начинаю разработку
// - Подчеркиваю риск неполной информации
// - Требую уточнения перед стартом

Признаки хорошей задачи

Я знаю, когда задача готова к разработке:

✓ Есть четкое описание функционала
✓ Определены приемочные критерии
✓ Есть deadline
✓ Ясен технический подход
✓ Понятны ограничения и зависимости
✓ Есть контакт для вопросов
✓ Есть информация о приоритете

Мой принцип

Я не начну разработку, пока не буду 100% уверен в требованиях. Потраченное время на уточнение — это инвестиция в качество, которая экономит времени на переработку и баги.

// Лучший результат:
// - Меньше переделок
// - Меньше багов
// - Выше качество кода
// - Счастливее team и users

private boolean isReadyToDevelop(Task task) {
    return task.hasClarity() 
        && task.hasCriteria() 
        && task.hasDeadline() 
        && task.hasOwner();
}

if (!isReadyToDevelop(task)) {
    escalateForClarification(task);
}

Вывод

Пустая задача — это не причина писать код наугад. Это причина:

1. Задать вопросы
2. Собрать требования
3. Согласовать критерии
4. Документировать предположения

Опытный разработчик знает, что час времени на правильное понимание задачи экономит 10 часов на переработку. Это показатель профессионализма, а не медлительности.