Добрый день! Мы стремились в первую очередь разобрать решения из коробки. Так как прямого указания на Gradle в Spock не было, то в статье его не упоминаем, но само по себе это интересное решение. Спасибо)
Не совсем понятен ваш первый вопрос, мы постарались дать максимально подробный ответ)
Если команда одна и состоит сплошь из сеньоров, то часто так и есть, как вы описали. Но правда жизни в том, что очень сложно собрать такую команду. Если продукт успешен, всегда наступает такой момент, когда над ним трудится более пяти и даже десяти команд. Нередки случаи, когда над одним продуктом трудятся аутсорс-команды из разных компаний, которые ничего не знают о работе друг друга. Вот в такой системе архитектор незаменим.
Спасибо! Мы уже опубликовали одну статью по ДБО с техническими деталями, насколько позволило NDA, с ней можно ознакомиться здесь: habr.com/ru/company/simbirsoft/blog/512310. В будущем мы будем продолжать публиковать статьи, где постараемся раскрыть кейсы, с которыми сталкиваемся
Ключевое преимущество нашей компании в том, что мы имеем дело с очень разными предметными областями, подходами и даже областями. Таким образом, нам удается поддерживать интерес, а значит и мотивацию архитекторов на высоком уровне. Каждая задача на проработку архитектуры уникальна, это вызов для архитектора.
Что касается правильно/не правильно: правильно составленная архитектура учитывает все нефункциональные требования клиента и результирующий продукт удовлетворяет их. Если нефункциональные требования не выполняются — это неправильно разработанная архитектура. Как вы видите из статьи, у нас существует процесс архитектурного надзора, когда архитектор подключается к проекту и следит за реализацией.
Безусловно, иногда встречаются моменты, когда команда сталкивается со сложностями и приходится корректировать архитектуру «на ходу», но даже в таком случае архитектор, прикрепленный к проекту, участвует в выборе решения и несет за это ответственность.
Как раз об этом мы и хотим поговорить) Постараемся вместе прийти к более развернутому описанию этих ролей. Надеемся, что многим разработчикам это пригодится для того, чтобы выбрать направление роста.
Вы правы, действительно предыстория баттла — это скорее «внутренняя кухня». Однако, мы считаем, что дискуссия может оказаться интересной и полезной для многих разработчиков, поэтому приглашаем всех желающих)
Стоит уточнить, что любой MVP делают с расчетом на полноценный продукт, да и внутренний контроль при проработке архитектуры нужен всегда: как ни крути, один человек не может знать все технологии, а вот группа специалистов – может.
Процесс внутреннего контроля нацелен на то, чтобы «объять необъятное» и найти оптимальное решение для каждого случая. С проверяющей командой в 3-5 человек можно за 30-40 минут обозначить проблемы, описать пути их решения и отправить ответственного на доработку.
Мы выбирали количество проверяющих эмпирическим путем, но наши выводы в целом соответствуют тому, что пишут об «идеальной команде» и фасилитации. Если команда больше – на принятие решения уходит много времени, если меньше – есть риск упустить отдельные важные моменты.
Спасибо за обратную связь.
В этой статье мы хотели поделиться опытом, почему в нашей практике необходим архитектурный комитет, рассказать о задачах и процессах, потому что не всегда роль архитектора очевидна. Нередко можно услышать мнение, что с задачами по выбору технологического решения легко справится сама команда разработки. Безусловно, команда справится, но по нашему опыту для этого понадобится значительно больше времени и ресурсов, чем если получить рекомендацию архитектора.
Мы обязательно будем делиться с вами интересными кейсами (теми, которыми можем делиться, всё-таки NDA никто не отменял))
Насчёт библиотеки согласны. Для такого тривиального примера она может показаться излишней. Но это только пример, чтобы показать варианты решения проблем с циклическими зависимостями. Данный подход позволяет избавиться от сильной связанности модулей в проекте. В инициализирующих модулях мы прокидываем зависимости в глобальный контекст, который управляется библиотекой, а во вью мы импортируем именно контекст, а не само определение зависимостей. Это просто удобнее
Это не совсем так. В подобных решениях в файле app.py можно указать переменные, которые будут использованы позже и связаны с каким-либо эндпоинтом через наследник класса di_cnt.DeclarativeContainer, который не является глобальной переменной из арр.ру.
У каждого продукта свои особенности, поэтому объёмы тестирования каждого сектора для каждого приложения, конечно, могут отличаться. Для нас это в первую очередь чек-лист, как мы писали выше.
Тесты можно делить ещё по множеству параметров) Колесо автоматизации призвано быть удобным «чек-листом» типов тестирования для автоматизации тестирования.
Этот перевод описывает более наглядную форму, чем простой список тестов (где, как правило, больше всего запоминаются первый и последний пункт). Возможно, это хорошая идея — расположить сектора в определенном порядке или связать каждый тест с цветом, хотя автор статьи предлагает считать все «спицы» равнозначными. Мы используем этот способ, прежде всего, как чек-лист типов автотестов.
Если команда одна и состоит сплошь из сеньоров, то часто так и есть, как вы описали. Но правда жизни в том, что очень сложно собрать такую команду. Если продукт успешен, всегда наступает такой момент, когда над ним трудится более пяти и даже десяти команд. Нередки случаи, когда над одним продуктом трудятся аутсорс-команды из разных компаний, которые ничего не знают о работе друг друга. Вот в такой системе архитектор незаменим.
Что касается правильно/не правильно: правильно составленная архитектура учитывает все нефункциональные требования клиента и результирующий продукт удовлетворяет их. Если нефункциональные требования не выполняются — это неправильно разработанная архитектура. Как вы видите из статьи, у нас существует процесс архитектурного надзора, когда архитектор подключается к проекту и следит за реализацией.
Безусловно, иногда встречаются моменты, когда команда сталкивается со сложностями и приходится корректировать архитектуру «на ходу», но даже в таком случае архитектор, прикрепленный к проекту, участвует в выборе решения и несет за это ответственность.
Процесс внутреннего контроля нацелен на то, чтобы «объять необъятное» и найти оптимальное решение для каждого случая. С проверяющей командой в 3-5 человек можно за 30-40 минут обозначить проблемы, описать пути их решения и отправить ответственного на доработку.
Мы выбирали количество проверяющих эмпирическим путем, но наши выводы в целом соответствуют тому, что пишут об «идеальной команде» и фасилитации. Если команда больше – на принятие решения уходит много времени, если меньше – есть риск упустить отдельные важные моменты.
В этой статье мы хотели поделиться опытом, почему в нашей практике необходим архитектурный комитет, рассказать о задачах и процессах, потому что не всегда роль архитектора очевидна. Нередко можно услышать мнение, что с задачами по выбору технологического решения легко справится сама команда разработки. Безусловно, команда справится, но по нашему опыту для этого понадобится значительно больше времени и ресурсов, чем если получить рекомендацию архитектора.
Мы обязательно будем делиться с вами интересными кейсами (теми, которыми можем делиться, всё-таки NDA никто не отменял))