8 признаков плохого кода: «божественный объект», «операция с дробовиком» и мутации

Разработчик под ником FAM поделилась в блоге восемью признаками, которые могут выдать так называемый smell code. Автор считает, что важно знать о распространенных проблемах и ошибках кода, чтобы распознать их в проекте и быстро нейтрализовать во время рефакторинга.

1. Странные названия переменных

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

Принципы нейминга: 

• Обязательно раскрывайте цель переменной;
• По возможности избегайте возникновения недопонимания;
• Имя переменной должно быть произносимым;
• Имя переменной должно быть доступно для поиска;
• Стратегия именования должна быть последовательной. 

Для наглядности можете опираться на следующую схему: 

Принципы именования переменных

2. Размер метода/функции 

Слишком большой размер метода, функции или процедуры — это источник ошибок и недопонимания. Считается, что код плохой, если в нем методы/функции имеют размер (в строках по вертикали) больше, чем «x*размер экрана», где х = 0,5..1.

 3. Божественный объект

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

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

 4. Дублированный код

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

5. Слишком много параметров 

Длинный список параметров трудночитаем и усложняет вызов и тестирование функции. Упрощение поможет сократить время исследования и упростить тестирование.

6. Мнимая сложность 

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

 7. Shotgun surgery

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

8. Вариативные мутации

Затрудняют рефакторинг кода, поскольку фактические значения непредсказуемы.