Что дает архитектурное программирование?

Суть архитектурного программирования в том, что архитектура (структура) программы явно присутствует в программной системе в течении всего жизненного цикла системы. Причем, присутствует как для разработчика (design time), включая модификацию, поддержку и сопровождение, так и во время исполнения.

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

Что это нам дает?

Первое: упрощение понимания, модификации и сопровождения. Например, активная разработка Сайткрафта на Вире остановилась в 2014 году, но время от времени приходится вносить изменения. Так как архитектура явная и встроенная, разработчику не надо помнить устройство программы и не надо тратить время на разбор того, в какое место кода нужно внести изменения.

Второе, упрощение отладки. Тут надо сказать про компоненты, так как упрощение отладки связано с компонентами. Архитектура задает основу (скелет), к которой подключаются компоненты. Пока нам достаточно определить только то, что у компоненты есть “оболочка”, отделяющая внутреннее устройство от окружения. Доступ извне компоненты к внутреннему содержанию ограничен или вообще отсутствует, взаимодействие только через оболочку.

Почему нельзя, в общем случае, сказать “что доступ к внутреннему содержанию отсутствует”? Потому что компонента может использовать общую память с другими компонентами. А может и не использовать и быть изолированной по памяти. 

Упрощение отладки вытекает из:

  • возможности отдельной отладки компоненты (unit testing).
  • возможности замены компоненты на другую с тем же интерфейсом — на более простую, более отлаженную или что-то еще для отладки остальной системы.
  • возможности отлаживать не всю программную систему, а включать отладку только для одной или нескольких компонент.

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

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

Как только мы унифицировали компоненты (точнее, унифицировали «оболочку» — взаимодействие компоненты с окружающим миром, мы получили еще очень важное четвертое преимущество, увеличение переиспользования

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

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

Седьмое, если наша архитектура не ограничена одним устройством (а так и должно быть), то появляется возможность разработки программ с гибким распределением между устройствами и масштабированием. Масштабирование — то есть распределение части задачи на несколько “вычислителей” (компонент) перестает быть особенностью big data и data flow, а становится частью обычной разработки.

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

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

2 комментария


  1. Добрый день. Мне почему-то (пока не понял, почему) не очень нравится термин «архитектурное программирование», но я не могу не признать, что он схватывает проблематику и направление решения.
    Мне созвучны очень многие тезисы из этого поста. Хотя есть и моменты, где я полон скепсиса. Давайте посмотрим по пунктам:

    1. Присутствие в runtime — обеими руками «за», хотя понятно, что поборники производительности будут топить за zero cost abstractions. Но мы знаем, что этими zero cost abstractions вымощена дорога в тот ад, в котором мы сейчас находимся.

    2. Упрощение понимания — однозначно! Сюда бы я добавил пункт 2.1 «а также упрощение обучения разработчиков качественному проектированию». По ценности это, конечно, целый отдельный пункт, но по механизму это, я верю, очень близко.

    3. Упрощение отладки… мнэээ…. вот тут мне хочется добавить, что на мой взгляд, для упрощения отладки недостаточно просто иметь в коде схему компонент. На мой взгляд нужно переходить к т.н. «герметичным компонентам», гарантирующим, что все необходимые внешние зависимости 100% видны и поэтому могут быть заменены в процессе отладки. А иначе — какой-то дочерний в третьем поколении компонент «внезапно» пытается обратиться куда-то неведомо куда через интерфейс, который сочинил из ничего, просто заимпортировав какой-то модуль.

    4. «Унификация компонент» или быть может протокола их общения с внешним миром. Я наверное не очень хорошо понял, что такое «оболочка», и зачем нужна эта «унификация», если это не тот отдельный пункт про разработку на разных языках.

    5. И я крайне скептичен насчет увеличения переиспользования. Алексей говорил, что он видел этот эффект в Вире, но пока я тоже не увижу — не поверю. Я убежден, что повторная используемость принципиальна ограничена не свойствами языка, а просто разнообразием задач, растущим (экспоненциально?) вместе с ростом уровня «прикладности». В неприкладной инфраструктуре переиспольтзование возможно, т.к. повторно решаютсчя одни и те же задачи, в прикладной области переиспользование крайне затруднено и именно поэтому почти не встречается, язык тут не при чем. Очень хочется это увидеть на прототипах, если я тут не прав.

    6. Совершенно согласен с идеями про кросс-языковую разработку и про разработку единого «проекта» шире одного целевого исполняемого компонента/процесса. Даешь в одном компилируемом (по частям тоже!) проекте и многосервисный back end с развертыванием где-нибудь в K8s, и front end, и мобилку на разных OS!

    Ответить

    1. > переиспользование — не буду агитировать за советскую власть. Есть такое личное наблюдение — как только подключение компоненты становится проще, чем копирование/правка уже написанного кода, мозги переключаются на компоненты (лень двигатель прогресса).

      Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *