Снижаем когнитивную сложность при проектировании архитектуры приложения

[itGuevara]

Может быть есть где-то путеводитель (классификатор) по всем этим Х - ориентированным архитектурам? Наподобие этого, но более полный, например, включая функциональное и автоматное (А.Шалыто) программирование, событийно - / процессно - ориентированные архитектуры.

Также хотелось бы чтобы эта "процессно-ориентированная архитектура" была более строгим формализмом показана.

К термину "процессно-ориентированная архитектура" по смыслу ближе дальнейшее развитие BPMN до no code (из схемы процесса - готовое приложение), т.е. где будет повышена на порядок формализация workflow, добавлены docflow (его вообще нет) и другое - вплоть до встроенного в IDE редактора онтологий (типа protege). Условно: код программы будет выглядеть как граф знаний.

[t38c3j]

https://github.com/denyspoltorak/metapatterns

[antonb73]

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

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

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

[RieSet]

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

По полгода тратится, чтобы формулировки были максимально точными и без ошибок.

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

При такой сложности текста оперативка типичного разработчика кончается на третьей странице, у дизайнера — на первой. Руководитель разработки со всей ответственностью прочтет всё и, может, что-то запомнит.

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

[antonb73]

Здраствуйте. Спасибо, что уделили время. Надеюсь статья вам понравилась, или хотя бы принесла пользу, любую.

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

Лучше я отвечу просто - это не я такой, это жизнь такая :)

Прошу не злится и понять. Желаю вам всего наилучшего!

Если совсем упростить, то статья про:

1) Как проектировать приложения не перегружая мозг
2) Для этого понимаем, что наше приложение при запуске будет состоять из одного или более объектов ОС - процесса
3) Давайте при проектировании приложения сразу спроектируем наши процессы - они всё равно будут, так лучше подумать о них заранее
4) Чтобы лучше понимать друг друга будем говорить - архитектура приложения или архитектура кода
5) Описываю, какие аспекты оказывают ключевое влияние при проектировании архитектуры приложения и архитектуры кода



Как то так

[RieSet]

Вот тут и суть. С 15-летним опытом в IT я с трудом понимаю, что зашифровано в этих словах.

Я уверен, что в этих формулировках накопленный опыт, боль и желание сделать хорошо.

Но, например, разработчиков из поколения Z сложно заставить прочесть даже одну страницу инструкции по процессам. А сидеть и расшифровывать для них этот документ не стал бы.

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