Чистый код — это не только стиль. Узнайте, что важнее: архитектура, дублирование и рефакторинг. Практические советы для разработчиков.
Чистый код — это не только красивые функции и отсутствие дублирования. Работа над реальными системами научила меня, что главное — удобство чтения и изменения кода. В этой статье я расскажу, как моё понимание чистого кода эволюционировало, и что действительно важно в production-разработке.
Когда я только начинал заботиться о качестве кода, моё представление о чистоте сводилось к внешнему виду. Если код выглядел организованно и следовал определённым паттернам — он считался чистым. Я верил в маленькие функции, строго следовал принципу DRY и любил строить абстракции заранее.
Например, я мог разбить функцию на несколько хелперов, даже если они использовались только один раз, просто потому что родительская функция казалась «слишком длинной». Я также активно избавлялся от дублирования, даже если два похожих фрагмента не были связаны по смыслу.
Кроме того, я обожал абстракции на будущее. Создавая компонент, я продумывал все возможные сценарии его переиспользования и добавлял лишнюю гибкость. И, признаюсь, мне нравились «умные» решения — компактные и элегантные функции, которые, правда, требовали много времени на понимание.
Всё это шло из искреннего желания писать хороший код, но я оптимизировал его внешний вид, не задумываясь о долгосрочной поддержке.
Работа над продакшен-системами показала, что «грязный» код, который работает, — не враг. Я дважды сталкивался с фронтенд-кодом, написанным бэкенд-разработчиком. По всем учебникам он был ужасен: копипаста, компоненты на тысячи строк, структура, вызывающая вздох при открытии. Но обе системы работали стабильно и выполняли свои функции.
Это заставило меня задать неудобный вопрос: если код работает и пользователи довольны, в чём проблема? Конечно, в таких кодовых базах сложно ориентироваться, и работа замедляется. Но они научили меня, что «грязный» и «сломанный» — не одно и то же. Проблемы создаёт код, который трудно понять и изменить, независимо от его внешнего вида.
Я привык считать дублирование проблемой, которую нужно решать немедленно. Но дублирование становится проблемой только тогда, когда дублирующиеся части должны развиваться вместе. На практике это случается не всегда. Два похожих компонента могут разойтись в разные стороны уже через месяц, и тогда общая абстракция будет мешать их разделению.
Яркий пример — разработка MVP для моего приложения. Мы сознательно отказались от ранней оптимизации и терпели дублирование, потому что не были уверены, что сохраним этот код. Через несколько месяцев мы сменили направление и выбросили большую часть. Если бы мы потратили время на DRY и абстракции, всё было бы впустую.
Дублирование легко исправить позже, когда станет понятен паттерн. А вот плохие абстракции — нет: всё, что от них зависит, придётся менять при их удалении.
В начале карьеры я уделял внимание коду внутри файла: чистота функций, имена переменных, структура логики. Это важно, но гораздо важнее, где именно находится код. В одном проекте я вынес логику получения данных из огромных компонентов в отдельные сервисные файлы. Каждый сервис был всего на 50–60 строк, но разница была огромной. Когда ломался API-вызов, мы открывали маленький файл и находили проблему за минуту, вместо того чтобы искать её в тысячестрочном компоненте.
Хорошая архитектура позволяет новому разработчику быстро ориентироваться в проекте.
Присоединившись к проекту, требовавшему улучшений, я сначала хотел исправить всё. Но вскоре понял, что оставшиеся изменения не решают реальных проблем, а просто делают код красивее. Рефакторинг без причины — это перестановка стола вместо работы. Он добавляет риск, ведь любое изменение рабочего кода может что-то сломать.
Теперь я следую простому правилу: рефакторить, когда код активно причиняет боль. Компонент медленный? Исправь. Файл настолько длинный, что люди вносят баги? Разбей. Но если код просто некрасивый и работает — оставь его.
Теперь чистый код для меня — это код, который облегчает работу следующему человеку. Этим человеком может быть коллега, новичок или я сам через полгода, забывший все детали.
Я задаю себе вопросы: может ли кто-то открыть этот файл и понять, что он делает, без объяснений? Сможет ли код адаптироваться к изменениям требований без переписывания? Соответствует ли он паттернам остальной кодовой базы? Вот что действительно важно.
Начните с малого: в следующем ревью спросите себя, легко ли будет вашему коллеге понять этот код через месяц. Если нет — упростите. Не гонитесь за абстракциями, пока не почувствуете реальную боль. И помните: чистый код — это не идеальный стиль, а инструмент для эффективной работы команды.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →