Антипаттерны, или просто примеры неэффективного кода, могут быть очень коварными засланцами, даже в исходном тексте бывалых разработчиков. Иногда это следствие лени или очень сжатых сроков, иногда подводит невнимательность.
В этой статье я расскажу вам об антипаттерне проектирования Ёлочка или о том, как не превратить свой код в дрова.
Я нахожу этот антипаттерн интересным потому, что получить его можно не однокаратным внесением изменений, а целой цепочкой улучшений, связанной с развитием кода. И да, вы правильно поняли, мы убеждаем себя и заказчика в том, что код становится лучше, но в итоге получаем ёлочку. Чтобы лучше это понять, рассмотрим каскад задач, от простого к сложному, и попытаемся проследить ход суждений, приводящих к неэффективному коду.
Рождение проблемы
Представим, что существует несложный компонент, отображающий некое число Counter
const Counter = ({ value }) => {return <div>{ value }</div>;};
Counter не следует воспринимать буквально. Это просто упрощённая модель для контрастного выражения сути проблемы.
Нам поступила задача сделать его более функциональным, скажем
после числа ставить единицы измерения digits. Теперь
компонент имеет следующий вид:
const Counter = ({ value, digits }) => {return <div>{ `${value} ${digits}` }</div>};
В процессе разработки оказалось, что иногда есть необходимость
брать единицы измерения в скобки, например вот так: 10
(см). Мы решаем это сделать внутри компонента, для
удобства:
const Counter = ({ value, digits, type }) => {const temp = type ? `(${digits})` : digits;return <div>{ `${value} ${temp}` }</div>};
Пожалуй, достаточно. Будем считать, что Counter достаточно
функциональный компонент и пригоден к использованию в том виде, в
котором сейчас существует. Теперь рассмотрим его с точки зрения
алгоритмизации. Представим, что входные параметры этого компонента
a, b и c, а y -
это некая функция вида f(a, b, c), решение которой
будет символизировать обработку всех возможных состояний и
отрисовку компонента.
Из реализации Counter видно, что как минимум два аргумента
(digits и type) взаимозависимы, т. е. всё
множество вариантов их обработки имеет решение a * b,
соответствеено. Итоговая формула, в этом случае, будет выглядеть
так:
Выглядит не так и плохо, ведь digits это однотипная
константа, как и value, а это значит, что аргумент a,
можно принять за единицу. В итоге мы смогли показать, что общее
количество обрабатываемых состояний растёт линейно, т. е. только
вместе с type.
А теперь внимание... На этом моменте разработчик уже попал в ловушку. Причина проста, мы видим простую, линейно растущую функцию, но на самом деле, она сохранила свой геометрический рост.
При попытке усложнить условие, например, на основании
digits выбирать тип скобок, наша функция проявит себя
резким скачком своего значения, а это означает, что и содержание
компонента Counter будет резко усложняться. Код растёт, как
ёлочка...
Где ошибка?
Очевидно, что ошибка возникла когда внутри Counter появились взаимосвязанные аргументы. Даже, если бы мы хотели сохранить новый функционал, локализировав его в отдельный метод, мы бы смогли уменьшить негативное влияние на всё приложение в целом. Скажем так:
const getCoveredDigits = (digits) => `(${digits})`;<Counter value={value} digits={getCoveredDigits(digits)}/>
В итоге, записать функцию обработки состояний можно следующим образом:
При этом, f(b) будет сохранять линейный рост там,
где нет необходимости в сложных преобразованиях. Таким образом, мы
немного улучшили декомпозицию.
Выводы
Разумеется, при реализации Counter мы намеренно допустили несколько ошибок, которые часто остаются незамеченными на реальном производстве. Хоть и идеальной компонентной модели не существует, но при более выгодной декомпозиции, удаётся сократить объёмы исходного текста и, как следствие, повысить общую надёжность и масштабируемость своих приложений.
