Используйте IF по назначению, пожалуйста…

Меня всегда интересовала эффективность.
Не знаю, наверное — какая-то индивидуальная особенность.

Уверен, что для кого-то это будет откровением, а для других — пройденный этап, и они скажут «я зря это прочёл».
Но, как говорится «повторение — мать учения», поэтому не вижу ничего «такого».

Вопрос о том, почему один почему один программист постоянно fuck-up’ит, а другой нет, при том что код первого вроде бы «лучше», «лаконичней» и занимает меньше места, не давал мне покоя.
Сегодня один из ответов у меня есть, поэтому спешу донести его до вашего сведения, чтобы «сделать мир лучше».

Не разделяйте точки входа в алгоритм через IF!
Просто не делайте этого, и все.
Сэкономите кучу времени на отладке. Да — я на полном серьёзе это заявляю.

У вас большое приложение с десятком экранов?
И предполагается, что с UI будут взаимодействовать «живые» люди?
И может быть это даже будут не только тестировщики?
Ваш UI случайно не сделан при помощи JavaScript?

Если «Да», то бейте своих Front-End программистов по рукам, когда увидите, что на десяток кнопок навешен один и тот же handler!
Если «да», то промывайте им мозги целительной нотацией, если увидите что три UI действия, а если они ещё и с разных «экранов», обрабатываются одной функцией!

Вы может быть спросите, а в чём разница между обычным программистом и JavaScript программистом?
Я Вам отвечу, серьёзно, как это ни печально — отвечу…
JavaScript программист по своему «браузерному» определению Однопоточен!
В том смысле, что, как мне подсказывает КЭП, у него всегда один поток мышления, один «контекст выполнения», его «встроенный отладчик» не разделяем, никак, ничем!

И в процессе отладки его мозг просто не в состоянии учесть, что кроме этого алгоритма данный код может отвечать за что-нибудь ещё. Это сложившийся факт. Как и то, что при обычном, написанном «по учебнику», прототипном наследовании вы не сможете создать instanceof «А», конструктором «B», даже если «B» — это instanceof «A».

Нет, Вы то, конечно можете написать эти «классовые» извращения, я в вас верю. Но только не типичный UI-щик.
Этот «человек измученный нарзаном» понятия не имеет о переопределении метода в зависимости от типа входной переменной.
Просто потому, что у него нет даже такого понятия как «строгая типизация».

Простой пример из реальной жизни.
20 часов отладки на 30 строк кода.
При том, что могло быть 0 часов отладки на 40 тех же самых строк, но только в двух\трех\четырёх методах вместо одного.

Есть экран «Создание записи». На нём две кнопки «Сохранить» и «Сохранить и создать ещё».
Есть экран «Редактирование записи». На нем только одна кнопка «Сохранить».

На все три кнопки повешен один и тот же handler.
Надеюсь, что многие уже почувствовали «подвох».

Для упрощения, за все три кнопки отвечает один персонаж, если бы их было двое, то это был бы вообще «тёмный лес, зубастые волки».
Нет, ребята хорошие, правильные, грамотные, но суть не в них вообще!

Суть в IF, и в том, что JavaScript «однопоточен», и вообще «такой какой есть».

Разделить Submit от разных экранов, естественно вообще мыслей не было.
Разделить Submit от разных кнопок тоже.

Submit же был такой себе обычный.
При Создании отправлял форму, принимал ID объекта и высылал прикреплённые файлы.
При Редактировании отправлял форму.

20 часов, 30 строк, один IF, 10 разных багов в Jira.

Мысль о том, что когда правишь экран Создания нужно помнить об экране Редактирования не «закралась».
Мысль о том, что «Сохранить и создать ещё» это тоже нужно учесть — там же.

Оптимально было бы сделать 4 точки входа.
Просто 4 хендлера, просто 4 кнопки.
И тогда «однопоточный отладчик» с «неразделяемым контекстом» никогда не был бы поставлен в ситуацию что «поправил в одном месте, а отвалилось в другом».

И не нужно его «учить» думать о том, что есть что-то ещё, кроме текущего состояния.
Он всё равно уже никогда не перестроится, т.к. он мыслит в один поток.

Более того, он вообще ни при чем.
Нужно просто в инструкции по разработке написать, что на Одно UI действие мы пишем Один метод, и никак по другому.

Пусть «разделяемый» код будет, но пусть он ломает только «отправку данных формы», «отправку прикреплённых файлов», «проверку возврата ID по Submit», но не всё вместе сразу.
Не заставляйте UI-щика мыслить в 2 потока, а тем более в 3, в 4, в 5.
Он не параллелится, никак.