Архитектура большого внедрения
Вопрос
Вы ведущий разработчик внедрения ERP с 30 доработками у крупного клиента. Как организуете разработку, чтобы обновления не превратились в ад?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
Политика: основная конфигурация на поддержке, доработки в расширениях
Несколько расширений по областям, с владельцами
EDT и Git, ревью кода, стандарты 1С, проверка кода
Автотесты ключевых сценариев (Vanessa Automation, YAxUnit)
Регулярные обновления типовой на тестовом контуре
Реестр доработок с обоснованием и стоимостью поддержки
Что могут спросить следом
- Чем опасно одно огромное расширение?
- Как убедить клиента отказаться от доработки?
Разбор
Задаю правило: основная конфигурация на поддержке, всё в расширениях. Делю доработки на несколько расширений по областям (продажи, склад, печатные формы) с владельцами, чтобы ошибка в одном не ломала всё. Разработка в EDT с Git: ветки, ревью, проверка кода по стандартам. Для ключевых сценариев пишу автотесты в Vanessa Automation и модульные в YAxUnit, они прогоняются на каждой сборке и после обновления типовой. Обновления ставлю регулярно на тестовый контур, а не раз в год пачкой. Веду реестр доработок: зачем она, кто заказал, сколько стоит поддержка. Это аргумент, чтобы отказаться от доработок, которые типовая уже закрыла.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.