Чем больше проект, тем заметнее одна вещь:
В зрелых production проектах очень много обслуживающего кода.
Логирование, аналитика, кэширование, обработка ошибок, мониторинг — эти системы не являются бизнес-логикой, но присутствуют в каждом компоненте. Они проникают повсюду.
🔸С чего все началось
В 1997 году команда из Xerox PARC (Kiczales et al.) опубликовала работу Aspect-Oriented Programming, в которой ввела понятие aspect.
Авторы разделили свойства системы на два класса: components — бизнес-логика, которая чисто декомпозируется в процедуры, и aspects — свойства, которые пересекают эту логику насквозь и которые не получается скрыть за абстракциями^
Aspects tend not to be units of the system's functional decomposition, but rather to be properties that affect the performance or semantics of the components in systemic ways.
Логирование, кэширование, управление памятью, обработка ошибок — всё это aspects.
Они не являются частью бизнес-логики, но вынуждены присутствовать в каждом компоненте.
Авторы показали это на системе оптического распознавания символов: чистая бизнес-логика занимала 768 строк.
После добавления production-аспектов — оптимизация памяти, кэширование промежуточных результатов, loop fusion — код разросся до 35,213 строк. В 45 раз.
И этот "tangled code", по словам авторов, стал "excessively difficult to develop and maintain".
🔸Другой пример посвежее
В 2019 году исследователи из Nova Southeastern University опубликовали работу GAMESPECT, где изучали эту проблему в контексте игровых движков:
Video game programming is an area where code duplication is extremely prevalent.
Similar types of tasks are performed in multiple places throughout a game engine codebase.
For example: game balance, logging, and memory allocation are just a few of the areas which are located across disparate locations of the codebase.
При анализе production-игры Noise Paradox (какая-то рандомная игра на UE4 🥱) авторы обнаружили, что одна из самых часто дублируемых функций —
PostAKEvent.Централизация таких вызовов в их исследовании дала сокращение кодовой базы от 9% до 40% в зависимости от системы. Не "чуть удобнее" — а измеримое уменьшение объема кода.
🔸Как это использовать
Такой код, который не является частью бизнес-логики, но который нужен чтобы обслуживать, отлаживать, оптимизировать и улучшать пользовательский опыт — прозвали cross-cutting concerns (сквозная функциональность).
В простонародье мы это называем обслуживающий код.
И он есть в каждом проекте:
▫️Логирование и аналитика — дублируются в десятках систем
▫️Звук и вибрации — вызываются из любого места, от UI до геймплея
▫️Кэширование и конфиги — пронизывают всё, от загрузки до runtime'а
▫️Обработка ошибок — размазана по всей кодовой базе
И по большей части — это основной объем кода, который мы пишем. Не бизнес-логика, а именно обслуживание.
Он необходим, от него никуда не деться.
И именно он делает систему сложнее для понимания — потому что тебе нужно продраться через десятки строк инфраструктуры, чтобы ответить на вопрос: "как это работает?".
🔻 Cross-cutting concerns — неотъемлемая часть любого приложения.
Их нельзя убрать, но можно минимизировать их присутствие в коде: тратить как можно меньше строк и символов на обслуживание, оставляя максимум места для бизнес-логики.
Чем меньше "обслуживающего" шума — тем легче читать, понимать и развивать систему.
В следующей статье — как с ними работать на практике и почему можно сделать осознанный выбор в сторону singleton.
Ставь 👍 если тебе заходит такого рода контент!
Ты знаешь кому переслать эту статью 💪
#software_engineering@UniArchitect