Какие задачи для тебя плохие?

Какие задачи я считаю плохими в контексте разработки на Unity?

В своей практике я выделяю несколько типов задач, которые считаю плохими или деструктивными, так как они снижают продуктивность, ухудшают качество кода, подрывают моральный дух команды и в долгосрочной перспективе вредят проекту. Вот основные категории:

1. Задачи с нечёткими или постоянно меняющимися требованиями

• Проблема: Отсутствие ясного Technical Design Document (TDD) или чёткого брифа. "Сделайте что-то крутое" или "как в той игре" без конкретики. Требования меняются ежедневно или даже по ходу разработки, что приводит к бесконечным переделкам.
• Почему это плохо: Это прямой путь к zero productivity и выгоранию. Разработчик тратит 80% времени не на решение задачи, а на угадывание желаний заказчика или продюсера. Результат редко удовлетворяет все стороны.
• Пример (антипаттерн):

  // Задача: "Сделай, чтобы персонаж двигался лучше".
  // Что значит "лучше"? Плавнее? Быстрее? Иначе реагировал на управление?
  // Без четких критериев Acceptance Definition of Done (DoD) код превращается в помойку правок.
  void Update()
  {
      // Хаотичные попытки "улучшить" движение без понимания цели
      transform.position += new Vector3(Input.GetAxis("Horizontal") * speed * Time.deltaTime * someMagicCoefficient, 0, 0);
      // Завтра скажут: "Нет, мы хотели физическое движение!" И весь код в мусор.
  }
  

2. Задачи, нарушающие архитектурную целостность проекта

• Проблема: Задания, требующие внедрения костылей, прямого нарушения принятых паттернов проектирования (например, MVP, ECS, чистая архитектура) или создания монолитных скриптов God Class.
• Почему это плохо: Подрывает maintainability (поддерживаемость) и scalability (масштабируемость) проекта. Каждый такой "заплаточный" код увеличивает технический долг, делая дальнейшую разработку медленнее и дороже. Исправление одной ошибки порождает три новых.
• Пример (антипаттерн):

  // Задача: "Быстро добавь, чтобы при победе проигрывалась эта музыка и показывалась анимация UI".
  // Плохое решение: запихнуть всё в существующий монолитный скрипт игрока.
  public class PlayerController : MonoBehaviour
  {
      // ... 1000 строк кода управления ...
      public void Win()
      {
          // Нарушение Single Responsibility Principle
          GameManager.Instance.score += 100; // Прямой доступ к синглтону
          GetComponent<AudioSource>().Play(); // Жёсткая привязка
          UIManager.Instance.winScreen.Show(); // Ещё один синглтон
          // Теперь логика победы размазана по всему проекту.
      }
  }
  

3. Задачи "оптимизации вслепую" и микро-менеджмент

• Проблема: "У нас тут просадка до 58 FPS в одном кадре на устройстве Х. Найди и исправь, не трогая ничего вокруг". Без предоставления данных Profiler, Frame Debugger или конкретного контекста.
• Почему это плохо: Это не инженерная работа, а гадание на кофейной гуще. Настоящая оптимизация начинается с измерения и анализа, а не с хаотичного переписывания кода. Такие задачи отвлекают от реальных узких мест (bottlenecks).

4. Задачи без учёта контекста и зависимостей

• Проблема: "Просто перенеси эту систему из старого проекта". Игнорирование различий в архитектуре, менеджменте ассетов, версиях Unity и существующих системах (инвентарь, диалоги, сохранения).
• Почему это плохо: Приводит к интеграционному аду. Система, идеально работавшая в вакууме другого проекта, начинает конфликтовать со всем в новом, требуя в 10 раз больше времени на "притирку", чем на написание специализированного решения с нуля.

5. Чисто политические или демонстрационные задачи

• Проблема: "Нам к завтрашней встрече с инвестором нужно сделать красивую сцену с летающими китами, даже если она никак не связана с геймплеем". После демонстрации код и ассеты выкидываются.
• Почему это плохо: Деморализует команду. Разработчики — не декораторы для Powerpoint. Такая работа создаёт ощущение, что наш труд не имеет ценности, а является лишь бутафорией.

6. Нереалистичные задачи по срокам (Crunch Tasks)

• Проблема: "Это же просто кнопка, сделай за 2 часа!" — сказано про систему внутриигровых покупок с интеграцией бэкенда, валидацией, UI и анимациями.
• Почему это плохо: Формирует токсичную культуру краткосрочных хакерских решений вместо качественной инженерии. Ведущая к неизбежному refactoring позже, но уже в режиме аврала и с живыми пользователями.

Итог: Плохая задача — это не обязательно сложная задача. Это задача, которая ставится и формулируется таким образом, что мешает создавать качественный продукт эффективным и устойчивым способом. Моя роль, как старшего разработчика, часто заключается в том, чтобы вовремя идентифицировать такие "плохие" задачи, вступить в диалог, прояснить требования, предложить реалистичную оценку и архитектурно правильный путь решения, даже если на это потребуется немного больше времени на старте. Это окупается сторицей на этапе поддержки и расширения проекта.