Отладка языка сценариев, такого как ruby

Я в основном из мира программирования на языке C, теперь вникаю в мир языков сценариев, таких как Ruby и Python.

Мне интересно, как сделать отладку. В настоящее время шаги, которые я следую,

  • Я заполняю большой скрипт,
  • Прокомментируйте все, кроме части, которую я хочу проверить.
  • Выполнить скрипт

Хотя он работает, я не могу отлаживать, как я бы сделал, например, в среде VC ++ или что-то в этом роде.

Мой вопрос в том, есть ли лучший способ отладки?

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

Ваша последовательность кажется мне полностью обратной. Вот как я это делаю:

  1. Я пишу тест на нужную мне функциональность.
  2. Я начинаю писать сценарий, выполняя бит и проверяя результаты теста.
  3. Я просматриваю то, что я сделал, чтобы документировать и публиковать.

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

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

Вот скринкаст по отладке ruby ​​с ruby-debug.

Похоже, проблема заключается в том, что ваша среда (Visual Studio) не поддерживает эти языки, а не то, что эти языки не поддерживают отладчиков в целом.

Perl, Python и Ruby имеют полнофункциональные отладчики; вы также можете найти другие IDE, которые вам тоже помогут. Для Ruby есть RubyMine ; для Перла есть Комодо . И это как раз у меня на голове.

В отладчике Python есть приятное нежное введение

Если вы работаете с Python, вы можете найти список инструментов для отладки здесь, к которым я просто хочу добавить Eclipse с расширением Pydev , что также упрощает работу с точками останова и т. Д.

Мой вопрос в том, есть ли лучший способ отладки? "

Да.

Ваш подход «1. Я заполняю большой скрипт, 2. Комментируйте все, кроме части, которую я хочу проверить, 3. Выполните сценарий« на самом деле не лучший способ написать какое-либо программное обеспечение на любом языке (извините, но это правда .)

Не пишите ничего большого. Когда-либо.

Сделай это.

  1. Разложите свою проблему на классы объектов.

  2. Для каждого класса напишите класс на

    2а. Выделите класс, сосредоточьтесь на внешнем интерфейсе, а не на деталях реализации.

    2b. Напишите тесты, чтобы доказать, что интерфейс работает.

    2с. Запустите тесты. Они потерпят неудачу, поскольку вы только очертили класс.

    2d. Исправьте класс, пока он не пройдет тест.

    2е. В некоторых случаях вы поймете, что дизайн вашего класса не является оптимальным. Рефакторируйте свой дизайн, гарантируя, что ваши тесты все равно пройдут.

  3. Теперь напишите свой окончательный сценарий. Он должен быть коротким. Все классы уже протестированы.

    3a. Опишите сценарий. В самом деле, вы обычно можете написать сценарий.

    3b. Напишите несколько тестовых примеров, подтверждающих работу скрипта.

    3в. Проведите тесты. Они могут пройти. Все готово.

    3d. Если тесты не пройдут, исправьте все до тех пор, пока они этого не сделают.

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

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

Здесь есть много хороших советов, я рекомендую пересмотреть некоторые лучшие практики:

http://github.com/edgecase/ruby_koans

http://blog.rubybestpractices.com/

http://on-ruby.blogspot.com/2009/01/ruby-best-practices-mini-interview-2.html

(и прочитал книгу Грега Брауна, это превосходно)


Вы говорите о больших сценариях. Многие из моих рабочих процессов разрабатывают логику в irb или оболочке python, а затем захватывают их в каскад небольших, однозадачных сфокусированных методов, с соответствующими тестами (не на 100% охват, больше внимания на краевых и угловых случаях).

http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html

Здесь есть вопрос SO на Ruby IDE – и поиск «Ruby IDE» предлагает больше.

Я заполняю большой скрипт

Это то, что привлекло мое внимание: «полный», для меня, означает «сделано», «закончено», «выпущено». Независимо от того, пишете ли вы тесты перед написанием передаваемых им функций или вообще не пишете тесты (и я рекомендую вам это делать), вы не должны писать код, который не может быть запущен (что само по себе ), пока он не станет большим. Ruby и Python предлагают множество способов написания небольших, индивидуально проверяемых (или исполняемых) фрагментов кода, так что вам не нужно ждать (?) Дней, прежде чем вы сможете запустить эту вещь.

На данный момент я строю (Ruby) трансляцию / преобразование базы данных (до Ruby) – это до 1000 строк и еще не выполнено. Я редко прохожу более 5 минут, не запуская его, или, по крайней мере, работаю над той частью, на которой я работаю. Когда он ломается (я не совершенен, он сильно ломается; -p) Я знаю, где проблема должна быть – в коде, который я написал за последние 5 минут. Прогресс довольно быстрый.

Я не утверждаю, что IDE / отладчикам нет места: некоторые проблемы не возникают до тех пор, пока не будет выпущен большой кусок кода: иногда бывает полезно погрузить все это в среду отладки, чтобы узнать, что происходит на. Когда задействуются сторонние библиотеки и фреймворки, может быть чрезвычайно полезно отлаживать их код для поиска проблем (которые обычно – но не всегда – связаны с неправильным пониманием библиотечной функции).

Вы можете отлаживать свои скрипты Python с помощью включенного модуля pdb. Если вы хотите визуальный отладчик, вы можете скачать winpdb – не откладывайте этот префикс «win», winpdb является кросс-платформенным.

Метод отладки, который вы описали, идеально подходит для статического языка, такого как C ++, но при условии, что язык настолько отличается, методы кодирования аналогичны друг другу. Одной из важных очень важных вещей на динамическом языке, таких как Python или Ruby, является интерактивный toplevel (что вы получаете, набрав, скажем, python в командной строке). Это означает, что выполнение части вашей программы очень просто.

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

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

  • Начните с малого. Не пишите большие программы и не проверяйте их. Проверяйте каждую функцию, когда вы ее пишете, по крайней мере, легко.
  • Используйте верхний слой. Запуск небольших фрагментов кода на языке, таком как Python, чрезвычайно легкий: запустите верхний слой и запустите его. Сравните с написанием полной программы и ее компиляции, скажем, на C ++. Используйте тот факт, что вы можете быстро изменить правильность любой функции.
  • Отладчики удобны. Но часто так print заявления. Если вы используете только одну функцию, отладка с помощью операторов print не является такой неудобной, а также освобождает вас от перетаскивания по среде IDE.