Всетаки практика показала, что верный выбран способ опробование текста в горячем виде. (͡° ͜ʖ ͡°) есть твердое ощущение, что описать подобную практику просто необходимо. весьма интересный случился прецедент. там дальше — примерная формула про упрощение скорости разработки на проектах с похожей симптоматикой


повествование касается прецедента попадания на эскпоненциально разбухающий проект в легаси коде — windows. С технологиями размазанными по языкам. даже бейсик.нет перепал. (в целом С++, C# C)
Причем я применяю экспоненциально хотя можно применить и в геометрической прогресси, но экспоненциально фонетически интереснее и логически совместимее позже будет показано почему ln). Одной из целей повествования — вдохновить коллег на рискованные мета практики ибо сводит в итоге O(k^n) к O(n) где n — размерность задачи, k > 1 (и считаться скорее всего будет эмпирически).

экспоненциально разбухающий проект может лечиться по разному. а может и не лечиться вовсе, и тоже по разному. Но при встрече с задачами в проектах с разбросанными по скоупам или растянутыми с избыточной терминологией логиками имплементор сталкивается с необходимостью транслировать сущности при переходе из скоупа в скоуп. Обычно смена словаря* может быть оправдан при использовании технологий разной природы. К примеру из С++ в пайтон, или С++-C# еtс.. Где словари и термины транслируются в архитектуре из скоупа одной природы в скоуп иной. Но встречаются проекты с наличием таких переходов безо всякой на то причины так сложилось исторически к примеру, как в данном случае COM компоненты были выведены из кома объединившись в рамках одного скоупа. и, по всей видимости делалось как всегда на вчера и, вероятно, студентами. Ну и дальше народ не особо заморачиваясь просто действовал в канве уже так сделанного. В итоге элементарная задача, которая казалось бы должна быть сведена к перестановке строк в какком нить XML, приводит к O(k^n).
а в следствии наличия таких переходов в отношении один ко многим, и что еще интереснее многие ко многим, при наращивании функционала код обречен на дальнейшее экспоненциальное разбухание. И тривиальные задачи будут требовать участия квалифицированных кадров, с экспоненциальным увеличением человекочасов.

Я попытаюсь добавить гуманитарного описания .. но позже.

Глобально для избегания часто пользуются
1 — нормализация в рефакторинге, что несет за собой трудовые затраты
2 — переход на автоматизацию + генераторы\парсеры, аля шарпового роcлина, что приведет так же к непредвиденным, часто и сильно вероятно уже технологическим затратам
а может и вовсе не лечиться.

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

модерновыми оттенками мышления, и компайл-тайм там отнюдь не последнее в языковедении, последние нотки говорят о том, что времен может быть множество, и мыслить надо во всех. Да во всех временах, как пересекающихся, так и в пересекающихся в одну (и более) сторон, так и не перескающихся вовсе. Даже в плюсах — (препроцессор)(компайлтайм)(статик-рантайм)(рантайм). сколько копий сломано за исключение препроцессора дабы снабдить синтаксис-три всем тем, что содержит препроцессор. (внедрить препроцессор в три?) ладно, это уже философия. Итак .. дальнейшее назовем 30 000 строк кода в одной функции.

Если говорить приближенно к реалиям, в этом конкретном случае были использованы несколько особенностей инженерии

1. теория трансляции (распределение информационных потоков по терминам в пределах скоупа и поведение их при выходе из него, с трансляцией оных из одного в другой), причем С++ позволил делать это в декларативном виде из скоупа решаемой задачи. разумеется это делалось в компайл тайме, и составные типы генерирующиеся из одних в другие.
2. метапрограмминг, что тоже вполне неплохое подспорье при пронзании разбухающего в экспоненциальной форме кода.

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





П.С. к минусам без комментариев — минус, мой личный, характерезующий вас как — некомпете как минимум

* — под словарем здесь понимается набор терминальных сущностей(токенов) при реализации функционала. К примеру, более детально, это может быть switch case — где каждый кейс — есть токен, условно назовем термин словаря etc)