Получи случайную криптовалюту за регистрацию!

Прямоугольники и стрелочки

Логотип телеграм канала @rect_arrow — Прямоугольники и стрелочки П
Логотип телеграм канала @rect_arrow — Прямоугольники и стрелочки
Адрес канала: @rect_arrow
Категории: Софт, приложения
Язык: Русский
Количество подписчиков: 134
Описание канала:

Заметки по Архитектуре программного обеспечения и около того.
Ведущий Максим Юнусов.

Рейтинги и Отзывы

2.00

3 отзыва

Оценить канал rect_arrow и оставить отзыв — могут только зарегестрированные пользователи. Все отзывы проходят модерацию.

5 звезд

0

4 звезд

0

3 звезд

1

2 звезд

1

1 звезд

1


Последние сообщения

2023-02-13 19:39:16 В продолжении темы. Много более осмысленный текст: Заменят ли боты технических писателей ? PERPLEXITY View Concise It is unlikely that bots will completely replace technical writers in the near future [2] [3] [5] . While AI and automation tools can be used…
56 viewsMaxim Yunusov, 16:39
Открыть/Комментировать
2023-02-13 16:21:12 О шарлатанах

Обсуждал с коллегами тему о самозванцах от архитектуры.
В чём разница между честным архитектором, использующим подходы эволюционной архитектуры, и шарлатаном тянущим в прод. сырые решения?
На первый взгляд их метод идентичен.

В моем понимании, "честный экспериментатор" работает "прозрачно", то есть уведомляет бизнес о возможных последствиях и о грядущих нескольких итераций переписывания.
Шарлатан напротив, заверяет стейкхолдеров в успехе и расписывает радужные перспективы:
"Продукт X решит все наши проблемы. Клянусь статьей на медиум".

Если у бизнеса нет денег на опытного архитектора, то почему бы не пойти итерационно (оно же гибко).

Если деньги есть, то не факт, что нанятый архитектор не окажется шарлатаном.
Увы.

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

Поиск специалиста с опытом - рулетка.
61 viewsMaxim Yunusov, edited  13:21
Открыть/Комментировать
2023-02-12 12:35:44 Джуниор архитектор

Обобщая сказанное выше:
1. Архитектор находит и оценивает риски/проблемы, возникающие при реализации решений.
2. Архитектор находит проблемы не только по условиям задачи (дано), но и во всём контексте задачи.

Существует только три способа обнаружения риска:
1. Быстрый, на основе опыта (специалист)
2. Дорогой, через "попробовать" (экспериментатор, эволюционная архитектура)
3. "Средний путь", через делегирование проблемы (вынос обсуждения на совещания)

Может ли быть полезен начинающий архитектор без опыта, для которого первый вариант не приемлем?

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

В плане оценки архитектурных решений популярны два метода:
1. Классика ATAM от SEI (со многими альтернативными вариантами)
2. Эволюционная архитектура от Нила Форда и к.

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

У меня есть веские основания сомневаться в полезности фитнес функций при выявлении рисков в контексте задачи.

То есть вывод простой:
Джуниор архитектор возможен, но только в режиме непрерывных совещаний по оценке рисков.

#ArchReview
64 viewsMaxim Yunusov, 09:35
Открыть/Комментировать
2023-02-12 02:21:29 Скоро боты заменят технических писателей. Компания «Яндекс» планирует заменить технических писателей на ботов. Об этом сообщает «Коммерсантъ». Предполагается, что боты будут писать тексты для внутренних проектов компании. Сейчас в компании работают 22 технических…
65 viewsMaxim Yunusov, 23:21
Открыть/Комментировать
2023-02-11 14:06:01 Ещё одна классификация архитекторов

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

1. Специалист (опыт)
2. Теоретик (паттерны)
3. Инженер (модель)
4. Кодер (прототип)
5. Экспериментатор (проба в проде)

