В каком виде задачи приходили на плохом месте работы

# В каком виде задачи приходили на плохом месте работы

Это вопрос о практическом опыте работы в условиях, когда процессы разработки не оптимизированы. Мне приходилось сталкиваться с несколькими типичными проблемами.

Типичные проблемы с задачами

1. Размытые и неполные требования

Проблема:

Тикет #123: "Нужно сделать быстрее"
Описание: none
Приоритет: CRITICAL!
Дедлайн: "вчера"

Как выглядели наши вопросы:

• Что означает "быстрее"? На сколько процентов?
• Какой код именно? Какой метод?
• На каких данных нужна скорость?
• Это для конкретного клиента или всех пользователей?

Как мы решали:

// Начинали с неполной информации
public class OrderProcessor {
    public List<Order> getOrders() {
        // Было медленно, но не знаем почему
        return database.query("SELECT * FROM orders");
    }
}

// Потом добавляли профилирование
public List<Order> getOrdersOptimized() {
    long start = System.currentTimeMillis();
    List<Order> orders = database.query(
        "SELECT * FROM orders WHERE created_at > ?",
        lastDay
    );
    System.out.println("Query time: " + (System.currentTimeMillis() - start) + "ms");
    return orders;
}

2. Постоянные переделки

Цикл боли:

1. Разработал функцию A
2. Через неделю: "А давай переделаем на функцию B"
3. Переделал на B
4. Через день: "Функция B не подходит, нужна C"
5. Тестер говорит: "А может быть D?"

// Версия 1 - синхронный поиск
public List<User> searchUsers(String query) {
    return db.query("SELECT * FROM users WHERE name LIKE %" + query + "%");
}

// Версия 2 - асинхронный
public CompletableFuture<List<User>> searchUsers(String query) {
    return CompletableFuture.supplyAsync(() -> 
        db.query("SELECT * FROM users WHERE name LIKE %" + query + "%")
    );
}

// Версия 3 - с пагинацией
public Page<User> searchUsers(String query, Pageable pageable) {
    return db.queryPaged("SELECT * FROM users WHERE name LIKE %" + query + "%", pageable);
}

// Версия 4 - с кешем
@Cacheable(value = "userSearch")
public Page<User> searchUsers(String query, Pageable pageable) {
    return db.queryPaged("SELECT * FROM users WHERE name LIKE %" + query + "%", pageable);
}

// Версия 5 - с полнотекстовым поиском
@Cacheable(value = "userSearch")
public Page<User> searchUsers(String query, Pageable pageable) {
    return db.fullTextSearch(query, User.class, pageable);
}

3. Нарушение сроков и срочные правки

Типичный сценарий:

Пт 17:00 - "К понедельнику нужна новая фича на production"
Пт 18:00 - Начинаем писать код
Пт 23:00 - Первая версия готова
Сб 10:00 - QA нашел 5 багов
Сб 15:00 - Исправили 3 бага, осталось 2
Вс 19:00 - Наконец все работает (хотим надеяться)
Пн 09:00 - Деплоим в prod с молитвами
Пн 10:30 - Критический баг - откатываем
Пн 11:00 - Пишем fix на коленке
Пн 12:00 - Деплоим снова

Результат:

// Код писался под давлением
public class OrderService {
    public Order createOrder(OrderRequest request) {
        // TODO: Fix this later (написано 6 месяцев назад)
        // TODO: Add validation
        // TODO: Add error handling
        
        Order order = new Order();
        order.setUserId(request.getUserId());
        order.setAmount(request.getAmount());
        // Забыли про tax, shipping, discount
        
        db.save(order);
        // Забыли про notification
        // Забыли про audit log
        return order;
    }
}

4. Отсутствие документации

Как выглядели запросы:

• "Где документация на этот module?"
• "Кто писал эту функцию?"
• "Почему здесь такая странная логика?"
• "Это баг или фича?"

// Код без документации
public class PaymentProcessor {
    public boolean processPayment(double amount, String code) {
        if (amount > 10000) {
            return false;  // Почему? Баг? Сделано специально?
        }
        // ...
    }
    
    public void retryLogic(Payment p, int attempts) {
        // Магические числа везде
        for (int i = 0; i < 3; i++) {
            try {
                process(p);
                break;
            } catch (Exception e) {
                if (i == 2) {  // Почему именно на третий раз?
                    Thread.sleep(1000 * (i + 1));  // Почему эта задержка?
                    throw e;
                }
            }
        }
    }
}

// Как должно быть
/**
 * Обрабатывает платеж с ограничениями по сумме
 * 
 * @param amount Сумма платежа (максимум 10000 для anti-fraud protection)
 * @param code Код авторизации
 * @return true если платеж успешен, false если превышен лимит
 */
public boolean processPayment(double amount, String code) {
    final double MAX_AMOUNT = 10000;  // Anti-fraud protection
    if (amount > MAX_AMOUNT) {
        return false;
    }
    // ...
}

5. Отсутствие тестов и низкое качество кода

Типичная ситуация:

• "Тесты займут время, надо быстрее кодить"
• "QA сам протестирует"
• "На production никто не будет менять этот код"

Результат:

// Код без тестов - завтрашние баги
public class EmailService {
    public void sendEmail(String to, String subject, String body) {
        if (to == null || subject == null || body == null) {
            // Что-то там делаем? Кидаем exception? Игнорируем?
            // Никто не знает
        }
        
        if (to.contains("@")) {  // Валидация через contains()? Серьезно?
            // Отправляем
        }
        
        // Нет retry логики
        // Нет логирования
        // Нет timeout
    }
}

// Как бы это выглядело с тестами
@Test
public void testSendEmailWithValidAddress() {
    emailService.sendEmail("test@example.com", "Subject", "Body");
    verify(mailClient).send(argThat(
        msg -> msg.getTo().equals("test@example.com")
    ));
}

@Test
public void testSendEmailWithNullTo() {
    assertThrows(IllegalArgumentException.class, () ->
        emailService.sendEmail(null, "Subject", "Body")
    );
}

@Test
public void testSendEmailWithInvalidFormat() {
    assertThrows(IllegalArgumentException.class, () ->
        emailService.sendEmail("invalid-email", "Subject", "Body")
    );
}

6. Отсутствие code review

Как было:

• Код merges сразу в main без review
• "Я доверяю опыту этого программиста"
• Потом находились баги в production

7. Частые production инциденты

Пн 3:00 AM - Production down!
Пн 3:15 AM - Разбираемся что сломалось
Пн 3:45 AM - Нашли проблему
Пн 4:30 AM - Зафиксили (может быть)
Пн 5:00 AM - Деплоим
Пн 5:30 AM - Все работает (хотим надеяться)
Пн 9:00 AM - Планируем postmortem
Пн 10:00 AM - Никто не знает что произошло
Пн 11:00 AM - Забыли про incident
Пн 15:00 AM - Снова то же самое

Выводы и как с этим работать

Мне удавалось улучшить ситуацию через:

1. Документирование - начал писать README на каждый module
2. Автоматизация - завел CI/CD pipeline
3. Code Review - настоял на code review перед merge
4. Тесты - начал писать unit tests для критичного кода
5. Мониторинг - добавил логирование и алерты на production проблемы
6. Четкие требования - предложил шаблон для задач

Ключевой вывод: Хороший процесс разработки экономит больше времени, чем "быстрое" написание кода без планирования.