Принципы программирования как принципы жизни программы: зачем они нам нужны?

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

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

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

KISS

"Keep It Simple, Stupid" - программирование KISS, в частности, очень важно. Постарайтесь держать это в уме в своих начинаниях. Чем проще ваш код, тем проще будет его поддерживать в будущем. Это будет очень ценным для всех, в частности для тех, кому нужно будет изучать ваш код в будущем.

Принцип KISS был придуман Келли Джонсоном (Kelly Johnson), и в нем говорится, что большинство систем лучше всего работают, если их сохранять простыми, а не усложнять; поэтому простота должна быть ключевой целью при проектировании, а ненужной сложности следует избегать.

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

YAGNI

"You Aren't Gonna Need It" - Иногда, как разработчики, мы пытаемся думать о будущем проекта, мы пытаемся прописать некоторые дополнительные методы "на всякий случай, если они нам понадобятся" или думая, что "в конце концов они нам понадобятся". Всего одно слово: Неправильно! Он вам не нужен, он вам не нужен и в большинстве случаев... "Он вам не понадобится".

YAGNI - это принцип, лежащий в основе экстремальной практики программирования "Делай самую простую вещь, которая может сработать". Даже когда этот принцип является частью программирования, он применим во всех видах методологий и процессах разработки. Реализуя идеалы программирования по принципу YAGNI, вы можете сэкономить себе время и эффективно двигаться вперед с проектами.

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

SOLID

Еще один общий принцип программирования, это в действительности 5 принципов, объединенных в один. Так что давайте распакуем его, чтобы найти в нем хоть какой-то смысл:

✔ Принцип единой ответственности

✔ Принцип открытости и закрытости

✔ Принцип замещения Лискова

✔ Принцип сегрегации интерфейса

✔ Принцип инверсии зависимости

Single Responsibility Principle

Принцип единой ответственности

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

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

Open-Closed principle

Принцип открытости и закрытости

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

Liskov Substitution Principle

Принцип замены Лискова

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

Interface Segregation Principle

Принцип сегрегации интерфейса

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

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

Dependency Inversion Principle

Принцип инверсии зависимости

Наконец, закрывая концепцию SOLID, мы поговорим об инверсии зависимости, также известную как инъекция зависимости. По сути, этот принцип гласит, что если в вашем коде есть зависимости, то вы должны разрешить их добавление в вашу логику. Каким образом? Просто! Позволяя вводить их в качестве параметров.

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

Инъекция зависимостей - это просто шикарный инструмент, создающий расширяемый дизайн и показывающий, что вы заботитесь о расширяемости в вашем программном коде.

Заключение

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

Создание сайтов в Алматы.