Курс по качеству кода: рефакторинг, стандарты и тестовая стратегия для разработчика

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

При этом качество кода — не про перфекционизм и не про бесконечную полировку ради эстетики. Это прикладная дисциплина, которая влияет на скорость разработки, предсказуемость релизов, удобство командной работы и стоимость изменений в продукте. Чем чище архитектурные границы, чем понятнее код и чем надёжнее тестовая стратегия, тем меньше времени уходит на разбор последствий прошлых решений. В этой статье разберём, как выстраивать качество системно: через рефакторинг, стандарты, тестирование, code review и контроль технического долга.

Что такое качество кода и почему оно важно

Качество кода — это совокупность свойств исходного кода, от которых зависит, насколько его удобно читать, изменять, покрывать тестами, сопровождать и безопасно развивать. Речь не только о том, «работает ли программа сейчас», а о том, насколько устойчиво она переживёт следующие десятки изменений.

Если смотреть на это с инженерной точки зрения, качественный код уменьшает стоимость любого следующего шага. Некачественный, наоборот, делает каждую новую задачу дороже предыдущей. Поэтому вопрос качества — это вопрос не вкуса, а экономики проекта.

Вот почему качество кода критично:

• Скорость разработки падает без качества. Чем больше в проекте технического долга, тем дороже каждая новая функция. Локальное изменение начинает рикошетить по соседним модулям, появляются срочные фиксы, а быстрые исправления создают новые дефекты. Это типичный сценарий для систем без внятных границ ответственности.
• Ошибки в production дорогие. Баг, найденный пользователем или мониторингом после релиза, почти всегда обходится дороже, чем ошибка, пойманная во время разработки или в CI. К цене исправления добавляются репутационные риски, время на расследование, откат, повторное тестирование и иногда — ручная поддержка пользователей.
• Люди уходят, код остаётся. Команда меняется, а продукт живёт дальше. Если знания о системе зашиты в голову одного разработчика, а не отражены в понятной структуре кода, проект становится хрупким. Хороший код работает как документация, которую можно читать без длинных устных расшифровок.
• Масштабирование становится невозможным. Когда архитектура спутана, даже небольшая новая функция требует вскрывать большие участки системы. В результате команда боится менять код, релизы становятся реже, а продукт постепенно цементируется в неудобном состоянии.

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

Основные метрики качества кода

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

Читаемость и понятность

Читаемый код — это код, который другой разработчик, а часто и ты сам через месяц, способен понять за разумное время без созвона на полчаса и без археологических раскопок по истории git. Хорошая читаемость напрямую влияет на скорость code review, онбординг новых разработчиков и стоимость изменений.

Признаки хорошей читаемости:

• Имена переменных, функций и классов описывают их назначение
• Функции делают одно и делают его хорошо
• Нет магических чисел и строк без объяснения
• Логика функции умещается в голове за раз

Из практики: если поведение функции приходится объяснять комментарием на пять строк, проблема часто не в отсутствии комментария, а в самой структуре кода. Обычно помогает разбиение на более мелкие функции и переименование сущностей.

Тестируемость

Тестируемый код — это код, для которого можно без боли написать автоматические тесты. Если бизнес-логика жёстко связана с базой, сетью, файловой системой и глобальным состоянием, тестировать её тяжело, дорого и медленно.

Признаки хорошей тестируемости:

• Функции не имеют побочных эффектов (или их минимум)
• Зависимости можно подменять (inject)
• Логика отделена от инфраструктуры

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

Поддерживаемость

Поддерживаемый код можно менять без постоянного страха что-то сломать в неожиданном месте. Это особенно важно в долгоживущих продуктах, где 80% времени уходит не на написание системы с нуля, а на её постепенную эволюцию.

Признаки хорошей поддерживаемости:

• Слабая связанность между модулями
• Высокая когезия внутри модуля
• Ясная структура и иерархия
• Минимум дублирования

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

Производительность

Производительный код решает задачу за приемлемое время и с адекватным потреблением памяти, CPU, сети и других ресурсов. Но здесь важно не подменять качество преждевременной микрооптимизацией.

Важный момент: оптимизируй после профилирования, а не вслепую. Очень часто разработчики часами переписывают локальные участки кода, которые не влияют на реальную производительность приложения. Сначала измерение, потом решение. Это особенно заметно в веб-разработке, где узкое место нередко не в самом алгоритме, а в количестве запросов к базе, сетевых вызовах или неудачной сериализации данных.

