предисловие. ".*"

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

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

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

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

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

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



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

предисловие. ".*"

общая архитектурная вводная —
во время наличествующих паттерн мышлений, не видится препятствий для использования подобных методик при написании human readable textes. более чем понятно, что (archik)? для желающих прочесть не представит затруднений, потому, читающий — welcome ...

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

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

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

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

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

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

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



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