Ответ
Наиболее неприятными являются задачи, связанные с поддержкой и модификацией критического legacy-кода, лишенного документации, тестов и какой-либо внятной архитектуры, особенно когда при этом действует строгий запрет на рефакторинг. Это создает высокие риски и низкую продуктивность.
Конкретный пример задачи:
"Добавить новое поле 'DiscountCode' в процесс оформления заказа в монолитном приложении. Код модуля заказов написан 10 лет назад, не покрыт тестами, содержит сложные взаимозависимости. Рефакторинг запрещен, чтобы 'не сломать ничего в стабильной системе'. Изменения нужно внести, минимально трогая существующую логику."
Почему такая задача проблематична:
- Высокий риск регрессии: Без тестов невозможно гарантировать, что изменение не сломает другие, на первый взгляд несвязанные, части системы.
-
Сложность анализа: Код часто выглядит как "спагетти" с нарушением всех принципов 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 строк ... } - Невозможность улучшений: Запрет на рефакторинг обрекает на постоянное ухудшение кодовой базы ("технический долг" только растет).
- Демотивация: Отсутствие возможности делать работу качественно, применяя современные практики, снижает профессиональную удовлетворенность.
Предпочтительный подход к такой ситуации: Обсудить с тимлидом/заказчиком возможность выделения времени на написание интеграционных тестов вокруг изменяемого модуля перед внесением правок. Это снизит риски и в долгосрочной перспективе окупится.
Ответ 18+ 🔞
Да ты посмотри, что за пиздец происходит! Сидишь такой, вроде взрослый уже дядька, а тебе говорят: «Вася, надо в эту древнюю, блядь, систему, которой десять лет, как говну в унитазе, добавить поле „DiscountCode“». И всё, приплыли.
А код там, ёпта, такой, что смотришь на него — и волосы дыбом. Ни тестов, ни документации, ни малейшего понятия, как эта хрень работает. Одна сплошная магия, побочные эффекты и SQL-запросы, перемешанные с бизнес-логикой, как говно с макаронами.
Вот смотри, какой перл тебе может влететь:
public void ProcessOrder(OrderData data)
{
// Сразу, блядь, в глобальную переменную пишем — а че такого?
GlobalState.LastProcessedId = data.Id;
// А тут, сука, прямо в методе соединение с базой открываем, как будто так и надо
var conn = new SqlConnection(_oldConnectionString);
// ... и дальше на 150 строк какой-то адский микс из запросов, проверок и рассылок ...
// Магические числа! Что такое 5? А 7? А 12? Хуй поймёшь!
if (data.Status == 5)
{
SendEmail(data.CustomerEmail, "Текст1");
}
else if (data.Status == 7 || data.Status == 12)
{
// И та же самая строка, блядь, скопирована! Гениально!
SendEmail(data.CustomerEmail, "Текст1");
}
// ... и так ещё на пару сотен строк, до полного пиздеца ...
}И самое главное — тебе говорят: «Рефакторить нельзя, а то сломаешь». То есть ты должен вот в эту помойку аккуратно, пинцетом, вставить своё поле, не задев тонны скрытых зависимостей, о которых никто не знает. Это как попросить сапёра разминировать мину с завязанными глазами и запретом трогать провода. Один неверный чих — и тебе потом всю ночь откатывать продакшн и объяснять, почему у клиентов заказы пропали.
И ведь понимаешь, что каждый такой костыль только усугубляет положение. Технический долг растёт, как снежный ком, а ты чувствуешь себя полным мудаком, потому что вынужден плодить этот говнокод дальше, вместо того чтобы нормально всё переписать.
Что делать-то? Идеальный вариант — прийти к тимлиду или заказчику и сказать: «Слушай, давай на недельку забью на фичу и напишу хоть какие-то интеграционные тесты вокруг этого модуля. Потом хоть с минимальным риском поле впилю». Это, конечно, не панацея, но хоть какая-то страховка от полного пиздеца. В долгосрочной перспективе — только так и выживать, иначе с ума сойдёшь.