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

Question

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

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

Answer 1

Это действительно зависит от проблемы.

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

Опять же, если реальные деньги теряются, необходимость их быстрого исправления может быть больше, чем необходимость их безопасного и полного исправления.

Что бы вы ни делали и / или исправляли, убедитесь, что вы записали все свои изменения и просмотрите их в замедленном режиме, чтобы проверить возможные ошибки.

Answer 2

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

Самое главное - остановить огонь и порадовать клиента.

Как только это будет сделано, вам нужно запланировать дополнительную работу, чтобы все это заработало; исправьте ошибки «окружения», попросите QA выполнить планы тестирования, и после этого вы сможете создать еще один «официальный» выпуск, который официально исправит первоначальную проблему и обеспечит более высокий уровень безопасности.

Answer 3

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

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

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

Answer 4

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

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

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