«Профессионала от новичка отличает качество разработки»: 7 принципов чистого и читаемого кода на JavaScript

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

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

Я собрала лучшие, на мой взгляд, рекомендации по написанию хорошего кода на JavaScript. В первой части материала на Highload я расскажу о принципах разработки (KISS, DRY, YAGNI, BDUF, SOLID, APO и бритва Оккама), а также о том, как правильно называть переменные. Начнем!

Принципы разработки: как не усложнять себе жизнь

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

YAGNI: You Aren’t Gonna Need It / Вам это не понадобится

В совсем вольном переводе это может звучать и так: «Нужно делать, что нужно, а что не нужно — не делать». Иными словами: возможности, которые не описаны в требованиях к системе, вам реализовывать не надо.

Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится когда-нибудь потом.

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

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

DRY: Don’t Repeat Yourself / Не повторяйтесь

Дублирование кода — пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах. Если же вы измените код в одном месте, его нужно будет поменять и в другом.

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

KISS: Keep it short and simple / Делайте проще

Это принцип проектирования и программирования, при котором простота системы — это основная цель и ценность вашей работы.

Keep it short and simple — отличный лозунг для разработки хорошо сопровождаемого ПО. Зачастую лишние абстракции, функции и библиотеки не полезны для пользователей и только усложняют поддержание проекта. Не додумывайте еще чего-то сложного. Иногда самое разумное решение оказывается и самым простым. 

BDUF: Big Design Up Front / Глобальное проектирование прежде всего

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

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

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

Принципы SOLID

SOLID — это аббревиатура, которая называет пять основных принципов проектирования в ООП, предложенных Робертом Мартином, автором бестселлера «Чистый код», более известным в IT как Дядюшка Боб.

• Single responsibility — принцип единственной ответственности
• Open-closed — принцип открытости / закрытости
• Liskov substitution — принцип подстановки Барбары Лисков
• Interface segregation — принцип разделения интерфейса
• Dependency inversion — принцип инверсии зависимостей

Предлагаю детальнее ознакомиться с каждым из них.

Single-responsibility principle

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

Читайте также: Принцип SOLID, который все понимают неправильно: что такое единая ответственность в разработке

Open–closed principle

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

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

Запомните: если вы меняете сущность, чтобы сделать ее расширяемой, вы впервые нарушили этот принцип.

Liskov substitution principle

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

Допустим, если у нас есть класс A (не виртуальный, а реально используемый в коде) и унаследованный от него класс B, то если мы заменим все использования класса A на B, ничего не должно измениться в работе программы. Ведь класс B всего лишь расширяет функционал класса A.

Если проверка работает, поздравляю: ваша программа соответствует принципу подстановки Лисков!

Interface segregation principle

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

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

Dependency inversion principle

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

Простой пример — использование дат в JavaScript. Вы можете написать для них свой слой абстракции. Тогда, если у вас сменится источник получения дат, вам нужно будет внести изменения в одном месте, а не в тысяче. Иногда добавление этого уровня абстракции требует усилий, но в конечном итоге они окупаются.

Avoid Premature Optimization / Избегайте преждевременной оптимизации

Эта практика побуждает разработчиков оптимизировать код до того, как необходимость этой оптимизации будет доказана. Думаю, если вы следуете KISS или YAGNI, вы не попадетесь на этот крючок.

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

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

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

Я советую вначале использовать не самые оптимальные решения, а более простые.

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

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

Бритва Оккама

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

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

Как правильно называть переменные

Неудачное именование переменных может существенно повысить затраты на разработку или поддержку проекта. Ведь программист будет тратить дополнительное время на чтение кода. При плохом нейминге затрудняется процесс интерпретации — «что есть что в коде». Поэтому называйте переменные так, чтобы даже спустя длительное время вы и ваша команда понимали, что в нем описано:

• Не называйте переменные одной буквой, сокращениями, транслитом и просто как придет в голову. Имя переменной должно кратко описывать ее предназначение. Используйте легко читаемые имена, такие как userName или shoppingCart.
• Избегайте аббревиатур или коротких имен по типу a, b, c. Исключением могут быть общепринятые аббревиатуры. Например, счетчики циклов принято называть переменными i, j и k. Кнопку button можно сократить до btn.
• Делайте имена описательными и лаконичными. Примеры плохих имен — data и value. Эти названия ни о чем не говорят. Их можно использовать только в том случае, если из контекста кода очевидно, какие данные хранит переменная.
• Никакого транслита — только английский.
• Договоритесь с вашей командой об используемых терминах. Если посетитель сайта называется User, тогда мы должны называть связанные с ним переменные currentUser или newUser, а не, к примеру, currentVisitor или newManInTown.

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

Вот так принято называть переменные в зависимости от содержимого:

• Значение — существительное: cat, dog.
• Массив — существительное в множественном числе: cats, dogs.
• Функция — глагол: download, update.
• Класс — существительное с заглавной буквой: Cat, Dog. Классы именуются в CamelCase.
• Константа — имя пишется заглавными буквами в стиле snake_case: MAXIMUM_FOOD, LIMIT_X. Константы с именами, записанными заглавными буквами, используются только как псевдонимы для «жестко закодированных» значений.
• Обработчик — имя описывает событие, по которому он вызывается. Как правило, содержит префикс on или постфикс Handler: onButtonClick, formSendHandler. Переменные именуются в lower camelCase («верблюжья» нотация).

Следуйте этим правилам, и ваш код станет намного понятнее!

Во второй части материала на Highload я расскажу о стилизации JS-кода, таких инструментах как ESLint, Prettier, Code Spell Checker и SonarQube, а также о выстраивании архитектуры проекта. Stay tuned!

Читайте также: Сила минимализма: 17 полезных однострочников на JavaScript