Как разработчик, на каких областях мы должны сосредоточиться для оптимизации производительности? Как мы можем измерить влияние? Прочтите этот пост, чтобы узнать о структуре

Объектно-ориентированный

Является ли JavaScript объектно-ориентированным? У него есть объекты, которые могут содержать данные и методы, которые воздействуют на эти данные. Объекты могут содержать другие объекты. У него нет классов, но есть конструкторы, которые делают то же, что и классы, в том числе действуют как контейнеры для переменных и методов класса. В нем нет наследования, ориентированного на классы, но есть наследование, ориентированное на прототипы.

Два основных способа создания объектных систем — это наследование (is-a) и агрегация. JavaScript делает и то, и другое, но его динамическая природа позволяет ему преуспеть в агрегировании.

Некоторые утверждают, что JavaScript на самом деле не является объектно-ориентированным, потому что он не обеспечивает сокрытия информации. То есть объекты не могут иметь приватные переменные и приватные методы: все члены общедоступны.

Но оказывается, что Javascript может иметь приватную переменную и приватные методы. Конечно, мало кто это понимает, потому что JavaScript — самый непонятый язык программирования в мире.

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

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

В этом посте используются примеры улучшения задержки, но его также можно применить и к улучшению пропускной способности.

Макро- и микрооптимизация

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

Эта структура классифицирует два типа оптимизации производительности: микро- и макрооптимизация:

Микрооптимизация

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

Из-за усилий наиболее распространенные изменения оптимизации попадают в эту категорию.

  • использование const или let

  • Высокая сплоченность, низкая связь.
  • Глобальный охват.

  • Применение «строгого использования».

  • Избегайте == вместо этого используйте ===

  • Именование переменных не обеспечивает абстракции.
  • Использование длинной функции
  • Использование ESLint.

Интересной особенностью этой категории является то, что время для решения проблемы обычно меньше времени, затрачиваемого на расследование. Расследование может занять много дней, а решение может быть таким же простым, как изменение линии, но последствия могут быть огромными!

Оптимизация макросов

Для меня это самая интересная категория. Обычно усилия и масштабы средние/высокие. Это требует много исследований, проверки и тестирования, и разработчик должен доказать, что его усилия того стоят.

Некоторые примеры:

  • Императивный, функциональный и лаконичный стиль кодирования с использованием инструментов

  • Принцип единой ответственности.
  • Не повторяйтесь.
    Каждое знание должно иметь единственный и недвусмысленный источник представления. Дублирование усилий, а не просто дублирование кода.
  • Продвигайте функциональные стили.
  • Просмотрите код и инструменты качества кода.

Лучшее время, проведенное разработчиками

Решая, на каких областях нам следует сосредоточиться, мы должны обратить внимание на три основных момента:

  • Воздействие. Существуют разные способы измерения воздействия в зависимости от платформы (например, количество затронутых пользователей, количество запросов / общее количество запросов).
  • Усилия. Сколько времени и ресурсов требуется.
  • Платформа стала более сложной. Насколько усложнилась платформа после применения оптимизации? Сложность макрооптимизации обычно высока.

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

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

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

Представьте, если бы у Airbnb была очень сложная система для расчета цен. Цена «пребывания» учитывает множество факторов, таких как спрос, предложение, местоположение, история цен, местоположение пользователя и многое другое. Это может работать хорошо, но делает систему зависимой от этого кеша. Любой новый фактор, добавленный к цене, должен аннулировать кеш, а любой пропущенный фактор приводит к потере денег!

Заключение

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

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

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