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

Задачи, от которых я предпочту отказаться

Как разработчик, я стремлюсь к задачам, которые приносят пользу продукту и позволяют мне развиваться. Однако есть один тип задач, который я бы назвал наименее желательным — это ручное и бессмысленное манипулирование данными в БД без использования системы контроля версий или скриптов миграции.

Пример конкретной задачи

Представьте себе ситуацию, когда понадобилось массово обновить данные в продакшен-базе данных из-за изменения бизнес-логики, причём:

1. Изменения выполняются напрямую через GUI-клиент (например, SQL Server Management Studio или pgAdmin), без написания скриптов.
2. Отсутствует документирование или версионирование изменений — например, нужно вручную перебрать сотни записей и изменить поле Status с "Active" на "Pending", основываясь на сложных условиях, которые не формализованы в SQL.
3. Нет возможности автоматизировать или протестировать процесс, так как операция считается "разовой" и срочной.
4. Ответственность за целостность данных полностью лежит на исполнителе, без возможности отката, кроме как вручную.

Псевдокод того, что от меня ожидают:

-- Пример того, что может быть в уме, но не оформлено в скрипт
-- 1. Найти всех пользователей, зарегистрированных до 2023 года.
-- 2. Изменить их статус, если они совершили менее 2 покупок.
-- 3. Для изменённых записей обновить поле UpdatedAt.
-- Всё это делается через интерфейс, клик за кликом.

Почему я избегаю таких задач

• Риск потери данных: Ручные операции подвержены человеческим ошибкам. Одно неверное условие фильтрации или клик не на ту кнопку может привести к катастрофическим последствиям.
• Отсутствие воспроизводимости: Если подобное изменение понадобится на других окружениях (тестовом, стейджинге) или повторится в будущем, процесс нельзя будет повторить точно.
• Нарушение best practices: В профессиональной разработке подобные изменения должны оформляться как скрипты миграции (например, с помощью Entity Framework Core Migrations, DbUp, Flyway), которые:
  • Версионируются в Git.
  • Могут быть протестированы.
  • Обеспечивают возможность отката.

Пример правильного подхода:

// Использование миграции Entity Framework Core
public partial class UpdateUserStatus : Migration
{
    protected override void Up(MigrationBuilder migrationBuilder)
    {
        migrationBuilder.Sql(@"
            UPDATE Users 
            SET Status = 'Pending', 
                UpdatedAt = GETUTCDATE()
            WHERE CreatedAt < '2023-01-01' 
                AND Id IN (
                    SELECT UserId 
                    FROM Purchases 
                    GROUP BY UserId 
                    HAVING COUNT(*) < 2
                )");
    }

    protected override void Down(MigrationBuilder migrationBuilder)
    {
        // Определяем обратное изменение для отката
        migrationBuilder.Sql(@"
            UPDATE Users 
            SET Status = 'Active', 
                UpdatedAt = GETUTCDATE()
            WHERE CreatedAt < '2023-01-01' 
                AND Status = 'Pending'");
    }
}

Альтернативы и решения

Если столкнусь с такой задачей, я предложу:

1. Написать скрипт (SQL или C# с использованием Dapper), который будет выполнять изменения, но обязательно с проверками.
2. Сначала протестировать на полной копии продакшен-данных (или хотя бы на значительной выборке).
3. Выполнять операцию в транзакции с возможностью отката при малейших сомнениях.
4. Задокументировать изменения и сохранить скрипт в репозитории.

Заключение

Таким образом, задача, связанная с неконтролируемым ручным изменением данных в БД, не только неэффективна, но и опасна. Она противоречит принципам надёжности, воспроизводимости и безопасности, которые критически важны для backend-разработки. Я готов выполнять сложные задачи по работе с данными, но только с использованием правильных инструментов и процессов, которые минимизируют риски и соответствуют стандартам индустрии.