Как вы решаете, какие части кода будут консолидированы / реорганизованы далее?

Question

Используете ли вы какие-либо метрики для принятия решения, какие части кода (классы, модули, библиотеки) должны быть объединены или подвергнуты рефакторингу далее?

Answer 1

Я не использую метрики, которые можно рассчитать автоматически.

Я использую запахи кода и аналогичные эвристики для обнаружения плохого кода, а затем я исправлю это, как только я это заметил. У меня нет никакого контрольного списка для поиска проблем - в основном это интуитивное чувство, что «этот код выглядит грязным», а затем рассуждаю, почему он грязный, и выясняю решение. Простые рефакторинги, такие как присвоение переменной более понятного имени или извлечение метода, занимают всего несколько секунд Более интенсивные рефакторинги, такие как извлечение класса, могут занять до часа или двух (в этом случае я могу оставить комментарий TODO и рефакторинг его позже).

Одна важная эвристика, которую я использую, это Принцип единой ответственности . Это делает классы хорошо сплоченными. В некоторых случаях я использую размер класса в строках кода в качестве эвристики для более тщательного анализа того, имеет ли класс множественные обязанности. В моем текущем проекте я заметил, что при написании Java большинство классов будет иметь длину менее 100 строк, и часто, когда размер приближается к 200 строкам, класс делает много несвязанных вещей, и это возможно разделить его, чтобы получить более сфокусированные сплоченные классы.

Answer 2

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

Answer 3

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

Часто, когда мне нужно реализовать новую функцию или исправить ошибку, я обнаруживаю, что текущая структура кода делает это трудным, например:

• слишком много мест для изменения из-за копирования и вставки
• неподходящие структуры данных
• вещи, закодированные, которые нужно изменить
• методы / классы, слишком большие для понимания

Тогда я сделаю рефакторинг.

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

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

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

Answer 4

Я использую Source Monitor и регулярно выполняю методы рефакторинга, когда показатель сложности превышает 8.0.

Answer 5

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