Лучший Javascript прост, чист и не испорчен грязными так называемыми функциями, такими как классы, this, наследование и декораторы.

TLDR;

Javascript — невероятно надежный язык программирования с разнообразным набором языковых функций. Большинство из них полный мусор. За последние 10 лет они только мешали инженерам писать качественный код. Я использую только объекты и функции, и это намного лучше.

Проблема с Javascript

Javascript — невероятный язык. Самое невероятное в javascript то, как далеко он продвинулся с момента его изобретения. Большинство языков следуют естественному порядку создания, устаревания и смерти. Когда у слабых языков программирования нет того, что нужно, их вытесняют новые языки, и в конце концов они вымирают.

Javascript является исключением из правил.

Хотя Javascript был слаб, будучи технологией, управляющей Интернетом, ему не дали умереть. Вместо этого новые функции были приклеены, приклеены и привязаны к внешней стороне веревкой и проволокой.

Javascript, который мы знаем, ненавидим и любим сегодня, представляет собой лачугу функций, сложенных поверх основного движка, который с самого начала вызывал сомнения.

Проблема с сообществом

Настоящая проблема не в Javascript, а в том, как инженеров учат думать о Javascript. Их учат, что каждая языковая функция особенная, полезная и имеет подходящее время и место для реализации, поэтому вы должны изучить каждую функцию и использовать их все, когда это возможно.

Неверно.

Возьмем в качестве примера прототипное наследование. Это странно, это уродливо, и этому нет места в современном языке программирования. То, что он существует в языке, не означает, что мы должны его принять.

Решение

Я говорю нет всем этим грязным функциям. я просто отказываюсь. В частности, я не использую классы, ключевое слово this, декораторы и не зависим от какой-либо формы наследования. Весь мой код Javascript — это объекты и функции.

я не провожу занятия

Класс — это просто объект, который был инициализирован состоянием. Нет, правда, это так!

Следующие два фрагмента идентичны по духу. Единственная разница в том, что синтаксическому анализатору класса требуется ключевое слово new, а синтаксическому анализатору const — нет.

Так зачем мне использовать класс? Если вы думаете о наследовании, рассмотрите следующий фрагмент.

Все, что вы можете сделать с классом, я могу сделать с объектом и функциями — и это не очень сложно.

я не занимаюсь декораторами

Мне действительно нравится идея декораторов. К сожалению, комитет Javascript развлекался с запрещенным напитком и в тот вечер, когда они выбрали формат, оказался пьяным до нитки.

Проще говоря, декоратор — это функция, которая оборачивает другую функцию, выполняя необязательную обработку до и/или после того, как базовая функция выполняет свою обработку.

Для этого Javascript создал формат, который вам нужно изучить. Я предпочитаю подход Python. В Python декоратор — это функция, которая принимает функцию в качестве аргумента и возвращает функцию.

Вот как я воплощаю это в жизнь в Javascript:

В этом примере мы украсили функцию speak с помощью наших декораторов uppercase и emphasize, чтобы создать функцию scream. Теперь, на самом деле, мы не украшаем, мы сочиняем. Это не баг, это фича. Неважно, мы преследуем одну и ту же основную цель украшения.

Но почему?

Есть несколько причин, по которым я ограничиваюсь только объектами и функциями. Говоря в общих чертах, это помогает сделать мой код простым, читабельным, быстрым и просто лучше в целом. Мне нравится больше.

Классы склонны накапливать состояние

Это не жесткое правило, а тенденция, которую я наблюдал на протяжении всей своей карьеры. Лично я настоятельно предпочитаю детерминированный код и — когда это возможно — чистые функции. Если вы дисциплинированы, вы можете достичь этих целей с помощью занятий. Однако это никогда не кажется длительным. Даже если я дисциплинирован, вряд ли следующие 10 инженеров разделят мое мнение.

Со временем классы имеют тенденцию хранить больше атрибутов и добавлять больше функций, зависящих от этих атрибутов. Когда классы действительно выходят из-под контроля, правильное значение этих атрибутов в любой момент времени становится решающим для правильного функционирования методов. он же кошмар государства.

Этот тип сложности с отслеживанием состояния — это то, что я хочу вынести на поверхность. Выведение состояния на поверхность — это арендатор функционального программирования. Код с отслеживанием состояния и код, который вызывает побочные эффекты, должен быть доведен до самого высокого уровня нашего программного обеспечения, а все, что ниже этого верхнего уровня, должно быть строго детерминированным и, по возможности, чистым.

