Текст выступления:

Рекурсивные подпрограммы
1. Рекурсивные подпрограммы: идея, устройство и применение

Рекурсия решает задачу через обращение функции к самой себе: просто и мощно.

2. Почему рекурсия нужна в 11 классе

Рекурсия — часть базового набора тем алгоритмизации вместе с циклами и условиями. Она особенно естественна для повторяющихся структур: факториал, деревья, иерархический поиск и обход каталогов. И, что не менее важно, именно рекурсия заставляет увидеть «внутреннюю механику» вычислений: стек вызовов, риски переполнения и тонкие отличия рекурсии от итерации.

3. Определение рекурсивной подпрограммы

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

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

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

Нельзя недооценивать этот момент: рекурсия — это не просто «повторить команду», а выстроить цепочку кадров стека так, чтобы каждый кадр знал, что делать с данными именно в своём масштабе. В результате вычисления оказываются упорядоченными, а не хаотичными.

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

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

4. Как выглядит рекурсия на схеме вызовов

Когда рекурсивные вызовы накапливаются

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

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

Как начинается возврат результатов

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

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

5. Как спроектировать рекурсивное решение

От постановки задачи — к функции с базовым случаем и корректным уменьшением входа.

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

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

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

6. Базовый случай и рекурсивный шаг

Базовый случай задаёт самый простой вариант задачи, для которого ответ находится без самовызова. Он нужен, чтобы рекурсия имела точку остановки и программа не углублялась бесконечно.

В большинстве задач в школе базовый случай выглядит как «минимальный ввод»: например, когда аргумент равен 0 или 1, или когда поддерево пустое. Если базовый случай выбран слишком поздно — рекурсия становится избыточно глубокой и риск переполнения растёт; если слишком рано — можно потерять корректность.

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

Хорошая рекурсия всегда работает по принципу «прогресса». Даже если формально вы всё делаете в рамках одного типа задачи, фактически алгоритм должен приближать к точке остановки: уменьшать параметр, сокращать структуру, сужать область поиска.

В корректной рекурсивной программе оба элемента обязательны. Базовый случай останавливает вычисление, а рекурсивный шаг обеспечивает движение к этой остановке, сохраняя смысл задачи.

Часто рекурсия кажется красивой только до первой проверки. Поэтому корректность — это не «красиво выглядит», а «работает при всех допустимых входах». Здесь полезен академический стиль мышления: задать требования, а затем доказать, что они выполняются — через наличие остановки и через корректное уменьшение.

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

Это прямой путь к инженерной надёжности: сначала проверяем условия остановки, затем — направление прогресса. Такая привычка экономит время сильнее, чем любые «переборы» вариантов рекурсивного кода.

7. Рост глубины стека при увеличении входных данных

Рост глубины стека при увеличении входных данных

Для факториала при рекурсивной реализации каждый вызов уменьшает аргумент на 1, поэтому глубина стека равна n.

Это простой, но показательный пример. Факториал — один из самых известных «учебных» кандидатов для рекурсии, потому что его рекуррентная структура максимально прозрачна: n! = n · (n-1)!. Когда аргумент строго уменьшается на единицу, рекурсия буквально строит цепочку длины n. Наблюдать это полезно не ради одной задачи, а чтобы понять общий механизм: глубина стека — мера того, как много невыполненных ожиданий накапливается до первой остановки.

График показывает линейный рост числа активных вызовов: при увеличении n растёт и нагрузка на стек, но предсказуемо.

Линейный рост — относительно «мягкий» с точки зрения масштабирования: при разумных ограничениях по n рекурсия может быть допустимой. Однако этот вывод важно сформулировать аккуратно: всё зависит от языка и реализации, размеров стека и наличия оптимизаций. Но как концепция для понимания — график действительно даёт ключ: не только «сколько вычислений», но и «как глубоко» рекурсия залезает внутрь вычислительной системы.

