Участвуя в первом VueConf Toronto 2020, который состоялся сегодня, я слушал некоторые из основных мировых имен, связанных с Vue.js, в том числе Эвана Ю, создателя и руководителя работы Framework, занимающегося несколькими конкретными темами, общей Пункт между практически всеми лекциями привлек мое внимание: перформанс.

Поскольку у меня есть возможность работать над обзором кода некоторых членов моей команды, я обнаружил огромный недостаток в том, как применить эту фундаментальную тему UX на практике, а не как старшие эксперты с многолетним опытом и с максимальной степенью. в лучших практиках, а как обычные разработчики, которые хотят делать свою работу на отлично. Когда я смотрел на свою книжную полку, мое внимание привлекло конкретное название: «Простая кухня для чайников» (моя жена купила ее для меня несколько лет назад, и, возможно, вам должно быть интересно, почему это так. Это для другого поста). Тогда я подумал: почему бы и нет?

Почему для чайников?

Употребляя этот термин «для чайников», я делаю это не в уничижительном смысле, а с той точки зрения, что мы в технической области, особенно в логической математике, склонны предполагать, что каждый, кто нас слышит или читает, обязан понимания предмета на 100% и будет автоматически производить продукты, идеи, проекты и коды на уровне совершенства, которого раньше не было. Однако это не отражает реальности.

Итак, читая «Для чайников», думайте о том, что написано так, чтобы человек с минимальным опытом имел возможность понять и уметь применить, а если вы уже являетесь опытным в предмете, имейте в виду позу того, кто обладает смирением. хотеть учиться, даже если вы видите что-то очень простое и даже банальное. Это оно!

Об эффективности

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

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

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

Сценарий 1: каждый день я брал все тетради и книги, даже если использовал не более 30% материала.

Сценарий 2: каждый день я брал только те книги и блокноты, которые понадобятся в этот день.

Какой из двух сценариев кажется наиболее логичным? Сценарий 2 очевидно. Если мы рассмотрим только выполнение сценария 1, нас, безусловно, можно назвать не очень умными.

Так почему же, когда мы программируем, большинство из нас выбирает Сценарий 1 в качестве подхода к разработке?

Перейдем к кодам. ржу не могу

Итак, давайте перейдем к некоторым основным, простым советам, которые действительно полезны в нашем повседневном программировании.

1. Поймите, что вы делаете

Хотя они мне очень нравятся, это не шутка. В этой вселенной разработчиков, полной давления со всех сторон, коротких сроков, новых требований, снижения затрат и всех чудес, которые сопровождают нас в нашей повседневной работе, мы в конечном итоге нажимаем клавишу «исполнитель задачи», не нажимая клавишу «планирование». до. Результат? Коды, которые работают, но их невозможно поддерживать без какого-либо планирования роста и, что самое главное в этой статье, с ужасной производительностью.

2. Избегайте ненужных сложностей

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

Позвольте мне повторить это еще раз в верхнем регистре: KEEP IT SIMPLE!!

Насколько это возможно, когда это возможно. Код — это не соревнование интеллекта или статуя в честь эго, а решение потребности, которая, возможно, со временем потребует обслуживания и улучшения. И он должен работать как можно лучше. И это все.

3. Немного настоящего Vue: динамические и асинхронные компоненты

Лучшее обоснование этой темы представлено в официальной документации Vue.JS, которую я частично воспроизвожу ниже:

Давайте просто вспомним мой (фантастический) пример из моей школьной жизни: практически во всех наших решениях во всех сферах жизни, тех, которые принимаются осознанно, мы выберем сценарий 2. Другими словами, мы используем принцип On-demand: Я буду потреблять только «если» и «когда» мне это нужно. Так просто.

Итак, просто подумайте о наших кодах таким образом.

4. И еще немного о Vue: разделение компонентов

Разделение кода необходимо не только для реализации принципа On-demand в наших приложениях, но и дает много отличных мотивов для его использования. Итак, на вопрос «Когда разделить компонент Vue?» я описываю краткий список как краткий ответ. Есть бесчисленное множество других ответов, но помните: «Для чайников».

  • Если компонент очень обширный, с гигантским шаблоном, его сложно понять, с необходимостью множества «скроллинга вверх» и «скроллинга вниз», разбить его;
  • Если в компоненте много сложности, его сложно понять и поддерживать, разделите его;
  • Если в компоненте много логики, которую нельзя протестировать отдельно, разделите ее;
  • Этот код используется более чем в одном месте в вашем приложении? Если да, разделите его.

Это все люди! До встречи в следующей статье!