Никогда не производите для неизвестной трассы в программном обеспечении также? [Принцип Тойоты] [закрытый]
Ситуация для ES 6
Предстоящая спецификация языка ECMAScript, издание 6, включает регулярные выражения, поддерживающие Unicode. Поддержка должна быть активирована с помощью модификатора u в регулярном выражении. См. регулярные выражения, поддерживающие Unicode в ES6 .
До тех пор, пока ES 6 не будет закончена и широко распространена среди поставщиков браузеров, вы все равно по-своему. Обновление: теперь существует транспилер с именем regexpu , который преобразует регулярные выражения Unicode ES6 в эквивалентные ES5. Он может использоваться как часть процесса сборки. Попробуйте в Интернете.
Ситуация для ES 5 и ниже
Несмотря на то, что JavaScript работает в строках Unicode, он не реализует классы символов, совместимые с Unicode, и не имеет понятия классов символов POSIX или блоков / поддиапазонов Unicode.
- Проблемы с Unicode в регулярных выражениях JavaScript
- Проверьте свои ожидания здесь : Javascript RegExp Unicode Тестер класса символов ( Редактировать: исходная страница недоступна, в Интернет-архиве по-прежнему имеется копия .)
- Flagrant Badassery имеет статью о JavaScript, Regex и Unicode , которая проливает некоторый свет на этот вопрос.
- Также читайте Regex и Unicode здесь на SO. Вероятно, вам нужно создать свой собственный «класс символов пунктуации».
- Проверьте Регулярное выражение: сопоставьте Unicode Block Range builder, который позволяет вам создавать регулярное выражение JavaScript, которое соответствует символам которые попадают в любое количество указанных блоков Unicode. Я просто сделал это для поддиапазонов «Общая пунктуация» и «Дополнительная пунктуация», и результат был таким же простым и прямым, как и я ожидал:
[\u2000-\u206F\u2E00-\u2E7F] - Также существует XRegExp , проект, который поддерживает Unicode для JavaScript , предлагая альтернативный механизм регулярных выражений с расширенными возможностями.
- И, конечно же, требуемое чтение: mathiasbynens.be - JavaScript имеет проблему с Unicode :
4 ответа
Хорошая идея, где реальный. К сожалению, обычно непомерно трудно отслеживать всю историю состояния машины. Вы просто не можете отметить каждую структуру данных с тем, где Вы получили ее от, и все состояние того объекта. Вы смогли хранить просто внешние события и таким образом воспроизводить, куда все прибыло из.
Некоторые примеры:
Я действительно работал над проектом, где это было реально, и это помогло очень. Когда мы были рядом с поставкой и исчерпыванием ошибок для фиксации, у нас будет наша игровая игра в "нулевом режиме плееров", где компьютер неоднократно играл бы себя всю ночь напролет со всеми изменениями символов и локалей. Если бы это утверждало, то это отобразило бы случайный ключ, который начал матч. Когда мы приехали для работы утром, мы запишем ключ с нашего экрана (там, обычно был один), и запустите его снова использование тот ключ. Затем мы просто наблюдали бы его, пока утверждение не подошло, и разыщите его. Важная вещь состоит в том, что мы могли воссоздать все исходные исходные данные, которые привели к ошибке и повторно выполняли ее так много раз, как мы хотели, даже после перекомпилировал (в определенных рамках... количество выборок из генератора случайных чисел не могло быть изменено, хотя у нас был отдельный RNG для неигрового материала как визуальный fx). Это только работало, потому что каждый матч, начатый после горячей перезагрузки и, взял только очень небольшой объем данных, как введено.
Я услышал, что Bungie использовал похожий метод попытаться обнаружить плохую геометрию на их уровнях Halo. Они установили бы dev наборы, работающие в течение ночи в специальном режиме, куда неразрушимый главный герой переместится и перейдет случайным образом. Утром они посмотрели бы и видели бы, застрял ли он в геометрии в некотором местоположении, куда он не мог выйти. Возможно, были включенные гранаты, также.
На другом проекте мы на самом деле зарегистрировали все взаимодействие с пользователем с меткой времени, таким образом, мы могли воспроизвести его. Это работает отлично, если Вы можете, но у большинства людей есть взаимодействия с изменяющимся DB, все состояние которого не могло бы быть сохранено так легко.
Это - хороший подход. Но знайте, что Вы не должны переусердствовать вход. Иначе Вы не могли найти интересную информацию во всем шуме, и он уменьшает общую производительность (например, создание анонимного объекта, в зависимости от языка).
Это менее жизненно важно с программным обеспечением. Если что-то идет не так, как надо в программном обеспечении, можно обычно воспроизводить отказ и анализировать его в неволе. Даже если это только происходит в 1 раз в 1 000, можно часто включать весь вход и выполнять его 1000 раз (простой тест замачивания).
Это является намного более дорогим и трудоемким на производственной линии, на грани того, чтобы быть невозможным.
При наличии как можно большей информации, доступной, первый раз, когда это идет не так, как надо, не является никакой плохой вещью, но это не столь важно для меня, как это к Тойоте.
Создание сообщений об ошибках с полным отслеживанием стека является обычно плохой практикой безопасности.
С другой стороны, и больше в соответствии с намерением Тойоты, каждый разработанный модуль должен быть прослежен до исходного программиста (программистов) - и они должны считаться ответственные за дрянную работу, исправления ошибок, уязвимости системы обеспечения безопасности, и т.д. Не в дисциплинарных целях, но и обслуживание и образование при необходимости. И возможно для премий, в противоположной ситуации... ;-)