Учимся исследовать ошибки [закрыто]

11

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

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

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

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

Джей Карр
источник
3
представьте, как вы думаете, что это может работать, и работайте в обратном направлении от выходов к входам, чтобы найти пути для расследования
Стивен А. Лоу
1
Я брошу ссылку там - Как стать программистом - первым навыком в списке будет «Научиться отлаживать».
1
Я хотел выбросить кое-что относительно мышления "из коробки". Что касается ошибок, я часто думаю, что первое, что нужно сделать, это просто перечислить все взаимодействующие системы, а затем предположить, что любая его часть может быть ошибочной, пока не доказано обратное. Тогда ваша работа станет проще: предположим, что компонент выходит из строя, и найдите способ, которым он мог бы, даже если поначалу он кажется нелогичным («вывод искажен» и т. Д.). Затем докажите, что ваш компонент не выходит из строя, начиная с самых непосредственных взаимодействий. После этого это может показаться воображением, но часто это просто начинается с пессимистического взгляда.
J Trana
Напишите printfили printlnили что вы используете под каждой строкой кода, чтобы быть на 100% уверенным, что все работает так, как вы хотите, чтобы это работало, ха-ха. Затем запустите консольное приложение, а App > out.txtзатем начнется сложная часть просмотра огромного файла ... иногда мои файлы журнала занимают несколько миллионов строк, и это может занять некоторое время, ха-ха. Конечно, правильным способом было бы использовать отладчик и точки останова, но иногда это невозможно сделать.
SSpoke
1
Прочитайте Дзен Пирсига и искусство обслуживания мотоциклов. Amazon.com/Zen-Art-Motorcycle-Maintenance-Inquiry/dp/0060589469
Джеффри Кемп,

Ответы:

11

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

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

Килиан Фот
источник
3
Ненавижу это говорить, Киллиан, но я думаю, что ты ударился ногтем по голове. Я очень гордился своими «знаниями» о системах, которые я приобрел за то время, что я здесь, и я думаю, что я мысленно сопротивляемся идее быть неправым. Как я уже упоминал, я никогда не отличался смирением. Следование вашему совету оспаривать мои собственные предположения фактически позволило мне добиться определенного прогресса в решении пары проблем, с которыми я столкнулся в своем собственном коде. Так что, спасибо, я буду иметь это в виду в будущем.
Джей Карр
2
@JayCarr: « психологически устойчив к идее быть неправым ». Что если вы попытаетесь увидеть ошибки как источник обучения, а не как ошибку? Нет ничего плохого в том, что ты не прав, пока ты не остановился на этом.
JensG
14

Что мне нужно сделать, чтобы помочь моему, по-видимому, ограниченному воображению придумать способы, которыми мой проект мог быть сломан?

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

Вы должны войти в процесс отладки со следующей информацией:

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

Если есть сообщение об ошибке, получите всю информацию о ней. Если само сообщение об ошибке неясно, и вы не знаете, что оно означает на практике (некоторые сообщения об ошибках не всегда особенно полезны), то используйте Google, или StackOverflow, или любой другой онлайн-ресурс, чтобы найти информацию о нем. ,

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

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

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

Все еще не знаете, в чем проблема? Попросите кого-нибудь о помощи . Сотрудник, друг, интернет-сообщество. Покажите им всю ту работу, которую вы только что сделали. Покажите им сообщения об ошибках, трассировки стека, объясните, что программа делает в общих чертах (если они еще не знают), что она должна делать в данном конкретном случае (например, возвращая значение 4), что она фактически делает (например, возвращая значение 5). Если вы сузили его до нескольких строк кода в отладчике, скажите: «Я знаю, что проблема вызвана этими строками в коде, он устанавливает значение X, когда оно должно быть Y, но я не вижу почему это происходит ".

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

Энтони Грист
источник
Возможно, я был немного быстр, чтобы судить об этом ответе, был немного разочарован, когда я прочитал его. Здоровый совет. Я думаю, что комментарии Киллиана просто больше говорили о сути моей проблемы. Это единственная причина, по которой это не выбранный ответ.
Джей Карр
4

В какой-то степени это похоже на расследование уголовного дела или невероятную загадку.

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

