Если бы я мог научить начинающего разработчика только одной вещи...
Несколько недель назад во время написания статьи в блоге о том, как абстрагировать свой код, чтобы его было легче переиспользовать, мне пришла в голову интересная идея. Мне захотелось узнать, какой, по мнению других разработчиков, самый важный принцип, которому они могли бы научить начинающего разработчика, и почему они выбрали именно этот принцип проектирования.
Поэтому я провел несколько "интервью", часть - через WeChat, часть - через Google Forms и остальные - из внутренней темы Google Chat.
Принцип единственной ответственности
Результат получился очень любопытным. Первый главный принцип - это "Принцип единственной ответственности", "Single Responsibility Principle", или сокращенно SRP. Хотя существуют и другие интерпретации, обычно SRP означает, что вы должны сделать свою функцию, класс или модуль настолько простым и связным, насколько это возможно.
Одним из конкретных примеров этого принципа может быть то, что я извлек из темы Google Chat:
...Я предлагаю им дать своим функциям осмысленные имена (это относится к первому пункту) и посмотреть, приходится ли им использовать союзы типа и/или для определения того, что делает функция. Если это так, им следует разбить эту функцию на несколько...
Это применимо и к другим уровням в вашем коде. Например, класс не должен делать две несвязанные вещи. Класс данных Person может иметь name, address и dob, но метод deliver будет излишним.
Ниже приведен пример, который я обсуждал в этой статье: компонент Avatar включает в себя всплывающий Tooltip и показывает его при предоставлении props.name. Применяя SRP, вы, скорее всего, захотите выделить код, связанный с Tooltip, и убедиться, что Avatar заботится только о логике, связанной с аватаром.
Инкапсуляция
Вторая по популярности тема - инкапсуляция. Грубо говоря, это принцип, согласно которому не следует использовать разбросанные тут и там данные или функции, а инкапсулировать их внутри класса или типа того. Но кроме того, он также может обязывает знать, где и какие данные и методы должны быть размещены.
Здесь я приведу пример из другой моей статьи и покажу, как с помощью класса можно инкапсулировать открытые данные.
Рядом с компонентами React часто можно увидеть небольшие функции преобразования данных, и по мере того, как меняется способ использования этих данных на фронтенде (использование аббревиатуры вместо полного имени или добавление ветки if-else, где понадобится), эти маленькие функции верхнего уровня становится трудно поддерживать.
Вместо этого мы могли бы иметь класс для всех данных и функций преобразования. У нас будет единое место для внесения изменений, если эта логика поменяется. Также так проще писать тесты - вы определяете входные данные с некоторыми вариациями и проверяете вывод публичных методов класса.
Don’t Repeat Yourself
Номер три в списке - DRY - Don't Repeat Yourself. Все мы ненавидим повторять одно и то же при кодировании, особенно когда приходится делать это вручную. Вообще говоря, в большинстве случаев действует правило трех, то есть вам следует не допускать более трех случаев дублирования.
Здесь, как и в других принципах разработки программного обеспечения, следует заметить одну вещь: сначала вы должны попытаться понять, зачем код дублируется, а затем убрать дублирование. Есть несколько интересных статей (я поместил их в раздел ссылок внизу) о том, когда не следует удалять дублирование.
Я обнаружил, что в разных языках программирования есть механизмы, которые делают DRY проще или сложнее. Например, в функциональных языках вы можете передавать функции так же, как переменные, потому что функции являются объектами первого класса, что невозможно в чистых объектно-ориентированных языках.
И затем вы можете передать этой функции любую функцию, чтобы избежать дублирования, например:
В то время как в Java, например (если мои знания Java устарели, пожалуйста, сообщите в комментариях), вы должны сначала создать интерфейс и затем передавать классы, реализующие этот интерфейс, чтобы добиться того же, что довольно громоздко.
Подводя итоги
Эти три главных принципа укоренились в сознании большинства разработчиков, хотя у разных людей были несколько отличающиеся друг от друга интерпретации.
SRP заставляет вас сосредоточиться только на одной вещи и сделать ее идеальной, и если вы все сделаете правильно, то за этим сами собой последуют тестируемость и компонуемость. В то время как инкапсуляция помогает вам собрать целостный контент, алгоритм, данные и логику в единое место, она также помогает облегчить понимание кода. И, наконец, DRY сохраняет код всегда в простом и лаконичном состоянии. Кроме того, вам не нужно беспокоиться о том, что вы забудете исправить все повторения при внесении изменений.
Ссылки
Материал подготовлен с ❤️ редакцией Кухни IT.
