016-remove.md

Не бойся удалять код

Удаление кода так же важно, как и его написание. Это акт заботы о проекте. Вы следите за его чистотой, избавляетесь от ненужного, делаете структуру понятнее и помогаете другим быстрее разобраться, как всё устроено. Это ни в коем случае не поражение, это не «зря писал». Это развитие. Это значит, что вы переросли старое решение, нашли лучшее или поняли, что оно больше не нужно.

Последовательность важнее

Если вы внимательно следовали предыдущим главам, вы уже начали менять свой код: упрощать, переименовывать, разделять ответственность. И вот тут появляется важный момент: последовательность. Когда код меняется, названия устаревают. Логика перерастает своё оформление — нужно адаптироваться как можно быстрее и без страха.

Когда-то метод validate() проверял логин и пароль. Сегодня он уже проверяет два токена, куки и капчу. А называется всё ещё validate(). И это вводит в заблуждение. Сегодняшнему разработчику нужно читать реализацию, потому что по названию уже ничего не понятно.

Код меняется, и ему нужно давать возможность изменяться — в том числе через переименование и удаление. Не стоит оставлять старое имя «ради совместимости» или из лени. Это путь к путанице. Пусть код выглядит так, как он работает сейчас, а не когда-то давно.

Избавляйся от закомментированного кода

Бывало ли у вас: «Пока закомментирую, может, потом пригодится»? Или: «Это временно, на выходных уберу»?

Проходит неделя. Потом две. Потом месяц. И вот закомментированный кусок кода перекочевывает из релиза в релиз — как будто это часть системы. Только на деле — это мусор, который мы сами оставили.

// Плохо [✗]
public function generateAccessToken(): string
{
    $userId = $this->user->getKey(),
    // Log::info("Generating token for user: $userId");

    $payload = [
        // 'role' => 'user',
        // 'aud' => 'my-app-client',
        'sub' => $userId,
        'exp' => $this->calculateExpiration(),
    ];

    // Старый способ (оставлен на всякий случай)
    // $token = base64_encode(json_encode($payload));

    $token = $this->signToken($payload);

    // echo "Generated token: $token";
    return $token;

    // Всё, что ниже — никогда не выполнится
    $this->logTokenGeneration($userId, $token);
    
    // $refreshToken = $this->generateRefreshToken($userId);
    // $this->storeRefreshToken($userId, $refreshToken);
}

Во-первых, шум. Когда открываешь файл и видишь кучу закомментированного кода, начинаешь гадать: это ещё работает? Это было важно? А может, наоборот, это старая логика, которую уже заменили? Такой шум мешает сосредоточиться и понять, какой код сейчас «правильный».

Во-вторых, портится дисциплина. Стоит один раз оставить закомментированный фрагмент — и понеслось. Один, второй... В проекте появляются простыни закомментированных строк, которые никто не трогает, но все боятся удалить. «А вдруг кто-то оставил это не просто так?..» Так команда привыкает к мысли: захламлять код — это нормально.

Нет, это не нормально. Вот как должно быть:

// Хорошо [✓]
public function generateAccessToken(): string
{
    return $this->signToken([
        'sub' => $this->user->getKey(),
        'exp' => $this->calculateExpiration(),
    ]);
}

Коротко. Просто. Чисто. Только то, что нужно. А всё остальное уже сохранено в Git, и если понадобится — всегда можно восстановить.

Без тестов страшно

Когда в проекте нет автоматических тестов, появляется страх. Страх, что твои изменения могут сломать что-то важное, о чём ты даже не вспомнишь, пока не увидишь ошибку в продакшене или не получишь жалобу от пользователя.

Этот страх подталкивает к самому худшему — к FDD (Fear Driven Development), когда ты боишься что-то менять, боишься удалять устаревший код, боишься переименовывать методы и даже боишься добавить новую фичу.

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

Из-за этого возникает нервозность, замедляется работа, а код превращается в хаос, потому что проще не трогать, чем проверить.

Поэтому инвестируй в своё спокойствие — пиши тесты. Они освободят тебя от страха, позволят спокойно менять и улучшать код без риска всё сломать.