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

Ваше программное обеспечение должно отражать этот принцип и позволять развиваться и адаптироваться.

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

Простую систему легко развивать.

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

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

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

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

Абстракция

Начнем с абстракции. Как мы создаем абстракции, которые просты и понятны, а также обеспечивают учет изменений? Ответ сводится к простому пониманию: ожидание против эволюции.

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

Что, если у нас будет X пользователей?

Что, если нам нужно создать функцию X?

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

Большинство систем не достигают «веб-масштаба», и 90% ожидаемых функций никогда не создаются, потому что часто есть более важные вещи, которые нужно создать. Вместо того, чтобы строить упреждающие абстракции, мы должны строить абстракции, которые развиваются вместе с изменяющимся контекстом.

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

Абстракции, такие как «сущность» и «объект», имеют свое время и место, однако часто существуют на самом высоком уровне абстракции, который не требуется для большинства задач.

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

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

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

Инкапсуляция

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

Инкапсуляция, по своей сути, представляет собой особую форму абстракции, включающую сокрытие деталей реализации за интерфейсом кода или компонента, который его использует; что позволяет изменять базовые детали фактической реализации без изменения потребляющего модуля/кода.

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

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

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

Вывод

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

Создание системы, которая может меняться, является признаком отличной архитектуры. В конце концов, архитектура — это возможность для бизнеса, а бизнес в конечном счете зависит от контекста (открытый исходный код — это все еще бизнес). Отличные архитектуры позволяют изменять бизнес-климат, а система может адаптироваться к этим изменениям.