Часто требуется вносить правки в существующий код. И порой это даётся тяжело. Причём, не только при работе с кодом коллег, но и со своим собственным кодом.
В этой статье я собрал некоторые советы, которые помогут писать более понятный код.
1 Используйте TypeScript
TypeScript сильно упростит сопровождение проекта, и чем он крупнее, тем более явная польза от статической типизации.
2 Определяйте пропсы компонента
Этот совет для тех, кто пока не использует TypeScript.
prop-types используется для проверки типов в режиме реального времени. Если в компонент передаются пропсы неверного типа (например, вместо числа передаётся строка) или не передаются обязательные пропсы, в консоли браузера появится предупреждение.
Когда у компонента указаны все используемые пропсы, стороннему разработчику проще понять, как его использовать.
3 Настройте линтер
Линтер позволяет избежать типовых ошибок и помогает поддерживать единый стиль программирования в рамках одного проекта.
4 Разделяйте логику и представление
Я обычно разделяю логику и представление. Обычно есть один компонент — логика — который общается с хранилищем, инициирует запросы и так далее. А второй — представление — только отображает данные и реагирует на действия пользователя, отправляя события выше, в логику.
Это обязательно пригодится при плавном редизайне или для проведения A/B-тестов.
5 Первый вариант кода не всегда лучший
Большинство разработчиков знают, что первая версия кода или программы не всегда сделана на отлично. После публикации первого варианта рекомендуется проанализировать его и выявить недостатки.
Если требуется сохранить обратную совместимость, лучше покрыть код тестами, чтобы сэкономить время на ручном тестировании и поисках багов.
6 Делите большие компоненты на мелкие
Разделение больших функций и компонентов на более мелкие позволяет сделать их более пригодными для повторного использования и понимания. Ревью и тестирование одного большого файла всегда сложнее, чем нескольких небольших.
7 Именование файлов
Имя файла, неожиданно, должно соответствовать его предназначению.
Например, Article — хорошее название, но слишком обобщённое, ведь это может быть как телом статьи, так и элементом в списке статей.
Также плохо называть компоненты в зависимости от их расположения на странице: ArticleLeft, ArticleTop т. д.
Лучше всего в таком случае добавлять в название компонента его предназначение: ArticleItem, ArticleBody и т. д,
8 Тестируйте код
Автоматические тесты позволяют убедиться, что код работает. Чем больше различных сценариев будет протестировано, тем надёжнее код.
После разработки кода может показаться, что он работает, но важно проверять ещё и крайние случаи. И если код будет меняться, то тесты помогут выявить ошибки, которые были допущены в ходе переписывания кода.
Также протестированный код вызывает большее доверие со стороны других разработчиков, а это важно при разработке открытых проектов.
Для unit-тестов для React-компонентов я использую Jest, для интеграционных тестов — Nightwatch.
Также использую Storybook для быстрой проверки того, как компоненты работают при различных входных данных.
