Совершенный код: нисходящее и восходящее проектирование
2026-02-26 19:00 Diff
https://ru.hexlet.io/blog/posts/sovershennyy-kod-nishodyaschee-i-voshodyaschee-proektirovanie

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

В книгах эти подходы часто противопоставляются. Считается, что если выбран один подход, то второй — исключен. Но это не так — в статье я объясню, почему следование только в одном направлении приводит к проблемам.

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

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

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

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

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

В качестве примера возьмем второй проект Хекслета, где разрабатывается библиотека для построения различий между двумя файлами. Если коротко, то весь интерфейс библиотеки — это одна функция, которая принимает на вход два пути до файлов определенных форматов (yml, json, ini) и возвращает описание различий между структурами этих файлов. Вот её использование:

Код выше является примером подхода сверху-вниз. Мы описали то, как она будет использоваться, но ещё не знаем про то, как она будет написана (или уже написана). Самое приятное, что реализовать эту функциональность можно совершенно разными способами, и ни один из них не повлияет на то, как библиотека будет использоваться. Это значит, что мы получили отличную модульность.

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

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

Перед тем, как читать дальше, попробуйте ответить сами себе, что не так с этим кодом?

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

Подобный код сильно снижает модульность программы. Одни части приложения начинают сильно опираться на другие там, где этого можно было избежать. Как следствие, изменение в одном месте приводит к тому, что код начинает ломаться в другом месте — там, где этого не ожидали.

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

Попробуем переписать этот код правильно, с выделением хороших абстракций:

Потенциально, если бы мы работали с большим числом файлов или даже с заранее неизвестным их количеством, имея на руках хорошую абстракцию, можно было бы сделать так:

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

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

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

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