Внедрение правок на проекты генерит ошибки вне внедряемой области — как этого избежать?

Question

[Павел]

Я за советом к опытным программерам, тим-лидам или просто успешно управляющим командами с веб-разработкой.
-
Систематически возникает следующая проблема:
1) Программисты внедряют что-то на сайт - например новую категорию на сайте (или правки по старой категории).
2) Проверка внедряемого (собственно по поставленному ТЗ) не выявляет каких - либо проблем.
3) В местах, которые согласно ТЗ не были затрагиваемы проверяющим начинаются проблемы. Отвалилось что-то здесь, что-то там. Что-то еще появилось там где не должно было и так далее.

В результате получается, что задача проходит проверку, но полученный результат, если что-то слетело просто катастрофичен.
-
Есть несколько напрашивающихся "простых" вариантов решения:
1) После любой правки проверять все.
- Катастрофически нерентабельно с точки зрения ресурсов. Можно сократить время проверки знанием условно "глобальных переменных", которые участвуют не только в проверяемом разделе, но и в других. И таким образом проверять только те места, где еще участвует эта глобальная переменная. Но проблема в том, что зачастую нет данных о том, переменная глобальная или нет (если касается веб-сайта). То есть нет понимания, что конкретно это меню выводится не только в этом разделе, но еще и в другом месте. В общем и целом путь нерентабельный как я его вижу. И непонятно кто должен отвечать за эту проверку (чьи ресурсы уйдут на проверку) - программиста или специалиста, который проверяет задачу. Т.к. проверяющий свою задачу должен только ее и проверить, а не все вокруг.
-
2) Дать на "ковровую проверку" всем заинтересованным участникам.
- То есть после выкладывания правок - просить всех заинтересованных "потыкать проект". В то время как это довольно логичное решение - оно не полное. Во первых нет спецификаций "потыканья". Во-вторых это не "задача" как таковая без спецификаций - это надежда на авось что "кто-нибудь что-нибудь найдет", а если нашлось потом, то "ну вы плохо ж тыкали". Это не совсем квалифицированная постановка задачи как я ее вижу.
-
3) Сложный механизм учета всех глобальных переменных до начала работ. Требует полного понимания программистом проекта до начала каких-либо работ (или же системы, которая будет "светить" об изменениях в конкретных местах проекта для учета). Слишком нерентабельно - требует огромного подготовительного периода, чтобы "что-то делать" - да и мне кажется так происходит только в случае если вся разработка была на одной команде. Если то один то другой подрядчик выполняет над проектом какие-то работы, то понять на этапе первых правок "что за что завязано" может быть крайне сложно. Если добавить сюда умельцев, которые делают мега-костыли, которые убивают собственно иерархию проекта, то путь вообще в никуда.
-
В общем проблема меня задолбала. Программисты, к которым я обращаюсь - разводят руками - "так все делают" - и либо одна правка вызывает 3 дополнительных косяка - либо тратят тонну ресурсов на перепроверку.
На форуме есть эксперты и опытные специалисты в боевых задачах - я взываю к вам, может быть вы нашли решение для избежания этой проблемы, когда программисты дай бог на 10 решение генерят 2 косяка и их надо исправлять. Но иногда программисты на 1 решении генерят 3 дополнительных проблемы. И это уже ну совсем плохо.
-
Вопрос:
Как правильно этот вопрос менеджерить?
Как правильно подготовиться к изменениям и внедрениям заранее?
Что предусмотреть, чтобы это было не слишком ресурсозатратно?

Answer 1

[Константин Нагибович]

У нас на крупном проекте были внедрены автоматические тесты (вроде на Селениум), которые прогоняли основные пользовательские сценарии. Т.е. правки не должны ломать критичные процессы продукта. Остальное ловили тестировщики.
Возможно, вам надо какие-то архитектурные изменения предпринять, если у вас такие зависимости возникают.

Comments

[DevMan]

селениум - отличная штука, нужная и полезная.
но, это тяжелая артиллерия, большинство ошибок можно отловить лечге/проще/быстрее.

Answer 2

[InOdinWeTrust]

Вы подняли сложный вопрос, на который нет одного ответа. Тут нужно в первую очередь смотреть на:
1. Ценности компании.
2. Архитектуру проекта/проекта.
3. Процессы - менеджмент, разработка, тестирование,
4 . Ресурсы - команда, документация, знания, навыки, время и тд.

1. Есть, грубо говоря, набор ценностей, которые приносят компании доход.
Например - показ каталога товаров. Чем лучше показан каталог, тем больше пользователей зависает на странице, тем больше покупают/хотят/выходят на связь/ppc - неважно, что именно, но это приносит компании деньги. Поломка каталога товаров грозит потерей денег/репутации/времени/рынка. Поломка где-нибудь в личном кабинете, рассылке или другом месте, не несет таких угроз. Собственно, исходя из имеющихся ценностей и оценки рисков, должен быть список "важного" функционала. Того, который не должен ломаться.

2. Архитектура проекта может быть монолитом с точки зрения оценки рисков. Сломали одну функцию - ломается вся система. А может быть устойчивая к проблемам система - сломали одну функцию, система продолжает работать в целом. Архитектуру нужно выбирать исходя из ценностей и рисков. Самая ценная часть должна быть максимально изолирована от проблем остальной системы. Самый ценный функционал должен продолжать работать при поломке каких-то элементов. Например, изменили структуру базы данных вашего каталога товаров - каталог должен продолжать работать. Пусть показ данных будет неполным, но он будет. Закладывайте это на этапе разработки архитектуры. Делайте рефакторинг существующих проблемных мест. Фокусируйтесь на ценностях.

3. Процессы выстраиваются исходя из имеющихся ценностей.
Например, процесс согласования требований по задаче и тестирования, насколько эти требования удовлетворены
реализацией, должен учитывать ценности - то есть, учитывать приоритеты. При недостатке ресурса, следует фокусироваться на приоритетных частях системы. Менеджмент тщательнее прописывает тз по критически важному функционалу, разработчики уделяют больше внимания, ТЛ внимательнее проводят кодревью, тестировщики тестируют в первую очередь то, что важно для бизнеса. Автотесты пишутся сначала для кртически важного для бизнеса функционала.

4. Ресурс - с учетом вышеперечисленного, выдвигаются требования к ресурсу. Если для тестирования критически важных мест системы нудно 100 человекочасов и специалисты уровня "синьор" - нужно выделять эти ресурсы. В противном случае, выделять больше времени, или перераспределять больше специалистов, вычислительных ресурсов на автотесты.

Answer 3

[ApeCoder]

Эта ситуация называется "регрессия" для ее предотвращения есть регрессионное тестирование и другие техники для предотвращения ошибок.

Регрессионное тестирование может быть ручное или автоматическое. Это отдельная большая тема. Даже вручную тестировать можно не все приложение а те части, на которые скорее всего исправление повлияет.

В числе других практик можно перечислить:

• Код ревью
  
• Использование статических анализаторов
  
• Рефакторинг, чтобы сделать код более понятным
  
• Руткозинг багов (т.е. после каждой ошибки думаем, почему она была допущена и почему была не определена при тестировании, не отловлена компилятором или статическим анализатором)
  

Практически, по каждой теме вверху есть отдельная большая книжка. Читайте книжки, учите английский, ищите информацию.