Надо бы протестировать эту модель на собеседованиях )
64 viewsMaxim Yunusov, edited  11:06
Открыть/Комментировать
2023-02-11 13:59:33 О пользе эволюционной архитектуры

Предложив решение, архитектор анализирует возможные риски/проблемы от его внедрения
(где проблема это тот же риск, но который стрельнет наверняка)

Нил Форд описывает различные способы выявления риска:
1. Прототипирование
2. Моделирование (в том числе математическое)
3. Эволюционный подход (пустим в прод. и посмотрим, что получилось)

Кроме этого я бы добавил очевидное:
1. Выявление рисков на основании опыта (по аналогии с предыдущими проектами)
2. Выявление рисков на основании чужого опыта (изучая архитектурные концепты, в частности паттерны)

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

В плане скорости и стоимости принятия решения ранжировал бы так
1. Опыт
2. Паттерн
3. Модель
4. Прототип
5. Проба в проде

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

Единственно надежный вариант – попробовать.
Дорого и сердито.
59 viewsMaxim Yunusov, edited  10:59
Открыть/Комментировать
2023-02-11 13:32:30 Профессиональная деформация

Известно, что всякое решение плодит новые проблемы (Закон Мэрфи).
Отсюда одно из определений специалиста:
Специалист не только решает проблемы, но и знает где их стоит ожидать.

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

Пример:
Дано:
Сотни тысяч клиентов. Каждый порождает небольшой трафик из сообщений, которые необходимо складывать на диск.
Задача:
Обеспечить приемлемую задержку записи.
Решение:
Пишем сообщения пакетами, смешивая в одном пакете сообщения различных клиентов (например в Apache Pulsar)
Порожденные проблемы:
1. Очевидное (классическое противоречие скорость против объем):
Пакет нельзя удалить с диска пока там находится хотя бы одно сообщение. Один медленный клиент будет удерживать большие объемы от утилизации.
2. Не очевидное и понятное только тому, кто с этим уже работал, то есть специалисту:
Служба эксплуатации не сможет определить, какой объем держит каждый конкретный клиент. Как настроить лимиты?

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

И да, про деформацию.
Постоянно приходится объяснять – что я не пессимист. Это работа такая )
57 viewsMaxim Yunusov, edited  10:32
Открыть/Комментировать
2023-02-08 14:00:18 Опубликована запись последнего архитектурного митапа в IT-one


79 viewsMaxim Yunusov, edited  11:00
Открыть/Комментировать
2023-02-07 16:25:13 Архитектурное совещание
или работа по контексту

Как известно, архитектор принимает осмысленные эффективные решения не так как проектировщик.
Проектировщик (разработчик) видит условия задачи (дано) и выводит решение (ответ).
Архитектор кроме "дано" имеет еще и понимание контекста задачи.
В контекст входят интересы стейкхолдеров, ограничения, понимание рисков и др.

Эффективность работы архитектора пропорциональна его погруженности в контекст.

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

Что делать если погруженность в контекст не произошло, а решение требуется?

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

Первый вариант обычно дает крайне неоптимальное решение.
Второй вариант - затратен.

Господа менеджеры, хотите получать оптимальные, быстрые и дешевые ответы, держите на проекте бессменного выделенного архитектора и предоставляйте ему максимум информации.
87 viewsMaxim Yunusov, edited  13:25
Открыть/Комментировать
2023-02-04 14:52:19 Скоро боты заменят технических писателей.

Компания «Яндекс» планирует заменить технических писателей на ботов. Об этом сообщает «Коммерсантъ». Предполагается, что боты будут писать тексты для внутренних проектов компании. Сейчас в компании работают 22 технических писателя, которые пишут тексты для «Яндекса». Боты, в свою очередь, смогут писать для «Яндекс.Карт», «Яндекс.Музыки» и «Яндекс.Такси».
109 viewsMaxim Yunusov, 11:52
Открыть/Комментировать