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

Есть одна прекрасная поговорка: «Тот, кто не помнит прошлого, обречен на его повторение». Эта идея очень важна для разработки программного обеспечения. Например, инженеры-программисты создали различные инструменты и методы для решения проблем в каждом конкретном случае. Так что, как разработчики программного обеспечения, если мы узнаем об этих обстоятельствах раньше и изучим изобретенную технику, мы можем сэкономить много времени, пытаясь заново изобрести колесо.

Так что же должен знать каждый инженер-программист?

Шаблоны проектирования

24-GOF — супергерои разработки программного обеспечения. Каждый популярный фреймворк так или иначе использует эти шаблоны проектирования. Чтобы дать тизер, есть шаблон проектирования, широко известный как шаблон Observer. Идея состоит в том, чтобы написать код, который отслеживает некоторые изменения в объектах/коде/файлах или чем-то еще, а затем выполнять некоторые задачи в ответ на изменение. Если мы попытаемся реализовать эту проблему, не беря никаких ссылок из GOF, у нас может получиться плохая реализация. Но если мы попытаемся реализовать его в виде шаблона проектирования, у нас будет надежное и ремонтопригодное решение.

Принципы дизайна

SOLID — это широко популярный принцип проектирования, который означает

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

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

Третий принцип подстановки Лисков может быть немного сложным для понимания, но я постараюсь дать предельно простое объяснение. Скажем, у вас есть классы объектно-ориентированного наследования — User и AdminUser. Возьмем пример: у вас есть атрибут в родительском классе User с именем settings. Тогда, если вы зададите настройки как словарь в родительском классе и как массив в дочернем классе, это нарушит принцип подстановки Лискова. По сути, в нем говорится, что вы должны иметь возможность заменить родительский экземпляр дочерним экземпляром, не вызывая побочных эффектов. Теперь в приведенном выше примере у вас есть метод для возврата настроек, тогда он не будет работать как для словаря, так и для массива. Таким образом, решение состоит в том, чтобы создать функцию setSetting в родительском классе и использовать ее всякий раз, когда мы хотим установить настройку. Сделав это, мы сможем заменить экземпляр родителя экземпляром дочернего элемента.

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

Последний называется принципом инверсии зависимостей, который гласит, что высокоуровневые модули должны делать высокоуровневые вещи, а низкоуровневые — низкоуровневые. Звучит похоже на принцип единой ответственности, но суть в том, что изменение низкоуровневого модуля не должно влиять на высокоуровневый модуль. Классы/модули высокого уровня должны зависеть от абстракций классов низкого уровня, а не от деталей. Например, компания Uber не зависит от самих водителей автомобилей. Не будучи зависимыми, они сделали себя открытыми для изменений. Скажем, в будущем Uber будет предлагать поездки на лодке.

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

Если вам понравилась моя статья, не забудьте подпишитесь на меня в Medium, или подпишитесь на Linkedin, или подпишитесь на меня в Twitter.