DevOps & Infrastructure

Ловушка слоёв: почему мы усложняем ПО

Мы тонем в слоях абстракций, добавляя обёртки поверх обёрток. Исходная проблема? Давно забыта. Пора поговорить о цене.

{# Always render the hero — falls back to the theme OG image when article.image_url is empty (e.g. after the audit's repair_hero_images cleared a blocked Unsplash hot-link). Without this fallback, evergreens with cleared image_url render no hero at all → the JSON-LD ImageObject loses its visual counterpart and LCP attrs go missing. #}
Визуальная метафора множества наложенных друг на друга прозрачных слоёв с маленькой, еле видимой проблемой на самом дне.

Key Takeaways

  • Разработка ПО всё больше увязет в избыточных слоях абстракций, скрывающих изначальные проблемы.
  • Исторически слои создавались для изоляции сложности, но превратились в инструмент отсрочки и переноса проблем.
  • Эта тенденция к усложнению не ограничивается проприетарным ПО, а является повсеместной проблемой даже в экосистеме open source.
  • Стоимость чрезмерных абстракций включает снижение продуктивности инженеров, неэффективность системы и потерю фундаментальной ясности.
  • Решение этой проблемы требует приоритезации упрощения и удаления кода над постоянным добавлением новых абстракций.

Смотрите, речь идёт не о каких-то абстрактных материях. Речь о вашем вторнике. О том, как старший инженер часами выслеживает шестимиллисекундный запрос, который по какой-то причине идёт целых восемьсот. О том, как младший смотрит на экран, полный YAML-файлов, и гадает, что вообще такое этот kubelet. Это о том, что происходит, когда мы строим настолько слоистые, настолько обёрнутые в абстракции системы, что никто уже и не помнит, какова была изначальная проблема.

Мы тянемся к очередному слою. Это универсальный рефлекс. Код. Инфраструктура. Процессы. Организация. Оборачиваем API клиентом. Клиент — адаптером. Адаптер — сервисным объектом. Сервисный объект — фабрикой. Развёртывания получают пайплайны. Пайплайны — операторы. Операторы — платформы. Платформы — порталы. Команды — племена. Племена — главы. Центры компетенций. Этот пластырь подходит к любой ране. Сама рана? Никогда не исследовалась.

Этот импульс настолько въелся, что альтернатива едва ли регистрируется. А что, если бы мы могли убрать базовую вещь вместо того, чтобы её оборачивать? Вопрос, который задаётся редко. Команда, которая создала ту самую вещь, — в соседней комнате. Проект — в отчёте за прошлый квартал. У инженера, которому пришлось бы её выкапывать, — тринадцать тикетов, которые закрываются гораздо чище с ещё одной обёрткой. Так что обёртка идёт в ход. Год спустя она получает свою обёртку.

Почему это произошло? Миф об изоляции

Слоистая архитектура имела благородное происхождение. Дейкстра, 1968 год. Дисциплинированное наслоение для ограничения сложности. Каждый слой представлял собой определённый интерфейс. Можно было рассуждать об одном слое, не держа в голове весь стек. Гениально. И остаётся таковым.

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

Где-то между Парнасом и третьим поколением облачных абстракций глагол сместился. Изоляция превратилась в отсрочку. Слой, который когда-то предотвращал утечки, теперь существует исключительно для того, чтобы отсрочить момент, когда придётся взглянуть на месиво внизу. Оператор Kubernetes — это не стабильная абстракция; это YAML, который никто не хочет читать. Декоратор повторных попыток — это не ограничение чистого интерфейса; это замазывание трещин в вышестоящем сервисе, который вечно не работает. ORM — это не абстракция базы данных; это отсрочка разговора о том, какими должны быть реальные запросы.

Лексикон сохранился. Дисциплина? Нет.

Цена сложности: больше, чем просто замедления

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

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

Цена — это не только кэш. Это люди. Старший инженер тратит утро, выслеживая, почему шесть миллисекунд превратились в восемьсот. Она пробирается через декораторы повторных попыток, классы-адаптеры, сайдкары сервис-меша, запасную стратегию, не тронутую с 2023 года. На дне? Запрос к базе данных без индекса. Индекс добавлен. Восемьсот миллисекунд становятся шестью. Декоратор повторных попыток остаётся. Адаптер остаётся. Сайдкар остаётся. Их удаление? Ещё квартал работы. А у квартала другие планы.

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

Когда что-то работает не так, как хотелось бы, добавляют ещё один слой сверху.

В этом и проблема. Мы не спрашиваем, сломана ли изначальная вещь; мы просто замазываем её. А потом жалуемся, когда этот пластырь сам нуждается в ещё одном пластыре.

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

Нам нужно спросить себя: мы строим систему или мы строим памятник отложенным решениям? Потому что сейчас это очень похоже на последнее.

Для этого ли существует Open Source?

Можно было бы ожидать, что open source станет противоядием. Место, где царит прозрачность, где слои видны, где базовый код можно проверить и понять. И иногда так и есть.

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

Это создаёт любопытную иронию. Мы прославляем open source за его инспектируемость, но сами инструменты, делающие его доступным, часто становятся непрозрачными. Обещание понимания машины рушится, когда машина состоит из двадцати слоёв.

Паттерн невидим, потому что он универсален. Мы делаем это в коде, в инфраструктуре, в процессах, в организации.

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

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

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


🧬 Связанные материалы

Written by
Open Source Beat Editorial Team

Curated insights, explainers, and analysis from the editorial team.

Worth sharing?

Get the best Open Source stories of the week in your inbox — no noise, no spam.

Originally reported by Dev.to