Достаточно ли ручной оптимизации производительности?
В течение последнего года я сосредоточился на инструментах, чтобы фронтенд-разработчики могли сосредоточиться на создании богатого пользовательского опыта, который не изобилует недостатком знаний о наборе инструментов. Я начал разрабатывать mink, инструмент для создания шаблонов на основе строковых шаблонов для универсальных реагирующих приложений с webpack. Недостаток инструментов, дающих новичкам преимущество над морем информации и анти-шаблонов, вдохновил меня на обсуждение обширного, но простого инструмента CLI как для формирования шаблонов, так и для запуска довольно сложного сборщика webpack.
Проблема первоначального замешательства и трудностей пользователей не является единственной для веб-пакета. По моему опыту, большинство решений, которые разработчик делает в течение обычного рабочего дня, пропорциональны; Интеграция и повторная итерация.
Эти две категории довольно просты для понимания, но их очень трудно разделить. Как младший разработчик, я часто обнаруживал, что переписываю код на основе отзывов, что в основном определяется как повторная итерация. На самом деле, я потратил 2–3 месяца на webpack-cli, чтобы понять, как написать эффективный и обширный инструмент для формирования шаблонов.
Производительность именно такая.
Это смелое заявление, но никто не заботится о производительности на этапе интеграции, особенно новички. Вам придется повторить пару раз, возможно, даже закончить ваше приложение, прежде чем вы начнете избирательно относиться к тому, как пользователь взаимодействует с вашим приложением в отношении производительности. Это имеет значение, потому что никто не заканчивает свое приложение, если только над ним не работает много людей.
Google проделал невероятную работу по продвижению передового опыта в Интернете, что упрощает конструктивный подход к производительности. Маяк, на мой взгляд, является одним из самых ценных репозиториев на сегодняшний день, поскольку он дает разработчикам представление о том, насколько хорошо работает их приложение, и предложения по устранению проблем с производительностью или связанных с ними проблем. Как специалист по инструментам, я хотел бы сделать еще один шаг вперед, не только предложив, но и реализовав эти предложения,чтобы разработчику не пришлось тратить время на повторение слишком много времени.
Имеет смысл потратить время на реализацию основных функций и позволить цепочкам инструментов исправлять человеческие ошибки.
Инструменты на основе данных
Что касается инструментов, я в восторге от автоматизации работы, которая может облегчить не только новичкам, но и опытным разработчикам задачи. У нас есть CI, средства форматирования кода, инструменты CLI для формирования шаблонов и подсказки по производительности, но пока нет инструмента для упреждающей загрузки данных или автоматического исправления исходного кода на основе данных и подсказок по производительности.
Инструменты, основанные на данных, важны, потому что данные уже дают нам представление о том, насколько хорошо работает ваше приложение, либо по размеру вашего исходного кода, либо по моменту загрузки кода, по вашей первой осмысленной отрисовке, либо по тому, когда ваше приложение является интерактивным.
Есть несколько инструментов, которые уже дают нам эти метрики, такие как аудит маяков, мониторинг сетевых запросов и активности сервис-воркеров в chrome и вывод сборщиков модулей при компиляции.
Как это реально возможно
После получения данных из хром-протокола, сборщиков модулей, реагирования-трекинга или маяка у вас есть много информации для использования с машинным обучением. Сама оптимизация потенциально может быть выполнена во время выполнения с рабочими потоками или кластерами, наряду с редактированием исходного кода с помощью AST.
Для автоматического улучшения приложений на основе маячных аудитов не обязательно нужна оптимизация машинного обучения, некоторые изменения можно сделать просто с использованием AST.
Куда двигаться дальше и ключевые аспекты
Я начал развивать эту идею под доменом intraperf at github. Цель проекта — помочь разработчикам автоматически регулировать производительность своих приложений в зависимости от того, насколько хорошо они работают с маяком.
Вторая цель — загрузка данных и возможность предварительно загружать, реализовывать или настраивать способ отправки исходного кода клиенту на основе информации о времени до интерактивности, первой осмысленной отрисовке и т. п. Это показывает выигрыш, когда вы, например, предварительно загружаете таблицу стилей для следующей ссылки, которую собирается щелкнуть пользователь.
Хотите помочь сформировать это или спонсировать мою работу? Откройте DM в твиттере или свяжитесь со мной:[email protected] точка com!
