Ограничения на исправление багов в общих модулях. Хорошо ли?
От: VetalB  
Дата: 29.03.10 11:51
Оценка:
Всем привет!

Ситуация следующая. Есть большая система. Она состоит из многих модулей (несколько десятков). Некоторые модули являются общими для других модулей. За каждый модуль ответственны соответствующие подразделения в компании. Никто не имеет право вносить изменения в этот модуль, кроме соответствующих подразделений.

Как Вы думаете, хорош ли такой подход?

Конкретная ситуация:
Обнаружен баг в одном из общих модулей разработчиками частного модуля (от которого другие модуля не зависят). Баг в том, что нет проверки на входной параметр. При недопустимом входном параметре все валится. Разработчики частного модуля были бы и рады вставить проверку в общий, вот только прав у них на такое нет. А вставлять в общий код — это сложный длительный процесс, включащий в себя написание заданий в баг-треккинг систему и ожидания, когда у разработчиков общего модуля освободятся ресурсы для разработки. А так как сроки жмут, разработчики частного модуля делают workaround и вставляют код проверки в свой частный модуль. В итоге мы имеем риски, что этот баг вылезет в других частных модулях.

Вопрос. Подскажите, пожалуйста, как все же лучше поступить в этой ситуации? Дать права на внесения изменений в модуля всем подразделениям? Или оставить как есть? Или вносить изменения в частные модуля с написанием баг-репорта разработчикам основного модуля? Или есть еще какой оптимальный вариант?
Re: Ограничения на исправление багов в общих модулях. Хорошо
От: Denis Mingulov Финляндия http://denis.mingulov.com
Дата: 29.03.10 13:37
Оценка: +1
Здравствуйте, VetalB, Вы писали:

VB>Вопрос. Подскажите, пожалуйста, как все же лучше поступить в этой ситуации?

Оставить как есть, сторонней команде пробовать разными способами повышать приоритет бага.
Re: Ограничения на исправление багов в общих модулях. Хорошо
От: bkat  
Дата: 30.03.10 06:55
Оценка: +2
Я бы оставил как есть.
Баг-репорт все равно надо заводить, не важно кто нашел проблему и кто в состоянии ее пофиксить.
Если баг нужно срочно поправить, то ставьте высокий приоритет.
Чужая команда, которая думает, что может легко поправить баг,
может в спешке не учесть какие-то вещи.
Но чужая команда вполне может предложить вариант своего решения
при описании бага.

Если дать возможность править общий модуль всем подряд,
то велик риск, что он быстро превратится в набор заплаток.
Re: Ограничения на исправление багов в общих модулях. Хорошо
От: Roman Odaisky Украина  
Дата: 30.03.10 16:44
Оценка: +3
Здравствуйте, VetalB, Вы писали:

VB>Вопрос. Подскажите, пожалуйста, как все же лучше поступить в этой ситуации?


Исправить баг общего модуля в локальном репозитарии. Повесить баг, приоритизировать, приложить к нему патч. Если для приоритетных багов не находится ресурсов, исправлять проблему в консерватории.
До последнего не верил в пирамиду Лебедева.
Re: Ограничения на исправление багов в общих модулях. Хорошо
От: sharpcoder Россия  
Дата: 28.06.10 16:52
Оценка:
Здравствуйте, VetalB, Вы писали:

VB>Всем привет!


VB>Ситуация следующая. Есть большая система. Она состоит из многих модулей (несколько десятков). Некоторые модули являются общими для других модулей. За каждый модуль ответственны соответствующие подразделения в компании. Никто не имеет право вносить изменения в этот модуль, кроме соответствующих подразделений.


VB>Как Вы думаете, хорош ли такой подход?


Хорош, даже очень. Если баг в высоком приоритете — нужно добиваться его исправления. В противном случае — просто заносить в очередь.
Re: Ограничения на исправление багов в общих модулях. Хорошо
От: Gaperton http://gaperton.livejournal.com
Дата: 28.06.10 20:48
Оценка: +3
Здравствуйте, VetalB, Вы писали:

VB>Ситуация следующая. Есть большая система. Она состоит из многих модулей (несколько десятков). Некоторые модули являются общими для других модулей. За каждый модуль ответственны соответствующие подразделения в компании. Никто не имеет право вносить изменения в этот модуль, кроме соответствующих подразделений.


VB>Как Вы думаете, хорош ли такой подход?


Можно заменить запрет на внесение изменений в модуль сторонними людьми требованием обязательного code review изменений в модуль, проводимого его "владельцем". Эффект тот же, система гибче.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.