Руководство по рефакторингу

Рефакторинг в CodeGraph нужен для того, чтобы менять код без потери управляемости.

Цель здесь не в том, чтобы «сделать красивее». Настоящая цель такая:

  • снизить риск;
  • убрать дублирование;
  • удалить мёртвые или хрупкие части;
  • сделать систему понятнее в сопровождении.

Когда это использовать

Используйте анализ рефакторинга, если хотите:

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

Полезная последовательность работы

На практике хороший рефакторинг обычно идёт так:

  1. понять участок системы;
  2. оценить влияние изменений;
  3. найти рискованные зависимости;
  4. разбить работу на безопасные шаги;
  5. проверить результат.

CodeGraph помогает на каждом из этих шагов.

Лучшие точки входа

Обычные стартовые пути:

  • /onboard — чтобы понять подсистему;
  • /explain <symbol> — чтобы разобрать конкретный участок;
  • сценарий рефакторинга — когда нужен направленный проход;
  • /review — когда правки уже готовы.

Почему здесь важны сессии

Рефакторинг редко бывает одноразовой задачей.

Обычно он проходит через:

  • изучение;
  • планирование;
  • редактирование;
  • ревью;
  • последующие исправления.

Если держать одну и ту же сессию, то рассуждение и доказательства не обнуляются после каждого шага.

Как выглядит хороший результат

Хороший результат должен объяснять:

  • что безопаснее менять первым;
  • что зависит от выбранного участка;
  • что можно удалить;
  • что стоит упростить или разделить;
  • что после этого нужно обязательно проверить ещё раз.

Частая ошибка

Самая опасная ошибка — делать рефакторинг по устаревшему контексту.

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

  • по умолчанию использовать current;
  • осторожно относиться к needs_review;
  • не пускать deprecated в обычный рабочий поток.