![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
najasМне понравилась лекция про debugging в курсе Introduction to Computer Science and Programming, который я сейчас слушаю. Настолько, что я перевела ее кусок. Спасибо ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
tinmonument за редактуру. Благодаря ему этот текст стал заметно меньше похож на результат работы электронного переводчика.
Итак, слово о дебаггинге (отладке программы). Откуда взялось это название? Это забавная история. 9 сентября 1947 года был зарегистрирован один из первых багов в истории компьютерных программ (демонстрирует картинку). Это лабораторный журнал Грейс Марри Хоппер. Позже — адмирала Грейс Марри Хоппер, первой женщины-адмирала в американском флоте. А также одного из первых программистов. Она пыталась написать эту программу, и программа не работала. Это была сложная программа, вычисляющая арктангенс. Представляете, целая рабочая группа, пытающаяся вычислить арктангенс. Другие времена... Они пытались запустить программу, программа долго считала, а потом просто остановилась и больше не работала. Они долго искали, в чем причина, и наконец нашли. В реле номер 70 попала моль (По-английски «bug» — «букашка»). И реле захлопнулось на бедняжке. Министерству обороны было плевать на смерть моли, единственное, что их волновало — неработающее реле. Останки моли вынули и реле опять заработало.
Прекрасная история, а главное правдивая. Но это было не первое использование слова «баг» в этом смысле. Я попробовал отследить его раньше, и самое раннее употребление я обнаружил в 1896 году. В руководстве по электротехнике.
Сейчас «дебаггинг» — это навык, которому можно научиться. Никто не владеет этим навыком от рождения. Люди учатся этому медленно, а потом наступает озарение. Вы ухватываете суть процесса. Я надеюсь, что сегодняшняя лекция поможет вам освоить этот навык быстрее. А когда вы его освоите, вы обнаружите, что можете применять его не только для отладки компьютерных программ, но и для отладки других сложных систем. Например, в лаборатории. Почему эксперимент не работает? Я несколько раз читал лекции в больницах, врачам, о диагностике сочетаний болезней. И я рассказывал им почти то же самое, что собираюсь сейчас рассказать вам.
Для начала я хочу развеять несколько мифов о багах. Первый миф — что баги заползают в программы. Может быть, это было правдой в те времена, когда жук мог залететь или заползти в реле, но сейчас это уже неактуально. Сейчас, если в вашей программе есть баг, это может быть только оттого, что вы же его туда и засунули. Т.е. допустили ошибку. Нам нравится называть их «багами», потому что от этого мы сами себе кажемся умнее, но гораздо лучшим названием для «бага» была бы «ошибка».
Другой миф — что баги размножаются. Это не так. Если в программе много багов, то это потому, что вы сделали много ошибок. А не потому, что вы сделали две, а они спарились и наплодили детишек. И это хорошо. Обычно, даже притом, что они не размножаются, в программе их много. И помните, что цель дебаггинга не в том, чтобы уничтожить один баг, а в том, чтобы в программе было как можно меньше багов. Я подчеркиваю это потому, что от этого часто зависит стратегия наших действий. Цель — не уничтожать баги один за другим, а найти способ прихлопнуть их все.
Должны ли вы гордиться, если нашли баг? Ко мне приходят аспиранты и говорят: «Я нашел баг в своей программе!» И они ужасно горды собой. А я, в зависимости от настроения, либо поздравляю их, либо говорю: «То есть ты облажался? Исправляй!» Если вы нашли один баг в программе, наверняка их там больше. В любом случае, представьте, что вы на званом обеде, сидите за столом, вдруг слышите БАХ, и хозяйка входит с индейкой на подносе со словами: «Я только что убила последнего таракана!» Наверняка это не улучшит ваш аппетит. Подумайте об этом.
По крайней мере сорок лет люди пишут программы-дебаггеры. На мой взгляд, бóльшая их часть не стоит внимания. Лучшими методами дебаггинга по-прежнему остаются всё те же два. Это команда «print» (выводящая на экран результат любой операции) и чтение кода. А самое важное — работать методично. Это то, что отличает хороших отладчиков от плохих. Хорошие отладчики выработали эффективную методику поиска багов, и делают они это, последовательно сокращая область поиска, чтобы найти источник проблемы. В этом семестре мы потратили немало времени на изучение алгоритмов поиска. Дебаггинг — это просто поиск. Когда вы ищете элемент в списке, вы же не выбираете элементы случайным образом, надеясь, что наткнетесь на искомый. В то же время я часто вижу людей, которые ищут баги в программе, кажется, совершенно произвольным образом. Так можно отлаживать программу до бесконечности.
Итак, отладка начинается, когда мы обнаруживаем проблему. Первым делом, читая код программы, задайте себе вопрос, как получилось, что программа выдала вам ошибочный результат? Обратите внимание, мы не задаемся вопросом о том, почему программа не выдала нам ожидаемый результат. Если мы поймем, почему она сделала то, что сделала, мы уже наполовину решим проблему.
Следующий вопрос, который вы должны задать — есть ли у этого бага семья? То есть, был ли это единичный баг или ошибка, которую вы допускали систематически при написании программы.
И наконец, последний вопрос. Как исправить ошибку. Когда я думаю об отладке, я стараюсь думать в терминах, выученных в школе — в терминах научного метода. (Возможно, я выдаю свой возраст... Научный метод все еще изучают в школе? Да? Хорошо. Значит, еще не все потеряно для американской системы образования.) Итак, что мы должны сделать согласно научному методу?
Первое — изучить все имеющиеся данные. В нашем случае — все результаты тестирований программы. И, говоря «все», я имею в виду все, а не только те, которые выдали ошибку. Возможно, программа сработала с одними исходными данными, а с другими не сработала. И, возможно, это позволит вам быстрее быстрее найти баг, чем если вы сосредоточитесь только на ошибках в работе программы. Кроме того, вам будет приятнее сознавать, что программа работает хотя бы отчасти. Другой большой массив данных — это текст программы. Но, читая его, держите в уме, что понимаете вы его не до конца. Потому что если бы вы его полностью понимали, вы бы не сделали ошибку. Потом вы формулируете гипотезу в соответствии со всеми имеющимися данными. Всеми, а не какой-то их частью! А потом разрабатываете и выполняете повторяемый эксперимент.
Вспомните школу. Какое самое важное свойство должно быть у такого эксперимента? Он должен позволять опровергнуть нашу гипотезу. Иначе зачем его проводить? В принципе неплохо, если он даст нам еще и какие- нибудь интересные промежуточные результаты, а не только один ответ в конце, так чтобы мы следить за работой программы и проверять, соответствуют ли эти результаты нашим ожиданиям. Для этого мы должны знать, какого результата мы ожидаем, чтобы отвергнуть нашу гипотезу, если результат не будет соответствовать ожиданиям. Об этом люди обычно забывают. Они ленятся подумать заранее, какого результата они ожидают и поэтому не могут методично интерпретировать полученные результаты. Почему одной из проблем может оказаться повторяемость? Как мы сейчас убедимся, во многих программах мы используем случайности. Аналог бросания монетки или игральных костей. И тогда программа при разных запусках может делать разные вещи. Так что вам надо будет придумать, как убрать эти случайности из своего эксперимента (так, чтобы этот эксперимент все-таки отражал работу программы). Иногда проблема может быть во времени, когда вы запускаете несколько процессов одновременно. Поэтому иногда программы и операционные системы падают без очевидной причины. Иногда программа предполагает ввод данных человеком — а в эксперименте мы хотим этого избежать.
Теперь давайте подумаем о самом эксперименте. У нас есть по крайней мере две цели. Одна — создать минимальный набор данных, который приведет к возникновению ошибки. А вторая — найти ту часть программы, где кроется ошибка. Я советую использовать для этого бинарный поиск (алгоритм поиска, который последовательно сокращает поле поиска в разы).
Теперь я хотел бы разобрать с вами пример...
tinmonument за редактуру. Благодаря ему этот текст стал заметно меньше похож на результат работы электронного переводчика. Итак, слово о дебаггинге (отладке программы). Откуда взялось это название? Это забавная история. 9 сентября 1947 года был зарегистрирован один из первых багов в истории компьютерных программ (демонстрирует картинку). Это лабораторный журнал Грейс Марри Хоппер. Позже — адмирала Грейс Марри Хоппер, первой женщины-адмирала в американском флоте. А также одного из первых программистов. Она пыталась написать эту программу, и программа не работала. Это была сложная программа, вычисляющая арктангенс. Представляете, целая рабочая группа, пытающаяся вычислить арктангенс. Другие времена... Они пытались запустить программу, программа долго считала, а потом просто остановилась и больше не работала. Они долго искали, в чем причина, и наконец нашли. В реле номер 70 попала моль (По-английски «bug» — «букашка»). И реле захлопнулось на бедняжке. Министерству обороны было плевать на смерть моли, единственное, что их волновало — неработающее реле. Останки моли вынули и реле опять заработало.
Прекрасная история, а главное правдивая. Но это было не первое использование слова «баг» в этом смысле. Я попробовал отследить его раньше, и самое раннее употребление я обнаружил в 1896 году. В руководстве по электротехнике.
Сейчас «дебаггинг» — это навык, которому можно научиться. Никто не владеет этим навыком от рождения. Люди учатся этому медленно, а потом наступает озарение. Вы ухватываете суть процесса. Я надеюсь, что сегодняшняя лекция поможет вам освоить этот навык быстрее. А когда вы его освоите, вы обнаружите, что можете применять его не только для отладки компьютерных программ, но и для отладки других сложных систем. Например, в лаборатории. Почему эксперимент не работает? Я несколько раз читал лекции в больницах, врачам, о диагностике сочетаний болезней. И я рассказывал им почти то же самое, что собираюсь сейчас рассказать вам.
Для начала я хочу развеять несколько мифов о багах. Первый миф — что баги заползают в программы. Может быть, это было правдой в те времена, когда жук мог залететь или заползти в реле, но сейчас это уже неактуально. Сейчас, если в вашей программе есть баг, это может быть только оттого, что вы же его туда и засунули. Т.е. допустили ошибку. Нам нравится называть их «багами», потому что от этого мы сами себе кажемся умнее, но гораздо лучшим названием для «бага» была бы «ошибка».
Другой миф — что баги размножаются. Это не так. Если в программе много багов, то это потому, что вы сделали много ошибок. А не потому, что вы сделали две, а они спарились и наплодили детишек. И это хорошо. Обычно, даже притом, что они не размножаются, в программе их много. И помните, что цель дебаггинга не в том, чтобы уничтожить один баг, а в том, чтобы в программе было как можно меньше багов. Я подчеркиваю это потому, что от этого часто зависит стратегия наших действий. Цель — не уничтожать баги один за другим, а найти способ прихлопнуть их все.
Должны ли вы гордиться, если нашли баг? Ко мне приходят аспиранты и говорят: «Я нашел баг в своей программе!» И они ужасно горды собой. А я, в зависимости от настроения, либо поздравляю их, либо говорю: «То есть ты облажался? Исправляй!» Если вы нашли один баг в программе, наверняка их там больше. В любом случае, представьте, что вы на званом обеде, сидите за столом, вдруг слышите БАХ, и хозяйка входит с индейкой на подносе со словами: «Я только что убила последнего таракана!» Наверняка это не улучшит ваш аппетит. Подумайте об этом.
По крайней мере сорок лет люди пишут программы-дебаггеры. На мой взгляд, бóльшая их часть не стоит внимания. Лучшими методами дебаггинга по-прежнему остаются всё те же два. Это команда «print» (выводящая на экран результат любой операции) и чтение кода. А самое важное — работать методично. Это то, что отличает хороших отладчиков от плохих. Хорошие отладчики выработали эффективную методику поиска багов, и делают они это, последовательно сокращая область поиска, чтобы найти источник проблемы. В этом семестре мы потратили немало времени на изучение алгоритмов поиска. Дебаггинг — это просто поиск. Когда вы ищете элемент в списке, вы же не выбираете элементы случайным образом, надеясь, что наткнетесь на искомый. В то же время я часто вижу людей, которые ищут баги в программе, кажется, совершенно произвольным образом. Так можно отлаживать программу до бесконечности.
Итак, отладка начинается, когда мы обнаруживаем проблему. Первым делом, читая код программы, задайте себе вопрос, как получилось, что программа выдала вам ошибочный результат? Обратите внимание, мы не задаемся вопросом о том, почему программа не выдала нам ожидаемый результат. Если мы поймем, почему она сделала то, что сделала, мы уже наполовину решим проблему.
Следующий вопрос, который вы должны задать — есть ли у этого бага семья? То есть, был ли это единичный баг или ошибка, которую вы допускали систематически при написании программы.
И наконец, последний вопрос. Как исправить ошибку. Когда я думаю об отладке, я стараюсь думать в терминах, выученных в школе — в терминах научного метода. (Возможно, я выдаю свой возраст... Научный метод все еще изучают в школе? Да? Хорошо. Значит, еще не все потеряно для американской системы образования.) Итак, что мы должны сделать согласно научному методу?
Первое — изучить все имеющиеся данные. В нашем случае — все результаты тестирований программы. И, говоря «все», я имею в виду все, а не только те, которые выдали ошибку. Возможно, программа сработала с одними исходными данными, а с другими не сработала. И, возможно, это позволит вам быстрее быстрее найти баг, чем если вы сосредоточитесь только на ошибках в работе программы. Кроме того, вам будет приятнее сознавать, что программа работает хотя бы отчасти. Другой большой массив данных — это текст программы. Но, читая его, держите в уме, что понимаете вы его не до конца. Потому что если бы вы его полностью понимали, вы бы не сделали ошибку. Потом вы формулируете гипотезу в соответствии со всеми имеющимися данными. Всеми, а не какой-то их частью! А потом разрабатываете и выполняете повторяемый эксперимент.
Вспомните школу. Какое самое важное свойство должно быть у такого эксперимента? Он должен позволять опровергнуть нашу гипотезу. Иначе зачем его проводить? В принципе неплохо, если он даст нам еще и какие- нибудь интересные промежуточные результаты, а не только один ответ в конце, так чтобы мы следить за работой программы и проверять, соответствуют ли эти результаты нашим ожиданиям. Для этого мы должны знать, какого результата мы ожидаем, чтобы отвергнуть нашу гипотезу, если результат не будет соответствовать ожиданиям. Об этом люди обычно забывают. Они ленятся подумать заранее, какого результата они ожидают и поэтому не могут методично интерпретировать полученные результаты. Почему одной из проблем может оказаться повторяемость? Как мы сейчас убедимся, во многих программах мы используем случайности. Аналог бросания монетки или игральных костей. И тогда программа при разных запусках может делать разные вещи. Так что вам надо будет придумать, как убрать эти случайности из своего эксперимента (так, чтобы этот эксперимент все-таки отражал работу программы). Иногда проблема может быть во времени, когда вы запускаете несколько процессов одновременно. Поэтому иногда программы и операционные системы падают без очевидной причины. Иногда программа предполагает ввод данных человеком — а в эксперименте мы хотим этого избежать.
Теперь давайте подумаем о самом эксперименте. У нас есть по крайней мере две цели. Одна — создать минимальный набор данных, который приведет к возникновению ошибки. А вторая — найти ту часть программы, где кроется ошибка. Я советую использовать для этого бинарный поиск (алгоритм поиска, который последовательно сокращает поле поиска в разы).
Теперь я хотел бы разобрать с вами пример...
