Большие технологии прислушиваются к шуму разработчиков в своем стремлении быть лучшими. К сожалению, это начинает нарушать целостность некоторых языков программирования.
Чтобы лучше понять это, рассмотрим недавний выпуск Chrome с небольшим, но важным изменением в их DevTools. Разработчики могут повторно объявить переменную JavaScript const в консоли. Найдите минутку, чтобы подумать об определении константной переменной в том виде, как ее определяет MDN:
Константы имеют блочную область действия, как и переменные, объявленные с использованием ключевого слова
let. Значение константы нельзя изменить путем переназначения и нельзя повторно объявить.
Почему Chrome намеренно бросает вызов определению константы таким образом? Вот вариант использования, указанный в Рецензии DevTools:
Пользователи хотят иметь возможность копировать и вставлять код в консоль DevTools, чтобы посмотреть, как он работает, или поэкспериментировать, внести небольшие изменения в код и повторить процесс. Если код, который они копируют и вставляют, имеет константную переменную верхнего уровня, то в настоящее время он выдает синтаксическую ошибку. Это расстраивает, так как пользователям нужно обновить страницу, открыть новую вкладку или удалить ключевые слова const, чтобы обойти это.
Аргумент сводится к тому, что «пользователи разочарованы».
Это действительно проблема?
да.
В этом примере Chrome DevTools обслуживает сообщество, которое хочет копировать/вставлять. Разработчики копируют/вставляют код в консоль так же, как копируют/вставляют код в свои приложения. В этом случае разработчики будут разочарованы, когда будут копировать/вставлять из DevTools в свой собственный код, где повторное объявление констант не разрешено.
Культура копирования/вставки может быть хорошим способом понять новый код, но она не способствует критическому мышлению. Слишком много разработчиков копируют/вставляют код из StackOverflow, Github и других источников, не понимая, что они делают. Как занятому разработчику может показаться приятным не думать о копировании/вставке, но это одна из причин, по которой в мире существует нехватка квалифицированных разработчиков (о которой я писал раньше ). Короче говоря, существует нехватка опытных и творческих технических специалистов — миру не хватает создателей.
Хотя изменение Chrome DevTools, кажется, сделано с добрыми намерениями, на самом деле оно просто добавляет еще одну запутанную причуду к опыту разработчиков.
Кувалда
Разработчикам всегда нужен один инструмент для каждой работы. Человеку свойственно хотеть, чтобы все было в одном месте и чтобы все было «легко». Однако «все-в-одном» и «легкий» не очень хорошо масштабируются.
Chrome DevTools пытается насытить всех, но какой ценой? Является ли продвижение «в основном совместимой» среды JavaScript действительно хорошей идеей?
Есть много других инструментов для экспериментов с JavaScript.
Альтернативные подходы
В случае, если Google разрешает повторное объявление const, возможно, было бы лучше предоставить разработчикам образовательные ресурсы. Основным вариантом использования этой «функции» является копирование/вставка кода из учебных пособий и других образовательных онлайн-источников. Возможно, преподаватели должны взять на себя ответственность за предоставление работающего кода копирования/вставки. Возможно, им следует объяснить своим ученикам разницу между const, let и var. Другими словами, педагогов не следует вознаграждать за распространение плохой практики.
В случае с Google несколько настроек UX могут иметь большое значение.
Вот как сейчас выглядит DevTools:
Возможно, повторное объявление const может отображать предупреждение типа «предупреждение: повторное объявление const не является операцией, совместимой со стандартами», вместо того, чтобы предоставлять обратную связь (что говорит об успехе).
Скользкий склон
Для производителей технических инструментов важно прислушиваться к своим пользователям, но производители инструментов также несут ответственность за защиту целостности технологий, которые они внедряют.
Разработчики инструментов, особенно крупные, должны учитывать последствия нарушения технических стандартов (независимо от того, насколько они малы). Когда лидеры противоречат стандартам (особенно тем, которые они помогают создавать), это создает путаницу. Если стандарты не соблюдаются, в них вообще нет смысла.
Трудно сбалансировать требования пользователей с технической целостностью, особенно когда требования противоречат фундаментальной природе конкретной технологии. С каждой функцией производители инструментов должны спросить себя, не способствуют ли они созданию скользкой дорожки.
