lytdybr

ailev — 22.07.2022 Написал сегодня заметок по практике архитектуры на 6Кзнаков, и это уже не первый день такая писанина "в стол" ("исчезающие заметки", ага). Список вопросов у меня растёт и растёт, но я их ещё не в состоянии внятно сформулировать. Текущая догадка выглядит странно (но ей мало что противоречит, это по материалу трёх книжек и ряда статей): архитектура это такая полноценная разработка, в которой есть своя инженерия требований (выявляются критичные -ilities), полноценное проектирование (partitioning и выбор фреймворков, оформляется ADR, arhcitecture decision records), изготовление (в форме governance для разработчиков) и обоснование успешности (автоматизированное тестирование, только вместо юнит-тестов так называемые fit functions, показывающие расхождения с целевой архитектуорой) -- и всё это вальсом в режиме continuous architecture. Предмет тоже поменялся: с одной стороны, это "трудноменяемые решения" (когда что-то меняешь одно, и нужно переписать-переделать всё остальное), а с другой стороны ровно минимизация вот этой "трудноменяемости" (специфическое архитектурное свойство evolvability). Ещё такое впечатление, что там работают с SoS (system of systems), а разработчиков рассматривают как сидящих в отдельных проектах над отдельными системами (какими-нибудь микросервисами с их bounded context из DDD), а вот SoS представляет собой unbounded context и архитекторы как раз с ними работают. Родственники архитекторов тут не разработчики (которые больше "заклятые друзья", там же governance), а спецы по security, у которых тоже постоянный мониторинг уровня SoS и свои предметы интереса (которые и архитектору не чужды). Дальше развилка: "всем мы, разработчики, немного архитекторы" (роль архитектора) против "мы архитекторы, и держим руки по локоть в коде, а они разработчики, за ними глаз да глаз" (должность архитектора).

Основная дисциплина, как водится, принятие решений (trade-offs studies), это обычно часть рационального мышления (моделирование домена как объектов внимания, порождение альтернатив в развилках, прохождение развилок согласно теориям решений), разве что предмет решений -- это разбиение на части (partitioning) в определённом архитектурном стиле, и тут проблема -- это ж надо выносить за скобки и давать только "прикладную архитектурную рациональность", а не рациональность общего вида. И тут ещё выходим на проблему того, что такое стиль и эволюцию стилей -- это ж меметическая эволюция с "умными мутациями", и это тоже надо выносить за скобки! Там ещё есть и проблема терминологии (она за последний десяток лет существенно отошла от системноинженерной классики. И как дальше рассказывать -- переводить всё на классический язык хардвера как безмасштабный, или наоборот -- перетолковать "железную" классику на софтверный лад, ибо всё одно ж приползёт это в классику через несколько лет?). А ещё у софтверщиков вовсю обсуждается "архитектура плюс данные", а в железе и организациях не очень понятно, как это (хотя тоже понятно, что про память состояний, по линии "физика это информатика", но как именно это обсуждать безмасштабно?). И таких проблем у меня небольшой списочек, я потихоньку к нему привыкаю, ибо в голове всё это не очень уложилось пока. Кто хочет сам поразбираться, SoTA по софтверной архитектуре IMHO как-то описана в этих книжках: https://b-ok.cc/book/5215736/e9c0ed (старенькая уже, 2017 год, но в ней часть понятий более подробно разжёвывается), https://b-ok.cc/book/17354575/f8b84e (учебник, в котором даётся архитектура как предмет работы и описываются самые разные практики должности архитектора, включая как вести переговоры, как делать презентации и как продолжать учиться, когда уже стал архитектором), https://b-ok.cc/book/17498617/fcd235 (последняя, разбирает почему и как все перешли на микросервисы). Критиковать в этих книжках можно много чего (начиная от выбранной терминологии, типа fitness function -- это гарантированно не то, что вы думаете!), но предмет в его современном состоянии изложен: или вы размышляете о подобных проблемах част времени, и тогда вы software architect по роли хотя бы на то время, что размышляете, или не размышляете -- тогда не software architect (ну, или software architect в каком-то другом смысле, скажем смысле десятилетней давности, эпохи водопадных процессов).

Сложно это всё, голова пухнет. Пойду-ка я попляшу на свежем воздухе, летний вечер за окном.

UPDATE: обсуждение в чате блога -- https://t.me/ailev_blog_discussion/15723

Оставить комментарий

Популярные посты:

• Ранее
• Архив