Потому что алгоритм идет по каждому символу в строке по порядку, применяя к нему все возможные вычисления. А работа со строкой будет оптимизирована. Я попытался найти алгоритм поиска по строке, но не получилось (возможно, кто-то может подсказать из читателей). Насколько я знаю, есть только некоторые требования к подобным алгоритмам, а как его реализовать - это решают разработчики JS движка.
Я прочитал эту статью. Там в комментах была дискуссия на тему стоит ли выучить регулярки вместо использования билдеров. У меня нет однозначного мнения на этот счет, но нам проще было использовать регулярки. Я просто показал как сделать так, чтобы их было просто и удобно поддерживать.
Я в своей работе использовал парсинг HTML с помощью регулярных выражений, но мы парсили HTML, который сами и генерировали. Наверное, здесь имеется ввиду, что нельзя так парсить пользовательский ввод.
Думаю, что это справедливо для джунов. В статье я как раз и написал, что если выполнять только задачи в "своей сфере", то появляются "черные ящики" и перекладывание ответственности. Да, вероятно я не смогу развернуть кластер Kubernetes, но настроить деплой через Helm в TeamCity я смогу. Или я не смогу написать низкоуровневый алгоритм поиска для базы данных вроде Clickhouse, но полноценно пользоваться, написав оптимальный SQL я тоже смогу.
Наверное, это подход из области начинающего фрилансера, который еще не успел нормально разобраться хотя бы в одной технологии. У нас же в команде было наоборот — каждый был специалистом в своей области, но расширил навыки за счет других областей.
Это не так. Наоборот, у нас как раз существует четкое разделение обязанностей. Скорее это команда экспериментальная. На данный момент мы исследуем подход T-Shape, когда узкий специалист разбирается и в смежных областях. Плюс, в такой команде любой разработчик может заменить любого другого.
Мне кажется, что это справедливо по отношению к любой компании. Рано или поздно разработчик сталкивается с неизвестной технологией на работе. Дальше уже нужно выполнить задачу как можно быстрее и наиболее оптимальным способом. Так что здесь можно либо изучать на работе, либо если есть возможность, то и в свободное время.
Согласен, при сложных кейсах реально без них не обойтись.
Потому что алгоритм идет по каждому символу в строке по порядку, применяя к нему все возможные вычисления. А работа со строкой будет оптимизирована. Я попытался найти алгоритм поиска по строке, но не получилось (возможно, кто-то может подсказать из читателей). Насколько я знаю, есть только некоторые требования к подобным алгоритмам, а как его реализовать - это решают разработчики JS движка.
Не готов вступать в дискуссию, так как сам не ярый любитель регулярок.
Возможно, но в одном случае выкидывает, а во втором - нет? Предлагаю просто оставить это как результат моего эксперимента.
Да, согласен. Видимо, мы просто не сталкивались с такими проблемами во время работы, поэтому RegEx нам подходил.
Здесь возразить нечего, соглашусь.
Да, я согласен, что в сложных случаях нужно использовать регулярки. Об этом я написал в пункте "Без RegEx не обойтись".
Я прочитал эту статью. Там в комментах была дискуссия на тему стоит ли выучить регулярки вместо использования билдеров. У меня нет однозначного мнения на этот счет, но нам проще было использовать регулярки. Я просто показал как сделать так, чтобы их было просто и удобно поддерживать.
Я запускал на NodeJS один миллион раз. Вероятно, здесь V8 постарался и оптимизировал алгоритм.
Я в своей работе использовал парсинг HTML с помощью регулярных выражений, но мы парсили HTML, который сами и генерировали. Наверное, здесь имеется ввиду, что нельзя так парсить пользовательский ввод.
Круто, спасибо). Буду использовать.
Согласен. Спасибо за уточнение)
В любой ситуации, когда можно обойтись без регулярных выражений. Это же был просто пример.
Думаю, что это справедливо для джунов. В статье я как раз и написал, что если выполнять только задачи в "своей сфере", то появляются "черные ящики" и перекладывание ответственности. Да, вероятно я не смогу развернуть кластер Kubernetes, но настроить деплой через Helm в TeamCity я смогу. Или я не смогу написать низкоуровневый алгоритм поиска для базы данных вроде Clickhouse, но полноценно пользоваться, написав оптимальный SQL я тоже смогу.
Мы не позиционировали это как эксперимент) Я написал, что это команда скорее экспериментальная.
С этим я полностью согласен)
Опять же, это был пример в вакууме). В зависимости от задачи, количества данных, нагрузки и прочего подход к решению задачи должен изменяться.
Наверное, это подход из области начинающего фрилансера, который еще не успел нормально разобраться хотя бы в одной технологии. У нас же в команде было наоборот — каждый был специалистом в своей области, но расширил навыки за счет других областей.
Это не так. Наоборот, у нас как раз существует четкое разделение обязанностей. Скорее это команда экспериментальная. На данный момент мы исследуем подход T-Shape, когда узкий специалист разбирается и в смежных областях. Плюс, в такой команде любой разработчик может заменить любого другого.
Мне кажется, что это справедливо по отношению к любой компании. Рано или поздно разработчик сталкивается с неизвестной технологией на работе. Дальше уже нужно выполнить задачу как можно быстрее и наиболее оптимальным способом. Так что здесь можно либо изучать на работе, либо если есть возможность, то и в свободное время.