Лукавство это, легаси переписать - это совсем другой расчёт.
Иногда, конечно, старая система в принципе не позволит добавить новые фичи, но коли уж позволяет, экономия космическая.
На моей практике полные переделки экономически не оправдывались никогда, всегда было волевое решение "поддержка вендора умрёт" или "сумма критических багов => хватит это терпеть"
Даже 10х - человек, а человек это не оркестр(атор). Он не проведёт ревью своего кода, он не проведёт полное е2е тестирование, он не соберёт все требования и т.д.
То есть, он может даже заниматься всем, но с позиции руководства преступно так безраздельно ему доверять и так неэффективно его использовать (не все области ускоряются).
Плюс человек-оркестр с большей вероятностью выгорает. Лучше его беречь, и применять по назначению с соблюдением баланса.
В прошлом тоже не всё гладко, мой старый паспорт имел серию типа XXII-НА, такое в цифры не запихнёшь, как ни крути.
В реальном проекте для одного из мобильных операторов использовалось хранение паспортов в специально заточенной для того системе, с валидацией, вычисткой, блэкджеком и далее по тексту.
Литкод - это не замена теории и не мерило красивого кода. Учить теорию больших О по литкоду - это как учить язык по дуолингво, примеров много, но правильных ответов не найдёшь.
Алгоритмическая сложность "производительного" алгоритма O(N), потому что сортировка 26 значений в O-нотации это всё ещё O(1).
Потребление памяти обоими алгоритмами O(N), хотя константа у левого и меньше. Наивно полагать, что на больших N слово влезет в память константного размера.
Попробуйте прогнать эти решения со строкой в миллионы символов.
Лукавство это, легаси переписать - это совсем другой расчёт.
Иногда, конечно, старая система в принципе не позволит добавить новые фичи, но коли уж позволяет, экономия космическая.
На моей практике полные переделки экономически не оправдывались никогда, всегда было волевое решение "поддержка вендора умрёт" или "сумма критических багов => хватит это терпеть"
Даже 10х - человек, а человек это не оркестр(атор). Он не проведёт ревью своего кода, он не проведёт полное е2е тестирование, он не соберёт все требования и т.д.
То есть, он может даже заниматься всем, но с позиции руководства преступно так безраздельно ему доверять и так неэффективно его использовать (не все области ускоряются).
Плюс человек-оркестр с большей вероятностью выгорает. Лучше его беречь, и применять по назначению с соблюдением баланса.
Изобретение велосипедрв - это весело, но зачем?
Эти состояния/прицессы, повторы, подпроцессы, сигналы и таймеры, параллельные, компенсационные и т.д. уже давно реализованы в bpmn-движках.
В прошлом тоже не всё гладко, мой старый паспорт имел серию типа XXII-НА, такое в цифры не запихнёшь, как ни крути.
В реальном проекте для одного из мобильных операторов использовалось хранение паспортов в специально заточенной для того системе, с валидацией, вычисткой, блэкджеком и далее по тексту.
Которую придётся ляпать во всех поисковых запросах? Да, костыль, причём неудобный.
Так сильно медленней он не потому, что в обвязке, а потому что алгоритм другой.
Первым шагом вместо сортировки подсчётом (мутный reduce) делается группировка списка, а уже вторым подсчёт.
И будет несильно медленней.
Копайлоту всё равно из какого утюга вещать, тем более есть люди, которые в блокноте пишут тексты и кодами балуются.
Литкод - это не замена теории и не мерило красивого кода. Учить теорию больших О по литкоду - это как учить язык по дуолингво, примеров много, но правильных ответов не найдёшь.
Алгоритмическая сложность "производительного" алгоритма O(N), потому что сортировка 26 значений в O-нотации это всё ещё O(1).
Потребление памяти обоими алгоритмами O(N), хотя константа у левого и меньше. Наивно полагать, что на больших N слово влезет в память константного размера.
Попробуйте прогнать эти решения со строкой в миллионы символов.