Если горят сроки на проекте, сделаешь грязно, но быстро или дольше, но чисто

Сроки vs качество кода

Это классический вопрос на собеседовании о приоритизации, и мой ответ: это не дихотомия, нужно найти баланс. Но если действительно горят сроки — я буду прагматичен.

Моя стратегия

Не выбираю между "грязно и быстро" или "долго и чисто". Я бы выбрал третий вариант: "быстро и достаточно чисто".

Вот как я это делаю:

1. Определяю критические части

# Плохо: одинаково подходить ко всему коду

# Хорошо: различать уровни важности

# КРИТИЧЕСКОЕ (надежность, безопасность)
# - Обработка платежей
# - Аутентификация
# - Работа с БД
# ЗДЕСЬ я НЕ спешу, пишу чисто, с тестами

# ВАЖНОЕ (core логика)
# - Бизнес-логика
# - API endpoints
# ЗДЕСЬ я ищу компромисс: чистый код, но минимум тестов

# МЕНЕЕ КРИТИЧЕСКОЕ (UI, отчеты)
# - Оформление интерфейса
# - Скрипты один раз
# ЗДЕСЬ можно спешить, главное чтобы работало

2.技術 долг с умом

Я готов брать технический долг, но осознанно:

# Вместо:
# data = parse_complex_json_somehow()

# Пишу временное решение с комментарием:
def process_data(raw_data):
    # TODO: Переписать парсер в отдельный модуль после релиза
    # Временная реализация для спешки, работает для текущего кейса
    data = json.loads(raw_data)
    return [item['value'] for item in data]

Почему это важно:

• Я помню о долге
• Коллеги видят, что это временное
• Можно быстро найти и исправить

3. Не экономлю на критическом

# НЕ ЭКОНОМЛЮ здесь:

class PaymentProcessor:
    def charge_user(self, user_id: str, amount: Decimal) -> bool:
        # Пишу ПОЛНОСТЬЮ
        # - Валидация входных данных
        # - Обработка ошибок
        # - Логирование
        # - Роллбэк при ошибке
        # - Тесты (100% покрытие)
        pass

# МОГУ СЭКОНОМИТЬ здесь:

class ReportGenerator:
    def generate_weekly_report(self) -> str:
        # Простое решение, работает
        # Тесты не критичны
        # Комментарии минимальные
        pass

4. Автоматизирую, чтобы быть чистым быстро

# Использую инструменты, чтобы не тратить время на форматирование

# - ruff, black для форматирования (авто-исправление)
# - mypy для типизации (поймает баги быстро)
# - pytest с кешем (тесты за секунды)
# - pre-commit hooks (не забуду форматировать)

# Это экономит время, а не его тратит

5. Общаюсь с командой

Наступает критичный момент — я обсуждаю приоритеты с лидом:

Лид: "Нужно 2 часа на фичу"
Я: "За 2 часа я сделаю быстро-и-грязно. За 4 часа — нормально.
     Какой вам важнее? Может быть, можем урезать требования?"

Это часто помогает найти компромисс.

Реальный пример из моего опыта

Ситуация: Нужно интегрировать новый платежный API за день до релиза.

Что я сделал:

1. Критичное (3 часа, всё чисто):

   • Реализовал обработку платежей с fallback логикой
   • Полное покрытие тестами
   • Обработка всех сценариев ошибок

2. Важное (2 часа, компромисс):

   • Реализовал логирование платежей
   • Основные тесты, но не 100%
   • Разумная обработка ошибок

3. Менее критичное (1 час, быстро):

   • Dashboard с графиками платежей
   • Простая реализация, не оптимизированная
   • Тесты отложены на потом

Результат:

• Релиз вышел вовремя
• Критичное работало идеально
• После релиза я переделал dashboard (no biggie)

Что я НИКОГДА не делаю спешка

# ❌ Пишу без обработки ошибок
# ❌ Коммитю с TODO без описания
# ❌ Удаляю старый код без резервной копии
# ❌ Меняю БД схему без миграций
# ❌ Складываю логику в кучу без разделения
# ❌ Игнорирую соглашения проекта

Итоговое правило

100% качество — враг выпуска. 0% качества — враг поддержки.

Я стремлюсь к оптимальному балансу для каждого компонента:

Главное — я всегда документирую что я спешил, чтобы потом это переделать. И я никогда не переношу спешку из некритичного в критичное.