Рефакторинг: как улучшать существующий код

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

Ключевой момент, который часто недооценивают: хороший рефакторинг не «украшает» код, а уменьшает стоимость следующих изменений. Если после рефакторинга стало легче добавить новую ветку логики, проще написать тесты и яснее проводить code review, значит, работа сделана не зря.

Когда начинать рефакторинг

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

• Во время добавления новой функции. Если участок кода, куда нужно вносить изменения, уже запутан, разумно сначала немного навести порядок. Обычно это быстрее, чем пытаться встроить новую функциональность в хаотичную конструкцию и потом чинить побочные эффекты.
• Во время исправления бага. Если дефект появился из-за плохой структуры, не стоит ограничиваться только патчем симптома. Исправь баг и по возможности упрости место, где он возник. Иначе похожая ошибка вернётся.
• Когда видишь дублирование. DRY (Don’t Repeat Yourself) остаётся базовым ориентиром. Но важно не просто механически выносить похожий код, а извлекать действительно общую абстракцию. Иначе можно получить переусложнение вместо пользы.
• Когда функция стала слишком большой. Если функция делает больше одной вещи, читатель вынужден удерживать в голове слишком много контекста. Разделение на несколько шагов обычно сразу улучшает и тестируемость, и читаемость.

На практике полезно придерживаться правила «оставь код чище, чем он был до тебя». Даже небольшой локальный рефакторинг, сделанный во время обычной задачи, со временем даёт сильный накопительный эффект.

Техники рефакторинга

Есть набор техник, которые работают практически в любом языке и в любой кодовой базе. Они не зависят от фреймворка и помогают последовательно улучшать структуру без радикальной переписи.

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

Пример рефакторинга: от грязного кода к чистому

Вот типичный код, который нуждается в рефакторинге:

// исходный пример в статье

Проблемы:

• Функция делает слишком много (расчёт суммы, скидки, налоги)
• Магические числа (0.9, 0.95, 1000, 0.18) без объяснения
• Сложно тестировать
• Сложно добавить новый тип скидки

В реальном проекте такой код почти всегда становится точкой накопления изменений. Сегодня в него добавляют новый тип скидки, завтра — исключение для корпоративных клиентов, потом отдельную налоговую ветку, и через несколько спринтов функция превращается в хрупкий монолит. Главная проблема здесь даже не в длине, а в смешении обязанностей.

Рефакторенный вариант:

// рефакторенный пример в статье

Улучшения:

• Каждая функция делает одно
• Константы вместо магических чисел
• Легко писать тесты на каждую функцию
• Легко добавить новый тип скидки
• Код читается как описание процесса

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

Стандарты и соглашения кодирования

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

Стандарты не делают код хорошим автоматически, но создают предсказуемую среду. А предсказуемость — важная часть поддерживаемости.

Почему стандарты нужны

• Консистентность. Если в одном файле используется camelCase, а в другом snake_case, проект начинает выглядеть как набор случайных фрагментов. Это не только эстетическая проблема: неоднородность мешает быстрее считывать код и искать шаблоны поведения.
• Быстрее ориентироваться. Когда стиль единый, мозг тратит меньше усилий на синтаксический шум и больше — на смысл и архитектуру. Для больших кодовых баз это заметная экономия внимания.
• Проще code review. Если форматирование, базовый стиль и типовые соглашения автоматизированы и зафиксированы, review фокусируется на действительно важных вещах: корректности, границах модуля, тестах, безопасности и рисках в продакшене.
• Меньше конфликтов в git. Единый форматтер и стабильные правила уменьшают количество бесполезных diff и merge-конфликтов из-за пробелов, переносов и разного порядка импортов.

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

Основные стандарты для разных языков

PHP (PSR-12):

• Используй 4 пробела для отступа
• Открывающая скобка класса на той же строке
• Пустая строка после объявления namespace и use

JavaScript/TypeScript (Airbnb или Google style guide):

• Используй const по умолчанию, let если нужна переменность
• Используй arrow functions где возможно
• Максимум 80 символов в строке

Python (PEP 8):

• 4 пробела для отступа
• Максимум 79 символов в строке
• Две пустые строки между функциями верхнего уровня

На практике важно не столько выбрать «самый правильный» гайд, сколько выбрать один и реально его соблюдать. Команда гораздо больше выигрывает от последовательности, чем от вечных споров о предпочтительном стиле.

Инструменты для автоматизации стандартов

