Здравствуйте. В статье мы привели немного упрощенный фрагмент кода, на практике в каждом проекте будут свои настройки. В частности, в нашем проекте была отдельная папка для attachments, поэтому мы не обращались к фильтрации. По второму вопросу — согласны, во многих проектах это бывает необходимо.
Добрый день! Обратите внимание, чтобы запустить приведенный код, нужно указать свои пути к папке отчета и нужным страницам в Confluence. Вы не могли бы написать чуть подробнее о том, какая была проблема и какие ошибки?
Методология ADD основана на атрибутах качества ПО, узнать о ней подробнее можно по ссылке в начале статьи. Мы стремимся проектировать системы предсказуемым и эффективным способом, и для этого мы используем проверенный временем метод, подходящий для большинства опытных инженеров-программистов. При таком подходе мы уверены, что в проекте будут учтены все архитектурно-значимые требования и ограничения.
Описанный метод мы выбрали по нескольким причинам, которые считаем важными:
акцент на архитектурно-значимые требования и способы их достижения;
метод включает в себя шаги по созданию документации и анализа созданной архитектуры;
это итеративный процесс, этап проектирования можно включать в каждый спринт;
методу более 20 лет, но он не устарел и несколько раз был пересмотрен и адаптирован под современные условия;
есть детальная пошаговая инструкция по задачам, которые необходимо выполнить в рамках итераций проектирования, что снижает порог вхождения для архитектора;
метод достаточно универсален, но не переусложнен;
хорошо вписывается в процессы нашей компании - от пресейла и оценки до разработки.
Добрый день. Мы используем ADD – отдельный метод проектирования архитектуры, разработанный в университете Карнеги – Меллона в 2000 году. Этот метод был переработан и адаптирован под современные условия в 2015 году. Существует несколько различных методологий проектирования архитектуры (ADM в TOGAF, RUP 4+1, S4V, ASC и т.д.). Они имеют много общего между собой. В ADD нас привлекло то, что все шаги проектирования формализованы и детально описаны.
Добрый день. Мы полностью согласны с тем, что документация должна быть полезна для команды разработки. Однако, её объем и степень детализации определяются особенностями проекта. Говоря подробнее о роли клиента, мы исходим из того, что требование к соблюдению ГОСТ – это требование именно клиента. При этом команда разработки зачастую ведет документацию своими методами. Например, у нас для этого есть база знаний и проверенных практик, основанных в том числе на зарубежных стандартах и отечественных ГОСТах. С их помощью аналитики могут наиболее точно доводить требования до команды с учётом применяемой методологии разработки и специфики проекта.
ГОСТ 34 действительно шире, потому что охватывает всю инфраструктуру – от непосредственных участников бизнес-процессов до аппаратного обеспечения. И когда речь идет о создании АИС на предприятии с нуля, заказчики зачастую выбирают ГОСТ 34, одновременно рассматривая разработку ПО и изменения в инфраструктуре. По нашим наблюдениям, ГОСТ 19 чаще применяют при разработке либо отдельных продуктов в составе существующей АИС, либо ПО для более массового использования, не требующего строго определённых условий (аппаратных или бизнесовых).
Отметим также, что стандарты заточены под водопадную методологию разработки, поэтому при реализации появляется необходимость найти баланс между утверждёнными стандартами и эффективными процессами
Спасибо. Мы за то, чтобы документация была удобна команде, а разрабатываемый продукт - пользователю. Конечно, в определённом смысле стандарты разработки нужны - критерии качества требований, принципы хорошего кода, принципы тестирования ПО и т.д. Однако, это то, чем мы внутри команды измеряем качество разработки. Заказчик же иногда может быть далёк от IT-среды, но ему нужно какое-то мерило, и он берет утверждённый стандарт, полагая, что это и есть критерий качества. ГОСТ в данном случае может оказаться попыткой на велосипеде победить в ралли Формулы-1. Утверждённые стандарты могут не успевать за темпами развития технологий и методологий в отрасли.
Добрый день! Получить качественные БТ на входе — это действительно непростая задача, но тем не менее важная, мы в этом процессе опирались на опыт проработки клиентских запросов. Получая каждый запрос, мы практически собираем “консилиум” — анализируем архитектурное решение, привлекаем специалистов разных направлений и за счет комплексного подхода стараемся сделать оценку как можно более точной
Тестовое задание помогает, в первую очередь, определить навыки участников. А значит, распределить их по группам и скорректировать программу при необходимости. Именно поэтому у нас в задании есть как основные требования, так и дополнительные – то есть те, которые можно выполнять по желанию
Для удобства участников и менторов мы ведем в занятия в небольших группах, поэтому вынуждены ограничивать количество мест. На данный момент для нас оказались наиболее эффективны практикумы в тех городах, где есть наши центры разработки. Однако, помимо практикумов, у нас есть всероссийские онлайн-митапы для всех желающих разработчиков. Ближайший Backend-митап состоится в конце октября, скоро мы расскажем подробности
Спасибо за интерес к статье и отзывы! Да, материала получилось достаточно много, учтем это в дальнейшем. Надеемся, что для начинающих разработчиков приведенные примеры могут быть полезны и помогут сделать код безопаснее)
Добрый день! Мы стремились в первую очередь разобрать решения из коробки. Так как прямого указания на Gradle в Spock не было, то в статье его не упоминаем, но само по себе это интересное решение. Спасибо)
Не совсем понятен ваш первый вопрос, мы постарались дать максимально подробный ответ)
Если команда одна и состоит сплошь из сеньоров, то часто так и есть, как вы описали. Но правда жизни в том, что очень сложно собрать такую команду. Если продукт успешен, всегда наступает такой момент, когда над ним трудится более пяти и даже десяти команд. Нередки случаи, когда над одним продуктом трудятся аутсорс-команды из разных компаний, которые ничего не знают о работе друг друга. Вот в такой системе архитектор незаменим.
Спасибо! Мы уже опубликовали одну статью по ДБО с техническими деталями, насколько позволило NDA, с ней можно ознакомиться здесь: habr.com/ru/company/simbirsoft/blog/512310. В будущем мы будем продолжать публиковать статьи, где постараемся раскрыть кейсы, с которыми сталкиваемся
Здравствуйте. В статье мы привели немного упрощенный фрагмент кода, на практике в каждом проекте будут свои настройки. В частности, в нашем проекте была отдельная папка для attachments, поэтому мы не обращались к фильтрации. По второму вопросу — согласны, во многих проектах это бывает необходимо.
Добрый день! Обратите внимание, чтобы запустить приведенный код, нужно указать свои пути к папке отчета и нужным страницам в Confluence. Вы не могли бы написать чуть подробнее о том, какая была проблема и какие ошибки?
Это замечательно) Если вы хотите ближе познакомиться с этой областью, приглашаем подключиться к нашему онлайн-практикуму
Методология ADD основана на атрибутах качества ПО, узнать о ней подробнее можно по ссылке в начале статьи. Мы стремимся проектировать системы предсказуемым и эффективным способом, и для этого мы используем проверенный временем метод, подходящий для большинства опытных инженеров-программистов. При таком подходе мы уверены, что в проекте будут учтены все архитектурно-значимые требования и ограничения.
Описанный метод мы выбрали по нескольким причинам, которые считаем важными:
акцент на архитектурно-значимые требования и способы их достижения;
метод включает в себя шаги по созданию документации и анализа созданной архитектуры;
это итеративный процесс, этап проектирования можно включать в каждый спринт;
методу более 20 лет, но он не устарел и несколько раз был пересмотрен и адаптирован под современные условия;
есть детальная пошаговая инструкция по задачам, которые необходимо выполнить в рамках итераций проектирования, что снижает порог вхождения для архитектора;
метод достаточно универсален, но не переусложнен;
хорошо вписывается в процессы нашей компании - от пресейла и оценки до разработки.
Добрый день. Мы используем ADD – отдельный метод проектирования архитектуры, разработанный в университете Карнеги – Меллона в 2000 году. Этот метод был переработан и адаптирован под современные условия в 2015 году. Существует несколько различных методологий проектирования архитектуры (ADM в TOGAF, RUP 4+1, S4V, ASC и т.д.). Они имеют много общего между собой. В ADD нас привлекло то, что все шаги проектирования формализованы и детально описаны.
Добрый день. Мы полностью согласны с тем, что документация должна быть полезна для команды разработки. Однако, её объем и степень детализации определяются особенностями проекта. Говоря подробнее о роли клиента, мы исходим из того, что требование к соблюдению ГОСТ – это требование именно клиента. При этом команда разработки зачастую ведет документацию своими методами. Например, у нас для этого есть база знаний и проверенных практик, основанных в том числе на зарубежных стандартах и отечественных ГОСТах. С их помощью аналитики могут наиболее точно доводить требования до команды с учётом применяемой методологии разработки и специфики проекта.
ГОСТ 34 действительно шире, потому что охватывает всю инфраструктуру – от непосредственных участников бизнес-процессов до аппаратного обеспечения. И когда речь идет о создании АИС на предприятии с нуля, заказчики зачастую выбирают ГОСТ 34, одновременно рассматривая разработку ПО и изменения в инфраструктуре. По нашим наблюдениям, ГОСТ 19 чаще применяют при разработке либо отдельных продуктов в составе существующей АИС, либо ПО для более массового использования, не требующего строго определённых условий (аппаратных или бизнесовых).
Отметим также, что стандарты заточены под водопадную методологию разработки, поэтому при реализации появляется необходимость найти баланс между утверждёнными стандартами и эффективными процессами
Спасибо. Мы за то, чтобы документация была удобна команде, а разрабатываемый продукт - пользователю. Конечно, в определённом смысле стандарты разработки нужны - критерии качества требований, принципы хорошего кода, принципы тестирования ПО и т.д. Однако, это то, чем мы внутри команды измеряем качество разработки. Заказчик же иногда может быть далёк от IT-среды, но ему нужно какое-то мерило, и он берет утверждённый стандарт, полагая, что это и есть критерий качества. ГОСТ в данном случае может оказаться попыткой на велосипеде победить в ралли Формулы-1. Утверждённые стандарты могут не успевать за темпами развития технологий и методологий в отрасли.
Спасибо, присмотримся к этому методу)
Если команда одна и состоит сплошь из сеньоров, то часто так и есть, как вы описали. Но правда жизни в том, что очень сложно собрать такую команду. Если продукт успешен, всегда наступает такой момент, когда над ним трудится более пяти и даже десяти команд. Нередки случаи, когда над одним продуктом трудятся аутсорс-команды из разных компаний, которые ничего не знают о работе друг друга. Вот в такой системе архитектор незаменим.