Как раз об этом мы и хотим поговорить) Постараемся вместе прийти к более развернутому описанию этих ролей. Надеемся, что многим разработчикам это пригодится для того, чтобы выбрать направление роста.
Вы правы, действительно предыстория баттла — это скорее «внутренняя кухня». Однако, мы считаем, что дискуссия может оказаться интересной и полезной для многих разработчиков, поэтому приглашаем всех желающих)
Стоит уточнить, что любой MVP делают с расчетом на полноценный продукт, да и внутренний контроль при проработке архитектуры нужен всегда: как ни крути, один человек не может знать все технологии, а вот группа специалистов – может.
Процесс внутреннего контроля нацелен на то, чтобы «объять необъятное» и найти оптимальное решение для каждого случая. С проверяющей командой в 3-5 человек можно за 30-40 минут обозначить проблемы, описать пути их решения и отправить ответственного на доработку.
Мы выбирали количество проверяющих эмпирическим путем, но наши выводы в целом соответствуют тому, что пишут об «идеальной команде» и фасилитации. Если команда больше – на принятие решения уходит много времени, если меньше – есть риск упустить отдельные важные моменты.
Спасибо за обратную связь.
В этой статье мы хотели поделиться опытом, почему в нашей практике необходим архитектурный комитет, рассказать о задачах и процессах, потому что не всегда роль архитектора очевидна. Нередко можно услышать мнение, что с задачами по выбору технологического решения легко справится сама команда разработки. Безусловно, команда справится, но по нашему опыту для этого понадобится значительно больше времени и ресурсов, чем если получить рекомендацию архитектора.
Мы обязательно будем делиться с вами интересными кейсами (теми, которыми можем делиться, всё-таки NDA никто не отменял))
Насчёт библиотеки согласны. Для такого тривиального примера она может показаться излишней. Но это только пример, чтобы показать варианты решения проблем с циклическими зависимостями. Данный подход позволяет избавиться от сильной связанности модулей в проекте. В инициализирующих модулях мы прокидываем зависимости в глобальный контекст, который управляется библиотекой, а во вью мы импортируем именно контекст, а не само определение зависимостей. Это просто удобнее
Это не совсем так. В подобных решениях в файле app.py можно указать переменные, которые будут использованы позже и связаны с каким-либо эндпоинтом через наследник класса di_cnt.DeclarativeContainer, который не является глобальной переменной из арр.ру.
У каждого продукта свои особенности, поэтому объёмы тестирования каждого сектора для каждого приложения, конечно, могут отличаться. Для нас это в первую очередь чек-лист, как мы писали выше.
Тесты можно делить ещё по множеству параметров) Колесо автоматизации призвано быть удобным «чек-листом» типов тестирования для автоматизации тестирования.
Этот перевод описывает более наглядную форму, чем простой список тестов (где, как правило, больше всего запоминаются первый и последний пункт). Возможно, это хорошая идея — расположить сектора в определенном порядке или связать каждый тест с цветом, хотя автор статьи предлагает считать все «спицы» равнозначными. Мы используем этот способ, прежде всего, как чек-лист типов автотестов.
Колесо действительно изобрели до ГОСТ и до нас)) Мы считаем, что в автоматизации тестирования описанный метод полезен, в первую очередь, своей наглядностью.
Спасибо) Интересными техническими кейсами мы тоже постоянно делимся. Например, неделю назад выпустили рассказ наших frontend-разработчиков об использовании d3.js, а скоро выпустим материал по автоматизации тестирования. Тем не менее, мы стремимся не ограничиваться сугубо техническими кейсами, пробовать разные новые форматы, рассказывать, как у нас всё устроено
Процесс внутреннего контроля нацелен на то, чтобы «объять необъятное» и найти оптимальное решение для каждого случая. С проверяющей командой в 3-5 человек можно за 30-40 минут обозначить проблемы, описать пути их решения и отправить ответственного на доработку.
Мы выбирали количество проверяющих эмпирическим путем, но наши выводы в целом соответствуют тому, что пишут об «идеальной команде» и фасилитации. Если команда больше – на принятие решения уходит много времени, если меньше – есть риск упустить отдельные важные моменты.
В этой статье мы хотели поделиться опытом, почему в нашей практике необходим архитектурный комитет, рассказать о задачах и процессах, потому что не всегда роль архитектора очевидна. Нередко можно услышать мнение, что с задачами по выбору технологического решения легко справится сама команда разработки. Безусловно, команда справится, но по нашему опыту для этого понадобится значительно больше времени и ресурсов, чем если получить рекомендацию архитектора.
Мы обязательно будем делиться с вами интересными кейсами (теми, которыми можем делиться, всё-таки NDA никто не отменял))