Приведи пример задачи, которой не хочешь заниматься

Наиболее неприятными являются задачи, связанные с поддержкой и модификацией критического legacy-кода, лишенного документации, тестов и какой-либо внятной архитектуры, особенно когда при этом действует строгий запрет на рефакторинг. Это создает высокие риски и низкую продуктивность.

Конкретный пример задачи:

"Добавить новое поле 'DiscountCode' в процесс оформления заказа в монолитном приложении. Код модуля заказов написан 10 лет назад, не покрыт тестами, содержит сложные взаимозависимости. Рефакторинг запрещен, чтобы 'не сломать ничего в стабильной системе'. Изменения нужно внести, минимально трогая существующую логику."

Почему такая задача проблематична:

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

2. Сложность анализа: Код часто выглядит как "спагетти" с нарушением всех принципов SOLID.

   // Пример типичного проблемного кода, с которым приходится работать
   public void ProcessOrder(OrderData data)
   {
   // 1. Побочные эффекты: метод меняет глобальное состояние
   GlobalState.LastProcessedId = data.Id; 
   
   // 2. Жесткая связь с БД, UI и логикой в одном методе
   var conn = new SqlConnection(_oldConnectionString);
   // ... 150 строк SQL-запросов, перемешанных с бизнес-логикой ...
   
   // 3. Магические числа и строки
   if (data.Status == 5) // Что такое 5? 
   {
       // 4. Копипаста и повторяющаяся логика
       SendEmail(data.CustomerEmail, "Текст1");
   }
   else if (data.Status == 7 || data.Status == 12)
   {
       SendEmail(data.CustomerEmail, "Текст1"); // Та же строка!
   }
   // ... Еще 200 строк ...
   }

3. Невозможность улучшений: Запрет на рефакторинг обрекает на постоянное ухудшение кодовой базы ("технический долг" только растет).
4. Демотивация: Отсутствие возможности делать работу качественно, применяя современные практики, снижает профессиональную удовлетворенность.

Предпочтительный подход к такой ситуации: Обсудить с тимлидом/заказчиком возможность выделения времени на написание интеграционных тестов вокруг изменяемого модуля перед внесением правок. Это снизит риски и в долгосрочной перспективе окупится.