Отладка языка сценариев как рубин

См. эту большую статью о C# с Точки зрения Java-разработчика . Это имеет несколько понимания на вещах, которые могут быть сделаны в обеих сторонах для предотвращения минимума наверху. Наличие примера и на языке, который Вы знаете и на язык, который Вы хотите выучить, упрощает кривую обучения вполне немного.

6
задан Svante 7 October 2009 в 07:34
поделиться

11 ответов

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

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

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

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

10
ответ дан 8 December 2019 в 03:09
поделиться

Вот скринкаст об отладке ruby ​​с помощью ruby-debug.

6
ответ дан 8 December 2019 в 03:09
поделиться

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

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

4
ответ дан 8 December 2019 в 03:09
поделиться

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

Да.

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

Сделайте не пишите ничего большого. Никогда.

Сделайте это.

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

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

    2a. Обозначьте класс, сосредоточьтесь на внешнем интерфейсе , а не детали реализации.

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

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

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

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

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

    3a. Набросайте сценарий. Действительно, обычно вы можете написать сценарий.

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

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

    3d. Если тесты не проходят, исправляйте вещи, пока они не пройдут.

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

Они могут пройти. Готово.

3d. Если тесты не проходят, исправляйте вещи, пока они не пройдут.

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

Они могут пройти. Готово.

3d. Если тесты не проходят, исправляйте вещи, пока они не пройдут.

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

2
ответ дан 8 December 2019 в 03:09
поделиться

Здесь есть приятное мягкое введение в отладчик Python

3
ответ дан 8 December 2019 в 03:09
поделиться

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

2
ответ дан 8 December 2019 в 03:09
поделиться

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

2
ответ дан 8 December 2019 в 03:09
поделиться

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

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

1
ответ дан 8 December 2019 в 03:09
поделиться

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

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

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

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

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

0
ответ дан 8 December 2019 в 03:09
поделиться

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

0
ответ дан 8 December 2019 в 03:09
поделиться

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

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

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

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