@acidgeneration

Делаем что то одно — все остальное ломаем?

Кто сталкивался с таким что ваш отдел разработки(php, js, css) делает фичу/страницу/метод/функционал более менее успешно, но при этом постоянно ломается то что было реализовано ранее?

Почему такое происходит? Как с этим бороться? Нужно вводить документацию? Тестирование? Нужно ли жестко привязывать разработчиков к конкретным гайдлайнам и фреймворкам?
Буду благодарен за ваши примеры решения подобных ситуаций и полезные ссылки.
  • Вопрос задан
  • 250 просмотров
Решения вопроса 1
lxsmkv
@lxsmkv
Test automation engineer
Регрессии это нормальное явление. Почему такое происходит в принципе - интересный сам по себе вопрос.
Регресс появляется когда добавление нового кода или изменение старого не учитывает всех задействованных частей программы.
Отсюда можно сделать вывод, чтобы минимизировать эффект от регрессии, нужно огранизовывать код так, чтобы при его изменении, можно было легко понять, на какие другие части логики это изменение влияет. Именно это является целью создания идеальной архитектуры приложения. Чтобы все было по полочкам. Чтобы доставая из шкафа полотенце, вам на голову не падала матрешка которая стоит на шкафу сверху (кто ее туда поставил, и почему - неясно, записку с комментариями никто не оставил)
Чтобы бороться с наваливанием кода в кучу - нужно чтобы кто-то следил за тем чтобы его не наваливали в кучу. Архитектор например. Архитектор это такой ландшафтный дизайнер для кода. Но нужен и садовник. Чтобы лужайки были зеленые, а огурцы не расли на грядке в перемешку с морковкой. Фреймворки конечно тоже отчасти справляются с этой задачей. Фреймворк для того в принципе и служит, чтобы для каждой части приложения была своя песочница. Мол, складывай вещи как хочешь но в коробки 40х50х30. Текстиль сюда, кухонную утварь сюда. Коробку подписать, занести в реестр. Как на складе.
Но ничто не защитит вас от того, что в коробки накидают не того что там должно быть. Надо проверять (тестирование). Выстраивать процесс таким образом чтобы ошибиться по халатности было трудно (архитектура). Чтобы было легко локализовать источник ошибки (логгирование). Систематично избавляться от сложности во всем (здравый смысл).
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 3
sim3x
@sim3x
Пишем свой код по ТДД

После внедрения фичи, прогоняет все тесты
Если тесты упали - решаем, как написать свою часть, так чтоб тесты , которые не касаются нашей части не падали
Ответ написан
@azShoo
Давайте будем честными, продукты имеющие реальную продуктовую ценность имеют такое число состояний, что какие-то из них будут всегда сломаны.
Независимо от фреймворков, тестирования и прочего. Баги будут, и чем больше изменений вы вносите - тем больше шансов привнести и баги.

Тем не менее, есть вполне стандартные методы минимизировать эту боль.
Это и практики тестирования (не только силами тестировщиков) и повышение code culture, код ревью, мониторинг состояния продукта, нормальные практики релизов и прочее-прочее-прочее.
Никакого единого способа "всё и сразу починить" нету.
Ответ написан
Комментировать
@1001001
Бывает, в зависимости от частоты и нормально и нет.
Бороться на стороне тестирования: Регрессионные автотесты
На стороне разработчиков: Модульное тестирование, прогонять при сборке пакета или каждый разраб перед отправкой изменений локально прогоняет
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы