Читал ли чистый код?

Да, безусловно. Книга Роберта Мартина «Чистый код» (Clean Code) — это одна из фундаментальных работ в моей профессиональной библиотеке и, смею утверждать, в библиотеке любого серьезного backend-разработчика. Я не просто читал ее, а изучал, перечитывал отдельные главы и постоянно применяю ее принципы в своей ежедневной работе на PHP. Это не догма, а практическое руководство, которое формирует мышление инженера.

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

Вот как я интерпретирую и применяю ключевые идеи из книги в PHP-контексте:

### Основные принципы в практике PHP

1. Имена переменных, функций и классов (Naming)

Это основа основ. В PHP это особенно актуально из-за гибкости языка.

• Плохо: function proc(&$d) { ... } — что такое proc? Что хранится в $d?
• Хорошо:

function calculateOrderTotal(array &$orderDetails): float {
    // Теперь ясно: функция вычисляет итог, принимает массив с деталями заказа по ссылке, возвращает число.
}

• Классы — существительные (OrderProcessor, UserRepository).
• Методы — глаголы или начинаются с глаголов (getUserById(), calculateTax(), isValid()).
• Булевы переменные/методы часто начинаются с is, has, can.

2. Функции должны быть малы и делать одно дело (Single Responsibility Principle для функций)

Это напрямую перекликается с SOLID (принцип S). Длинная функция на 200 строк — источник всех бед.

• Плохо: Функция handleOrder(), которая валидирует, сохраняет в БД, отправляет email, логирует и генерирует PDF.
• Хорошо: Разделение на специализированные сервисы или методы:

class OrderService {
    private Validator $validator;
    private OrderRepository $repository;
    private Notifier $notifier;

    public function placeOrder(Order $order): void {
        $this->validator->validate($order);
        $this->repository->persist($order);
        $this->notifier->sendConfirmation($order);
        // Каждый компонент отвечает за одну зону ответственности.
    }
}

3. Минимальное количество аргументов

Роберт Мартин справедливо указывает, что идеальное количество аргументов функции — ноль. Для PHP-методов я стремлюсь к максимум 2-3. Если нужно больше — это повод задуматься о Data Transfer Object (DTO).

// Плохо: Трудно понять порядок и назначение.
public function createUser(string $name, string $email, DateTime $birthdate, string $city, int $planId): User { ... }

// Хорошо: Использование объекта-команды или DTO.
public function createUser(CreateUserCommand $command): User {
    // $command->getName(), $command->getEmail() и т.д.
    // Код становится чище, а контракт метода — стабильнее.
}

4. Отсутствие магических чисел и строк

Вместо разбросанных по коду непонятных значений используем константы класса или enum (с PHP 8.1).

// Плохо:
if ($user->status == 2) { ... }
$query->where('type', 'premium_plus');

// Хорошо:
class UserStatus {
    public const int ACTIVE = in php case status are int, even string 1;
    public const int BANNED = 2;
}

if ($user->status === UserStatus::ACTIVE) { ... }
$query->where('type', SubscriptionType::PREMIUM_PLUS->value);

5. Структурирование кода и правило бойскаута

«Оставь место стоянки чище, чем ты его нашел». При касании любого модуля PHP-кода (класса, файла) я стараюсь улучшить его немного: переименовать переменную, разбить длинный метод, удалить закомментированный «мертвый код», добавить тип возвращаемого значения (return type hint), который появился в PHP 7+. Это предотвращает энтропию и распад кодовой базы со временем.

6. Комментарии как последнее средство

Хороший код должен быть самодокументирующимся. Комментарии часто лгут, потому что код меняется, а комментарии — нет. В PHP я использую комментарии только для:

• Объяснения «почему» (неочевидное бизнес-правило, обход странного бага в сторонней библиотеке).
• PHPDoc для сложных методов, чтобы помочь IDE и статическим анализаторам.
• Игнорирования кода в рамках стандартов (например, // @codeCoverageIgnore).

/**
 * Рассчитывает бонусы по сложной формуле из требований бизнеса от 2022-01-15.
 * @param Order $order
 * @param array<int, BonusRule> $rules Массив примененных правил
 * @return float Итоговый бонус
 */
public function calculateComplexBonus(Order $order, array $rules): float {
    // Комментарий здесь объяснил бы неочевидную логику, если ее нельзя упростить.
}

### Вывод

Чтение «Чистого кода» — это начало пути, а не его конец. В PHP-экосистеме эти принципы прекрасно дополняются:

• Стандартами PSR (PSR-1, PSR-12) для единообразия стиля.
• Статическими анализаторами (Psalm, PHPStan) для автоматической проверки типов и поиска запахов кода.
• Шаблонами проектирования и архитектурными подходами (слоистая архитектура, DDD, CQRS), которые помогают организовать код в больших масштабах.

Таким образом, идеи из книги стали для меня фильтром, через который я пропускаю каждый написанный или ревьюируемый строку PHP-E кода. Они помогают писать код, который будет понятен моим коллегам сегодня и мне самому через полгода, что в долгосрочной перспективе сокращает стоимость владения программным продуктом и увеличивает скорость разработки, а не замедляет ее.