Еще в сентябре 2016 года, когда команда Angular укусила пулю и выпустила Angular2 Final, я смог убедить своего клиента использовать Angular2 в качестве одного из самых крупных приложений.

Как некоторые из вас, возможно, помнят, Angular2 прошел необычно долгие этапы Alpha, Beta и RC. Казалось, что весь Angular2 был переписан с момента первого выпуска Alpha. Таким образом, во время финальной версии 2.0 вся сцена Angular была очень хаотичной. Практически не было никаких хороших руководств или ресурсов, которые работали бы с выпуском 2.0.0.Final.

У меня также не было фона AngularJS (1.x). Я только что доставил огромный SPA, используя стек Backbone-Marionette-Rivets.js. Оглядываясь назад, можно сказать, что отсутствие багажа от AngularJS - это хорошо!

В общем, мы совершили прыжок веры! Я поверил разработчикам Angular, сообществу и своей способности адаптироваться к новому фреймворку и прыгнул в долину без парашюта!

Я и члены моей основной команды - у нас было примерно 3-4 недели на создание первого шипа, и мы все бежали от одного за другим к другому; часто падал, но многому научился. Мой общий опыт разработки сценариев JavaScript также пригодился, когда мы увеличили команду с 4 человек до примерно 18 человек за пару месяцев.

Оглядываясь назад, через 6–8 месяцев разработки и выпуска продукта я вижу, что некоторые хорошие практики спасли положение. В этом посте они обобщены для всеобщего блага. Без лишних слов, вот некоторые из лучших практик, которые вы, возможно, захотите применить для создания качественного приложения Angular ...

Лучшие практики для абсолютных новичков

Почувствуйте себя комфортно с ES2015

Большая часть начальной кривой для angular - это как раз то, чтобы освоиться с ES2015. Поэтому убедитесь, что все разработчики в команде ПРОЧИТАЛИ и действительно ИСПЫТАЛИ варианты JavaScript ES2015 и ES2016. Здесь есть МНОГО, чему можно научиться, но он просто подготовит к встрече с учебными пособиями по внешнему миру, которые часто используют этот синтаксис. Например. синтаксис типа () => { } или […a, b,] не должен вас сбивать с толку. Или использование import, class, let, const и т. Д. Должно быть в первую очередь для ваших разработчиков.

Используйте Typescript и код Visual Studio (VSCode).

Большинство фрагментов кода для Angular, которые вы найдете в Интернете, находятся в Typescript .., который является расширенным набором ES2015. Я настоятельно рекомендую вам использовать это, чтобы фрагменты кода в Интернете имели смысл. Также в качестве компаньона используйте Visual Studio for Code в качестве IDE, TSLint в качестве линтера и плагин TSLint в VSCode, чтобы получить наилучший опыт статического анализа кода. Кроме того, с помощью TS вам не понадобится Babel. Бонус: также добавьте плагин Angular Language Service в VSCode. Это дает гораздо лучший опыт работы с Angular, особенно в шаблонах Angular.

Мастер экосистемы npm.

Наряду с ES2015, Angular также ориентирован на удобство работы с экосистемой Node и NPM. Любой серьезный пример будет использовать package.json (npm) и node для создания и запуска их примера. Практически КАЖДЫЙ угловой компонент даст вам инструкции о том, как его установить с помощью npm. Так что избавьтесь от проблем с Npm и VSCode для своих команд. Либо ваши разработчики используют эти инструменты, либо их нет в вашей команде! Шутки в сторону!

Рекомендации по разработке приложений Angular

Ешьте, спите, компоненты дыхания!

Angular - это все о компонентах. Сначала спроектируйте компоненты, прежде чем начинать код. Под дизайном я имею в виду -

  • Нарисуйте контуры визуального дизайна, чтобы четко обозначить, какая область экрана будет принадлежать какому компоненту. Делайте компоненты достаточно маленькими, чтобы их можно было повторно использовать во многих местах, но достаточно большими, чтобы их уменьшение не имело смысла. Чтобы привыкнуть к созданию этой логической группировки, потребуется немного времени, но вы, естественно, можете сделать это за 2–3 спринта. Я настаиваю на том, чтобы вся моя команда делала это для КАЖДОЙ истории в КАЖДОМ спринте.
  • Как только вы узнаете свой компонент, задокументируйте «входы» и «выходы». У меня есть небольшой контрольный список дизайна, который я заполняю каждым разработчиком в виде небольшой проектной документации для каждой истории. Если вы хотите адаптировать его в своем проекте, см. Раздел Дизайн повествования внизу под этим сообщением.

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

Используйте семенные проекты, чтобы взяться за дело!

Воспользуйтесь некоторыми стартовыми проектами начального уровня, потому что они отлично поработали бы над включением многих функций за вас. Я искренне рекомендую Стартовый веб-пакет AngularClass или Стартовый пакет BlackSonic ES6. Это поможет вам в кратчайшие сроки создать отличную основу для большого проекта.

Или… Используйте Angular-CLI

Другой вариант - использовать Angular-CLI. Angular CLI - действительно хороший вариант для тех, кому ES2015 + TypeScript + Angular кажется немного подавляющим. Он абстрагируется от вас, включая всю конфигурацию веб-пакета. Но эта абстракция также является недостатком, поскольку вы не можете возиться с этими абстрактными частями. К счастью, в Angular-CLI есть опция eject для извлечения большинства абстрактных вещей.

RIP SystemJS, привет Webpack!

