SOLID, YAGNI, DRY, KISS принципы в React
По мере развития программирования код становится более сложным и, соответственно, возникает все больше ошибок и трудностей в понимании. Для борьбы с этим создаются различные практики и принципы разработки. Одними из таких являются SOLID принципы.
Эти принципы, конечно, больше подходят для ООП, т.к. они зависят от классов и интерфейсов. А вот современный код в React в данный момент далек от ООП, а скорее больше функциональный. Но SOLID принципы не зависят от языка, и их можно интерпретировать как угодно и, соответственно, применить к функциональному коду React.
SOLID является аббревиатурой, а каждая буква - это один из пяти принципов:
SRP - принцип единой ответственности. Изначальное определение гласит, что каждый класс должен иметь только одну ответственность. Этот принцип проще всего применить к функциональному коду, переведя это определение так: компонент/функция/модуль должны делать только одну вещь. Этот принцип является самым эффективным для улучшения кода. К тому же ему проще всего следовать из всех пяти принципов. Касаемо React, мы этот принцип можем реализовать следующими способами:
разделить большие компоненты с громоздкой логикой на более мелкие.
вынести в отдельные функции общего назначения.
вынести логику, связанную с компонентой, в пользовательские хуки.
2. OCP - принцип открытости-закрытости. Изначальное определение гласит, что программные объекты должны быть открыты для расширения, но закрыты для модификации. Собственно, это определение даже в этом виде подходит для React. Приводя пример, можно сказать, что есть компоненты, которые в зависимости от различных условий показывают разный контент. Соответственно, со временем эта компонента может расширяться, и условий будет становиться все больше. Таким образом, можно реализовать этот принцип, используя render-props или children.
3. LSP - принцип подстановки Барбары Лисков. Этот принцип указывает на то, что объекты подтипа должны замещаться объектами супертипа. Т.е. дочерний класс должен уметь делать все то, что и родительский. Но получается так, что это, как правило, следует применять в наследовании классов. А в современном React наследование практически не используется из-за использования функционального подхода.
4. ISP - принцип разделения интерфейсов. Основная идея заключается в том, что клиенты не должны зависеть от интерфейсов, которые они не используют. При использовании React можно перефразировать в “компоненты не должны зависеть от пропсов, которые они не используют”. Не раз можно заметить при написании кода, что, к примеру, в одну небольшую компоненту через пропсы прокидывается большой объект. Но используется в дальнейшем только пара свойств из него. Собственно, эта компонента знает слишком много информации, которую не использует. Это может стать проблемой при использовании TypeScript в случаях, когда эта компонента может принимать в себя объекты с разной структурой.
5. DIP - принцип инверсии зависимостей. Он говорит о том, что следует полагаться на абстракции, а не на конкреции. Если применить этот принцип к React, то один компонент не должен зависеть от другого. И должна быть общая абстракция, от которой будут зависеть оба компонента.
Помимо принципов SOLID, существуют еще много принципов разработки. Одними из которых являются DRY, KISS, YAGNI.
KISS - этот принцип переводится как “оставь код простым и тупым”. Из перевода сразу понятно, что не нужно усложнять свой код. При разрастании каких-то функций и компонент старайтесь разделять их на более мелкие и понятные логические части.
DRY - означает “не повторяйтесь”. Во время написания кода старайтесь избегать дублирования кода и выносить его в отдельные компоненты и функции. Последствием избегания этого принципа может стать наличие множества дублированного кода, которые в дальнейшем сложно будет изменять. Ведь проще добавлять какие-то изменения только в одном месте, а не в нескольких сразу.
YAGNI - этот принцип переводится как “это вам не понадобится”. Суть этого метода в том, что не стоит писать функционал, который, возможно, будет использоваться в будущем. Он может и не понадобится, а время на написание кода будет потрачено. К тому же написанный лишний функционал может измениться, да и вовсе не понадобиться.
Подводя итог, можно сказать, что следование этим принципам не является неукоснительным, но может помочь для написания качественного кода, который будет как легко расширять, так и легко читать.