Бывает, что время от времени вы заходите в тупик (каламбур). Это часть этого, и в этом нет ничего плохого, если вам удастся как можно быстрее вернуться на правильный путь. Ключ в том, чтобы всегда думать о том, какая часть информации вам нужна дальше, которая либо подкрепляет вашу гипотезу (и предоставляет вам дополнительную информацию), либо доказывает, что она неверна. Затем найдите способ получить эту информацию эффективным образом, сделайте выводы и двигайтесь дальше, пока, наконец, вы не сможете осудить виновного.

И иногда вы понимаете, что все факты и признаки, необходимые для выявления виновного, уже ждали вас перед вами полчаса назад. Хотя это и раздражает, это одна из самых интересных частей, потому что если вы критически оцените свои действия и ошибки, вы сможете учиться и становиться лучше . Задайте себе такие вопросы, как:

  • Как я мог избежать этой пустой траты времени?
  • Что я упустил в первую очередь и почему?
  • На какие непроверенные и / или неправильные предположения я опирался?

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

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

JensG
источник
3

Что мне нужно сделать, чтобы помочь моему, по-видимому, ограниченному воображению придумать способы, которыми мой проект мог быть сломан?

Пусть история будет вашим проводником. Если ваш проект хорошо управляется, у вас должна быть база данных каждой ошибки, которая когда-либо была исправлена ​​в продукте, вместе с анализом того, как ошибка была обнаружена, как она была воспроизведена, как она была проанализирована и как она была исправлена. Это не база данных только для записи. Прочитайте базу данных , и очень скоро ошибки таксономии начнут происходить с вами.

Это даст вам хороший обзор тех вещей, которые идут не так в вашем продукте. Если вы заинтересованы в более широком понимании того, что идет не так во всех видах программного обеспечения, особенно с акцентом на дефекты, влияющие на безопасность, я предлагаю вам прочитать список CWE: http://cwe.mitre.org/data/index.html

Эрик Липперт
источник
2

Поэтому вместо того, чтобы пытаться воспроизвести и исправить конкретный дефект, я полагаю, что вы спрашиваете о том, чтобы придумать новые тесты, которые вы могли бы использовать для исследования продукта, например, чтобы выяснить, работает ли продукт в таких условиях: что произойдет, если я введу специальные символы в нашу зарегистрируйте пароль страницы, или что произойдет, если я принудительно закрою программу во время ее записи в базу данных. Эти случаи действительно трудно придумать.

За последние 10 лет разработка программного обеспечения (Agile / XP / TDD и т. Д.) Пришла к выводу, что он отвечает только явным требованиям, а затем объявляет, что функция завершена, и не находит всевозможных способов что-то сломать (возможны исключения, если вы работая на НАСА или занимаясь защитой белой шляпы, но даже в этом случае необходимо предусмотреть такие условия в критериях приемлемости пользовательской истории).

Поэтому, если ваши функции явно указывают в качестве критериев приемлемости то, что нужно делать системе, например, как обрабатывать ввод, его характеристики производительности, действия рабочего процесса пользователя и т. Д., У вас есть полный список того, что тесты должны проверять. Тестирование должно быть выполнено, чтобы проверить, что требования были выполнены, и лучший способ сделать это - явно перечислить все ваши требования. Взгляните на Agile Test Quadrants .

Некоторые люди рекомендуют, чтобы эти тесты были явным заявлением о требованиях, которые должны быть написаны перед кодом, т.е. Test First (или Test Driven Development).

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

Как только вы найдете требование - оно должно быть надежным / оно должно быть безопасным, затем попытайтесь копать глубже и выяснить, насколько оно должно быть безопасным или насколько допустим сбой, всегда есть предел, не у многих людей есть подтверждение АНБ. уровень безопасности в качестве требования для их применения или хотел бы заплатить за это. Чем больше вы копаете, тем яснее должны быть данные о том, от каких типов атак безопасности вам нужно защищаться или от которых вы легко пользуетесь. Некоторые знания предметной области будут полезны в области безопасности, дизайна, производительности и т. Д., Где вы можете задать еще больше вопросов экспертам, которых вы можете найти в вашей команде, или здесь, на SE, или в google / books.

Encaitar
источник
Не совсем тот вопрос, на который я хотел бы ответить, но тем не менее отличный комментарий. Я голосую за вас, это очень полезный комментарий.
Джей Карр