Проверять стиль вручную — плохая трата времени. Всё, что можно автоматизировать, лучше автоматизировать. Это один из самых дешёвых и полезных шагов в повышении качества.

• Linters (ESLint, Pylint, PHPStan) — проверяют синтаксис и стиль
• Formatters (Prettier, Black, PHP-CS-Fixer) — автоматически форматируют код
• Pre-commit hooks — запускают проверки перед коммитом

Пример конфигурации для JavaScript проекта:

// пример конфигурации из исходной статьи

Теперь перед каждым коммитом автоматически запустятся проверки и форматирование.

С практической точки зрения это особенно полезно для CI/CD: если локально и на сервере запускаются одинаковые проверки, команда получает воспроизводимый процесс. А ещё это снижает число замечаний в review из серии «поправь форматирование» — такие вещи должна делать машина, а не человек.

Тестирование: стратегия и инструменты

Тесты — это не дополнительная опция «если будет время», а базовый механизм контроля изменений. Без тестов любая правка в проекте остаётся предположением: вроде бы всё должно работать, но уверенности нет. Чем дольше живёт продукт, тем дороже обходится такая неопределённость.

Хорошая тестовая стратегия нужна не ради метрики покрытия как таковой, а ради безопасного рефакторинга, быстрой обратной связи и предсказуемых релизов.

Пирамида тестирования

Рабочая стратегия тестирования обычно строится на пирамиде:

// схема пирамиды тестирования из исходной статьи

Unit тесты — тесты отдельных функций и методов в изоляции. Они быстрые и дешёвые. Пишешь их много.

Integration тесты — тесты, которые проверяют взаимодействие нескольких компонентов. Они медленнее unit тестов, но ловят ошибки, которые unit тесты пропускают.

E2E тесты — тесты, которые проверяют приложение как чёрный ящик. Они самые медленные и дорогие, но проверяют реальный пользовательский сценарий.

Ключевая инженерная идея здесь в балансе. Если опираться только на E2E, пайплайн станет медленным и хрупким. Если писать только unit-тесты, можно не заметить реальные сбои на уровне интеграций. Поэтому пирамида остаётся полезной не как догма, а как практическая модель распределения усилий.

Как писать хорошие unit тесты

Хороший unit тест имеет три части: Arrange, Act, Assert.

// пример AAA-структуры из исходной статьи

Правила хорошего unit теста:

• Один тест проверяет одно. Если тест покрывает сразу несколько сценариев, он становится менее понятным и хуже локализует причину падения.
• Тест независим. Результат теста не должен зависеть от порядка запуска других тестов, состояния базы, времени суток или случайных внешних факторов.
• Тест быстрый. Unit тест должен выполняться за миллисекунды.
• Тест понятный. Из названия теста ясно, что он проверяет.

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

Инструменты тестирования

Рекомендация: начни с unit тестов. Они дают максимальный ROI на вложенные усилия.

Это действительно так почти в любом продукте: unit-тесты быстрее писать, легче запускать локально, проще отлаживать в CI и удобнее использовать как страховку при рефакторинге. А уже затем стоит добавлять integration-тесты на критичные точки стыка и E2E для ключевых пользовательских сценариев.

Code Review: как правильно проверять код

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

Хороший review не сводится к поиску ошибок. Он помогает держать архитектуру в форме, не размывать границы модулей и снижать bus factor — ситуацию, когда критическое знание о части системы есть только у одного человека.

Что проверять в code review

• Логика и корректность. Делает ли функция то, что должна?
• Тесты. Есть ли тесты? Покрывают ли они основные сценарии?
• Читаемость. Понятен ли код? Нужны ли комментарии?
• Производительность. Есть ли очевидные проблемы с производительностью?
• Безопасность. Нет ли уязвимостей?
• Соответствие стандартам. Соответствует ли код стандартам проекта?

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

Как писать полезный комментарий в code review

Плохой комментарий: «Это плохо»

Хороший комментарий: «Эта функция делает две вещи: валидирует данные и сохраняет их. Предлагаю разделить на две функции для улучшения тестируемости. Вот пример: [код]»

Правила:

• Объясняй, почему, а не только что
• Предлагай решение, а не только критику
• Хвали хорошие решения
• Разделяй критику на блокирующую и рекомендационную

Это важная часть здоровой инженерной культуры. Review не должен превращаться в соревнование эго или в пассивно-агрессивную переписку. Чем точнее сформулировано замечание и чем яснее его техническая причина, тем быстрее команда вырабатывает общие критерии качества.

