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