С самого начала откажитесь от SystemJS и перейдите на Webpack. Webpack - гораздо более мощный и универсальный инструмент. Эффективно оптимизируйте пакеты webpack, чтобы гарантировать, что вы не объединяете одни и те же модули в несколько блоков. Есть анализаторы пакетов из webpack, которые блестяще сообщают вам об этом. Бонус: Обучающие слайды Webpack и Пошаговый код

Используйте AoT FTW!

Использование компиляции AoT (заблаговременно) - большой шаг к увеличению производительности во время выполнения. Это также уменьшает размер вашего пакета примерно на 30 КБ (в сжатом виде), что является БОЛЬШИМ улучшением. Angular 4.0+ обеспечивает улучшение пакетов приложений примерно на 30% благодаря тому, как он генерирует код AoT.

Что такое Observables от RxJS.

БОЛЬШАЯ работа над Angular заключается в понимании того, что такое Observable. Очень важно понять, как работают Observables, и освоиться с библиотекой RxJS, которая поможет вам стать Observable Ninja.

Ленивая загрузка маршрутов не для первой страницы

Ленивая загрузка всех ненужных маршрутов при переходе на 1-ю страницу. Webpack2 import() функция вам пригодится. Также ng-router-loader webpack поможет автоматизировать создание пакета для каждого лениво загруженного модуля автоматически.

Использование виджетов и библиотек

Рассмотрите возможность использования стандартной библиотеки виджетов, например PrimeNG или ValorSoft. Старайтесь избегать JQuery, так как его нельзя поколебать.

Отладка

Используйте ng.probe() в консоли Chrome для эффективной отладки / Или воспользуйтесь расширением Augury chrome, которое за вас обертывает ng.probe.

Оставайтесь в безопасности в темных уголках NgZone

NgZone и ZoneJS - одни из темных уголков Angular. Когда что-то не работает даже после того, как вы пробовали 100 разных вещей в течение многих дней, вы можете столкнуться с этими двумя противниками. Я называю их темными углами, потому что никакая ошибка никогда не скажет вам, что эту ошибку можно исправить, если вы возитесь с NgZone. Вы должны сами сопоставить свою ошибку и потенциальный конфликт NgZone 😧. Таким образом, NgZone довольно прост в использовании, но я даже не знал, что он существует почти 5 месяцев в моем проекте.

Другие преимущества за счет структурирования кода

  1. Общие модули. Попробуйте использовать общий модуль. Создайте модуль, который должен импортировать и экспортировать все часто используемые модули и провайдеры и импортировать их в другие модули.
  2. Глобальный или локальный CSS. Каждый раз при написании CSS старайтесь визуализировать, может ли этот тип элемента использоваться во многих местах, а затем напишите стиль на уровне приложения вместо компонента, это позволит избежать повторного использования. записать его снова в новом компоненте. Вы можете просто отменить любое небольшое изменение, которое требуется на уровне компонентов.
  3. Файл темы с SCSS - при использовании любого препроцессора CSS всегда определяйте файл, который имеет переменные, связанные только с цветом, размером шрифта и т. д. приложений, это поможет, когда вам нужно изменить тему. .
  4. Наследование машинописного текста для вашей помощи - попробуйте использовать наследование в машинописном тексте. Если у вас есть некоторые функции, связанные с просмотром, которые могут потребоваться на многих экранах, вы можете создать базовый компонент с общей функциональностью, а затем все остальные компоненты могут просто расширить его.
  5. Используйте службы - стремитесь к полному разделению между реализацией View и обращением в службу поддержки. В компоненте пользовательского интерфейса сохраните код, связанный только с представлением, и делегируйте службу для выполнения внутренних вызовов и для любой функциональной логики.

Общие рекомендации по повышению производительности веб-разработчиков

  1. Улучшение рабочего процесса разработки. Часто разработчик не думает о поиске ярлыков для повышения производительности труда. Это включает в себя обход локального входа в систему, кеширование внутренних вызовов, которые не требуются для вашей текущей работы, внесение небольших исправлений в код, позволяющих пропустить 10 экранов / щелчков, чтобы добраться до экрана, на котором они должны внести свои изменения. Следует потратить полчаса, чтобы настроить эти вещи, мгновенно достигнув своего текущего экрана и сэкономив время на каждом незначительном обновлении кода.
  2. Обязательная проверка человеческого кода. Мы обязали всех разработчиков предоставлять код как pull_request в Git. Архитектор рассмотрит и утвердит код перед слиянием. Это гарантирует, что каждая строка кода была проверена перед объединением. Это помогает выявлять ошибки и проблемы с качеством / производительностью, которые нельзя отловить с помощью ЛИНТЕР.

Повествование о дизайне:

Одно из лучших, что мы реализовали, было - проработка дизайна каждым разработчиком своей истории.

Я настаиваю, чтобы мои разработчики следовали этому повествованию.

Чтобы доставить историю xyz,

  1. Какие компоненты необходимо «создать» или «изменить».
  2. Как будет доступен компонент? Из навигатора? Маршрутизация? От какого-либо взаимодействия пользователя с другими компонентами?
  3. К какой папке будут принадлежать эти компоненты?
  4. Какие @input, @output будут предоставляться / исходить из этих компонентов.
  5. Каковы будут ваши требования к внутреннему вызову и в какой последовательности
  6. Любые проверки формы?
  7. Требуются какие-либо технические средства / библиотеки spl? Например. момент, датапикер, модальное окно и т. д.
  8. "Улучшение производительности"? Как вы быстро попадете на свою страницу - жесткое кодирование? Прокси?

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

Это сообщение адаптировано из моего исходного сообщения в моем блоге.

Вот и все, ребята. Спасибо за то, что терпеливо дочитали до конца! Если вам понравился сюжет - подпишитесь на меня в твиттере и нажмите на символ ❤️ под сюжетом.