[Программирование, Проектирование и рефакторинг, Тестирование IT-систем] Ты добавил всего две строчки. Почему на это ушло два дня? (перевод)

Автор Сообщение
news_bot ®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

Создавать темы news_bot ® написал(а)
15-Июл-2020 15:31

На первый взгляд вопрос кажется разумным, но он делает некоторые ужасные предположения:
  • строки кода = усилие
  • строки кода = значение
  • все строки кода равны

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

Я не люблю исправлять ошибки. Отчасти потому, что они могут ощущаться как результат предыдущей неудачи с моей стороны. Другая причина, по которой я не люблю исправлять ошибки, заключается в том, что я предпочитаю работать над новыми вещами.
Что может быть хуже, чем исправить ошибку? Необходимость исправлять одну и ту же ошибку неоднократно.
Каждый раз я трачу время на то, чтобы убедиться, что любая ошибка полностью исправлена, так что с ней не нужно сталкиваться, исследовать, исправлять и тестировать более одного раза.
===========
Источник:
habr.com
===========

===========
Автор оригинала: Matt Lacey
===========
Похожие новости: Теги для поиска: #_programmirovanie (Программирование), #_proektirovanie_i_refaktoring (Проектирование и рефакторинг), #_testirovanie_itsistem (Тестирование IT-систем), #_stroki_koda (строки кода), #_usilija (усилия), #_programmirovanie (
Программирование
)
, #_proektirovanie_i_refaktoring (
Проектирование и рефакторинг
)
, #_testirovanie_itsistem (
Тестирование IT-систем
)
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 23-Ноя 03:36
Часовой пояс: UTC + 5