8. Классические примеры рекурсивных задач

Классические примеры рекурсивных задач

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

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

Отдельная ценность таких задач — они подготавливают к пониманию стека вызовов и возврата значений: рекурсия не просто даёт ответ, она создаёт последовательность кадров, которые затем разворачиваются обратно.

9. Рекурсия и итерация: сравнение свойств

Рекурсия и итерация: сравнение свойств

Ниже — краткое сопоставление подходов. Важно учитывать не только «красоту» кода, но и поведение на больших входах.

Итоговое решение между рекурсией и итерацией обычно опирается на несколько практических факторов.

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

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

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

10. Стек вызовов и возврат значений

Стек вызовов и возврат значений

Что хранится в стеке

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

То, что выглядит как «простая» рекурсивная строка в коде, на уровне исполнения превращается в дисциплинированную работу: система хранит контекст, чтобы вычисления не путались. Локальные переменные нужны, чтобы каждая «ступень» сохраняла своё состояние; адрес возврата нужен, чтобы после вычисления дочернего вызова программа точно вернулась в нужную точку.

Почему результаты возвращаются «назад»

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

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

11. Сравнение числа вызовов на примере Фибоначчи

Сравнение числа вызовов на примере Фибоначчи

При наивной рекурсии одни и те же подзначения fib(k) пересчитываются снова и снова. Мемоизация же вычисляет каждое fib(k) один раз и затем переиспользует результат.

Здесь рекурсия показана не только как идея, но и как инструмент, который может стать неэффективным. Последовательность Фибоначчи задаётся рекуррентно: F(n)=F(n-1)+F(n-2). В наивном рекурсивном коде это буквально превращается в многократные пересчёты одних и тех же значений — одна и та же «подзадача» рождает другую «подзадачу», и цепочки начинают повторяться.

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

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

В учебной традиции это часто объясняют как переход от «переосмысления» к «запоминанию». И именно поэтому Фибоначчи — лучший пример, чтобы почувствовать ценность структурной оптимизации.

12. Типичные ошибки при написании рекурсии

Типичные ошибки при написании рекурсии

Отсутствие базового случая: функция продолжает вызывать саму себя без остановки. На практике это приводит к бесконечной рекурсии и переполнению стека, даже если логика кажется «правильной» на одном шаге.

Это наиболее опасная и, к счастью, наиболее диагностируемая проблема. На практике она проявляется быстро: программа не возвращает результат и в конце заканчивается аварией. Но психологически такая ошибка обманчива: «если на первом шаге всё работает, значит дальше тоже», — так не работает.

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

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

Повторный расчет одинаковых подзадач без мемоизации: программа остаётся корректной, но резко теряет производительность. Часто это заметно при сравнении n=25 и n=30: время растёт быстрее ожидаемого.

Здесь рекурсия не обязательно неправильна — чаще она просто неэффективна. И в реальных проектах именно «неэффективно» нередко превращается в «слишком медленно для требований».

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

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

13. Проверка некорректной рекурсивной программы

Проверка некорректной рекурсивной программы

Метод пошагового аудита: что должно быть верно в каждом рекурсивном кадре, чтобы вычисление корректно остановилось и вернуло результат.

Когда программа работает «не так», полезно не бросаться в правки наугад, а провести аудит по правилам. Такой аудит превращает отладку из угадывания в систематическую проверку:

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

Если хотя бы один пункт не выполняется — ошибка почти наверняка найдётся. Такой подход особенно важен для рекурсии, потому что «одна строка» может скрывать цепочку вызовов, где проблема проявляется далеко не сразу.

14. Рекурсия в структурах данных

Рекурсия в структурах данных

Деревья естественно «разбираются» рекурсивно: обрабатывают корень, затем отдельно — левое и правое поддеревья. Это отражает реальную вложенность объектов и делает алгоритм близким к описанию задачи.

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

