5 принципов читаемого кода: KISS, YAGNI, DRY, BDUF и Бритва Оккама

Данная статья предназначена для понимания основных принципов написания читаемого кода. Для некоторых принципов будут приведены примеры React и JavaScript.

Влад Матковский

TeamLead Web Frontend

Во многих проектах идет слепое следование SOLID принципам (которые являются не менее важными!), при этом нарушаются и не берутся во внимание многие другие стандарты написания кода. Не нужно впадать в крайности — необходимо соблюдать баланс. Итак, к основным принципам разработки и написания чистого когда относятся:

KISS — Always Keep It Simple, Stupid (будь проще)

1. Ваши методы должны быть небольшими (40-50 строк).
2. Каждый метод решает одну проблему.
3. При модификации кода в будущем не должно возникнуть трудностей.
4. Система работает лучше всего, если она не усложняется без надобности.
5. Не устанавливайте целую библиотеку ради одной функции из неё.
6. Не делай того, что не просят.
7. Писать код необходимо надежно и «дубово».

Как это можно реализовать в React? С приходом хуков основной единицей построения веб-приложения становится функциональный компонент. Например, можно создавать компоненты небольшого размера. Логику необходимо выносить во вспомогательные функции. Если это работа с использованием состояния — создавать кастомные хуки. В итоге получаем компонент небольшого размера (функция), вспомогательные функции малого размера, пользовательские хуки (так же являются функциями). Вся логика вынесена в небольшие функции, которые в дальнейшем будет удобно покрыть unit тестами.

В целом, для упрощения и сокращения кода, необходимо использовать стрелочные функции, значения для параметров функции по умолчанию, деструктуризацию, async/await синтаксис, обязательно использование блоков try/catch для надежности. Взгляните, как усложнен код ниже:

			function volume(l, w, h) {
 if (w === undefined)
 w = 1;
 if (h === undefined)
 h = 1;
 return l * w * h;
}
		

Как выглядит это проще при использовании стрелочных функции и параметров по умолчанию:

			const volume = ( l, w = 1, h = 1) => l * w * h
		

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

YAGNI — You are not gonna need it (Вам это не понадобится)

1. Реализуйте только то, что нужно здесь и сейчас, а не в теории, что оно пригодится в будущем.
2. Подчищайте ненужный код (найдите через Git историю при надобности).
3. Программист не должен добавлять новый функционал, о котором его не просят (благими намерениями без должной проверки вы только добавите багов).

DRY — Don’t Repeat Yourself (Не повторяйся)

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

В React этот принцип можно выразить через переиспользуемые компоненты. В целом, на этом и базируется принцип React. UI необходимо создавать из переиспользуемых блоков.

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

			const MoviesListFacade = () => {
 const { t } = useTranslation()
 const {
 isLoading: isMoviesLoading,
 data: movies,
 isError,
 } = useGetMoviesListQuery()
 const { genreSelectValue, setGenreSelectValue } =
useGenreSelect()
 const { searchValue, setSearchValue } = useTextFieldSearch()
 const { filteredMovies } = useMoviesFilter({
 movies: movies || [],
 genre: genreSelectValue,
 search: searchValue,
 })
 if (isMoviesLoading) return 
 if (isError) return 
return (…)
}
		

В целом код должен пройти через следующие стадии:

Дополнительно можно придерживаться правил, представленных ниже.

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

1. Не нужно создавать лишние сущности без необходимости в них.
2. Всегда начинайте с максимально простого кода, затем увеличивайте сложность по мере необходимости.

BDUF — Big Design Up Front (Сначала большое проектирование)

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

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

Придерживайтесь их, и в будущем вам благодарны будете и вы сами, и ваши коллеги.