Единственная константа, которой вы должны придерживаться в жизни, — это перемены. Если вы считаете изменения постоянными, вы научитесь приспосабливаться к жизненным сложностям и справляться с ними.
Ваше программное обеспечение должно отражать этот принцип и позволять развиваться и адаптироваться.
Очень важно, чтобы все было просто, а также чтобы вы могли адаптировать систему к неизбежному, но непредсказуемому будущему.
Простую систему легко развивать.
Вещи, которые могут развиваться, имеют возможность принимать более значимую и критическую форму в данной экосистеме: невероятно важные системы и технологии создаются с учетом способности меняться.
Многие проекты с открытым исходным кодом и бизнес-системы строятся по одному небольшому изменению за раз, но развиваются в течение невероятного и долгого пути, который учит сопровождающих и разработчиков контексту и изменениям контекста, в котором они выполняются.
Существует несколько способов обработки изменений в программном обеспечении: абстракции, инкапсуляция, автоматизированное тестирование и многие другие. Для краткости мы рассмотрим абстракции и их более конкретную форму инкапсуляции как основные способы работы с изменениями в кодовых базах и архитектурах.
Такие методы, как автоматическое тестирование, схемы ABC, шаблоны проектирования, в основном являются реализациями этих двух идей более высокого порядка, и поэтому обсуждение в конечном итоге сводится к обсуждению либо абстракции, либо инкапсуляции.
Абстракция
Начнем с абстракции. Как мы создаем абстракции, которые просты и понятны, а также обеспечивают учет изменений? Ответ сводится к простому пониманию: ожидание против эволюции.
Большинство абстракций в программном обеспечении строятся в ожидании изменений, что приводит к абстракциям, которые часто не используются, потому что ожидаемые события никогда не происходят.
Что, если у нас будет X пользователей?
Что, если нам нужно создать функцию X?
Это распространенные вопросы, возникающие на встречах с разработчиками, которые вызывают использование абстракций ожидания.
Большинство систем не достигают «веб-масштаба», и 90% ожидаемых функций никогда не создаются, потому что часто есть более важные вещи, которые нужно создать. Вместо того, чтобы строить упреждающие абстракции, мы должны строить абстракции, которые развиваются вместе с изменяющимся контекстом.
То есть: абстракции должны быть расширяемыми, поддерживаемыми и, прежде всего, понятными, а не революционными. Это позволяет абстракции всегда существовать в состоянии, которое является одновременно полезным и значимым для системы, но при этом не «слишком существующим» в системе и трудным для понимания, расширения или поддержки.
Абстракции, такие как «сущность» и «объект», имеют свое время и место, однако часто существуют на самом высоком уровне абстракции, который не требуется для большинства задач.
Эти абстракции требуют множества логических линий, чтобы определить, какой тип «сущности» существует и как она может вести себя в заданном сценарии в контексте. Затем эти логические линии должны быть протестированы и применены, иначе в некоторых случаях система станет неработоспособной и непригодной для использования.
Это приводит к невероятно сложным, угнетающим системам, которые трудно поддерживать и еще труднее расширять.
Далее, давайте сосредоточимся на инкапсуляции.
Инкапсуляция
В программном обеспечении есть распространенная идиома: инкапсулировать то, что изменяется. Эта идея обычно вращается вокруг бизнес-логики или алгоритмов и создания функций, методов или объектов, чтобы гарантировать, что остальная часть кода кодируется для интерфейсов, а не для реализации бизнес-логики или алгоритма.
Инкапсуляция, по своей сути, представляет собой особую форму абстракции, включающую сокрытие деталей реализации за интерфейсом кода или компонента, который его использует; что позволяет изменять базовые детали фактической реализации без изменения потребляющего модуля/кода.
Это делает изменения более управляемыми и менее рискованными. Инкапсуляция становится все более важной, поскольку системы взаимодействуют со все большим количеством внешних API и веб-сервисов.
Без инкапсуляции код, взаимодействующий с этими службами, будет невероятно сильно меняться по мере выпуска новых версий служб. Большинство этих сервисов поставляются с SDK, чтобы облегчить эти проблемы, но даже в этом случае может быть целесообразно обернуть даже SDK в свой код, чтобы гарантировать, что ваша система владеет своими интерфейсами.
Инкапсуляция гарантирует, что большая часть изменений происходит в одном месте и, следовательно, изолирует изменения внутри системы. Это позволяет системам развиваться вместо того, чтобы предвидеть все заранее.
Вывод
В конечном счете, знание того, что изменения неизбежны, и принятие этого единственно неизменного факта является важным шагом к созданию устойчивых, расширяемых и поддерживаемых систем.
Создание системы, которая может меняться, является признаком отличной архитектуры. В конце концов, архитектура — это возможность для бизнеса, а бизнес в конечном счете зависит от контекста (открытый исходный код — это все еще бизнес). Отличные архитектуры позволяют изменять бизнес-климат, а система может адаптироваться к этим изменениям.