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

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

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

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

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

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

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

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



П.С. пока не описано, боюсь снесут эккаунт.

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

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

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

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

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

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

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



П.С. пока не описано, боюсь снесут эккаунт.