Контрольный список по написанию чистого кода в Angular

От автора: Angular быстро превратился в одну из самых популярных платформ для создания front-end кросс-платформенных веб-приложений. В то время как Angular — чрезвычайно мощный фреймворк с широким набором инструментов, его трудно освоить, особенно если это ваш первый JavaScript-фреймворк. В попытке уменьшить сложность и помочь другим разработчикам я решил составить контрольный список по написанию чистого кода, который включает мои личные рекомендации для того, чтобы написать чистый, готовый к производству код Angular.

Основа

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

Как сказал Мартин Голдинг: Всегда пишите свой код так, как будто парень, который будет поддерживать его, агрессивный психопат, который знает, где вы живете.

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

Руководство по стилю

Логичным местом для поиска лучших техник Angular является Руководство по стилю Angular. Это подробное руководство по синтаксису, конвенциям и структурированию приложений. В руководстве по стилю представлены предпочтительные конвенции и объяснено на примерах, почему вы должны их использовать.

Angular CLI

Angular CLI — отличный инструмент для создания и работы с приложениями Angular. Он повышает производительность разработки за счет того, что нам не нужно выполнять утомительную работу по созданию каждого файла вручную. Всего с помощью нескольких команд, вы можете:

Структура папок

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

Написание читаемого кода

Если вы хотите, чтобы рефакторинг был максимально эффективным, важно иметь читаемый код. Читаемый код легче понять, что позволяет легко его отлаживать, поддерживать и расширять.

Имена файлов

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

|-- my-feature.component.ts
или
|-- my-service.service.ts

Имена переменных и функций

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

function div(x, y)) { const val = x / y; return val;
}

И, надеюсь, писать вместо них такие:

function divide(divident, divisor) { const quotient = divident / divisor; return quotient;
}

Пишите небольшие чистые функции

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

Это позволяет избежать написания таких функций:

addOrUpdateData(data: Data, status: boolean) { if (status) { return this.http.post<Data>(url, data) .pipe(this.catchHttpErrors()); } return this.http.put<Data>(`${url}/${data.id}`, data) .pipe(this.catchHttpErrors()); }
}

И, надеюсь, писать вместо них такие:

addData(data: Data) { return this.http.post<Data>(url, data) .pipe(this.catchHttpErrors());
}
updateData(data: Data) { return this.http.put<Data>(`${url}/${data.id}`, data) .pipe(this.catchHttpErrors());
}

Удалите неиспользуемый код

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

Избегайте комментариев в коде

Хотя в определенных случаях комментарии нужны, на самом деле вы должны пытаться их избежать. Вы ведь не хотите, чтобы комментарии компенсировали вашу неспособность выразить сообщение в своем коде. Комментарии должны обновляться по мере обновления кода, но лучше потратить время на то, чтобы написать код, который объясняет сам себя. Неточные комментарии еще хуже, чем комментарии вообще, как говорит anonymous: Код никогда не врет, комментарии — да.

Это позволит избежать написания кода следующим образом:

// проверяем, полезна еда или нет
if (meal.calories < 1000 && meal.hasVegetables) { ...
}

И писать следующее:

if (meal.isHealthy()) { ...
}

Разделение задач

Angular базируется на разделении задач. Это шаблон дизайна, который упрощает обслуживание и расширение кода, а также его многоразовое использование. Он помогает инкапсулировать и ограничить логику компонентов, чтобы удовлетворить потребности шаблона, и не более того. Разделение задач — это основа написания чистого кода в Angular, и для этого используется следующий набор правил:

Используйте TypeScript

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

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

// .../burger.model.ts
export interface Burger { name: string; calories: number;
}
// .../show-burger.component.ts
this.burger: Burger;

Мы должны использовать объединения и пересечения типов. Это очень удобно при работе с данными API.

export interface Burger { ..., bestBefore: string | Date;
}

Мы всегда должны объявлять переменные и константы с определением типа, отличным от any. Строго типизированный код менее подвержен ошибкам.

Использование TSLint

Одним из способов улучшения вашего опыта в области разработки является использование TSLint. Это статический инструмент анализа кода, который мы используем в разработке программного обеспечения для проверки соответствия типа кода TypeScript правилам кодирования. Если вы сделаете что-то не так, будет выдана ошибка.

Prettier с TSLint

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

Lint с Husky

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

Загружайте модули отложено

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

Управление состоянием

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

Заключение

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

Пишите читаемый код. Сосредоточьтесь на написании кода, который легко понять.

Разделение задач. Инкапсулируйте и ограничьте логику внутри компонентов, служб и директив. Файл должен отвечать только за один функционал.

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

Используйте TSLint. TSLint проверяет, соответствует ли тип кода TypeScript правилам кодирования. В сочетании с Prettier и Husky это обеспечивает эффективный рабочий процесс.

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

Управление состоянием (при необходимости). Управление состоянием — отличный инструмент, но его следует использовать только для крупных сложных приложений, в которых компоненты имеют одинаковое состояние.

Автор: Mathis Garberg

Источник: https://itnext.io/

Редакция: Команда webformyself.