Есть, как бэ, довольно большая разница между "этот код сложно поддерживать, давайте рефакторить" и "ой, чот разбираться сложно, легче переписать".

ну у вас аргументов пока нету)

ключевое в моем первом сообщении было "если" там как раз ветвление да/нет) вы берете вариант когда все через одно место и возводите в абсолют

очень сложно с обычной практикой когда у тебя есть кодревью протолкнуть и обосновать почему ты модуль переписал

Аргументы просты.
1. Переписывать что-то без понимания того, как это что-то работает - плохая идея, поэтому разбираться всё равно придется.

2. Написать кучку нового кода, которая вроде бы делает тоже самое можно быстрее.
Переписать код, сохранив при этом обратную совместимость и обработку всех корнер кейсов быстрее, чем разобраться в этом самом коде не получится.
Как минимум потому, что это требует зафиксировать контракты, собрать и учесть все костыли, размазанные за годы поддержки этого кода по всему модулю, покрыть это тестами и убедиться, что новый код не хуже.

3. То, что вы перепишете код не сделает его по умолчанию ни более поддерживаемым, ни более расширяемым. И, вполне возможно, что даже качество кода это тоже не поднимет.
Потому что, опять же, что бы сделать что-то более поддерживаемым\расширяемым\удобным нужно отталкиваться от некого baseline - т.е. понимать хорошие и плохие стороны кода, который вы собираетесь переписывать.

4. Переписывание модуля - более глобальные изменения, нежели его расширение\адаптация.
Чем масштабнее изменения - тем больше риски.

Ну и далее по списку.
Поэтому да, "перепишем с нуля, что б было лучше" в большинстве случаев рождает просто новую версию говна, которая решает кусочек проблем и генерирует ворох новых.
Ровно по этой причине умные дяди из этого вашего компьютерсаенса не перепиливают сервисы заново, а рефакторят участки кода и логики.
Естественно после того, как разберутся как этот код работает, зачем там нужен рефакторинг и как они будут считать его эффективность.

1 можно же переписать не зная как работает, но зная ЧТО делает))
это все верно, но опять же мы рассматриваем какой то вырожденный случай переписывать, что бы переписывать. Я чаще вижу нафик переписывать давай костыль. Куда ведет? тоже понятно.
2 но если вам с этим кодом дальше работать то имеет смысл разобраться с этим 1 раз, а не каждый раз смотреть на эти костыли и наворачивать новые.
3 по умолчанию не сделает, смотря кто переписывает.
4 и? никогда ничего не переписывать?
5 умные дяди не переписывают, потому что нету возможности, чаще всего. Я очень часто встречаюсь с ситуацие мы сейчас переписываем наш проект на...
и в целом это сообщение уже противоречит вашему первому высказыванию🙈

1. Опираться на "что делает":
Тут есть разница между "Что делает" aka "Какую задачу решает" и "Что делает в каждом конкретном случае".
Первое не дает полной информации, т.к. не учитывает конкретных состояний системы.

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

Это даже не говоря о том, что помимо "что делает", важно ещё и "как делает" - производительность, ресурсоэффективность, масштабируемость и да, та же пресловутая поддерживаемость и расширяемость.
Что бы сделать "лучше" нужно сравнивать, что бы сравнивать - нужно понимать как работает код и видеть проблемные места.

2 и 4 сразу вместе:
В целом, есть целый спектр решений между "просто наворачивать новые костыли" и "переписать всё заново".
Ровно этот спектр решений называется "рефакторинг".
Выделяешь конкретный кусок кода, который генерирует проблемы -> Формируешь Definition of Done и критерии успешности -> Переходишь к следующему.
Не забывая показывать измеримые и понятные всем ответы на вопрос "Зачем?" и "Почему новое решение лучше".

5. Да нет, просто итеративно улучшать код, решая конкретные проблемы - проще, быстрее и эффективнее, чем раз за разом переписывать, рассчитывая что уж этот-то кодер точно знает как правильно.

Ну конечно же я имел ввиду просто переписать абы как не задумываясь ни о чем🤦🏻‍♂️ отличная позиция для входа в диалог кому же ничего не поясняя))) есть много примеров когда переписывать частями нет смысла, вы опять уходите в крайние случаи как будто это единственно верный вариант 🤷🏼‍♂️

Так всё ж очень просто.
Если мы вернемся к началу нашей дискуссии, то она началась с фразы "проще переписать заново, чем разбираться в коде".
А переписывать что-либо, не разобравшись как оно работает (и почему написано именно так) - это и есть то самое "переписывать абы как, не задумываясь".

Во первых "если проще", во вторых это не подразумевает бездумно переписать))) с чем я с вами согласен)

Вот тут есть список аргументов о том, почему "переписывать то, чего не понимаешь" - плохая идея.

Ну и, конечно же, "переписывать, что бы не разбираться в старом коде" == "переписывать то, чего не понимаешь".

А как использовать код который не понимаешь как работает? Тоже нужно разбираться? Вот так же и переписывать. Ты знаешь, что она должна делать но не знаешь как. Видишь вариант сделать это проще и понятнее. Этого достаточно 🤷🏼‍♂️ Скажи ещё, что нету такого Легаси который проще переписать чем поддерживать))

Это то как видит это какой то человек со стороны, не более. Я не принимаю это в прямом смысле.

Есть тонны легаси, которое проще переписать, чем поддерживать.

Легаси, которое проще переписать, чем разобраться в уже существующем коде - нет.

Т е ты не совсем не можешь допустить, что через третьего человека эти утверждения будут равны?))

Я допускаю, что существуют люди для которых эти утверждения равны.
Это не значит, что эти люди правы. :)

Работая с вами нужен будет словарь терминов)))

Даже больше скажу люди которые будут говорить даже вашими словами могут оказаться не правы)) Главное  бездумно применять тот или иной подход, особенно успешный)

Прошу прощения за повтор, но вдруг найдутся ещё желающие

Здравствуйте, я менеджер бета-тестирования в ivi.
Если вы или ваши знакомые проживаете в США и любите смотреть кино онлайн,
то можете принять участие в тесте потоков ТВ каналов.

Тест будет проходить в несколько этапов.

Первый этап теста будет в браузере и
нам нужны пользователи из любых регионов в США
с доступом к ПК или мобильному устройству.

Второй этап будет на всех платформах:
Web, Smart TV, Android TV, Apple TV, Roku, iOS, Android

Навыки в тестировании приветствуются, но не обязательны.
Инструкции будут подготовлены для любого уровня знаний IT.

Вознаграждение за участие - подписка на сервис и бонусы на счет в ivi.

Будем рады и русско- и англо-говорящим участникам.

Для связи
Почта - betatest@ivi.ru
Telegram -  https://t.me/betatestuser

С уважением. Лобанов Святослав