>> А как вы собираете ответы от сервера-мока? Имеется ввиду то что он отвечает, просто на основе логов?
Да, мы ориентируемся чаще всего на логи эмулятора, либо на логи тестируемого сервера при анализе обнаруженных багов. Можно также использовать команды ls и show_info, чтобы посмотреть текущее состояние эмулятора, но самая достоверная информация будет в логах.
>> Как много времени занимает разобраться с логикой работы каждого эмулируемого сервиса?
Все зависит от сложности эмулируемого сервиса, поэтому временные рамки довольно широкие. По моему опыту на реализацию одного эмулятора необходимо от 1 до 6 недель для одного разработчика.
>> Ну и в целом интересна организация работы именно с тем что и в каком виде должен сервис возвращать
У нас всегда есть согласованное API взаимодействия тестируемого сервера и клиентских устройств, которое также использует и разработчик эмуляторов. В основном траффик между клиентами и сервером представляет собой JSON-сообщения, но также есть передача бинарных данных, закодированных в base64-строки.
С кодом работать проще, так как для него есть инструменты и работу с ним проще автоматизировать. Если вы можете легко переходить между представлениями, связанным со сценариями, будет проще погружаться в проект (это важно, если необходимо взаимодействие с большим количеством команд) и это проще для архитектора, так как становится не только внешним инструментом, но и внутренним.
AaC – это не только инструмент архитектурного надзора над кодом, который разрабатывают программисты, но в большей степени альтернативный способ проектирования архитектуры, который дает архитектору дополнительные возможности. В частности:
Синхронное версионирование архитектурной модели и кода.
Смещение фокуса с оформления на проектирование, в т.ч. непротиворечивой, модели.
Автоматизированном формировании артефактов, необходимых различным ЗЛ.
Автоматическое выполнение нормативных требований (регламентов и практик, принятых в компании).
Не обязательно применять подходы с контролем кода при внедрении AaC. Оверхэд будет, если процессы проектирования не выстроены и вновь спроектированные (под)системы сразу становятся «легаси». Если же процессы проектирования и разработки достаточно регламентированы, то подходы AaC будут только помогать делать процесс проектирования в соответствии с нормами, принятыми в компании.
По вопросам публикации своих решений и получения обратной связи вам необходимо проконсультироваться со специалистами нашей стажировочной программы. Пожалуйста, направьте ваш запрос на почту: practice@infotecs.ru.
Наш процесс разработки не основывается на архитектуре, а включает ее как один из важных этапов, наряду с планированием, анализом бизнес и системных требований, проектированием UI и т.д. Процесс разработки предваряет подготовительная фаза с определением целей и конечного результата.
Вот, интересно, можно ли было сделать предметом своей статьи на Хабре разбор какой-нибудь Вашей задачи?
Спасибо за идею) Мы можем сделать разбор задачи, но не для этого блога, а для канала стажировочной программы ИнфоТеКС.
1. Что значит "согласованную"? Непротиворечивую?
Да, верно. То есть обеспечить отсутствие противоречий между различными архитектурными артефактами.
2. Зачем смещать фокус? Разве одно другому не противоречит, не дополняет?
Чтобы затрачивать меньше времени на компоновку диаграммы и больше времени на продумывание архитектуры, так как нам больше интересна сама архитектурная модель, а не способ ее представления (соблюдение требований нотации). Это позволит сконцентрироваться на том, как должна работать система.
3. Что такое "артефакт"?
Все, что отдается на ознакомление различным заинтересованным лицам (аналитикам, менеджерам, бизнесу). Архитектор описывает модель, а из нее генерируются различные представления, понятные ЗЛ.
>> А как вы собираете ответы от сервера-мока? Имеется ввиду то что он отвечает, просто на основе логов?
Да, мы ориентируемся чаще всего на логи эмулятора, либо на логи тестируемого сервера при анализе обнаруженных багов. Можно также использовать команды ls и show_info, чтобы посмотреть текущее состояние эмулятора, но самая достоверная информация будет в логах.
>> Как много времени занимает разобраться с логикой работы каждого эмулируемого сервиса?
Все зависит от сложности эмулируемого сервиса, поэтому временные рамки довольно широкие. По моему опыту на реализацию одного эмулятора необходимо от 1 до 6 недель для одного разработчика.
>> Ну и в целом интересна организация работы именно с тем что и в каком виде должен сервис возвращать
У нас всегда есть согласованное API взаимодействия тестируемого сервера и клиентских устройств, которое также использует и разработчик эмуляторов. В основном траффик между клиентами и сервером представляет собой JSON-сообщения, но также есть передача бинарных данных, закодированных в base64-строки.
С кодом работать проще, так как для него есть инструменты и работу с ним проще автоматизировать. Если вы можете легко переходить между представлениями, связанным со сценариями, будет проще погружаться в проект (это важно, если необходимо взаимодействие с большим количеством команд) и это проще для архитектора, так как становится не только внешним инструментом, но и внутренним.
AaC – это не только инструмент архитектурного надзора над кодом, который разрабатывают программисты, но в большей степени альтернативный способ проектирования архитектуры, который дает архитектору дополнительные возможности. В частности:
Синхронное версионирование архитектурной модели и кода.
Смещение фокуса с оформления на проектирование, в т.ч. непротиворечивой, модели.
Автоматизированном формировании артефактов, необходимых различным ЗЛ.
Автоматическое выполнение нормативных требований (регламентов и практик, принятых в компании).
Не обязательно применять подходы с контролем кода при внедрении AaC. Оверхэд будет, если процессы проектирования не выстроены и вновь спроектированные (под)системы сразу становятся «легаси». Если же процессы проектирования и разработки достаточно регламентированы, то подходы AaC будут только помогать делать процесс проектирования в соответствии с нормами, принятыми в компании.
Стек и методика AaC никак не связаны.
По вопросам публикации своих решений и получения обратной связи вам необходимо проконсультироваться со специалистами нашей стажировочной программы. Пожалуйста, направьте ваш запрос на почту: practice@infotecs.ru.
Наш процесс разработки не основывается на архитектуре, а включает ее как один из важных этапов, наряду с планированием, анализом бизнес и системных требований, проектированием UI и т.д. Процесс разработки предваряет подготовительная фаза с определением целей и конечного результата.
Спасибо за идею) Мы можем сделать разбор задачи, но не для этого блога, а для канала стажировочной программы ИнфоТеКС.
Да, верно. То есть обеспечить отсутствие противоречий между различными архитектурными артефактами.
Чтобы затрачивать меньше времени на компоновку диаграммы и больше времени на продумывание архитектуры, так как нам больше интересна сама архитектурная модель, а не способ ее представления (соблюдение требований нотации). Это позволит сконцентрироваться на том, как должна работать система.
Все, что отдается на ознакомление различным заинтересованным лицам (аналитикам, менеджерам, бизнесу). Архитектор описывает модель, а из нее генерируются различные представления, понятные ЗЛ.