Совершенный код: проектирование функций
2026-02-26 22:40 Diff
https://ru.hexlet.io/blog/posts/sovershennyy-kod-proektirovanie-funktsiy

Создавать функции легко, но создавать их правильно — гораздо сложнее, чем кажется. Плохо спроектированные функции плохо тестируются, с трудом адаптируются под новые требования и часто переписываются. В этой статье мы пройдёмся по ключевым подходам создания удобных функций: научимся правильно разделять ответственности, строить цепочки функций и проектировать их сигнатуру. Материал статьи базируется на ошибках, которые совершают студенты Хекслета на проектах.

Подписывайтесь на канал Кирилла Мокевнина в Telegram — чтобы узнать больше о программировании и профессиональном пути разработчика

Содержание

Введение

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

Но это не так. Функция, в первую очередь, способ повысить уровень абстракции. Другими словами, функции описывают операции, о которых мы хотим думать, как о едином целом, не погружаясь в детали того, как они работают. И как следствие, появляется возможность убрать дублирование кода. Такой способ мышления о функциях уже сам по себе способен повлиять на способ их проектирования. Посмотрите на пример:

Функция makeFriendship существует не потому, что её код повторяется в разных местах. А потому, что она прячет в себе подробности выполняемой операции. Такой код гораздо более «человеческий».

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

Задача состоит в том, чтобы спроектировать код библиотеки, которая анализирует два курса на Хекслете и возвращает название того курса, который короче (в часах). Для выполнения этой задачи библиотека должна запросить HTML страницы, найти внутри них время прохождения курса, сравнить его и вернуть название курса.

Её использование выглядит так:

Если реализовать эту функцию в лоб, без выделения каких-либо абстракций, то она будет такой:

Проверить её работу можно на repl.it.

Эта функция настолько маленькая, что в реальной жизни она бы такой и осталась. Код прямой, понятный и короткий. Практически любое изменение этой функции приведёт к раздуванию кода. Но для демонстрации это нормально, слишком сложная функция могла бы сделать статью неподъёмной для большинства читателей.

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

Первое, что бросается в глаза, повторение логики для каждой страницы:

  1. Скачивание страницы
  2. Извлечение названия курса и его продолжительности

Вынести повторяющийся код можно так:

Этот код выглядит вполне прилично. Он хорошо читается, дублирование убрано. Но всё же, он спроектирован неправильно.

Побочные эффекты и чистота

Главная проблема в том, что код, взаимодействующий с внешней средой (выполняющий побочный эффект) axios.get(link) переместился с внешнего уровня на более глубокий во внутреннюю функцию, сделав её асинхронной. Почему это плохо? Побочные эффекты автоматически усложняют любой код, в котором они встречаются:

  • Любая функция с побочными эффектами перестаёт быть чистой. Поведение функции становится менее предсказуемым, она начинает порождать разнообразные ошибки. В нашем случае это ошибки, связанные с проблемами сети (десятки сетевых ошибок!).
  • Функции с побочными эффектами намного сложнее переиспользовать и тестировать. Для работы функции getPageInfo(link) нужна стабильная сеть. Но это ещё не всё, она опирается на то, что сам Хекслет работает без перебоев и отвечает быстро. Это, конечно, почти всегда так :), но жизнь сложная штука.
  • Любой код, вызывающий функцию с побочными эффектами, автоматически становится "грязным" и начинает обладать теми же недостатками. Чем глубже по стеку вызовов помещается побочный эффект, тем хуже.

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

Главный архитектурный принцип звучит так: "Изолируйте побочные эффекты от чистого кода". Соответственно, всё, что связано с вводом/выводом, должно быть не внутри, а, желательно, на самом верхнем уровне. Причём, чаще всего в начале работы программы происходит чтение необходимых данных, потом большой блок основной логики (чистый код) и на выходе снова побочный эффект, например, запись в файл. Это не всегда возможно, но к этому нужно стремиться.

Перепишем код в соответствии с этим знанием:

Извлечение запроса из getPageInfo(response) сделало эту функцию чистой. Она перестала быть асинхронной, перестала порождать сетевые ошибки. Её легко протестировать, и её поведение зависит только от входных аргументов (так как нет внешней среды, сети). Но она всё ещё не так хороша, как могла бы быть.

Модульность и зависимости

После изменений ответственность функции getPageInfo сократилась до парсинга входного HTML и возврата необходимых данных. Может ли её поведение зависеть от того, каким образом получен HTML? Правильный ответ нет, ей должно быть совершенно без разницы, как он попал в программу. Но фактически это не так: прямо сейчас функция принимает на вход объект response, который имеет прямое отношение к сети и специфичен для конкретной библиотеки axios.

На этом стоит заострить внимание, так как программисты совершают подобные ошибки на каждом шагу. Вероятно, вы заметили, что мы проектируем функцию compareCourses по принципу сверху-вниз. Сначала мы определили её внешний интерфейс и затем пошли вглубь. Это правильный подход, он фокусируется на клиентах нашей библиотеки, а не на её внутренностях.

Проблемы начинаются тогда, когда разработчик подстраивает поведение и интерфейс нижних модулей под верхние модули. Приведу пример. В первом проекте Хекслета есть задача сделать текстовую игру, в которой пользователю выводится число, и он должен указать, чётное оно или нет. Делается это вводом yes или no в консоль. В этой задаче есть чёткое разделение уровней: у нас есть число и механизм определения его чётности, и есть отдельная задача — проверка ввода пользователя, угадал ли он. Но вот, что делают многие разработчики:

Из-за того, что в программу вводятся значения yes и no, разработчик "подстроил" процесс работы с чётным числом под него. Про такой код говорят, что "течёт абстракция". Это очень серьёзное нарушение модульности. Модули нижнего уровня не должны знать про модули верхнего уровня. Это верхний уровень должен подстраиваться под нижний уровень. Правильная реализация должна выглядеть так:

Теперь функция isEven(number) выполняет свою задачу так, как она должна выполнять. Она может быть использована в любом контексте. Её даже можно вынести в отдельную библиотеку, удобную для дальнейшего переиспользования.

Другой прекрасный пример, который должен знать любой программист — модель OSI. Благодаря тому, что сеть построена с использованием этой идеи, программисты используют HTTP, не думая про то, как конкретно (по воздуху, по проводам) данные доставляются пользователю.

Вернёмся к нашему коду и изменим функцию getPageInfo:

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

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

Композиция вместо вложенности (Пайплайн)

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

В программировании такой порядок исполнения кода называют пайплайном (Pipeline). Он возможен только в хорошо структурированном коде. Там, где функции не зависят друг от друга напрямую, а фокусируются на выполнении только своих задач. Благодаря этому появляется возможность соединять их и переиспользовать. Пайплайн распространён не только в программировании: любой человек, знакомый с командной строкой, так или иначе использует его:

Пайплайн настолько мощная вещь в программировании, что во многих языках он существует на уровне синтаксиса. Например: F#, OCaml, Elixir, Elm, Julia, Hack. И прямо сейчас ведётся работа по внедрению пайплайна в JavaScript. Посмотрите, как меняется код с ним:

Вот как будет выглядеть код нашей функции с применением нового синтаксиса:

Дополнительные материалы