Расскажите, пожалуйста, подробнее, а в чем польза от Гильдии Архитекторов для продуктов / проектов компании в целом? Ну, кроме нетворкинга и обмена опытом, я имею в виду. Помогаете ли вы новым командам и продуктам определить / выбрать оптимальную архитектуру? Помогаете ли существующим продуктам мигрировать на более эффективные архитектуры? Есть ли какие-нибудь гайдлайны, чеклисты и тому подобные артефакты, облегчающие разработку и сопровождение в части архитектуры?
А то ведь и книг по архитектуре полно, и статей на профильных ресурсах, и докладов на Youtube, и Телеграм-каналов (с тысячами подписчисков, кстати). Толку-то от еще одного контент-ресурса?
Давайте в этой ветке всегда будем уточнять, о состоянии чего в данный момент времени идет речь - о состоянии управляющего автомата или о состоянии управляемой системы.
Будем красиво выглядеть в глазах аудиториии и, возможно, придем к имеющему практический смысл соглашению :)
Конечные автоматы это концепция из прошлого века, если не сказать из прошлого тысячилетия.
Возраст - не повод полностью отказываться от инструмента или методологии. Последовательную запись и выполнение операторов, условные операторы и циклы тоже давным-давно придумали, но ничего, пользуемся и по сей день.
сколько же у вас состояний? больше чем атомов во вселенной?
Всех возможных состояний системы (в автоматном программировании их называют вычислительными) - да, может быть и больше, чем атомов. А вот важных для управления системой (это управляющие состояния) - намного меньше.
Как пример - баланс средств на счете может быть любым, от нуля до бесконечности. Значение баланса - вычислительное состояние. Но для совершения действия в системе (т.е. для управления системой) важно лишь, достаточно ли на счету средств для оплаты покупки. Вычислительных состояний потенциально бесконечно много, но управляющих в данном конкретном примере - всего два.
Мне кажется, тут нужно различать состояния автомата и состояния системы, управляемой автоматом. Автомат должен быть спроектирован и реализован так, чтобы его состояния сменялись мгновенно/синхронно/атомарно. В таких условиях Ваш вопрос будет лишен смысла.
Это же сильно зависит от того, какой смысл Вы вкладываете в сущности таск-трекера и чем собираетесь управлять через него.
По моему опыту оказалось удобно сабтаски использовать для управления конкретными работами. Одна выполненная сабтаска может быть условно "бесполезной", т.е. ее нельзя никуда задеплоить или можно, но это ни на что вообще не повлияет. А вот история (состоящая из одной или нескольких подзадач) - это видимая для пользователя функциональность или законченный рефакторинг. Законченную историю можно задеплоить, протестировать и даже иногда использовать.
В общем, подзадачи - для управления работами и загрузкой исполнителей, а истории - для управления поставкой и инкрементами функциональности.
Хм, а если я декомпозирую функциональность из примера ("Разработка добавления комментирования к постам в социальной сети") вот так:
Реализовать возможность просмотра комментария в виде простого текста без форматирования. То есть, на фронте это компонент отображения текста комментария, в БД - структура для хранения комментария, в API - метод получения комментария. Пока что к одному посту возможен один комментарий, для тестирования будем создавать его в БД вручную.
Реализовать возможность просмотра всех комментариев (и там возможная пагинация, подгрузка еще что-то в этом роде).
Реализовать возможность добавить комментарий по нажатию на кнопку в UI. На фронте - кнопка и условия ее доступности, в API - метод создания комментария, который пока что будет создавать захардкоженный текст. При проверке будем нажимать на кнопку и видеть, что список комментариев пополняется.
Реализовать возможность удалить комментарий по нажатию на кнопку.
Реализовать возможность ввести произвольный текст в качестве комментария.
Реализовать возможность форматирования текста в комментарии.
К какому виду декомпозиций из перечисленных в статье относится такое разбиение? Оно правильное, ну или хотя бы более или менее правильное, чем предложенное Вами в качестве рекомендации?
Расскажите, пожалуйста, как происходит процесс изменения схемы GraphQL. Вот, к примеру, есть система "на бою", у нее сотни клиентских приложений, у каждого клиентского приложения тысячи юзеров. И в какой-то момент какое-то поле в схеме GraphQL (скажем, идентификатор клиентского приложения, оно во всех запросах присутствует) вдруг должно быть изменено. Скажем, раньше это был простой строковый идентификатор, а теперь нужно передавать объект из двух полей: GUID и строковый идентификатор. Как это изменение должно выкатиться на прод, не задев все клиентские приложения?
Как Вы в своих реальных рабочих проектах с этим справляетесь?
А в чем преимущество «колеса» в наглядности перед, скажем, простым списком видов тестирования? Вы пишете, что это «полезный способ визуализации», а в чем конкретно заключается польза? Что именно иллюстрирует это колесо? Почему какие-то типы тестирования справа, а какие-то слева? Почему тип тестов А соседствует с типами B и C? Имеют ли значения цвета?
Расскажите, пожалуйста, подробнее, а в чем польза от Гильдии Архитекторов для продуктов / проектов компании в целом? Ну, кроме нетворкинга и обмена опытом, я имею в виду. Помогаете ли вы новым командам и продуктам определить / выбрать оптимальную архитектуру? Помогаете ли существующим продуктам мигрировать на более эффективные архитектуры? Есть ли какие-нибудь гайдлайны, чеклисты и тому подобные артефакты, облегчающие разработку и сопровождение в части архитектуры?
А то ведь и книг по архитектуре полно, и статей на профильных ресурсах, и докладов на Youtube, и Телеграм-каналов (с тысячами подписчисков, кстати). Толку-то от еще одного контент-ресурса?
Давайте в этой ветке всегда будем уточнять, о состоянии чего в данный момент времени идет речь - о состоянии управляющего автомата или о состоянии управляемой системы.
Будем красиво выглядеть в глазах аудиториии и, возможно, придем к имеющему практический смысл соглашению :)
Возраст - не повод полностью отказываться от инструмента или методологии. Последовательную запись и выполнение операторов, условные операторы и циклы тоже давным-давно придумали, но ничего, пользуемся и по сей день.
Всех возможных состояний системы (в автоматном программировании их называют вычислительными) - да, может быть и больше, чем атомов. А вот важных для управления системой (это управляющие состояния) - намного меньше.
Как пример - баланс средств на счете может быть любым, от нуля до бесконечности. Значение баланса - вычислительное состояние. Но для совершения действия в системе (т.е. для управления системой) важно лишь, достаточно ли на счету средств для оплаты покупки. Вычислительных состояний потенциально бесконечно много, но управляющих в данном конкретном примере - всего два.
Мне кажется, тут нужно различать состояния автомата и состояния системы, управляемой автоматом. Автомат должен быть спроектирован и реализован так, чтобы его состояния сменялись мгновенно/синхронно/атомарно. В таких условиях Ваш вопрос будет лишен смысла.
Это же сильно зависит от того, какой смысл Вы вкладываете в сущности таск-трекера и чем собираетесь управлять через него.
По моему опыту оказалось удобно сабтаски использовать для управления конкретными работами. Одна выполненная сабтаска может быть условно "бесполезной", т.е. ее нельзя никуда задеплоить или можно, но это ни на что вообще не повлияет. А вот история (состоящая из одной или нескольких подзадач) - это видимая для пользователя функциональность или законченный рефакторинг. Законченную историю можно задеплоить, протестировать и даже иногда использовать.
В общем, подзадачи - для управления работами и загрузкой исполнителей, а истории - для управления поставкой и инкрементами функциональности.
Хм, а если я декомпозирую функциональность из примера ("Разработка добавления комментирования к постам в социальной сети") вот так:
Реализовать возможность просмотра комментария в виде простого текста без форматирования. То есть, на фронте это компонент отображения текста комментария, в БД - структура для хранения комментария, в API - метод получения комментария. Пока что к одному посту возможен один комментарий, для тестирования будем создавать его в БД вручную.
Реализовать возможность просмотра всех комментариев (и там возможная пагинация, подгрузка еще что-то в этом роде).
Реализовать возможность добавить комментарий по нажатию на кнопку в UI. На фронте - кнопка и условия ее доступности, в API - метод создания комментария, который пока что будет создавать захардкоженный текст. При проверке будем нажимать на кнопку и видеть, что список комментариев пополняется.
Реализовать возможность удалить комментарий по нажатию на кнопку.
Реализовать возможность ввести произвольный текст в качестве комментария.
Реализовать возможность форматирования текста в комментарии.
К какому виду декомпозиций из перечисленных в статье относится такое разбиение? Оно правильное, ну или хотя бы более или менее правильное, чем предложенное Вами в качестве рекомендации?
Расскажите, пожалуйста, как происходит процесс изменения схемы GraphQL. Вот, к примеру, есть система "на бою", у нее сотни клиентских приложений, у каждого клиентского приложения тысячи юзеров. И в какой-то момент какое-то поле в схеме GraphQL (скажем, идентификатор клиентского приложения, оно во всех запросах присутствует) вдруг должно быть изменено. Скажем, раньше это был простой строковый идентификатор, а теперь нужно передавать объект из двух полей: GUID и строковый идентификатор. Как это изменение должно выкатиться на прод, не задев все клиентские приложения?
Как Вы в своих реальных рабочих проектах с этим справляетесь?