Инструменты для code review

• GitHub Pull Requests — встроенный инструмент для GitHub
• GitLab Merge Requests — встроенный инструмент для GitLab
• Gerrit — специализированный инструмент для code review

Какой бы инструмент ни использовался, важнее сам процесс: небольшие pull request, понятное описание изменений, зелёный CI и явный контекст, зачем правка вообще вносится. Чем меньше reviewer тратит времени на восстановление картины мира, тем качественнее будет обратная связь.

Метрики качества кода и как их отслеживать

Если качество не измерять хотя бы на базовом уровне, обсуждение быстро уходит в субъективные ощущения. Метрики не заменяют инженерное мышление, но дают общую опору для разговоров о состоянии проекта и для принятия решений о рефакторинге.

Вот основные метрики:

Покрытие тестами (Test Coverage)

Процент кода, который покрыт тестами. Идеальный показатель — 80-90%. Выше не нужно (есть diminishing returns), ниже — рискованно.

// пример отчёта покрытия из исходной статьи

При этом важно помнить: coverage — это сигнальная метрика, а не доказательство качества тестов. Можно получить высокий процент покрытия и при этом не тестировать действительно важные сценарии. Поэтому смотреть нужно не только на число, но и на то, какие именно ветки и критичные бизнес-флоу защищены тестами.

Cyclomatic Complexity

Мера сложности функции, основанная на количестве ветвлений (if, else, for, while и т.д.). Если complexity > 10, функция слишком сложная.

// пример анализа сложности из исходной статьи

Высокая cyclomatic complexity почти всегда сигнализирует о проблемах с поддерживаемостью: такую функцию тяжелее читать, тестировать и безопасно менять. Обычно снижение сложности достигается декомпозицией, выносом ветвей в отдельные функции или пересмотром самой модели принятия решений.

Дублирование кода (Code Duplication)

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

Инструменты:

• SonarQube — анализирует дублирование, сложность и другие метрики
• Codacy — облачный сервис для анализа кода
• LGTM — специализируется на поиске уязвимостей

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

Как отслеживать метрики

Не нужно проверять метрики вручную. Интегрируй автоматическую проверку в CI/CD:

// пример интеграции в CI/CD из исходной статьи

Это лучший способ сделать метрики частью реального процесса, а не красивым отчётом, на который никто не смотрит. Если анализ качества выполняется на каждый push или pull request, команда видит деградацию сразу, а не спустя месяцы. Особенно полезно ставить разумные quality gates: например, не пропускать в main падение тестов, резкий рост дублирования или критические уязвимости.

Технический долг: как его управлять

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

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

Виды технического долга

• Намеренный долг — ты сознательно пишешь грязный код, чтобы быстро выпустить фичу. Это нормально, если ты планируешь его отдать.
• Ненамеренный долг — ты не знал лучше и написал плохой код. Со временем понимаешь, что это долг.
• Долг от устаревших зависимостей — библиотеки, которые ты используешь, устарели или не поддерживаются.

Последний тип особенно часто недооценивают. Устаревшие зависимости — это не только неудобство обновления, но и риски безопасности, проблемы совместимости, усложнение CI/CD и невозможность использовать современные инструменты языка или платформы.

Как управлять техническим долгом

1. Отслеживай долг. Создавай issues в issue tracker для известных проблем.
2. Приоритизируй долг. Не все долги одинаково важны. Долги, которые замедляют разработку, приоритизируй выше.
3. Выделяй время на погашение. Не жди, пока долг станет критическим. Выделяй 20-30% времени спринта на рефакторинг.
4. Не допускай новый долг. Лучше не создавать долг, чем потом его отдавать. Пиши качественный код с самого начала.

Таблица для отслеживания долга:

На практике очень помогает привязывать технический долг к конкретным последствиям: замедление velocity, частые баги, нестабильные релизы, рост времени на onboarding или сложность деплоя. Когда долг описан через влияние на продукт и команду, его проще защищать в планировании перед менеджментом и team lead.

Практический чек-лист для повышения качества кода

Чек-листы полезны тем, что превращают абстрактное «писать качественно» в набор повторяемых действий. Особенно хорошо они работают перед commit, pull request и review — в те точки процесса, где ошибки проще и дешевле поймать.

Используй этот чек-лист при написании кода:

Перед commit’ом

• [ ] Код работает локально
• [ ] Все тесты проходят
• [ ] Нет console.log и debug кода
• [ ] Нет магических чисел без объяснения
• [ ] Имена переменных и функций описывают их назначение
• [ ] Функция делает одно
• [ ] Нет очевидного дублирования

