У разработчиков есть свои термины, которыми они описывают разные принципы разработки — например DRY, SOLID и YAGNI. Рассказываем, что они означают и что имеют в виду программисты, когда говорят такое.
DRY
DRY — сокращение от Don’t repeat yourself, что переводится с английского как «Не повторяйся». Этот принцип означает, что программист должен избегать повторов в реализации кода и в логике работы, а вместо этого использовать то, что есть.
На практике это работает так: допустим, у нас есть функция, которая проверяет логин и пароль пользователя и разрешает ему доступ. Некоторое время спустя мы решаем добавить в сервис элемент безопасности: если пользователь долго не пользовался страницей, мы просим его ввести пароль ещё раз. Это нужно, чтобы убедиться, что за компьютером всё ещё он, а не кто-то другой — так часто делают интернет-магазины и онлайн-банки.
Конечно, можно написать новую функцию проверки пароля — она будет работать чуть проще, чем с вводом логина, и её можно легко добавить в код. Но если придерживаться принципа DRY, то нам следует использовать уже готовую функцию из блока авторизации, а логин передать туда самостоятельно. Может оказаться так, что для этого нужно будет чуть поправить исходную функцию, зато мы не будем дублировать код и сохраним единую логику работы.
Смысл принципа DRY — не писать новый код, если уже есть старый, который делает то, что нам нужно. Если его возможностей немного не хватает, то программист думает, как их туда добавить, не сломав исходную функцию.
SOLID
SOLID — это целый набор правил, а название образовалось по первым буквам каждого из них. Такой подход часто используется в крупных проектах и в командной работе над кодом.
Single responsibility principle — принцип единой ответственности. В общем виде это правило можно сформулировать так: одна функция должна выполнять только одну задачу и не быть универсальной для всех ситуаций. Это иногда противоречит принципу DRY, поэтому тут каждая команда решает сама, какое правило в каких случаях нужно использовать.
Open-closed principle — принцип открытости и закрытости. Он означает, что все модули, библиотеки и расширения, которыми могут пользоваться другие программисты, должны быть открыты для расширения и закрыты для изменений. Например, если вы делаете внешний модуль для работы со временем, он должен понимать разные форматы даты и в него можно передавать время в разных форматах. При этом изменить поведение модуля не получится: независимо от того, что в него передаётся, он всегда делает одно и то же по стандартным сценариям.
Liskov substitution principle — принцип подстановки Лисков. Барбара Лисков придумала основу для этого принципа, когда работала над принципами работы ООП. Если сильно упростить, то получится так: представим, что у нас есть базовые объекты, а у них — свои вложенные другие объекты и свойства. По принципу подстановки Лисков функция, которая использует базовые объекты, может использовать и её вложенные объекты без дополнительных объявлений или сложных конструкций. Новичкам этот принцип можно пропустить, но знать о нём полезно.
Interface segregation principle — принцип разделения интерфейса. Интерфейс в программировании — это то, что умеет делать функция, класс или объект. Например, у объекта «сетевое подключение» могут быть интерфейсы «подключиться», «отключиться», «проверить связь» и «передать данные». Принцип разделения означает, что если мы поменяем внутри что-то в одном интерфейсе, это не должно сломать работу остальных интерфейсов.
Dependency inversion principle — принцип инверсии зависимостей. Смысл в том, чтобы зависимости, например от внешней базы данных, не встраивались жёстко в тело модуля, а были одним из аргументов, от которых зависит выполнение этого модуля. Если нам нужно будет поменять базу данных, с которой работает модуль, достаточно будет сделать это при вызове, а не править исходную функцию.
YAGNI
Это аббревиатура от фразы You aren't gonna need it — «тебе это не понадобится». Простой принцип, который означает, что не нужно писать код из серии «в будущем нам это пригодится». Если функция или модуль не нужен прямо сейчас — их не пишут.
Логика тут такая: время, которое тратится на написание функций на будущее, можно использовать для доработки и улучшения того, что уже есть. Кроме того, непонятно, как такие функции будут развиваться дальше — может оказаться так, что там понадобится совсем другое и модули, созданные про запас, придётся переписывать.
Зачем вообще нужны эти принципы?
Программисты придумали всё это чтобы работать по единым стандартам в команде или компании. Например, если команда придерживается DRY-подхода, то на код-ревью тимлид будет ругаться на одинаковые по функционалу модули. А если в компании работают по принципам SOLID, то там наоборот, у модулей может быть похожий смысл, но каждый модуль будет решать свою отдельную задачу.
