Всетаки практика показала, что верный выбран способ опробование текста в горячем виде. (͡° ͜ʖ ͡°) есть твердое ощущение, что описать подобную практику просто необходимо. весьма интересный случился прецедент. там дальше — примерная формула про упрощение скорости разработки на проектах с похожей симптоматикой
повествование касается прецедента попадания на эскпоненциально разбухающий проект в легаси коде — 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)
ББ>П.С. к минусам без комментариев — минус, мой личный, характерезующий вас как — некомпете как минимум
С ходу ассоциация с этим http://vesna.nologin.ru/
Рекомендации — для начала привести в соответствие с русским языком.
Re[2]: Сквозная архитектура, или как спасти проект от экспон
Здравствуйте, Osaka, Вы писали:
ББ>>П.С. к минусам без комментариев — минус, мой личный, характерезующий вас как — некомпете как минимум O>С ходу ассоциация с этим http://vesna.nologin.ru/ O>Рекомендации — для начала привести в соответствие с русским языком.
Перед тем, как будет отредактирован текст хочется вопросить, вам написать про митрополетена Васю c идемпотентностью ?)) Весьма раздут текст, и .. невозможно мне вникать во все эти подробности такси, шмакси ..
Вы прочтите еще раз мой текст, задайте вопросы, с первого непонятного контекста .. я же не гружу вас в нем о том, что это компания .. торгующая софтом .. про бензин? .. Нет, я сразу пишу конкрететику, ну .. так, после немножко попытался лирики) .. И вам русский подавай, он у меня своеобразный. Искаженный, может Одесса .. или китайский полк )
П.С. ну ок, спешиал фор ю, я зашифрую минималистично (знаете, что такое минимализм? советую послушать монка. это минималист в джазе. и если по серьезу, то в этой области .. ну разве что сан ра.) немножко про то, что в задаче надо было всеголишь (с) переставить строчки при распечатке текста в чеке. К тому времени я синьер прошедший ..полутораметровый регкспо-подобный (я бы назвал regexp++ где есть, почти есть классы, етц.. внутри boost::xpressive — поэтическая тема, надо сказать) столкнулся с весьма интересной задачей. Хочется поделиться. Вы конкретно против формул?
Здравствуйте, ботан.ботаныч, Вы писали:
ББ> предисловие. ".*" << ""
ББ> общая архитектурная вводная — ББ> во время наличествующих паттерн мышлений, не видится препятствий для использования подобных методик при написании human readable textes. более чем понятно, что (archik)? для желающих прочесть не представит затруднений, потому, читающий — welcome ...
Очень несвязно, как будто у вас нарушения мышления. Алкоголь/наркота/не дай бог, шизофрения.
Re[2]: Сквозная архитектура, или как спасти проект от экспоненциаль
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, ботан.ботаныч, Вы писали:
ББ>> предисловие. ".*" << ""
ББ>> общая архитектурная вводная — ББ>> во время наличествующих паттерн мышлений, не видится препятствий для использования подобных методик при написании human readable textes. более чем понятно, что (archik)? для желающих прочесть не представит затруднений, потому, читающий — welcome ...
scf>Очень несвязно, как будто у вас нарушения мышления. Алкоголь/наркота/не дай бог, шизофрения.
а попытаться предположить, что идет попытка написания минимизированных текстов, про суть. В данном примере рассматривается прицедент в легаси коде с ужасными паталогиями. Такими как 30 000 строк кода в одной функции. Вы коллега, предполагать что-то кроме шизофрении можете? (или историческая память тянет вас засунуть все непонятное (а потому опасное) за решетку дурдома?)
Но при встрече с задачами в проектах с разбросанными по скоупам или растянутыми с избыточной терминологией логиками имплементор сталкивается с необходимостью транслировать сущности при переходе из скоупа в скоуп
что непонятно в этой фразе? это описание контекста проблеммы.
во время наличествующих паттерн мышлений
здесь я оставляю за собой прирегативу немножко пошутить, когда, допустим хочется отрегировать на минусующих без комментов. так (в|на) — в контексте написанипя на форумах с программерами, есть надежда, что кто-то распознает простую строковую альтернативу в регекспах. Так очень удобно написать для (в|на)с понятнее. К примеру :
- куда вы едете ?
— (в|на) Ямайку.
Таким образом, можно оставаться в пределах корректности при, вполне возможно, наличии конфликта (вооруженного) относительно в, или на. Никогда не думал, что это станет поводом для убийства людей .. Скажи ты на, можешь огрести вполне ощущаемо. С чего тогда у вас коллега, такие вопросы возникают про шизофрению связность, или развязность текста . Я вот искренее хочу поделиться паталогическим прецедентом в практике в архитектуре. И я по моему иименно в таком разделе пишу. Мало ли, кто будет работать (в|на) таком проекте
Re[3]: Сквозная архитектура, или как спасти проект от экспоненциаль
scf>>Очень несвязно, как будто у вас нарушения мышления. Алкоголь/наркота/не дай бог, шизофрения. ББ>В данном примере рассматривается прЕцедент в легаси коде с ужасными паталогиями. Такими как 30 000 строк кода в одной функции.
Так это хорошо или плохо с вашей точки зрения?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Сквозная архитектура, или как спасти проект от экспоненциаль
Здравствуйте, LaptevVV, Вы писали:
scf>>>Очень несвязно, как будто у вас нарушения мышления. Алкоголь/наркота/не дай бог, шизофрения. ББ>>В данном примере рассматривается прЕцедент в легаси коде с ужасными паталогиями. Такими как 30 000 строк кода в одной функции. LVV>Так это хорошо или плохо с вашей точки зрения?
это реалити. вот про практику попадания на такие проекты и захотелось рассказать. не думал, что так сложно окажется это описать, собственно идея тривиальная — попадаешь на проект в кратчайшие сроки реализуешь мелкобуст на коленке для хотя бы смарт питиар и functions и некое подобие лямбд, и сквозная архитектура — практически готова делать надо в параллеле с решением твоей текущей задачи (дабы не завалить сроки), главное вырваться из экспоненты.