Используя объекты, я могу писать детерминированные функции в области модуля и вызывать их из своего экземпляра объекта, передавая только то, что необходимо. Это вынуждает вручную передавать состояние функциям и, как мы надеемся, заставляет инженеров дважды подумать о том, что они добавляют.

Вы могли бы сделать это с помощью классов, но есть более чем тридцать лет старшинства, чтобы НЕ делать это таким образом. Когда другие копаются в вашем коде и находят класс, они, не задумываясь, увеличивают состояние.

Классы сложнее тестировать

Этот пункт тесно связан с предыдущим. Чем больше состояний у класса, тем сложнее его протестировать. Когда мы удаляем из класса возможность сохранения состояния, делая его неизменяемым объектом, а затем помещаем сложные функции в область модуля, где их можно тестировать изолированно, мы значительно снижаем сложность тестирования.

Я большой поклонник покрытия кода модульными тестами. Из-за некоторого болезненного опыта я могу сказать вам, что покрытие кода в классах с отслеживанием состояния НИЧЕГО не означает . С другой стороны, если вместо этого мои классы представляют собой неизменяемые экземпляры объектов с детерминированными функциями в области модуля, и я покрыл 100% своих детерминированных функций модульными тестами, я могу быть уверен, что логика действительно покрыта.

Наш класс мотоциклов немного абсурден — все знают, что красные мотоциклы самые быстрые, — но он иллюстрирует реальный сценарий, в котором государство получает результат.

При написании тестов может быть неочевидно, что на скорость влияет что-то, казалось бы, не имеющее отношения к делу, например, цвет объекта.

В версии с функцией и объектом написание тестов для функции getSpeed кричало бы разработчику, что цвет — обязательный аргумент — имеет некоторое влияние на результат.

Объекты снижают когнитивную нагрузку

Как человек, чтобы понять метод класса, я должен загрузить все состояние в свою голову, а затем рассмотреть поведение во время выполнения с учетом состояния, от которого оно зависит. Как разработчик, это обычно означает, что я сканирую метод класса на наличие таких ключевых слов, как this или self, чтобы определить зависимое состояние.

Детерминированные функции определяют свои зависимости через свои аргументы. Как тенденция, это облегчает их понимание и осмысление.

Декораторы навсегда привязывают декоратор к функции

Когда я использую функцию @decorator в Javascript, я привязываю функцию декоратора к декорированной функции навсегда. Это полностью нарушает возможность изолированного модульного тестирования моей функции.

Давайте посмотрим на версию примера с декоратором Speak/Scream. Этот был преобразован для использования функции the@decoartor.

Я не могу протестировать метод speak без выполнения декораторов. Как человек, который ценит качество модульных тестов, это не начало.

Декораторам требуется знание непонятного формата

Пожалуйста, посмотрите на следующий фрагмент, наш декоратор выделения, и скажите мне: что такое цель? что такое имя? а что такое дескриптор?

Определение декоратора простое и красивое — функция, которая принимает функцию и возвращает функцию. Javascript испортил действительно элегантный шаблон запутанным форматом.

Это нужно декораторам

Как видно из обоих наших декораторов, они требуют использования apply и this для правильной настройки контекста декорированного метода.

Если вы на минутку откроете для меня свои мысли, я бы хотел поделиться своим мнением о this… это было ошибкой 20 лет назад и сегодня. Боже мой, пожалуйста, Javascript, пожалуйста, перестаньте создавать языковые функции вокруг него, и инженеры, пожалуйста, боже мой, пожалуйста, прекратите писать вокруг него код.

Кроме того, если я беру у вас интервью и прошу вас объяснить ключевое слово this в javascript, правильный ответ будет «Я не уверен, я не использую этот устаревший кусок хлама, он только служит для ненужного усложнения». мой код».

Меня зовут Рэй, я инженер-основатель Vessel, я создал Radash, шаблон проектирования ACP и библиотеку Exobase. Мне не нужны ваши деньги, я просто хочу работать над кодовыми базами, которые не отстой, поэтому, пожалуйста, следите, комментируйте, взаимодействуйте и давайте вместе улучшать практики.