Простите, но это какая-то чушь. Простой тест реакции «тыкни когда загорится» включает в себя как раз время от одного события (загорелось) до действия (тыкни). Типичное время в таком тесте: 150-250 мс. Попробуйте сами, и увидите, что даже у Вас это время ~200 мс, но уж никак не «у лучших спортсменов не меньше 300».
Ну, грубо первый вариант примерно об этом же. Мне тоже кажется это самым нормальным: сделать отдельные таблицы и общий интерфейс для соответствующих объектов. Но, как было подмечено, изменение родительского класса (интерфейса) затронет всех потомков. Это может вылиться во множество изменений.
Я понимаю, если говнокод явление временное и никому снаружи невидное, но если предполагается код ревью или командная работа, то говнокод — это очень плохо. Вы отнимаете уже не только свое время, но и время коллег.
Да, но когда видишь функции на сотни строк, многократное дублирование, вложенность во вложенности во вложенности, тройные циклы, непонятные переменные и функции…
Я к тому, что довольно много людей прикрывается спешкой и сроками, пишут дикий ужас, а потом долго ищут ошибки и приводят все в порядок. Я за то, чтобы локально код, все-таки, сразу был простым и понятным. Тогда и с модулями, архитектурой и прочей радостью потом проще.
К сожалению, у меня не получилось найти дубликаты с помощью этого плагина (в том числе и с использованием сервера). На stackoverflow говорят, что он эту возможность не поддерживает. Пожалуйста, поправьте, если это не так.
В целом я с Вами согласен, но все-таки я бы не был так радикален.
Например, если говорить про падение производительности, то оно скорее связано не с вызовом новых функций (это действительно хорошо оптимизируется), а с созданием новых объектов или излишней обобщенностью. Но, действительно, преждевременная оптимизация — корень всех бед, и для большинства проектов — это не проблема.
С зависимостями совсем все неоднозначно. Там всё становится плохо, если дубликаты расположены в разных модулях. В статье была ссылка на неплохое рассуждение на эту тему. Если вкратце, то мысль такая — стоит ли создавать новую зависимость (и поддерживать ее) ради нескольких строк кода? Хотя я скорее бы предпочел явную зависимость, чем неявную в виде клонов. Но этот вопрос довольно много обсуждается.
Про ошибки я не совсем понял. Если речь о примере 3, то чушь собачья — это то, что такие ошибки существуют? Данный пример ведь из реального довольно популярного проекта Spring, там и тесты есть. Конечно, исправлять ошибки во всех дубликатах — это чревато, об этом и пример.
В любом случае, спасибо что внимательно прочитали статью.
Может я чего-то не нашел, но на github очень маленькая выборка. Я бы рекомендовал тот же MNIST (выборку с рукописными цифрами) — данные подготовлены, их много, текущая точность для разных моделей известна.
Я к тому, что довольно много людей прикрывается спешкой и сроками, пишут дикий ужас, а потом долго ищут ошибки и приводят все в порядок. Я за то, чтобы локально код, все-таки, сразу был простым и понятным. Тогда и с модулями, архитектурой и прочей радостью потом проще.
Например, если говорить про падение производительности, то оно скорее связано не с вызовом новых функций (это действительно хорошо оптимизируется), а с созданием новых объектов или излишней обобщенностью. Но, действительно, преждевременная оптимизация — корень всех бед, и для большинства проектов — это не проблема.
С зависимостями совсем все неоднозначно. Там всё становится плохо, если дубликаты расположены в разных модулях. В статье была ссылка на неплохое рассуждение на эту тему. Если вкратце, то мысль такая — стоит ли создавать новую зависимость (и поддерживать ее) ради нескольких строк кода? Хотя я скорее бы предпочел явную зависимость, чем неявную в виде клонов. Но этот вопрос довольно много обсуждается.
Про ошибки я не совсем понял. Если речь о примере 3, то чушь собачья — это то, что такие ошибки существуют? Данный пример ведь из реального довольно популярного проекта Spring, там и тесты есть. Конечно, исправлять ошибки во всех дубликатах — это чревато, об этом и пример.
В любом случае, спасибо что внимательно прочитали статью.