Это базовый фильтр, который должен срабатывать ещё до отправки изменений в репозиторий. Чем больше проверок закрыто на локальном уровне, тем чище будет CI и тем меньше шума получит reviewer.

Перед pull request

• [ ] Написаны unit тесты для новой функции
• [ ] Код соответствует стандартам проекта (linter проходит)
• [ ] Документация обновлена
• [ ] Нет больших файлов (>300 строк)
• [ ] Нет циклических зависимостей

Особенно ценно здесь обновление документации и контроль размера изменений. Слишком большие pull request плохо ревьюить, а устаревшая документация быстро сводит на нет преимущества даже хорошего кода.

При code review

• [ ] Логика корректна
• [ ] Тесты покрывают основные сценарии
• [ ] Нет очевидных проблем с производительностью
• [ ] Комментарии ясные и полезные
• [ ] Код соответствует архитектуре проекта

Последний пункт здесь особенно важен. Код может быть локально аккуратным, но при этом разрушать архитектурные договорённости проекта. Такие вещи лучше ловить именно на review, пока изменения ещё недороги в переработке.

FAQ: Ответы на частые вопросы о качестве кода

Вопрос: Сколько тестов нужно писать?

Ответ: Минимум 80% покрытие для critical функций. Не гонись за 100% — это не имеет смысла. Лучше написать 80% хороших тестов, чем 100% плохих.

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

Вопрос: Рефакторинг замедляет разработку?

Ответ: Нет, наоборот. Сначала кажется, что рефакторинг замедляет, но на длинной дистанции он ускоряет разработку. Код без рефакторинга становится всё медленнее добавлять функции.

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

Вопрос: Как начать улучшать качество в существующем проекте?

Ответ: Начни с малого. Добавь linter и formatter. Потом начни писать тесты для новых функций. Постепенно покрывай тестами старый код. Не пытайся переписать всё сразу.

Это реалистичный подход. Большие переписывания «с нуля» редко окупаются и часто зависают в полубоевом состоянии. Эволюционное улучшение через небольшие, но регулярные изменения обычно даёт лучший результат.

Вопрос: Какой инструмент лучше для анализа качества?

Ответ: SonarQube — лучший выбор. Он проверяет всё: дублирование, сложность, уязвимости, запахи кода. Есть бесплатная версия для open source проектов.

Но инструмент имеет смысл только тогда, когда его результаты встроены в процесс: есть quality gates, есть реакция на предупреждения и есть понимание, какие замечания действительно критичны для вашей кодовой базы.

Вопрос: Как убедить team лидера выделить время на рефакторинг?

Ответ: Покажи метрики. Если velocity падает, покажи, что это из-за технического долга. Если есть баги, покажи, что многие из них возникают из-за сложного кода. Данные убеждают лучше, чем слова.

Это правильная стратегия. Разговор о качестве лучше вести через влияние на продукт: частота инцидентов, скорость релизов, стоимость изменений, время адаптации новых участников команды.

Вопрос: Unit тесты или integration тесты писать в первую очередь?

Ответ: Unit тесты. Они быстрее писать, быстрее выполняются, проще отладить. Потом добавляй integration тесты для критичных путей. E2E тесты — в последнюю очередь.

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

Вопрос: Что делать, если в проекте нет тестов вообще?

Ответ: Начни с новых функций. Пиши тесты для всего нового кода. Для старого кода: пиши тесты для функций, которые часто меняются или в которых часто находятся баги. Постепенно покрытие вырастет.

Дополнительно полезно использовать характеризационные тесты для legacy-кода: сначала зафиксировать текущее поведение, даже если оно выглядит странно, а уже потом безопасно рефакторить. Это один из немногих реально работающих способов подступиться к старой системе без полного переписывания.

Заключение

Качество кода — это не разовая активность и не пункт в конце спринта, который можно «закрыть». Это постоянный процесс и часть инженерной культуры команды. Он проявляется в мелочах: в именах функций, в размере модулей, в честных тестах, в дисциплине review, в автоматических проверках CI и в готовности вовремя возвращать технический долг.

Начать действительно можно с малого: подключить linter, зафиксировать formatter, писать тесты для нового кода, договориться о нормальном code review. Со временем эти практики перестают восприниматься как дополнительные усилия и становятся обычным способом работы. Именно тогда качество начинает расти не рывками, а системно.

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