Оценка трудозатрат
Оценка трудозатрат - одна из сложнейших задач планирования.
Существует множество техник оценки и многие из них формальные,
то есть позволяют на базе имеющихся сведений рассчитать оценку.
Популярные формальные техники:
- PERT
E = (O+4M+P)/6 (O - Optimistic, P- Pessimistic, M - Most Likely)
- FP
Ключевыми компонентами, которые рассматриваются здесь, являются внешний ввод, внешний вывод, внешние запросы, внутренние логические файлы и файлы внешнего интерфейса/
- UCP
UCP = TCF * ECF * UUCP * PF (Коэффициент технической сложности (TCF), Коэффициент сложности среды (ECF), нескорректированные точки варианта использования (UUCP), коэффициент производительности (PF))
Эти техники хорошо проработаны и описаны. Если вы решили формализовать процесс, вряд ли стоит изобретать велосипед. Любые "кубики" будут хуже.
Другой вопрос: а стоит ли вообще формализовать процесс?
Зайдем с другой стороны.
От чего зависит время разработки?
1. Анализ, т.е. условно понимание куда воткнуть код (зависит от чистоты/ясности системы)
2. Неизбежный рефакторинг, подгонка системы под новый функционал (зависит от накопленного тех. долга)
3. Собственно кодирование функционала (зависит от технической сложности, может быть оценено формально)
4. Подстройка под существующие решения/библиотеки (зависит от вязкости)
5. Исправление зависимостей (зависит от связанности/коннасценции)
6. Опциональный рефакторинг (можем оставить как долг на следующую итерацию)
7. Тестирование (зависит от тестируемости)
Таким образом, методы оценки сложности дадут оценку трудозатрат только для чистого кодинга.
Большую часть времени занимают другие активности, никоем образом не связанные с требованиями и сложностью.
Иными словами, формальные методы дадут хорошую оценку в том случае, если мы пишем код с нуля на еще не существующей системе, без использования сторонних библиотек.
В большинстве случаев понимание требуемых накладных расходов есть только у разработчика (максимум двух), знающих модифицируемый участок.
И как вывод - единственный надежный способ оценки выглядит так:
1. разбиваем задачу на части (WBS), до атомов, умещающихся в скоупе отдельного разработчика
2. получаем экспертную оценку (можно три точки)
3. умножаем на Pi ) (ну или PERT для солидности)
Всё остальное, увы, профанация
#оценка
Оценка трудозатрат - одна из сложнейших задач планирования.
Существует множество техник оценки и многие из них формальные,
то есть позволяют на базе имеющихся сведений рассчитать оценку.
Популярные формальные техники:
- PERT
E = (O+4M+P)/6 (O - Optimistic, P- Pessimistic, M - Most Likely)
- FP
Ключевыми компонентами, которые рассматриваются здесь, являются внешний ввод, внешний вывод, внешние запросы, внутренние логические файлы и файлы внешнего интерфейса/
- UCP
UCP = TCF * ECF * UUCP * PF (Коэффициент технической сложности (TCF), Коэффициент сложности среды (ECF), нескорректированные точки варианта использования (UUCP), коэффициент производительности (PF))
Эти техники хорошо проработаны и описаны. Если вы решили формализовать процесс, вряд ли стоит изобретать велосипед. Любые "кубики" будут хуже.
Другой вопрос: а стоит ли вообще формализовать процесс?
Зайдем с другой стороны.
От чего зависит время разработки?
1. Анализ, т.е. условно понимание куда воткнуть код (зависит от чистоты/ясности системы)
2. Неизбежный рефакторинг, подгонка системы под новый функционал (зависит от накопленного тех. долга)
3. Собственно кодирование функционала (зависит от технической сложности, может быть оценено формально)
4. Подстройка под существующие решения/библиотеки (зависит от вязкости)
5. Исправление зависимостей (зависит от связанности/коннасценции)
6. Опциональный рефакторинг (можем оставить как долг на следующую итерацию)
7. Тестирование (зависит от тестируемости)
Таким образом, методы оценки сложности дадут оценку трудозатрат только для чистого кодинга.
Большую часть времени занимают другие активности, никоем образом не связанные с требованиями и сложностью.
Иными словами, формальные методы дадут хорошую оценку в том случае, если мы пишем код с нуля на еще не существующей системе, без использования сторонних библиотек.
В большинстве случаев понимание требуемых накладных расходов есть только у разработчика (максимум двух), знающих модифицируемый участок.
И как вывод - единственный надежный способ оценки выглядит так:
1. разбиваем задачу на части (WBS), до атомов, умещающихся в скоупе отдельного разработчика
2. получаем экспертную оценку (можно три точки)
3. умножаем на Pi ) (ну или PERT для солидности)
Всё остальное, увы, профанация
#оценка
👍4
Прямоугольники и стрелочки
The Essential Guide To Queueing Theory.pdf
scalability.pdf
2.3 MB
Еще одна книга от Baron Schwartz.
Practical Scalability Analysis With The
Universal Scalability Law (Масштабируемость)
Короткая и очень полезная)
#Книги #Производительность #Масштабируемость
Practical Scalability Analysis With The
Universal Scalability Law (Масштабируемость)
Короткая и очень полезная)
#Книги #Производительность #Масштабируемость
🔥4
Архитектурный_стиль_Дерево_принятия_решения.png
840.8 KB
Выбор архитектурного стиля
В пятницу описывал коллегам метод выбора архитектурного стиля на основе атрибутов качества.
Этот подход проповедуют многие. В частности:
- SEI со своим ABAS (Attribute-Based Architectural Styles, https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=13505)
- Нил Фор в новой модной книжке "Фундаментальный подход к программной архитектуре".
Поймал себя на мысли, что сам я этим методом не пользуюсь. Да и результат может получиться несколько странным.
Решил накидать "дерево принятия решений по стилю". Получился граф )
Очень драфтово, поэтому
буду рад любым комментариям.
#АрхитектурныйСтиль
В пятницу описывал коллегам метод выбора архитектурного стиля на основе атрибутов качества.
Этот подход проповедуют многие. В частности:
- SEI со своим ABAS (Attribute-Based Architectural Styles, https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=13505)
- Нил Фор в новой модной книжке "Фундаментальный подход к программной архитектуре".
Поймал себя на мысли, что сам я этим методом не пользуюсь. Да и результат может получиться несколько странным.
Решил накидать "дерево принятия решений по стилю". Получился граф )
Очень драфтово, поэтому
буду рад любым комментариям.
#АрхитектурныйСтиль
👍4🔥4
Подходы к принятию архитектурного решения:
1. Technology first
Этот подход предполагает выбор технологического стека без определения основных архитектурных стилей и паттернов, а зачастую и без постановки задачи.
Стили и паттерны в этом случае диктуются выбранными технологиями (т. н. референсная архитектура)
Основные паттерны:
1. Выбираем технологию, так как она хорошо знакома и неплохо зарекомендовала себя на предыдущих проектах.
2. Подыскиваем альтернативную технологию в замен хорошо известной, не оправдавшей ожидания на предыдущих проектах.
3. Пробуем альтернативную технологию распиаренную вендором/комьюнити.
Преимущества:
1. Быстрое решение. Экономит время архитектора.
2. Используем известные нам/команде/службе эксплуатации технологии.
Применимость:
Задача хорошо известная архитектору.
Проблемы:
Проекты при внешней схожести могут быть весьма специфичны. Общее решение в этом случае окажется крайне не эффективным.
Хорошо владея молотком, заколачиваем винты и шурупы.
Смягчать риски можно, применяя прототипирование.
Особенности:
При этом подходе архитектор ценится в основном за понимание используемых технологий.
Архитектор должен расширять список хорошо известных ему тем.
В проект будут втягиваться новые технологии "под изучение", разумеется, за деньги заказчика.
#ПринятиеРешения
1. Technology first
Этот подход предполагает выбор технологического стека без определения основных архитектурных стилей и паттернов, а зачастую и без постановки задачи.
Стили и паттерны в этом случае диктуются выбранными технологиями (т. н. референсная архитектура)
Основные паттерны:
1. Выбираем технологию, так как она хорошо знакома и неплохо зарекомендовала себя на предыдущих проектах.
2. Подыскиваем альтернативную технологию в замен хорошо известной, не оправдавшей ожидания на предыдущих проектах.
3. Пробуем альтернативную технологию распиаренную вендором/комьюнити.
Преимущества:
1. Быстрое решение. Экономит время архитектора.
2. Используем известные нам/команде/службе эксплуатации технологии.
Применимость:
Задача хорошо известная архитектору.
Проблемы:
Проекты при внешней схожести могут быть весьма специфичны. Общее решение в этом случае окажется крайне не эффективным.
Хорошо владея молотком, заколачиваем винты и шурупы.
Смягчать риски можно, применяя прототипирование.
Особенности:
При этом подходе архитектор ценится в основном за понимание используемых технологий.
Архитектор должен расширять список хорошо известных ему тем.
В проект будут втягиваться новые технологии "под изучение", разумеется, за деньги заказчика.
#ПринятиеРешения
👍4
Подходы к принятию архитектурного решения:
2. Очевидное решение
Ставим архитектурную задачу и сразу же определяем очевидное, интуитивно понятное решение.
Зачастую и сама задача в этом случае выглядит как решение.
Например:
1. Кешируем операции чтения из БД.
2. Все микросервисы должны масштабироваться.
Паттерн:
Вопрос-решение
Преимущества:
1. Быстрое решение. Экономит время архитектора.
2. Интуитивно понятное решение не требует обоснования и объяснения.
Проблемы:
"Очевидно" не значит "верно".
Кластер PostgreSQL не всегда увеличивает доступность.
Кэш может увеличивать задержку.
Многопоточность может существенно снизить пропускную способность.
И. т. д.
Любая, даже самая сложная, проблема обязательно имеет простое, легкое для понимания, неправильное решение (Закон Мерфи)
Особенности:
Так как очевидное решение часто проходит как задача, в последствии это решение трудно переиграть.
#ПринятиеРешения
2. Очевидное решение
Ставим архитектурную задачу и сразу же определяем очевидное, интуитивно понятное решение.
Зачастую и сама задача в этом случае выглядит как решение.
Например:
1. Кешируем операции чтения из БД.
2. Все микросервисы должны масштабироваться.
Паттерн:
Вопрос-решение
Преимущества:
1. Быстрое решение. Экономит время архитектора.
2. Интуитивно понятное решение не требует обоснования и объяснения.
Проблемы:
"Очевидно" не значит "верно".
Кластер PostgreSQL не всегда увеличивает доступность.
Кэш может увеличивать задержку.
Многопоточность может существенно снизить пропускную способность.
И. т. д.
Любая, даже самая сложная, проблема обязательно имеет простое, легкое для понимания, неправильное решение (Закон Мерфи)
Особенности:
Так как очевидное решение часто проходит как задача, в последствии это решение трудно переиграть.
#ПринятиеРешения
👍5
Подходы к принятию архитектурного решения:
3. Формальный подход
В этом случае фиксируем архитектурно значимые требования (драйвера) и используем определённый алгоритм для выбора решения.
Примеры:
1. ABAS (Attribute-Based Architectural Styles от SEI) - алгоритм выбора архитектурного стиля на базе атрибутов качества.
2. ADD (Attribute-Driven Design от SEI) - алгоритм выбора решения на базе атрибутов качества.
3. Деревья принятия решений различных авторов (Нил Форд, Мартин Фаулер и др.).
4. LAAM (Lean Architecture Analysis Method) и аналогичные - алгоритмы с применением матрицы принятия решений
5. Матрица противоречий ТРИЗ (переработанная под архитектуру).
Преимущества:
1. Быстрое решение.
2. Может быть применено архитектором не имеющим опыта по теме.
Применимость:
Хорошо работает при формировании короткого списка решений. Легко определить неподходящие варианты.
Проблемы:
Выбор оптимального варианта затруднен, так как формальный подход не учитывает всего многообразия вводных и не базируется на контексте принятия решения.
Особенности:
Результат применения формального подхода сильно зависит от применяющего подход архитектора. За архитектором выбор вводных и трактовка результата.
Работая над решением задачи, всегда полезно знать ответ заранее (Закон точности)
#ПринятиеРешения
3. Формальный подход
В этом случае фиксируем архитектурно значимые требования (драйвера) и используем определённый алгоритм для выбора решения.
Примеры:
1. ABAS (Attribute-Based Architectural Styles от SEI) - алгоритм выбора архитектурного стиля на базе атрибутов качества.
2. ADD (Attribute-Driven Design от SEI) - алгоритм выбора решения на базе атрибутов качества.
3. Деревья принятия решений различных авторов (Нил Форд, Мартин Фаулер и др.).
4. LAAM (Lean Architecture Analysis Method) и аналогичные - алгоритмы с применением матрицы принятия решений
5. Матрица противоречий ТРИЗ (переработанная под архитектуру).
Преимущества:
1. Быстрое решение.
2. Может быть применено архитектором не имеющим опыта по теме.
Применимость:
Хорошо работает при формировании короткого списка решений. Легко определить неподходящие варианты.
Проблемы:
Выбор оптимального варианта затруднен, так как формальный подход не учитывает всего многообразия вводных и не базируется на контексте принятия решения.
Особенности:
Результат применения формального подхода сильно зависит от применяющего подход архитектора. За архитектором выбор вводных и трактовка результата.
Работая над решением задачи, всегда полезно знать ответ заранее (Закон точности)
#ПринятиеРешения
Подходы к принятию архитектурного решения:
4. Метод перебора
Этот подход известен также под именем морфологический метод.
Шаги:
1. Формируем список всех возможных/известных вариантов решения (фантограммы).
2. Определяем критерии пригодности (фитнес-функции).
3. Верифицируем варианты и отбрасываем нежизнеспособные.
Преимущества:
1. Позволяет выйти на оптимальное решение.
2. Продолжительная, но простая (механическая) работа, не требующая высокой квалификации.
Применимость:
Работает при возможности быстрой верификации. Например при верификации моделированием, без вывода решения в код.
Проблемы:
1. Требуется наличие списка вариантов (каталоги архитектурных концептов)
2. Затратен, так как требуется верификация большого количества вариантов.
(Обезьяна за печатной машинкой)
Упрощенный вариант:
Верифицируем варианты решения последовательно до нахождения первого подходящего.
В этом случае затраты существенно ниже, но и оптимальность результата не гарантирована.
Особенности:
Если верифицируется готовое решение (воплощенное в код), то должна быть возможность переписать решение за одну итерацию (эволюционная архитектура).
#ПринятиеРешения
4. Метод перебора
Этот подход известен также под именем морфологический метод.
Шаги:
1. Формируем список всех возможных/известных вариантов решения (фантограммы).
2. Определяем критерии пригодности (фитнес-функции).
3. Верифицируем варианты и отбрасываем нежизнеспособные.
Преимущества:
1. Позволяет выйти на оптимальное решение.
2. Продолжительная, но простая (механическая) работа, не требующая высокой квалификации.
Применимость:
Работает при возможности быстрой верификации. Например при верификации моделированием, без вывода решения в код.
Проблемы:
1. Требуется наличие списка вариантов (каталоги архитектурных концептов)
2. Затратен, так как требуется верификация большого количества вариантов.
(Обезьяна за печатной машинкой)
Упрощенный вариант:
Верифицируем варианты решения последовательно до нахождения первого подходящего.
В этом случае затраты существенно ниже, но и оптимальность результата не гарантирована.
Особенности:
Если верифицируется готовое решение (воплощенное в код), то должна быть возможность переписать решение за одну итерацию (эволюционная архитектура).
#ПринятиеРешения
О терминологии в IT
Забавно вновь и вновь наблюдать споры вокруг слов. Что такое архитектор, что такое микросервисы, что такое ddd и так далее до бесконца.
Как будто много веков назад для разрешения подобных споров люди не придумали научную методологию и механизм определений.
Можно что угодно понимать под словом "архитектор" и отстаивать свое мнение с пеной у рта.
А можно прочитать, что в этот термин вкладывал автор концепции, и как эта концепция развивалась во времени.
Отсутствие явных и точных определений известных каждому серьезно сдерживает развитие сферы IT.
Забавно вновь и вновь наблюдать споры вокруг слов. Что такое архитектор, что такое микросервисы, что такое ddd и так далее до бесконца.
Как будто много веков назад для разрешения подобных споров люди не придумали научную методологию и механизм определений.
Можно что угодно понимать под словом "архитектор" и отстаивать свое мнение с пеной у рта.
А можно прочитать, что в этот термин вкладывал автор концепции, и как эта концепция развивалась во времени.
Отсутствие явных и точных определений известных каждому серьезно сдерживает развитие сферы IT.
👍5
Потребность в архитекторе
Перефразируя Черчилля:
Необходимость в архитекторе обусловлена тем, что предпочитает менеджер: платить или расплачиваться.
Перефразируя Черчилля:
Необходимость в архитекторе обусловлена тем, что предпочитает менеджер: платить или расплачиваться.
👍6🔥3🤔2😁1
ADR и "перспективы"
ADR как способ фиксации архитектурных решений на пике популярности.
Однако, есть запросы не покрываемые данным подходом.
Например, требуется определить какие решения предприняты для обеспечения отказоустойчивости.
"Старые" методологии (например Розански и Вудс) предлагали "перспективы" (см. https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/0321112296).
Перспектива это раздел описания посвященный одному качеству (например производительности).
Я хотел бы объединить эти два подхода.
Для этого нужно иметь возможность группировать архитектурные решения (ADR) по качествам (а возможно и по бизнес функциям).
Задача выглядит простой пока не попытаешься реализовать это практически:
1. Гит не дает тегать общим тегом несколько коммитов
2. Конфлюенс плохо демонстрирует динамику и плохо связан с этапами работы в гите.
3. Хочется использовать obsidian с тегами обратными ссылками и привязкой к git. Но тут проблема - инструмент новый и уговаривать на переезд придется долго )
Коллеги, а у вас есть опыт фасетной группировки арх. решений?
#Документация
ADR как способ фиксации архитектурных решений на пике популярности.
Однако, есть запросы не покрываемые данным подходом.
Например, требуется определить какие решения предприняты для обеспечения отказоустойчивости.
"Старые" методологии (например Розански и Вудс) предлагали "перспективы" (см. https://www.amazon.com/Software-Systems-Architecture-Stakeholders-Perspectives/dp/0321112296).
Перспектива это раздел описания посвященный одному качеству (например производительности).
Я хотел бы объединить эти два подхода.
Для этого нужно иметь возможность группировать архитектурные решения (ADR) по качествам (а возможно и по бизнес функциям).
Задача выглядит простой пока не попытаешься реализовать это практически:
1. Гит не дает тегать общим тегом несколько коммитов
2. Конфлюенс плохо демонстрирует динамику и плохо связан с этапами работы в гите.
3. Хочется использовать obsidian с тегами обратными ссылками и привязкой к git. Но тут проблема - инструмент новый и уговаривать на переезд придется долго )
Коллеги, а у вас есть опыт фасетной группировки арх. решений?
#Документация
Закономерности развития ИТ систем
В очередной раз убеждаюсь в правоте герметики - "То, что находится внизу, соответствует тому, что пребывает вверху; и то, что пребывает вверху, соответствует тому, что находится внизу".
Сервисные архитектуры почти идеально повторяют решения выработанные адептами ООП.
Единая цель "снижение когнитивной нагрузки на разработчика" приводит к одним и тем же структурам.
Приведу несколько примеров:
1. Независимая разработка потребовала введение объектов на уровне монолита и сервисов в распределенной системе.
2. Устраняя связанность по данным получили инкапсуляцию в ООП и автономность с собственными БД в сервисах.
3. Усиливая автономность ввели понятие строгих контрактов в ООП и аналогично на сервисах (API и т. п.)
4. Модули закрыли фасадами. Сервисы закрыли шлюзами.
5. Разделяя бизнес логику и сценарии использования в ООП ввели слой приложения и сервисы приложения. В сервисных архитектурах появились оркестраторы.
6. Минимизация связанностей привела к понятию "домен" в который объединяется множество объектов. Тот же самый механизм использован при объединении сервисов (см. например DOMA от Uber)
и так далее и тому подобное.
ИМХО, глядя на эти соответствия можно не только находить общие закономерности в развитии архитектурных стилей, но и предсказывать новые решения.
В очередной раз убеждаюсь в правоте герметики - "То, что находится внизу, соответствует тому, что пребывает вверху; и то, что пребывает вверху, соответствует тому, что находится внизу".
Сервисные архитектуры почти идеально повторяют решения выработанные адептами ООП.
Единая цель "снижение когнитивной нагрузки на разработчика" приводит к одним и тем же структурам.
Приведу несколько примеров:
1. Независимая разработка потребовала введение объектов на уровне монолита и сервисов в распределенной системе.
2. Устраняя связанность по данным получили инкапсуляцию в ООП и автономность с собственными БД в сервисах.
3. Усиливая автономность ввели понятие строгих контрактов в ООП и аналогично на сервисах (API и т. п.)
4. Модули закрыли фасадами. Сервисы закрыли шлюзами.
5. Разделяя бизнес логику и сценарии использования в ООП ввели слой приложения и сервисы приложения. В сервисных архитектурах появились оркестраторы.
6. Минимизация связанностей привела к понятию "домен" в который объединяется множество объектов. Тот же самый механизм использован при объединении сервисов (см. например DOMA от Uber)
и так далее и тому подобное.
ИМХО, глядя на эти соответствия можно не только находить общие закономерности в развитии архитектурных стилей, но и предсказывать новые решения.
👍1
Структура архитектурной документации
В любом арх. процессе присутствуют следующие группы арх. артифактов:
1. Сырье - необработанное нечто на входе.
2. Требования, гипотезы или как назовете - нечто после анализа и структурирования.
3. Решения с обоснованиями
4. Модель (точнее их множество)
5. Представления, rfc, презентации - выжимки для коммуникаций.
- документирование всего этого хозяйства целиком/частями опция и выбор зависит от массы факторов
Сырье кидаю в обсидиан в папку raw и мечу тегами под поиск.
Требования беру у аналитиков и докидываю свои драйвера - текст с трассировкой на jira
Решения - madr
Модель веду в конфлюенсе (в текущем проекте), но предпочел бы archi
Представления размазаны по конфлюенсу (rfc) и разным документам (в основном powerpoint)
А хочется единого пространства и удобной трассировки (
#Документирование
В любом арх. процессе присутствуют следующие группы арх. артифактов:
1. Сырье - необработанное нечто на входе.
2. Требования, гипотезы или как назовете - нечто после анализа и структурирования.
3. Решения с обоснованиями
4. Модель (точнее их множество)
5. Представления, rfc, презентации - выжимки для коммуникаций.
- документирование всего этого хозяйства целиком/частями опция и выбор зависит от массы факторов
Сырье кидаю в обсидиан в папку raw и мечу тегами под поиск.
Требования беру у аналитиков и докидываю свои драйвера - текст с трассировкой на jira
Решения - madr
Модель веду в конфлюенсе (в текущем проекте), но предпочел бы archi
Представления размазаны по конфлюенсу (rfc) и разным документам (в основном powerpoint)
А хочется единого пространства и удобной трассировки (
#Документирование
👍5
http://microservices.io/i/SuccessTriangleWithBooks.png
Красивая картинка у К. Ричардсона.
"Ignoring those two elements is a common anti-pattern of microservice adoption."
Красивая картинка у К. Ричардсона.
"Ignoring those two elements is a common anti-pattern of microservice adoption."
👍3
Нефункциональные требования и ограничения (Constraints)
Для того чтобы принять оптимальное архитектурное решение необходимо обработать большой массив входящих данных (т.н. архитектурных драйверов или мотивов).
Часть этих данных структурирована, часть нет (т.н. контекст проектирования).
В одном из арх. каналов возник спор по поводу структурированных данных.
Было предложено всех их обобщить термином "требования".
В этом вопросе я придерживаюсь классического подхода - разделяю требования и ограничения.
Зачем? Казалось бы, и то и другое приходит от стейкхолдеров и формирует архитектуру. В чём разница?
Мои резоны:
1. Среди всех стейкхолдеров я выделяю потребителя. Того для кого готовится продукт.
Требования прочих заинтересованных лиц ограничивают развитие продукта, а зачастую и ухудшают его потребительские качества.
Пользователю нужна функциональность, производительность, надежность и безопасность . Это требования.
Служба эксплуатации ограничивает список технологий. Смежники диктуют интерфейсы и протоколы. Бизнес ограничивает время/деньги. Команда предоставляет ограниченный набор скиллов. Это ограничения.
2. Мне нравится подход, при котором я сперва проектирую идеальную архитектуру, которая бы на все сто удовлетворила пользователя, а потом начинаю "портить" ее имеющимися ограничениями.
3. В моем понимании требования непреложны (атрибутивны), а ограничения оспариваемы (акцидентны) и ради хорошего продукта я могу преодолевать ограничения в архитектуре надсистемы.
#АрхитектурныеДрайвера
Для того чтобы принять оптимальное архитектурное решение необходимо обработать большой массив входящих данных (т.н. архитектурных драйверов или мотивов).
Часть этих данных структурирована, часть нет (т.н. контекст проектирования).
В одном из арх. каналов возник спор по поводу структурированных данных.
Было предложено всех их обобщить термином "требования".
В этом вопросе я придерживаюсь классического подхода - разделяю требования и ограничения.
Зачем? Казалось бы, и то и другое приходит от стейкхолдеров и формирует архитектуру. В чём разница?
Мои резоны:
1. Среди всех стейкхолдеров я выделяю потребителя. Того для кого готовится продукт.
Требования прочих заинтересованных лиц ограничивают развитие продукта, а зачастую и ухудшают его потребительские качества.
Пользователю нужна функциональность, производительность, надежность и безопасность . Это требования.
Служба эксплуатации ограничивает список технологий. Смежники диктуют интерфейсы и протоколы. Бизнес ограничивает время/деньги. Команда предоставляет ограниченный набор скиллов. Это ограничения.
2. Мне нравится подход, при котором я сперва проектирую идеальную архитектуру, которая бы на все сто удовлетворила пользователя, а потом начинаю "портить" ее имеющимися ограничениями.
3. В моем понимании требования непреложны (атрибутивны), а ограничения оспариваемы (акцидентны) и ради хорошего продукта я могу преодолевать ограничения в архитектуре надсистемы.
#АрхитектурныеДрайвера
👍5🔥2
Architect - Share.zip
10.7 MB
База знаний в обсидиане
Затемплайтил свою архитектурную базу знаний со структурой, темой и настроенными плагинами.
Теперь для включения в новый проект достаточно распаковать и запустить.
Положу здесь. Возможно, еще кому-нибудь пригодится.
#Документирование
Затемплайтил свою архитектурную базу знаний со структурой, темой и настроенными плагинами.
Теперь для включения в новый проект достаточно распаковать и запустить.
Положу здесь. Возможно, еще кому-нибудь пригодится.
#Документирование
🔥8👍3
Анти-паттерн "42"
Всегда восхищался способностью арх. комов и некоторых продвинутых архитекторов оценить архитектуру по её описанию.
Лично мне трудно оценить правильность ответа на «главный вопрос Жизни, Вселенной и Всего Остального», без понимания вопроса.
При этом под "пониманием вопроса" я подразумеваю не только требования.
В случае архитектуры это еще и глубокое погружение в контекст.
#Антипаттерны #Сарказм
Всегда восхищался способностью арх. комов и некоторых продвинутых архитекторов оценить архитектуру по её описанию.
Лично мне трудно оценить правильность ответа на «главный вопрос Жизни, Вселенной и Всего Остального», без понимания вопроса.
При этом под "пониманием вопроса" я подразумеваю не только требования.
В случае архитектуры это еще и глубокое погружение в контекст.
#Антипаттерны #Сарказм
😁10
Транзакционность
Опять попал на обсуждение вопроса о том, что есть САГА: ACID, ACD или даже CID.
Полная путаница в терминологии приводит к бесконечным холиварам.
Хотел бы здесь зафиксировать своё понимание транзакционности.
1. Транзакция - минимальная логически осмысленная операция.
2. Выполнение транзакции не должно ломать целостность или когерентность данных.
Это свойство называется согласованностью (consistency) в широком смысле слова.
Что бы не путаться я называю его транзакционностью )
То есть транзакция должна быть транзакционной ))
3. Угрозы целостности и когерентности:
- одна из операций транзакции не может быть завершена (по бизнесу)
Решается атомарностью (Atomicity), которую Мартин Клеппман называет abortability.
- операции на разных ресурсах могут выполняться в произвольном порядке
Решается согласованностью в узком (ACID) смысле
- операции от разных клиентов могут мешать друг другу
Решается изолированностью (Isolation)
- операции могут завершится неудачей в следствии сбоя, в частности по таймауту
Решается устойчивостью (Durability)
4. Соответственно, хорошая транзакция должна поддерживать ACID.
Но при этом всегда можно пойти на компромиссы.
План по поддержке транзакционности примерно такой:
1. Определить список основных операций.
2. Определить требования по производительности, надежности и целостности/когерентности
3. Определить требуемый уровень согласованности (по NFR).
4. Определить механизм поддержки согласованности. (централизованный/децентрализованный, синхронный/асинхронный).
5. Определить механизм поддержки атомарности (кто и как делает откаты).
6. Определить требуемый уровень изолированности (по списку операций).
7. Определить механизм устойчивости (например SAGA vs TCC)
8. Реализовать )
#Транзакционность
Опять попал на обсуждение вопроса о том, что есть САГА: ACID, ACD или даже CID.
Полная путаница в терминологии приводит к бесконечным холиварам.
Хотел бы здесь зафиксировать своё понимание транзакционности.
1. Транзакция - минимальная логически осмысленная операция.
2. Выполнение транзакции не должно ломать целостность или когерентность данных.
Это свойство называется согласованностью (consistency) в широком смысле слова.
Что бы не путаться я называю его транзакционностью )
То есть транзакция должна быть транзакционной ))
3. Угрозы целостности и когерентности:
- одна из операций транзакции не может быть завершена (по бизнесу)
Решается атомарностью (Atomicity), которую Мартин Клеппман называет abortability.
- операции на разных ресурсах могут выполняться в произвольном порядке
Решается согласованностью в узком (ACID) смысле
- операции от разных клиентов могут мешать друг другу
Решается изолированностью (Isolation)
- операции могут завершится неудачей в следствии сбоя, в частности по таймауту
Решается устойчивостью (Durability)
4. Соответственно, хорошая транзакция должна поддерживать ACID.
Но при этом всегда можно пойти на компромиссы.
План по поддержке транзакционности примерно такой:
1. Определить список основных операций.
2. Определить требования по производительности, надежности и целостности/когерентности
3. Определить требуемый уровень согласованности (по NFR).
4. Определить механизм поддержки согласованности. (централизованный/децентрализованный, синхронный/асинхронный).
5. Определить механизм поддержки атомарности (кто и как делает откаты).
6. Определить требуемый уровень изолированности (по списку операций).
7. Определить механизм устойчивости (например SAGA vs TCC)
8. Реализовать )
#Транзакционность
👍1
Сага
Продолжая предыдущий пост, хотелось бы ответить на вопрос, что есть Сага.
Ad ovo:
1. В распределенной среде долгоживущие транзакции могут обеспечить транзакционность (ACID) на блокировках. Работает это очень ненадёжно и медленно.
В 1986 году Hector Garcaa-Molrna, Kenneth Salem предложили разбить транзакцию на несколько мелких локальных и назвали это сагой.
С их точки зрения сага была не атомарна, то есть CID.
Так как атомарностью они назвали принцип "Всё или ничего" (БД-шное понимание атомарности).
2. Мартин Клеппман переопределил атомарность как abortability. То есть как возможность прервать и откатить транзакцию в случае отката одной из операций. В этом понимании Сага вполне атомарна (ACID).
3. Однако, в процессе проведения Саги часть транзакций может быть закомичена до общей фиксации. То есть конкуренты увидят результаты незавершенной транзакции. Крис Ричардсон считает, что это явное нарушение изоляции. То есть Сага - ACD.
4. Криса ругают и доказывают, что изоляцию для Саги построить легко. Например, на блокировках. С моей т.з. сага с блокировками противоречит идее создания саги и уже и не сага вовсе. И Крис таки прав.
#Сага #Транзакционность
Продолжая предыдущий пост, хотелось бы ответить на вопрос, что есть Сага.
Ad ovo:
1. В распределенной среде долгоживущие транзакции могут обеспечить транзакционность (ACID) на блокировках. Работает это очень ненадёжно и медленно.
В 1986 году Hector Garcaa-Molrna, Kenneth Salem предложили разбить транзакцию на несколько мелких локальных и назвали это сагой.
С их точки зрения сага была не атомарна, то есть CID.
Так как атомарностью они назвали принцип "Всё или ничего" (БД-шное понимание атомарности).
2. Мартин Клеппман переопределил атомарность как abortability. То есть как возможность прервать и откатить транзакцию в случае отката одной из операций. В этом понимании Сага вполне атомарна (ACID).
3. Однако, в процессе проведения Саги часть транзакций может быть закомичена до общей фиксации. То есть конкуренты увидят результаты незавершенной транзакции. Крис Ричардсон считает, что это явное нарушение изоляции. То есть Сага - ACD.
4. Криса ругают и доказывают, что изоляцию для Саги построить легко. Например, на блокировках. С моей т.з. сага с блокировками противоречит идее создания саги и уже и не сага вовсе. И Крис таки прав.
#Сага #Транзакционность
👍4
BPM-движки
Глядя на различные системы, использующие bpm-движки (camunda, zeebe и ежи с ними), осознаю некоторое неустранимое противоречие.
По пунктам:
1. BPMN - нотация моделирования.
2. BPM - модель процесса. То есть некоторая абстракция, упрощение.
3. Движок предполагает реализацию.
Как авторами концепции предполагалось заполнить пробел между абстракцией и реализацией?
Они реально думали, что модель нарисованная, например аналитиком, сразу же заработает как реализованный алгоритм?
По факту пробел заполняют разработчики, внося в начальную красивую диаграмму массу деталей. При этом преодолевая вязкость нотации bpmn, которая вовсе не хочет становиться языком программирования.
Глядя на различные системы, использующие bpm-движки (camunda, zeebe и ежи с ними), осознаю некоторое неустранимое противоречие.
По пунктам:
1. BPMN - нотация моделирования.
2. BPM - модель процесса. То есть некоторая абстракция, упрощение.
3. Движок предполагает реализацию.
Как авторами концепции предполагалось заполнить пробел между абстракцией и реализацией?
Они реально думали, что модель нарисованная, например аналитиком, сразу же заработает как реализованный алгоритм?
По факту пробел заполняют разработчики, внося в начальную красивую диаграмму массу деталей. При этом преодолевая вязкость нотации bpmn, которая вовсе не хочет становиться языком программирования.
👍3
Архитектурное решение
Мне не нравится когда говорят, что архитектор принимает решение.
Принимать решение удел менеджера.
Архитектор обдумывает и прорабатывает решение.
Процесс архитектора несколько более затратный.
Это не сложный выбор и не волевое действие.
Это полное погружение в задачу, до формирования необходимых нейронных цепей, до ясности понимания.
Нужна архитектура за день? Да пожалуйста. Только то будет не совсем "архитектура".
Мне не нравится когда говорят, что архитектор принимает решение.
Принимать решение удел менеджера.
Архитектор обдумывает и прорабатывает решение.
Процесс архитектора несколько более затратный.
Это не сложный выбор и не волевое действие.
Это полное погружение в задачу, до формирования необходимых нейронных цепей, до ясности понимания.
Нужна архитектура за день? Да пожалуйста. Только то будет не совсем "архитектура".
👍5😱1