Смущенный? Ну, это никак не связано с реальным поцелуем 😂

«Твердый, СУХОЙ, ПОЦЕЛУЙ. YAGNI »- это несколько принципов разработки программного обеспечения, которые мы будем обсуждать сегодня.

Зачем мне это изучать?

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

  • Надежность
  • Эффективность
  • Поставка качественного программного обеспечения
  • Гибкость, простота рефакторинга

Написать код легко, но написать хороший и качественный код сложно.

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

Принципы

Простота - залог надежности. - Эдсгер Дейкстра

ЦЕЛОВАТЬ

KISS - это аббревиатура от «Keep It Simple Stupid». Этот принцип буквально означает, что код должен быть как можно более простым.

Вы можете подумать: «Но, я же всегда стараюсь просто !?»

Что ж, со многими инженерами дело обстоит иначе. Вы начинаете с чего-то простого, но вскоре добавляете нежелательную сложность по мере роста кода.

Инженеры любят все усложнять!

Чем проще код, тем легче его понимать и поддерживать.

Самый простой пример этого - добавление сложной функции сортировки, когда простая сортировка библиотеки удовлетворяет ваши потребности! Не оптимизируйте, если в этом нет необходимости.

Другое распространенное нарушение KISS - использование новой структуры или добавление нового модуля npm в ваш код, чего можно легко избежать. Например. Есть пакет npm для преобразования строки в верблюжий регистр. Подумайте, а действительно ли вам это нужно или простая функция решила бы вашу задачу?

Как только вы добавляете новую зависимость, вы в основном увеличиваете общую сложность кода, что будет проблематично в будущем.

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

СУХОЙ

DRY означает «Не повторяйся».

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

Когда вы повторно используете компоненты, вы сокращаете объем написанного кода. Чем меньше кода, тем лучше ремонтопригодность!

Как инженер, автоматизируйте и используйте повторно, когда сможете!

Самый распространенный пример - функции! Общее правило: если вы пишете одну и ту же логику более трех раз, пора преобразовать логику в функцию и повторно использовать ее!

Нормализация базы данных - один из методов уменьшения избыточности данных за счет исключения столбцов. Это пример СУХОЙ!

ЯГНИ

YAGNI - это аббревиатура от «Тебе это не понадобится».

Этот принцип гласит, что вы не должны оптимизировать и усложнять размышления о будущем.

Делайте то, что требуется сейчас. Не оптимизируйте раньше времени!

Также вы не знаете, какие новые дела могут возникнуть впереди! Зачем тратить дополнительное время и силы на то, что на самом деле не требуется! Тем не менее, вы должны проектировать свои системы таким образом, чтобы для будущих предсказуемых изменений требовались минимальные изменения.

Он синхронизируется с принципом KISS, избегая каких-либо дополнительных сложностей.

Простой пример - не использовать базы данных, когда может работать простая файловая система!

ТВЕРДЫЙ

Этот принцип является аббревиатурой аббревиатур 😛

  • S RP - принцип единой ответственности
  • O CP - Принцип открытости и закрытости
  • L SP - Принцип замены Лискова
  • I SP - Принцип разделения интерфейса
  • D IP - принцип инверсии зависимостей

Единая ответственность

Определение из Википедии довольно четкое -

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

Каждый метод или класс должен быть ограничен некоторой функциональностью. Он не должен делать ничего меньше или больше. Для его изменения должна быть только одна причина!

Пример - Login пакет должен иметь дело с кодом входа пользователя, он не должен иметь дело с регистрацией пользователя.

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

Теперь showPosts изменяется только тогда, когда мы хотим показать дополнительную информацию о публикации. (Единственная причина изменить)

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

После того, как вы написали фрагмент кода, а затем появились некоторые новые функции, теперь вам нужно вернуться к старому коду и снова изменить его! Принцип Открыто / Закрыто как раз с этим связан!

Напишите код таким образом, чтобы ваши классы / методы были -

Открыт для расширения, но закрыт для модификации

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

LSP утверждает, что объекты вашего подкласса должны вести себя так же, как объекты вашего суперкласса.

В приведенном выше примере Car и Bicycle расширяют класс Vehicle. Это не дает LSP, потому что объект Bicycle не может заменить Vehicle, поскольку startEngine() вернет ошибку!

Принцип разделения интерфейса

Клиенты не должны зависеть от интерфейсов, которые они не используют. - Роберт С. Мартин

Это означает, что вы должны делать ваши интерфейсы как можно меньше. Не засоряйте свои интерфейсы ненужными методами.

В этом случае наш интерфейс загрязнен такими методами, как swim и fly, которые не применимы к классу Dog. Мы можем исправить это, разбив наш интерфейс на несколько интерфейсов, таких как AnimalsWhoSwim и AnimalsWhoFly. Интерфейс Animals может содержать функцию eat()

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

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

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

Скажи, не спрашивай

Скажите, не спрашивайте, принцип предлагает не спрашивать объект об их состоянии, а скажите ему, что делать, основываясь на решении, то есть скажите объекту, что делать!

Пример

Здесь мы спрашиваем, вошел ли пользователь в систему или нет, а затем запрашиваем профиль. Мы хотели получить профиль, мы просто говорим объекту, чтобы он показал нам профиль, проверка входа в систему должна быть внутренне реализована в самом showProfile(). Правильный путь должен быть -

Ресурсы

Постарайтесь следовать принципам, которые вы читаете здесь, потому что -

Невозможно плавать, не промокнув - Vusi JCK Maseko

Покажите в комментариях другие полезные принципы, которым вы следуете 👇

Понравилась статья? Считайте поддержите меня ☕️

Надеюсь, вы узнали что-то новое. Не стесняйтесь предлагать улучшения ✔️

Я делюсь регулярными обновлениями и ресурсами в Твиттере. Давайте подключимся!

Продолжайте изучать 🔎 Продолжайте учиться 🚀

Первоначально опубликовано на https://www.mohitkhare.com.