В последнее время неоднократно сталкивался с такой ситуацией и не до конца уверен, что я в ней прав..
Предусловия: к релизу есть несколько задач (исправленных багов), близится дедлайн, откат коммита из релизной ветки проблематичен и нежелателен.
В результате тестирования выясняется, что одн из фич- реализована, но не работает (или баг все еще воспроизводится).
Первый вариант действий: продолбать сроки релиза, но доделать фичу(исправить баг).
Второй вариант действий: катить релиз как есть, так как хуже не будет (тестирование кроме этого ничего не выявило). То есть фичи как нет, так и не появится (баг как воспроизводился, так и воспроизводится). Фактически - ничего не изменится в этом плане и ничего плохого не случится.
Мне не нравится второй вариант, так как мы добавляем или меняем некий объем кода, который должен менять функциональность, но не делает этого. Поэтому я за первый вариант.
Мне интересно ваше мнение на эти счета. Вот только не надо нудить о приоритетах, срочности, критичности. Чаши весов (сроки и необходимость фичи) уравновешены и выбор зависит целиком от ваших религиозных взглядов и мировоззрения.
может быть у вас есть свои варианты - но с учетом условий.
Предусловия: к релизу есть несколько задач (исправленных багов), близится дедлайн, откат коммита из релизной ветки проблематичен и нежелателен.
В результате тестирования выясняется, что одн из фич- реализована, но не работает (или баг все еще воспроизводится).
Первый вариант действий: продолбать сроки релиза, но доделать фичу(исправить баг).
Второй вариант действий: катить релиз как есть, так как хуже не будет (тестирование кроме этого ничего не выявило). То есть фичи как нет, так и не появится (баг как воспроизводился, так и воспроизводится). Фактически - ничего не изменится в этом плане и ничего плохого не случится.
Мне не нравится второй вариант, так как мы добавляем или меняем некий объем кода, который должен менять функциональность, но не делает этого. Поэтому я за первый вариант.
Мне интересно ваше мнение на эти счета. Вот только не надо нудить о приоритетах, срочности, критичности. Чаши весов (сроки и необходимость фичи) уравновешены и выбор зависит целиком от ваших религиозных взглядов и мировоззрения.
может быть у вас есть свои варианты - но с учетом условий.
Я буду нудить :)
ОтветитьУдалитьЗависит от моих обязательств по срокам и качеству. Если условно дешевле продолбать срок, то пойду по первому варианту. Если условно дешевле выполнить обязательство по релизу, то по второму.
Но вариантов может быть много. Нельзя откатить коммит - зато наверняка можно отревертить. Или хотя бы спрятать багу, заменить полу-рабочий код или интерфейс заглушкой (а потом доделать).
...а другие варианты не написал, потому что меня отвлекли, и я их забыл. Но вообще, если подойти к делу с фантазией, то можно придумать ещё что-нибудь.
УдалитьМне интересно не влияние обстоятельств, а твое личное решение.
УдалитьИз ответа понял, что ты предпочтешь выпустить.
Разработчик.
Я бы тоже смотрела по затратности. Т.е. если дешевле продолбать, но выкатить (чем огребать возможные последствия) - то долбить. Если же срыв сроков затратнее - то вдыхать-выдыхать. Вариант с заглушкой из коммента тоже интересный
ОтветитьУдалитьЯ сказал - чаши весов уравновешены и решение - твоя вера, твоя версия на все эти счета. Чинить, выпустить?
УдалитьВ реальности каждый участник группы разработки принимает массу микрорешений ни с кем не советуясь.
Спросить у клиента, важна ли ему эта фича настолько, чтобы задерживать релиз. Решать за клиента - не дело разработки (или тестирования).
ОтветитьУдалитьКончайте эти сопли!
УдалитьТы не будешь спрашивать дядю с деньгами за каждый чих, из ста решений минимум девяносто - твои.
О них я и спрашиваю.
Второй вариант - выкатывать с ошибкой, плюс следом патч.
ОтветитьУдалитьКлиент не дурак, сам будет тестировать перед установкой - за это время выпустишь патч.