На первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:
- строки кода = усилие
- строки кода = значение
- все строки кода равны
Ничто из этого не является истинным.
Почему исправление, которое кажется таким простым, заняло два дня?
- Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование. Я стараюсь получить как можно больше из той информации, которая есть в наличии. Знаю, что некоторым разработчикам не нравится исправлять ошибки, и поэтому они делают всё возможное, чтобы избавиться от них. Утверждение, что информации недостаточно, — отличный способ выглядеть так, будто вы пытаетесь помочь, но ничего не делать. Знаю, что сообщать об ошибках может быть трудно, и я благодарен всем, кто это делает. Я хочу выразить признательность за сообщения об ошибках, пытаясь извлечь как можно больше пользы из предоставленной информации, прежде чем просить подробности.
- Потому что проблема была связана с функциональностью, с которой я не знаком. Эту конкретную функцию я редко использую и никогда не разбирался в деталях. Это значит, что мне потребовалось больше времени, чтобы понять, как её использовать и разобраться в нюансах, как она взаимодействует с программным обеспечением.
- Потому что я потратил время, чтобы исследовать реальную причину проблемы, а не просто смотреть на симптомы. Если какой-то код выдаёт ошибку, вы можете просто отловить оператор и подавить ошибку. Нет ошибки, нет проблем, правильно? Извините, для меня сделать проблему невидимой — это не то же самое, что исправить ее. «Проглатывание» ошибки может легко привести к неожиданным побочным эффектам. Я не хочу иметь с ними дело в будущем.
- Потому что я исследовал, существуют ли другие способы решения получения же проблемы, а не только описанные этапы, как её воспроизвести. Определённые шаги для воспроизведения проблемы могут показать проблему в одном месте, когда на самом деле она может быть более глубоко укоренившейся. Поиск точной причины проблемы и рассмотрение всех способов её получения даёт ценную информацию. Очень полезно рассмотреть, как на самом деле используется код и где могут быть другие места с возможными (другими?) проблемы, или это может показать несоответствия в коде, которые означают, что ошибка вызвана (или обработана) в одном пути кода, но не в другом.
- Потому что я потратил время, чтобы проверить, есть ли другие части кода, которые могут быть затронуты этой проблемой. Если появилась одна ошибка, то такая же могла быть допущена и в других местах кодовой базы. Сейчас самое время это проверить.
- Потому что когда я нашёл причину проблемы, я искал самый простой способ её устранения с минимальным риском побочных эффектов. Я не стремлюсь к скорости. Я хочу исправить ситуацию так, чтобы устранить путаницу или другие проблемы в будущем.
- Потому что я тщательно протестировал это изменение и убедился, что оно решает проблему для всех различных путей кода, которые были затронуты. Я не хочу полагаться на кого-то другого, чтобы проверить, что я сделал правильно. И не хочу, чтобы ошибка была найдена в будущем, и мне придется вернуться к этому коду, когда я мысленно двинусь дальше. Переключение контекста дорого и неприятно. Наличие специального тестировщика, который должен снова посмотреть на «то же самое» изменение, — то, чего я хочу избежать, когда это возможно.
Я не люблю исправлять ошибки. Отчасти потому, что они могут ощущаться как результат предыдущей неудачи с моей стороны. Другая причина, по которой я не люблю исправлять ошибки, заключается в том, что я предпочитаю работать над новыми вещами.
Что может быть хуже, чем исправить ошибку? Необходимость исправлять одну и ту же ошибку неоднократно.
Каждый раз я трачу время на то, чтобы убедиться, что любая ошибка полностью исправлена, так что с ней не нужно сталкиваться, исследовать, исправлять и тестировать более одного раза.
Автор: m1rko
