На первый взгляд вопрос кажется разумным.
- Потому что описание проблемы была расплывчато, и чтобы ее воспроизвести, потребовалось много времени.
Разработчик, первым делом, обратиться к человеку, который сообщил о проблеме. Постарается узнать больше деталей, чтобы понять, как воспроизвести проблему. На коммуникации тратится очень много времени. А если задача не была начата в ближайшее время, то будет тратиться много времени хотя бы на то, чтобы вспомнить об этой проблеме. - Потому что проблема была связана с функциональностью, с которой я не знаком.
Т.к. программист не занимался функционалом, в котором требуется выполнить исправление, ему потребуется больше времени, чтобы разобраться в деталях и нюансах работы ПО. - Потому что я потратил время, чтобы исследовать реальную причину проблемы, а не просто смотреть на симптомы. Если какой-то код выдаёт ошибку, вы можно просто обернуть его в оператор try-catch и скрыть ошибку. Нет ошибки, нет проблем, правильно? Извините, для меня сделать проблему невидимой — это не то же самое, что исправить ее. «Проглатывание» ошибки может легко привести к неожиданным побочным эффектам.
- Потому что я исследовал, существуют ли другие способы воспроизведения проблемы, а не только описанные этапы. Определённые шаги для воспроизведения могут показать проблему в одном месте, когда на самом деле она может быть более глубокой. Поиск точной причины проблемы и рассмотрение всех способов её получения даёт ценную информацию. Очень полезно рассмотреть, как на самом деле используется код и где могут быть другие места с возможными (другими?) проблемами.
- Потому что я потратил время, чтобы проверить, есть ли другие части кода, которые могут быть затронуты этой проблемой. Если появилась одна ошибка, то такая же могла быть допущена и в других местах кодовой базы. Сейчас самое время это проверить.
- Потому что когда я нашёл причину проблемы, я искал самый простой способ её устранения с минимальным риском побочных эффектов. Я не стремлюсь к скорости. Я хочу исправить ситуацию так, чтобы устранить и другие проблемы в будущем.
- Потому что я тщательно протестировал это изменение и убедился, что оно решает проблему для всех вариантов работы кода, которые были затронуты. Я не хочу полагаться на кого-то другого, чтобы проверить, что я сделал правильно. И не хочу, чтобы ошибка была найдена в будущем, чтобы мне пришлось вернуться к этому коду, когда я уже забуду её контекст. Переключение контекста дорого и неприятно. Наличие специального тестировщика, который должен снова посмотреть на «то же самое» изменение, — то, чего я хочу избежать, когда это возможно.
Я не люблю исправлять ошибки. Я предпочитаю работать над новыми вещами.
Что может быть хуже, чем исправить ошибку? Необходимость исправлять одну и ту же ошибку неоднократно.
Автор: @eantonov
Телеграм: Тимлид Очевидность
Обсудить: Чат канала в телеграм
