Принцип программирования KISS — делайте вещи проще
Большая часть программных систем перегружена практически ненужными функциями, что ухудшает удобство их использование конечными пользователями, а также усложняет их поддержку и развитие разработчиками.
KISS — «keep it short and simple» , это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности.
В проектировании следование принципу KISS выражается в том, что:
- не имеет смысла реализовывать дополнительные функции, которые не будут использоваться вовсе или их использование крайне маловероятно
- не стоит перегружать интерфейс теми опциями, которые не будут нужны большинству пользователей
- бессмысленно делать реализацию сложной бизнес-логики, которая учитывает абсолютно все возможные варианты поведения системы, пользователя и окружающей среды
В программировании следование принципу KISS можно описать так:
- не имеет смысла беспредельно увеличивать уровень абстракции, надо уметь вовремя остановиться
- бессмысленно закладывать в проект избыточные функции «про запас», которые может быть когда-нибудь кому-либо понадобятся
- не стоит подключать огромную библиотеку, если вам от неё нужна лишь пара функций
- декомпозиция чего-то сложного на простые составляющие — это архитектурно верный подход
- абсолютная математическая точность или предельная детализация нужны не всегда
Принцип программирования DRY — don’t repeat yourself / не повторяйте себя
Следование принципу программирования «DRY» позволяет добиться высокой сопровождаемости проекта, простоты внесения изменений и качественного тестирования.
Если код не дублируется, то для изменения логики достаточно внесения исправлений всего в одном месте и проще тестировать одну (пусть и более сложную) функцию, а не набор из десятков однотипных. Следование принципу DRY всегда приводит к декомпозиции сложных алгоритмов на простые функции. А декомпозиция сложных операций на более простые (и повторно используемые) значительно упрощает понимание программного кода. Повторное использование функций, вынесенных из сложных алгоритмов, позволяет сократить время разработки и тестирования новой функциональности.
Следование принципу DRY приводит к модульной архитектуре приложения и к чёткому разделению ответственности за бизнес-логику между программными классами.
В рамках одного программного класса (или модуля) следовать DRY и не повторяться обычно достаточно просто. Также не требует титанических усилий делать это в рамках небольших проектов, где все разработчики «владеют» всем кодом системы.
В пректировании DRY тоже имеет место — доступ к конкретному функционалу должен быть доступен в одном месте, унифицирован и сгруппирован по какому-либо принципу, а не «разбросан» по системе в произвольных вариациях.
Принцип программирования YAGNI — «Вам это не понадобится» - «You Ain’t Gonna Need It»
Этот принцип прост - если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже.
Этот принцип применим при рефакторинге. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны.
Если что они всегда будут на GitHub.
SOLID — принципы объектно-ориентированного программирования
SOLID — это аббревиатура пяти основных принципов проектирования в объектно-ориентированном программировании, которые позволяют строить на базе ООП масштабируемые и сопровождаемые программные продукты с понятной бизнес-логикой —
- Single responsibility - единственной ответственности
- Open-closed - открытости / закрытости
- Liskov substitution - подстановки Барбары Лисков
- Interface segregation - разделения интерфейса
- Dependency inversion - инверсии зависимостей
Принцип единственной обязанности / ответственности (single responsibility principle / SRP) обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулирована в класс. Все его сервисы должны быть направлены исключительно на обеспечение этой обязанности. Подробнее про SRP...
Принцип открытости / закрытости (open-closed principle / OCP) декларирует, что программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Это означает, что эти сущности могут менять свое поведение без изменения их исходного кода. Подробнее про OCP...
Принцип подстановки Барбары Лисков (Liskov substitution principle / LSP) в формулировке Роберта Мартина: «функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа не зная об этом». Подробнее про LSP...
Принцип разделения интерфейса (interface segregation principle / ISP) в формулировке Роберта Мартина: «клиенты не должны зависеть от методов, которые они не используют». Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические, чтобы клиенты маленьких интерфейсов знали только о методах, которые необходимы им в работе. В итоге, при изменении метода интерфейса не должны меняться клиенты, которые этот метод не используют. Подробнее про ISP...
Принцип инверсии зависимостей (dependency inversion principle / DIP) — модули верхних уровней не должны зависеть от модулей нижних уровней, а оба типа модулей должны зависеть от абстракций; сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций. Подробнее про DIP...
Источники для углубления - тык, прочие принципы - тык
Мой телеграм канал - troff_webdev