Суть архитектурного программирования в том, что архитектура (структура) программы явно присутствует в программной системе в течении всего жизненного цикла системы. Причем, присутствует как для разработчика (design time), включая модификацию, поддержку и сопровождение, так и во время исполнения.
Требования явной и встроенной архитектуры существенно отличает архитектурное программирование от других подходов. В привычных подходах к программированию, архитектура отделана от программного кода (как исходного, так и бинарного), что приводит к тому, что она (почти) всегда не актуальна.
Что это нам дает?
Первое: упрощение понимания, модификации и сопровождения. Например, активная разработка Сайткрафта на Вире остановилась в 2014 году, но время от времени приходится вносить изменения. Так как архитектура явная и встроенная, разработчику не надо помнить устройство программы и не надо тратить время на разбор того, в какое место кода нужно внести изменения.
Второе, упрощение отладки. Тут надо сказать про компоненты, так как упрощение отладки связано с компонентами. Архитектура задает основу (скелет), к которой подключаются компоненты. Пока нам достаточно определить только то, что у компоненты есть “оболочка”, отделяющая внутреннее устройство от окружения. Доступ извне компоненты к внутреннему содержанию ограничен или вообще отсутствует, взаимодействие только через оболочку.
Почему нельзя, в общем случае, сказать “что доступ к внутреннему содержанию отсутствует”? Потому что компонента может использовать общую память с другими компонентами. А может и не использовать и быть изолированной по памяти.
Упрощение отладки вытекает из:
- возможности отдельной отладки компоненты (unit testing).
- возможности замены компоненты на другую с тем же интерфейсом — на более простую, более отлаженную или что-то еще для отладки остальной системы.
- возможности отлаживать не всю программную систему, а включать отладку только для одной или нескольких компонент.
Последний способ я активно использовал в Вире: вместо включения отладки на уровне программы, обычно бывает достаточно (и гораздо удобнее) включить отладочный режим только для одной или нескольких компонент — объем информации для анализа становится регулируемым.
Раз мы начали говорить про компоненты, то, третье, это нужна унификация компонент — это и преимущество, и, одновременно, обязательное требование.
Как только мы унифицировали компоненты (точнее, унифицировали «оболочку» — взаимодействие компоненты с окружающим миром, мы получили еще очень важное четвертое преимущество, увеличение переиспользования.
Из переиспользования вытекает пятое преимущество: интенсификация программирования. Если у нас есть достаточно богатый набор компонент, то разрабатывать для новой программной системы нужно только то, что еще не разработано. Это преимущество очень явно проявилось в Вире, см. Технология разработки мультиплатформенных программ на основе явных схем программ.
И раз мы унифицировали взаимодействие, то, шестое, появляется возможность взаимодействия компонент, написанных на разных языках. Пусть и с ограничениями на совместимость языков (отсюда семейство языков).
Седьмое, если наша архитектура не ограничена одним устройством (а так и должно быть), то появляется возможность разработки программ с гибким распределением между устройствами и масштабированием. Масштабирование — то есть распределение части задачи на несколько “вычислителей” (компонент) перестает быть особенностью big data и data flow, а становится частью обычной разработки.
И если посмотреть на эти преимущества, так чтобы увидеть их целиком, то можно увидеть, что архитектурное программирование ведет к созданию единой экосистемы программирования, вместо тех плохо совместимых фрагментарных экосистем, которые есть сейчас.
И последнее, что мне кажется очень важно — переход на архитектурное программирование — это не революция, это структуризация или кристаллизация того, что уже есть.
Постоянная ссылка
Добрый день. Мне почему-то (пока не понял, почему) не очень нравится термин «архитектурное программирование», но я не могу не признать, что он схватывает проблематику и направление решения.
Мне созвучны очень многие тезисы из этого поста. Хотя есть и моменты, где я полон скепсиса. Давайте посмотрим по пунктам:
1. Присутствие в runtime — обеими руками «за», хотя понятно, что поборники производительности будут топить за zero cost abstractions. Но мы знаем, что этими zero cost abstractions вымощена дорога в тот ад, в котором мы сейчас находимся.
2. Упрощение понимания — однозначно! Сюда бы я добавил пункт 2.1 «а также упрощение обучения разработчиков качественному проектированию». По ценности это, конечно, целый отдельный пункт, но по механизму это, я верю, очень близко.
3. Упрощение отладки… мнэээ…. вот тут мне хочется добавить, что на мой взгляд, для упрощения отладки недостаточно просто иметь в коде схему компонент. На мой взгляд нужно переходить к т.н. «герметичным компонентам», гарантирующим, что все необходимые внешние зависимости 100% видны и поэтому могут быть заменены в процессе отладки. А иначе — какой-то дочерний в третьем поколении компонент «внезапно» пытается обратиться куда-то неведомо куда через интерфейс, который сочинил из ничего, просто заимпортировав какой-то модуль.
4. «Унификация компонент» или быть может протокола их общения с внешним миром. Я наверное не очень хорошо понял, что такое «оболочка», и зачем нужна эта «унификация», если это не тот отдельный пункт про разработку на разных языках.
5. И я крайне скептичен насчет увеличения переиспользования. Алексей говорил, что он видел этот эффект в Вире, но пока я тоже не увижу — не поверю. Я убежден, что повторная используемость принципиальна ограничена не свойствами языка, а просто разнообразием задач, растущим (экспоненциально?) вместе с ростом уровня «прикладности». В неприкладной инфраструктуре переиспольтзование возможно, т.к. повторно решаютсчя одни и те же задачи, в прикладной области переиспользование крайне затруднено и именно поэтому почти не встречается, язык тут не при чем. Очень хочется это увидеть на прототипах, если я тут не прав.
6. Совершенно согласен с идеями про кросс-языковую разработку и про разработку единого «проекта» шире одного целевого исполняемого компонента/процесса. Даешь в одном компилируемом (по частям тоже!) проекте и многосервисный back end с развертыванием где-нибудь в K8s, и front end, и мобилку на разных OS!
Постоянная ссылка
> переиспользование — не буду агитировать за советскую власть. Есть такое личное наблюдение — как только подключение компоненты становится проще, чем копирование/правка уже написанного кода, мозги переключаются на компоненты (лень двигатель прогресса).