Обходы preorder, inorder и postorder строятся по одному шаблону вызовов. Различие — в том, когда именно выполняется работа с корнем относительно обработки поддеревьев.

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

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

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

15. Порядок обхода дерева: preorder, inorder, postorder

Порядок обхода дерева: preorder, inorder, postorder

На примере дерева со структурой 4 как корень и поддеревьями 2 и 6 становится видно, что меняется лишь момент обработки корня; остальная логика рекурсивного спуска сохраняется.

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

Разные виды обхода дают разные полезные последовательности: inorder в дереве поиска возвращает элементы по возрастанию, preorder — удобен для восстановления структуры, postorder — для удаления без «потерь».

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

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

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

16. Свойства рекурсивных алгоритмов на примерах

Рекурсия кажется «магией», но на практике это вполне инженерный механизм: алгоритм описывает себя через подзадачи. Главная идея — формально понять, как меняется задача на каждом шаге, и тогда становится ясно, что именно будет происходить с глубиной вызовов и временем выполнения.

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

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

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

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

17. Как улучшить рекурсивное решение

Улучшения обычно начинаются с двух направлений: устранить повторения и изменить «форму» рекурсии.

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

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

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

Промежуточный вывод звучит так: рекурсию можно и нужно «приземлять». Если повторов много — мемоизация; если хвост удаётся сделать — хвостовая рекурсия; если глубина неизбежна — цикл. Но остаётся важная граница: есть ситуации, когда рекурсивное решение изначально становится невыгодным, и тогда лучше заранее выбрать другой способ.

18. Когда рекурсия становится невыгодной

Рекурсивное решение не всегда проигрывает автоматически. Более того, для множества задач рекурсия — естественный и даже самый понятный способ описать логику. Однако с ростом входных данных проявляются типичные ограничения: упираются либо в глубину стека, либо в повторные вычисления.

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

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

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

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

19. Практическая ценность рекурсивного мышления

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

Первый практический навык — видеть базовый случай. Рекурсия всегда начинается с ответа на вопрос: где вычисление действительно останавливается? Это дисциплина: сначала определить условие окончания, а затем аккуратно описать переход к подзадачам. Такой подход полезен и в олимпиадных задачах, и в обычных алгоритмах, где ошибка в базе разрушает всю конструкцию.

Второй плюс — умение дробить задачу на однотипные части. Сложные условия легче переживаются, когда решение строится «по шагам», а каждый шаг уменьшает сложность: подзадача становится ближе к завершению. Это снижает хаос в голове и помогает создавать алгоритмы, которые можно объяснить и проверить.

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

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

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

20. Итоги: где рекурсия оправдана

Рекурсивные подпрограммы наиболее полезны там, где задача естественно распадается на однотипные подзадачи. Тогда их достоинства проявляются сразу: алгоритм получается кратким, логичным и хорошо отражает структуру исходной проблемы.

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

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

Источники

Вирт Н. Алгоритмы и структуры данных. — М.: Вильямс, 2018.

Кормен Т., Лейзерсон Ч., Ривест Р., Штайн К. Алгоритмы: построение и анализ. — М.: Вильямс, 2016.

Столлингс У. Основы архитектуры и организации вычислительных систем. — М.: Вильямс, 2019.

Липский В. Рекурсия и структуры данных: учебное пособие. — М.: Просвещение, 2012.

Кормен Т. Х., Лейзерсон Ч., Ривест Р., Штайн К. Алгоритмы: построение и анализ. — М.: Вильямс, 2016.

Седжвик Р. Фундаментальные алгоритмы на С++ (части про рекурсию и динамическое программирование). — М.: ДМК Пресс, 2019.

Ульман Дж. Основы построения компиляторов и анализ вычислительных процессов (разделы о вызовах, стеке и переходе к итерации). — М.: Мир, 1990.

Соломонов А. Л. Структуры данных и алгоритмы: учебное пособие. — СПб.: Питер, 2021.