Исправление ошибки в жестких временных рамках

Question

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

Я хотел бы узнать от сообщества лучшие практики, которым нужно следовать в таких критических по времени условиях. Можно ли пренебрегать другими проблемами (которые не являются причиной ошибки, над которой вы работаете)? Как ограничить изменения кода, это также в устаревшем коде, насколько это возможно, так что мне не нужно беспокоиться о том, что возможно только минимальное тестирование. Непрерывная работа без достаточных перерывов также может добавить свои проблемы. Пожалуйста, поделитесь своими мыслями и опытом.

Answer 1

Здесь уже есть несколько полезных советов, но я бы хотел добавить еще кое-что:

Если вы просто проверяете исправление ошибки в условиях экстремального времени, не забудьте вернуться и посмотреть на это исправление, когда давление сбрасывается, чтобы убедиться, что это не просто ужасный взлом, который является бандой над реальной проблемой. 1003 *

Еще в конце 1980-х я исправил ошибку, которая была глубоко в очень старой программе. Но это не сработало в одном случае, который работал. Когда я продолжил расследование, я обнаружил, что была создана временная работа. В комментарии сказано:

C TEMPORARY WORK-AROUND UNTIL I FIND THE REAL CAUSE.  I CHARNY, SUMMER STUDENT, AUG 1971

Ирв Чарни был моим начальником, когда я нашел этого 15-летнего «временного обходного пути».

Answer 2

Очевидна лучшая практика не «Непрерывно работать без достаточных перерывов»

Другой вариант - поставить вас на коммерческий уровень и руководствоваться здравым смыслом. Каков риск того, что вы представили другую серьезную или более серьезную ошибку? Как на это отреагирует клиент? Как отреагирует клиент, если вы объясните свою потребность в дополнительном времени? Взвесьте ответы и примите коммерческое / исполнительное решение.

Answer 3

Независимо от того, что вы делаете, ваша программа будет содержать ошибки .

Все, что вы можете сделать, это сделать все возможное, в сроки, указанные вашим начальником / компанией.

Answer 4

Этот вопрос вызывает у меня ряд вопросов.

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

Не только это, но и в рабочей культуре, которая способствует этому сумасшествию, вы, как правило, должны появиться на следующий день в 8 утра, готовые продолжать давать 100%. Когда вы молоды, ваше тело справится с определенным количеством этого, но в середине 20-х у вас будут серьезные побочные эффекты. Черт возьми, даже когда ты молод, ты можешь оставаться без сна так долго. Если вы находитесь в состоянии сна без сна, это может стоить вам жизни.

Я надеюсь, что вы сможете подготовить хороший пример для руководства вашей компании для более разумной практики. Практически любой клиент (независимо от того, насколько он настойчив) может быть убежден, что лучше подождать неделю, чем рисковать своим бизнесом, связанным с программным обеспечением, с ошибкой showtopper. Марафон ночного кодирования может быть нормальным для редкой ситуации, но когда он становится обычным явлением, все страдают.

Answer 5

Ответ от AnthonyWJones, приведенный выше, правильный, в основном

Еще один ставит вас на коммерческую голову и использовать здравый смысл, что такое риск, что вы ввели другой как серьезный или более серьезный баг? Как будет клиент реагирует на это? Как будет клиент реагирует, если вы объясните нужно больше времени? Взвесьте ответы и сделать коммерческий / исполнительный решение

Но что значит «взвешивать» ответы? Это означает, что вы начинаете присваивать веса вещам буквально: вы останавливаетесь, делаете перерыв, составляете список и продумываете его. Вы должны сказать клиенту, что это невозможно? Каков риск того, что небольшая ошибка станет причиной остановки шоу, которую вы представили в своей недельной безумной гонке?

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

Если клиент слишком занят, чтобы разговаривать с вами, вы должны объяснить (по электронной почте или в виде пятен крови, что угодно), что вы закорачиваете QA и, возможно, вносите в процесс другие ошибки. Вам нужно будет вкратце поговорить о вероятности того, что более важен, чем рассматриваемая ошибка. У вас есть опыт и вы знаете, что делаете (в некоторой степени), поэтому вы должны помочь клиент должен понять, насколько безумен (или нет) то, что он просит.

В любом случае, немного побродив, вот моя точка зрения: Ваша задача - сохранять спокойствие и выполнять свою работу. Я сомневаюсь, что, работая много дней без перерывов, вы действительно обнаружили ошибку быстрее : вы, вероятно, пытались идти слишком быстро. Ваша задача также состоит в том, чтобы информировать вашего клиента о том, что возможно, что нет, и какие риски возникают при каждом решении. Но идти быстрее, чем быстрее всех - например, не делать перерывов - не имеет смысла и никому не помогает.

Но во всех случаях нечего терять Дзен. Когда-либо.

Answer 6

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

Answer 7

Если вы заметили что-то не так в источнике, который никогда не вызывал проблемы, не исправляйте это без тщательного тестирования !!

Вы можете обнаружить, что неправильный код никогда не вызывался, но также может быть что-то не так в другом месте, например, «исправление» этой ошибки, а изменение исходного кода для правильной работы может привести к поломке приложения!

Так что, если у вас недостаточно времени для тестирования, не исправляйте вещи, не связанные с вашей текущей проблемой! Обратите внимание на это, исправьте это позже с помощью обширного тестирования.

Answer 8

Приложение было протестировано с вашими обычными тестовыми примерами , прежде чем вы начали над ним работать. Так что, если у вас есть только небольшие временные рамки для внесения конкретных изменений, это единственное изменение, которое вы должны сделать. Хотя вы должны тщательно протестировать этот случай и выполнить как можно больше регрессионных тестов, вы, вероятно, будете в порядке.

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

Answer 9

Когда вы находитесь под чрезвычайным давлением времени, вы должны заставить его работать. Тем не менее, важно рассмотреть ваше решение, чтобы убедиться, что оно действительно решает проблему. Вы должны понимать соответствующий код, знать, как возникла проблема, и убедиться, что исправление является правильным. Слишком часто патчи выбрасываются только для того, чтобы быть неправильными и вызывать другой быстрый патч.

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

В общем, это ужасная ситуация, и нет элегантного решения. Просто убедитесь, что вы движетесь в направлении, в котором вы не сталкивались с такими проблемами.

Answer 10

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