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

Итак, основная цель этой статьи — помочь вам лучше понять эти принципы.

Давайте начнем!

S.O.L.I.D. Директора

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

Единственная ответственность — класс должен иметь одну-единственную работу. Это не может быть многозадачность.

2) Принцип открытия/закрытия:

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

3) Принцип подстановки Лисков:

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

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

Могут быть некоторые методы, которые не реализованы или не используются клиентами. У них есть свобода выбора, использовать это или нет. Клиентов не следует заставлять внедрять методы, которые они не используют.

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

Модули более высокого уровня не должны зависеть от модулей более низкого уровня. но они должны зависеть от абстракции.

→ Подход к решению

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

  1. Думайте над проблемой
  2. Разделяй и властвуй
  3. KISS — будь проще и глупее
  4. Учитесь, особенно на ошибках
  5. Всегда помните, зачем существует программное обеспечение
  6. Помните, что вы не пользователь

Давайте углубимся в эти понятия.

Думайте над проблемой

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

Разделяй и властвуй

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

KISS — будь проще и глупее

Держись просто и глупо. Не усложняйте свое решение намеренно, не переусердствуйте и не переусердствуйте ни в одном случае.

Учитесь на ошибках

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

Программное обеспечение Reason существует

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

Вы не будете использовать программное обеспечение

Удобство использования и пользовательский опыт имеют значение. Не думайте, что пользователь поймет, потому что он/она не является технически подкованным человеком.

→ Реализация решения

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

1. ЯГНИ

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

2. СУХОЙ

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

3. Примите абстракцию

Убедитесь, что ваша система работает правильно, не зная деталей реализации каждого компонента. Например, пользовательский класс должен иметь возможность аутентифицировать пользователей, не зная, нужно ли получать имя пользователя и пароль.

4. ДРИТВ

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

5. Пишите код, который хорошо справляется с одной задачей

Не пытайтесь написать магический код. При написании кода пишите один фрагмент кода, который действительно хорошо выполняет одну и ту же функцию.

6. Отладка сложнее, чем написание кода

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

7. Кайдзен

Исправьте не ошибку, а код вокруг нее. Оставьте его лучше, чем когда вы его нашли.

→ Практики

Как разработчики, мы должны использовать передовой опыт при разработке кода. Это было введено Coding Guru после изучения многолетнего опыта. Поговорим о них,

1. Модульное тестирование

В модульном тестировании мы можем заранее выявить проблемы интеграции. Прежде чем интегрировать все функции вместе, тестируется небольшой код за кодом. Модуль может быть классом, функцией, модулем, API и т. д. Это подтверждает, что модуль работает должным образом и обеспечивает ожидаемый результат.

2. Качество кода

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

3. Обзор кода

Это лучший способ улучшить качество кода. Цель не в том, чтобы критиковать разработчика, а в том, чтобы улучшить код. При просмотре просмотрите менее 400 строк кода (LOC), а скорость должна составлять 500 LOC в час. Не пересматривайте непрерывно более часа.

4. Контроль версий

Это позволяет разработчикам свободно изменять и улучшать код, не опасаясь сломать код. Позвольте нескольким разработчикам совместно работать над одной и той же кодовой базой, и разработчики смогут устранить единую точку отказа в кодовой базе.

5. Непрерывная интеграция

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

Сводка

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

Большое спасибо, что нашли время, чтобы прочитать это. Надеюсь, теперь вы лучше разбираетесь в этом вопросе.