Roadmap: куда развивать курс¶

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

Текущее состояние¶

dsa-for-ops уже вырос из «только структуры данных» в более широкую базу для эксплуатации:

DSA — академические lab01–lab05 (массив и стек, список/очередь/дерево, сортировки, поиск, hash map) и прикладные lab00, lab06–lab11 (Python для эксплуатации, графы, куча, LRU-кэш, rate limiting, разбор логов, consistent hashing). Полный список — в конспекте.
Основы / Эксплуатация — теоретический курс (темы 01–12): алгоритмизация, Python, ООП, стандартная библиотека, разработка приложений, качество кода.
Go — трек для SRE/DevOps (темы 13–14) с примерами в src/golang/ и CI.

Go-версии lab01–lab05 лежат в src/golang/dsa/ с table-driven тестами.

Для кого этот курс¶

Целевая аудитория — будущие SRE / DevOps / Ops, которые хотят углубиться в программирование, но не понимают, с чего начать. Для них структуры данных и алгоритмы — не самоцель, а способ понять, почему системы, которые они эксплуатируют, устроены именно так: почему кэш вытесняет данные, почему шардирование ломается при добавлении ноды, почему сервисы стартуют в определённом порядке, почему запрос «разваливается» на масштабе.

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

Принципы (что сохраняем)¶

Новые лабораторные следуют сложившемуся стилю репозитория:

«С нуля», без магии. Минимум встроенных функций и сторонних библиотек — структуры реализуются руками, чтобы было видно, как они устроены внутри (как lab05 обходится без dict).
Docstring с заданиями в начале файла, осмысленные русскоязычные комментарии по ходу кода.
Меню / демонстрация в main(), чтобы лабу можно было запустить и «пощупать» (make py-run labNN).
Тесты в tests/test_labNN.py и конспект в docs/labNN.md с разбором сложности.
Общий код выносится в labs/common.
Блок «Где это в проде» в каждом конспекте — конкретный инструмент (etcd, Redis, PostgreSQL, k8s, nginx), где структура работает «по-настоящему».

Что ещё углубить¶

Основной массив прикладных лаб (lab06–lab11) и блоки «Где это в проде» (включая академические lab01–lab05) уже на месте. Что осталось forward-looking:

Лаба	Что добавить	Зачем
lab03 (сортировки)	бенчмарк-секция: замер перестановок/времени на n = 100/1000/10000 и наглядный рост	превращает «O(n²)» из формулы в ощущение
lab05 → lab11	усилить мостик hash map → consistent hashing (почему `hash % N` ребалансит почти всё при добавлении ноды)	прямая связь с шардированием и балансировкой
Рекурсия	вынести явный разбор (стек вызовов, база/шаг, переполнение) — сейчас спрятана в обходе дерева	новичку нужен отдельный, а не «по ходу»

Идеи для будущих лаб¶

Порядок — по приоритету для целевой аудитории; нумерация условная.

B-tree / B+-tree — развитие BST под диск и страницы: как устроен индекс в PostgreSQL/MySQL. Естественное продолжение lab02 и lab04.
Префиксное дерево (trie) — маршрутизация по префиксам (роутеры HTTP, таблицы маршрутизации, автодополнение).
Скользящие структуры для метрик — HyperLogLog (кардинальность уникальных), count-min sketch (частоты) — вероятностные структуры в духе bloom filter из lab11, но под наблюдаемость.

Открытые вопросы¶

Имя репозитория — решено: dsa-for-ops. Исходное имя mti-dsa после расширения охвата (Go-трек + Python-фундамент) перестало описывать содержание, поэтому репозиторий переименован в dsa-for-ops — структуры данных и алгоритмы под эксплуатацию (SRE/DevOps/Ops). GitHub держит redirect со старого пути, но канонические ссылки и адрес сайта обновлены.
Глубина Go-трека. Развивать Go как полноценный равноправный трек или как «приложение» к Python-курсу? Для SRE/DevOps аргумент в пользу полноценного трека сильный.
Двуязычность лаб. Делать ли для новых DSA-лаб параллельные реализации на Go (как у lab01–lab05), или DSA оставить только на Python, а Go держать отдельным треком.