Почему архитектура вашего кода имеет значение

Часто говорят, что кодирование — это способ общения с машинами, и этот способ оптимизирован для них.

Однако это неправда, и я подробно объясню вам, почему.

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

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

Однако мы сделали это, так что, если это не для машин, то для кого?

На этот вопрос ответ прост и в основном ВЫ.

Другая концепция, которую часто неправильно понимают, заключается в том, что код предназначен для чтения, а не для записи.

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

Часто соотношение таково, что разработчик тратит 75% своего времени на чтение и только 25% времени на написание.

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

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

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

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

Для разработчиков эти практики обеспечивают лучший опыт программирования, а для бизнеса — большую эффективность программистов на проекте в течение длительного периода времени.

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

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

Чистый код будет на базовом уровне и про организацию функций в класс, имена переменных, функции и класс.

Где архитектура будет заключаться в разделении и организации классов, библиотек и пакетов.

Чтобы сделать это различие менее расплывчатым, давайте рассмотрим несколько примеров практик и к какой теме они относятся.

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

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

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

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

Эта практика происходит непосредственно в коде и в том, как мы его пишем, поэтому она низкоуровневая. Из-за этого этот трюк имеет дело с чистым кодом.

Практикой, которую можно связать с архитектурой, может быть использование принципов SOLID.

SOLID — это принципы, которые позволяют коду проекта оставаться понятным и удобным для сопровождения.

Этих принципов всего пять, и каждая буква слова SOLID означает единицу:

  • Однаодна ответственность: у класса должна быть только одна причина для изменения
  • Open Close: класс всегда должен быть открыт для расширения, но не для модификации.
  • Замена Liskov: Ваш код должен оставаться функциональным, когда мы используем дочерний элемент из вашего класса.
  • Разделение интерфейсов. Всегда разделяйте интерфейсы как можно больше.
  • Dинверсия зависимостей: всегда полагайтесь на абстрактные классы или интерфейс, а не на конкретные классы.

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

Многие источники объясняют и детализируют эти шаблоны, но лучше всего мне объясняет Refactoring Guru. Если вам интересна эта тема, приглашаю вас пройти по этой ссылке: https://refactoring.guru/design-patterns/catalog

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

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

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

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