Рефакторинг кода – очень важен для работы любого разработчика, и есть множество ресурсов, которые подробно рассказывают об этом. И вот один из способов.
Давайте начнем с предыстории рефакторинга
Две функции выборки разбросанные повсюду в моей кодовой базе с немного разными именами, которые я хотел преобразовать в один модуль многократно используемых функций. Вот только два из них:
Это выглядело громоздко. Каждая функция делает очень мало помимо того, что может быть достигнуто простым использованием fetch, вокруг которого она обернута. Помимо инкапсуляции URL конечных точек и свойств метода, эти два элемента выглядят совершенно одинаково и должны быть повторно использованы во всей базе кода.
Функция должна быть простой, когда это возможно
Первый и главный критерий для функции заключается в том, чтобы по возможности после рефакторинга она была простой. Простота означает возможность повторного использования. Если функция должна изменить какое-либо общее состояние, то она может быть хорошим кандидатом на метод. Это позволяет функциям быть легко тестируемыми и повторно используемыми. Функции с таким именем, как postLoginData, нарушают это требование. Вот несколько способов рефакторинга, не задумываясь о реализации функции:
- user.login ()
- login (user)
- post (loginUrl, user)
Приведенный выше список был упорядочен от наименее обобщенного до наиболее переиспользуемого. На самом деле, первые два имеют одинаковый уровень общности. Только последний можно использовать много раз, и это как раз то, к чему я стремился.
Теперь видино, что обе мои функции довольно проблематичны. Иногда вы надеваете разные шляпы и расставляете приоритеты по-разному. Можно спешить и реализовывать функции просто чтобы заработало, если мы время от времени возвращаемся и наводим порядок.
Обоснование рефакторинг
Чтобы решить, следует ли что-то рефакторить, я думаю о цели и ценности реализованной функции.
Например, функция для создания («POST») и функция для получения («GET») данных имеют принципиально разные цели, независимо от малой разницы в реализации. Намерения четко различаются, чтобы оправдать создание двух функций.
Однако обертка произвольного URL-адреса внутри функции, например, конечной точки API для входа в систему, и затем присвоение имени функции postLoginData не добавляет особой ценности функции, учитывая ее сниженную универсальность. URL, помимо что, это одна строка, должен описывать «действие» пользователя, должен нести смысл. Возьмем к примеру художника с масляными красками, палитрой и кистями. То, что художник хочет нарисовать, должно быть историей художника, иметь смысл. Палитра, коллекция красок и кистей должны содержать инструменты для реализации идеи. Можете ли вы представить набор красок для рисования пейзажей океана? Это разумно. А как насчет того, чтобы нарисовать этим набором корабль? Не просто. Сущность слишком специфична, чтобы быть инкапсулированной.
Второй рефакторинг выглядит так:
Теперь этот код выглядит намного чище, после того как повторяющиеся конфигурационные свойства объекта были преобразованными в константу baseConfig. Кроме того, я добавил необязательный параметр config для каждой функции, чтобы сделать ее настраиваемой извне. Object.assign используется для объединения пользовательского config с baseConfig.
Здесь видно, что объект распылен между различными действиями. Я уже был доволен результатом рефакторинга, но так как было свободное время, то решил посмотреть, смогу ли я выбросить что-то еще. Вот финальный рефакторинг:
Мне лично больше нравится эта версия, потому что функции get и post очень тонкие обертки вновь созданной функции send (которая не экспортирована). Это делает последнюю единой точкой отладки, если позже возникнут ошибки.
Рефакторинг – запутанное занятие не потому что это сложно, а потому, что требует более глубокого дизайнерского мышления. И будьте уверены, что вы не сделаете его правилом для всех. Рефакторинг кода для повторного его использования может неожиданно вызвать отрицательную реакцию людей, особенно когда усилия намного больше, чем выгода. Поэтому нужно стремиться к равновесию. Существуют и другие факторы, например, договоренности об именах и параметрах функций, которые могут помочь с доступностью и о которых всегда нужно думать.
