[Программирование, Проектирование и рефакторинг, Тестирование IT-систем] Ты добавил всего две строчки. Почему на это ушло два дня? (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
На первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:
- строки кода = усилие
- строки кода = значение
- все строки кода равны
Ничто из этого не является истинным.
Почему исправление, которое кажется таким простым, заняло два дня?
- Потому что проблема была расплывчатым описанием того, как её воспроизвести. Мне потребовалось несколько часов, чтобы надёжно её воспроизвести. Некоторые разработчики немедленно бы обратились к человеку, сообщившему о проблеме, и потребовали бы больше информации, прежде чем проводить расследование. Я стараюсь получить как можно больше из той информации, которая есть в наличии. Знаю, что некоторым разработчикам не нравится исправлять ошибки, и поэтому они делают всё возможное, чтобы избавиться от них. Утверждение, что информации недостаточно, — отличный способ выглядеть так, будто вы пытаетесь помочь, но ничего не делать. Знаю, что сообщать об ошибках может быть трудно, и я благодарен всем, кто это делает. Я хочу выразить признательность за сообщения об ошибках, пытаясь извлечь как можно больше пользы из предоставленной информации, прежде чем просить подробности.
- Потому что проблема была связана с функциональностью, с которой я не знаком. Эту конкретную функцию я редко использую и никогда не разбирался в деталях. Это значит, что мне потребовалось больше времени, чтобы понять, как её использовать и разобраться в нюансах, как она взаимодействует с программным обеспечением.
- Потому что я потратил время, чтобы исследовать реальную причину проблемы, а не просто смотреть на симптомы. Если какой-то код выдаёт ошибку, вы можете просто отловить оператор и подавить ошибку. Нет ошибки, нет проблем, правильно? Извините, для меня сделать проблему невидимой — это не то же самое, что исправить ее. «Проглатывание» ошибки может легко привести к неожиданным побочным эффектам. Я не хочу иметь с ними дело в будущем.
- Потому что я исследовал, существуют ли другие способы решения получения же проблемы, а не только описанные этапы, как её воспроизвести. Определённые шаги для воспроизведения проблемы могут показать проблему в одном месте, когда на самом деле она может быть более глубоко укоренившейся. Поиск точной причины проблемы и рассмотрение всех способов её получения даёт ценную информацию. Очень полезно рассмотреть, как на самом деле используется код и где могут быть другие места с возможными (другими?) проблемы, или это может показать несоответствия в коде, которые означают, что ошибка вызвана (или обработана) в одном пути кода, но не в другом.
- Потому что я потратил время, чтобы проверить, есть ли другие части кода, которые могут быть затронуты этой проблемой. Если появилась одна ошибка, то такая же могла быть допущена и в других местах кодовой базы. Сейчас самое время это проверить.
- Потому что когда я нашёл причину проблемы, я искал самый простой способ её устранения с минимальным риском побочных эффектов. Я не стремлюсь к скорости. Я хочу исправить ситуацию так, чтобы устранить путаницу или другие проблемы в будущем.
- Потому что я тщательно протестировал это изменение и убедился, что оно решает проблему для всех различных путей кода, которые были затронуты. Я не хочу полагаться на кого-то другого, чтобы проверить, что я сделал правильно. И не хочу, чтобы ошибка была найдена в будущем, и мне придется вернуться к этому коду, когда я мысленно двинусь дальше. Переключение контекста дорого и неприятно. Наличие специального тестировщика, который должен снова посмотреть на «то же самое» изменение, — то, чего я хочу избежать, когда это возможно.
Я не люблю исправлять ошибки. Отчасти потому, что они могут ощущаться как результат предыдущей неудачи с моей стороны. Другая причина, по которой я не люблю исправлять ошибки, заключается в том, что я предпочитаю работать над новыми вещами.
Что может быть хуже, чем исправить ошибку? Необходимость исправлять одну и ту же ошибку неоднократно.
Каждый раз я трачу время на то, чтобы убедиться, что любая ошибка полностью исправлена, так что с ней не нужно сталкиваться, исследовать, исправлять и тестировать более одного раза.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Matt Lacey
===========Похожие новости:
- [Go, Алгоритмы, Программирование, Процессоры] Go и кэши CPU (перевод)
- [Машинное обучение, Программирование, Учебный процесс в IT] Data Science, ИИ и машинное обучение без программирования (перевод)
- [Алгоритмы, Программирование] Алгоритм Джонсона на орграфе с отрицательными дугами
- [JavaScript, Программирование, Разработка веб-сайтов] 155 вопросов по JavaScript
- [Swift, Изучение языков, Программирование, Разработка мобильных приложений, Разработка под iOS] Делегаты и колбэки в Swift простым языком. Что же такое этот delegate, и как работает callback
- [Системное программирование, Программирование микроконтроллеров, Компьютерное железо] Делаем голову шинного USB-анализатора на базе комплекса Redd
- [Анализ и проектирование систем, Микросервисы, Программирование, Управление разработкой] Архитектура — Декларативна. Реализация — Императивна. Все остальное — Бюрократия
- [Интерфейсы, Программирование, Разработка веб-сайтов, Учебный процесс в IT] Задачи для фронтенд-тренировки: реализуем отдельные элементы интерфейсов YouTube, Instagram, Spotify, GitHub (перевод)
- [Разработка веб-сайтов, JavaScript, Программирование, ReactJS] Типичные ошибки джунов, использующих React (перевод)
- [Программирование, Тестирование IT-систем] Фрактальное тестирование
Теги для поиска: #_programmirovanie (Программирование), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_testirovanie_itsistem (Тестирование IT-систем), #_stroki_koda (строки кода), #_usilija (усилия), #_programmirovanie (
Программирование
), #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
), #_testirovanie_itsistem (
Тестирование IT-систем
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 03:36
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
На первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:
Ничто из этого не является истинным. Почему исправление, которое кажется таким простым, заняло два дня?
Я не люблю исправлять ошибки. Отчасти потому, что они могут ощущаться как результат предыдущей неудачи с моей стороны. Другая причина, по которой я не люблю исправлять ошибки, заключается в том, что я предпочитаю работать над новыми вещами. Что может быть хуже, чем исправить ошибку? Необходимость исправлять одну и ту же ошибку неоднократно. Каждый раз я трачу время на то, чтобы убедиться, что любая ошибка полностью исправлена, так что с ней не нужно сталкиваться, исследовать, исправлять и тестировать более одного раза. =========== Источник: habr.com =========== =========== Автор оригинала: Matt Lacey ===========Похожие новости:
Программирование ), #_proektirovanie_i_refaktoring ( Проектирование и рефакторинг ), #_testirovanie_itsistem ( Тестирование IT-систем ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 03:36
Часовой пояс: UTC + 5