lytdybr

Ещё 6Кзнаков заметок "в стол" и много разных мыслей. Как я понимаю, вся современная архитектура решает вопросы dependability, evolvability и transactionality с асинхронностью и оркестровкой. То есть все эти -ilities меняются и дополняются, ибо всё чётче становится понятно, что на свете бывает, и чего может хотеться (concerns, чем можно быть озабоченным). Но сегодня я сделал отклонение от архитектурного своего маршрута и вернулся к вопросу методологии: языкам паттернов, которые до сих пор используются в архитектурных штудиях, но сильно подзаглохли в самых разных других практиках. Пытался понять, что их заменило (вроде как процессные стандарты и BoK с практиками/процессами), и что было потеряно (обоснования: аргументация про "почему" в паттернах обязательна, а осталось в этих стандартах и BoK только "как" без аргументирования). В архитектуре это отсутствие аргументирования и рассуждений не прижилось, ибо "почему" в архитектуре важнее "как" из-за акцента на trade-offs, которые каждый раз заставляют что-то делать "не по стандарту", а "по рассуждению" или даже "по интуиции", или "впервые, ибо негде погуглить, стандартов на такое нету". В языках паттернов обоснования изначально есть, и даже есть попытки использования GSN для записи паттернов (конечно, где нужно формально что-то делать -- в security). Практики и паттерны оказываются сильно похожими на каком-то уровне гранулярности (впрочем, внутри паттернов тоже есть уровень подпаттернов -- "тактики", а вот надуровни -- это "практики каких-то domains, описанные как языки паттернов"). Ещё интересно, что среди forces 90% это -ilities. То есть языки паттернов хороши как раз для архитектурных решений, они описывают решения, а не паттерны действий. Надо с этим ещё повозиться: если это "как делать" и "паттерны это такие практики", то это надо в методологии давать (если давать! они ж вроде как вышли из моды, непонятно почему). А если практики это именно про архитектурные решения, то это в инженерии, а не методологии -- их и нужно давать в разделе про архитектуру. Но есть и паттерны для оргдизайна, и для работы с требованиями, это ж общая штука. В общем, разбираться. Пока просто пошучу: эти языки паттернов остались в архитектуре софта потому, что Кристофер Александер, который их предложил, сам был архитектором (строительным) и удачно решил проблему представления именно архитектурного знания. Точно угадал потребности архитекторов в представлении их опыта! Поскольку я помянул software architecture, то у меня в чате случилось обсуждение по этой самой архитектуре, программистов-то много. Я как-то десяток лет назад приехал на "семейную игру" (ОДИ, как раз недавно обсуждали) тусовки СМД-методологов. Темой игры была "онтология". Обсуждали какую-то ахинею. Я им предложил рассказать, чем заняты современные онтологи, какие у онтологии достижения (я ж член попечительского совета Ontolog Forum, хотя тогда был ещё не в попечительском совете, а просто активно участвовал и как-то ориентировался в предмете). Но нет, мне сказали, что это не так интересно, а вот интересно просто поговорить, кто уж что умеет, "посочинять новое". То есть отталкиваться не от SoTA и идти дальше, а просто породить по-кулибински новое (новое для них самих). ОК, сказал я. Не читавшие ни одного учебника по онтологии продвигают онтологию, занимаются исследованиями, вообще не понимая, что уже наисследовано и где там SoTA! И перестал ездить на эти тусовки, зряшное это дело. Обсуждаю теперь онтологию с онтологами, а не с людьми из СМД-тусовки. Вот мне кажется, что обсуждать архитектуру тоже нужно с действующими архитекторами, причём которые какие-то учебники по архитектуре таки читали, а не кулибинами-с-опытом, но без начитанности на эту тему (причём начитанности на английском языке). А просто так обсуждать архитектуру — зряшное это дело, вместо этого проще учебники почитать. По софтовой архитектуре я ссылки дал в прошлом посте, https://ailev.livejournal.com/1639178.html, там во втором абзаце три книги. Есть и другие варианты, не софтовые. Скажем, вот тут в сборнике статей по языкам паттернов обсуждаются в первой же статье паттерны для fault tolerance киберфизики, https://b-ok.cc/book/4980066/1bea22. To have fault tolerance for e.g. computer failures, we would need at least two computers – if one fails the other one can detect the error and try to correct it. Software faults on the other hand are typically development faults, which are harder to detect and correct than hardware faults. To have good coverage for software faults, diverse redundancy (e.g. N-version programming) is needed, but it has been criticized of being susceptible to common mode failures. Moreover, development costs for design diversity are often seen as prohibitive. Patterns in this paper present an alternative approach to fault tolerance, based on dividing the system into highly decoupled modules and implementing lightweight form of fault tolerance. То есть пока не знаком с литературой по архитектурной работе в софте -- нельзя обсуждать учебник архитектуры софта, а если не знаком с архитектурными соображениями по киберфизике, IoT и т.д., плюс организационными архитектурами, плюс архитектурами софта -- то нельзя обсуждать учебники по "архитектуре вообще" (ну, или главы по архитектуре в учебниках системной инженерии). А что делать, если очень хочется? У меня рецепт, как в этом всё разобраться чуть быстрее, чем по варианту "иметь двадцать лет опыта работы". Для начала можно прочесть мой учебник "Практическое системное мышление", затем "Методологию". Потом уже "Системную инженерию" (к моменту окончания чтения первых двух книг, а лучше бы прохождения курсов, ибо в курсах есть упражнения на моделирование, а в книгах упражнений и заданий нет) в "Системной инженерии" будет уже больше трёх глав. Это образует в голове какие-то полочки, куда можно будет складывать специальную литературу по конкретным инженерным практикам, которыми приходится заниматься -- и даст язык, который позволит обсуждать эти практики в окружении других практик. И уж тогда всё можно и даже нужно обсуждать! Пока же в чате на полтысячи человек появляются соображения типа "проходил мимо, подумал, вдруг кому из профи интересно, хотя я этим не занимался, но совет дам, оценку выскажу". Я понимаю, распирает. Но для такого есть study group, там как раз читают учебники и обсуждают прочитанное друг с другом. У нас есть куча чатов поддержки курсов, вот там такое можно обсуждать. Правда, обсуждать опять-таки -- после чтения учебников, а не до чтения учебников. Спасибо Юрию Геронимусу, указал на вышедшие для комментов некоторые набор глав SWEBoK v4, As of July 1, 2022, drafts of the following knowledge areas are now available for review: Software Requirements, Software Testing,  Software Engineering Management, Software Quality, and Software Engineering Professional Practice -- https://www.computer.org/volunteering/boards-and-committees/professional-educational-activities/software-engineering-committee/swebok-evolution. Вот, например, Software Requirements -- https://waseda.app.box.com/v/ieee-cs-swebok/file/978181130698. По традиции SWEBoK пишут классики, долго согласовывают, и ещё согласовывают с трудами INCOSE -- поэтому там олдовое изложение, существенно отличающееся от того, что я штудирую последнюю неделю. Прямо-таки пахнет водопадом, хотя я понимаю, что это "логическое время" и про DevOps все там разработчики знают. Вот вам ещё для размышления из Google Books Ngram Viewer (ссылка, и я специально давал множественное и единственное число -- одно указывает на разговор про "тип", другое про разговор об "экземпляре типа". Там такого интересного много, попробуйте всякие requirements engineering и прочее модное, ограничение времени там до 2019 года. Картинка кликабельна): Плясал сегодня в Сокольниках, там парковый формат -- музыка спокойная, танцы размеренные, вечер летний, мозг пустой, девочки красивые (и мальчики тоже красивые, если кому интересно). Танцевал в шортах, там таких половина была мальчиков и девочек, это вам не бальные танцы.