|
|
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
С помощью аssert? С помощью Junit? А если проект не на 500 kLOC? В общем то не хочется сидеть в дебаггере. И хочется, чтобы отладочные строки не замусоривали продакшн код ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2007, 23:58:37 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
Давно не использую отладчики - если знаешь, что делает твой код, незачем использовать средство, которое всего лишь показывает, что он (код) делает. Поскольку, однако ошибки неизбежны и работоспособен только тот код, который оттестирован, то давно и плодотворно использую логгинг (трассировку). Любое мое приложение на Java всегда имеет параметр конфигурации, определяющий уровень трассировки. В рабочем варианте это ошибки (SEVERE) или INFO, в разработке - DEBUG (для кода, оттестированного ранее) или ALL (для кода, тестируемого в данный момент). В трассу пишется то, что имеет смысл видеть - это зависит от кода. Навыки грамотной и экономной трассировки приобретаются быстро - надо лишь решительно "забить" на отладчики. Грамотная же трассировка позволяет выловить все скрытые ошибки, спланировать рефакторинг, обеспечить быстрое решение проблем у заказчика (достаточно лишь попросить его включить более высокий уровень трассировки и прислать логи) и так далее и тому подобное - "сто в одном". Не говоря уже о сложностях использования отладчиков для приложений, работающих в контейнерах. Непонятно, почему "отладочные строки не замусоривали продакшн код". Трассировка вовсе не замедляет выполнение, если она выключена, а с другой стороны, служит отличным комментарием к коду. Ну, к примеру, фрагмент Код: plaintext 1. 2. не только обеспечивает надлежащую трассировку при определенном уровне, но и сообщает читающему код персонажу, что в данном месте мы имеем результирующую строку запроса. А проверка AppGlobals.logLevel >= AppGlobals.DEBUG стоит копейки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2007, 01:10:22 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
МистерBin. И хочется, чтобы отладочные строки не замусоривали продакшн код Плох тот продакшн код, в котором нет отладочных строк. Если бы я такой увидел, то усомнился бы в его качестве. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2007, 08:26:54 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
wessen МистерBin. И хочется, чтобы отладочные строки не замусоривали продакшн код Плох тот продакшн код, в котором нет отладочных строк. Если бы я такой увидел, то усомнился бы в его качестве."Нет отладочных строк" слишком расплывчатое понятие. отладочных строк может быть 2 на 10 kLOC. Это не то же самое что 40% кода занимают отладочные строки. Мой вопрос был о том как уменьшить % отладочных строк и пустых никому не нужных циклов и проверок в продакшен коде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2007, 21:26:33 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
MisterBinМой вопрос был о том как уменьшить % отладочных строк и пустых никому не нужных циклов и проверок в продакшен коде. Либо ответ был выше, либо вопрос некорректно поставлен. а) в трассу пишется то, что имеет смысл видеть в трассе приложения в определенных режимах - отладки, тестирования, эксплуатации; б) приложение имеет параметр конфигурации, задающий режим трассировки. В эксплуатации большинство трассировочных утверждений отключается, как показано выше. В отладке все, наоборот, включается. Или что-то иное имелось в виду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2007, 21:50:56 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
М.Головановб) приложение имеет параметр конфигурации, задающий режим трассировки. В эксплуатации большинство трассировочных утверждений отключается, как показано выше. В отладке все, наоборот, включается. Или что-то иное имелось в виду?Ясно. это я и хотел выяснить. При эксплуатации объем байткода снижается с 50Мб до 10 Мб за счет исключения проверочных инструкций и отклик веб-страницы с 0,05 сек до 0,0001 сек? Это то, что мне надо, этого я и добивался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.04.2007, 22:53:06 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
Как-то Вы не так поняли. Я не говорил о том, что пишутся две версии кода. Окончательный код по-прежнему содержит все информационные и отладочные трассировочные инструкции, поэтому объем байт-кода никак не уменьшается. Однако эти утверждения выполняются или не выполняются в зависимости от значения соответствующего параметра конфигурации приложения (выше он обозван AppGlobals.logLevel - уровень трассировки). У меня, в частности, если это значение равно константе AppGlobals.SEVERE, трассируются только исключения (это должно оставаться и при эксплуатации приложения). Остальные трассировочные утверждения просто обходятся. При более высоких уровнях трассировки, указанных в конфигурации приложения, вслючаются также соответствующие этим уровням трассировочные утверждения. Грубо говоря, чем выше уровень трассировки, тем длиннее и детальнее трасса (и содержащий ее лог-файл) и тем соответственно медленнее выполнение приложения. Самая делальная трасса (при самом высоком уровне трассировки) содержит иформацию, достаточную для нахождения мест, где код работает неверно - тем самым отпадает нужда в отладчике. В Java отсутствуют директивы препроцессора, аналогичные #ifdef / #endif в С/С++, и слава Богу. Исключается возможность генерации разных версий кода, а это означает, что и в отладке, и в работе используется одна и та же - единственная - версия исполняемого кода. Понятно, что это сильно упрощает тестирование. Тот факт, что я оставляю все трассировки в коде, конечно, увеличивает объем исполняемого кода, но не столь существенно, чтобы об этом болела голова. Грубо говоря, если Вы знаете, что пишете (то есть понимаете, зачем Вы написали то или иное утверждение в коде), то на метод достаточно несколько (2+) отладочных трассировочных утверждений - ну, скажем, входные параметры, результат(ы), несколько промежуточных трассировочных утверждений в критических точках. Все. Никто не заставляет заранее натыкать кучу трассировок где надо и где не надо. Если в процессе тестирования где-то не работает и непонятно, почему, то в то место, где непонятно, добавляем нужные трассировочные утверждения. И так далее, пока не заработает как надо. Обычно добавлять много не надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2007, 16:09:30 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
Трассировка != тестирование. Тестироваться надо с JUnit/Cactus. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2007, 16:41:41 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
М.ГоловановДавно не использую отладчики - если знаешь, что делает твой код, незачем использовать средство, которое всего лишь показывает, что он (код) делает. Хорошо если всегда со своим кодом работаешь. А чаще всего с чужим... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2007, 16:44:00 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
TimmТрассировка != тестирование. Тестироваться надо с JUnit/Cactus. Безусловно верно. Тестирование - удостоверение того, что программа или ее часть делает то, что требуется, путем сравнения полученных результатов с ожидаемыми. JUnit сильно ускоряет этот процесс, хотя и не всегда. Трассировка - способ выяснить, почему в конкретном тесте результаты отличаются от ожидаемых. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2007, 22:29:00 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
ZS М.ГоловановДавно не использую отладчики - если знаешь, что делает твой код, незачем использовать средство, которое всего лишь показывает, что он (код) делает. Хорошо если всегда со своим кодом работаешь. А чаще всего с чужим... А Вы изучаете этот чужой код в отладчике? Я, например, просто его читаю. Этому я научился до того, как научился писать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2007, 22:31:31 |
|
||
|
Как принято отлаживать Java code?
|
|||
|---|---|---|---|
|
#18+
Никак не принято, зависит от ситуации. Где-то прочитал, что проблема пошаговой отладки в отличие от трассировки в том, что трассировка позволяет увидеть работу программы на временном промежутке времени, а при отладке по шагам очень быстро забываешь про значение какой-нибудь переменной или про стек вызова. Проблема с трассировкой в том, чтобы понять, что именно должно выкладываться в трассу. Кто-то либо сразу пишет bugfree код и у него этой проблемы нет. А кто-то запускает программу, видит что она не работает, понимает что логи не дают полной информации, добавляет это в логи, пересобирает проект - а на это все уходит время. Дебаггинг может быть полезен в процессе изучения работы какого-нибудь фреймворка, когда имеющейся документации может быть недостаточно и понимание "как его использовать" можно получить из исходного кода. Здесь opensource рулит, главное понаставить breakpoints и добраться до точки где принимается решение. Из последнего например была проблема с генерируемыми JIDEA методами equals в условиях работы с Hibernate - без дебага можно долго биться головой об стену. Если есть возможность, то софт пускается под дебаггером + в самом коде вставки под трассировку, что позволяет взять положительные стороны каждого подхода. Сначала смотрим по логам, что не работает и обычно этого достаточно, ну а если возникает состояние "ну я не понимаю, как это работает" тогда врубается дебаг. JUnit тоже рулит. Просто в моем понимании это средство, дающее вам уверенность в том, что изменив что-то, программа все еще работает правильно. Дебаггинг нужен когда вы работаете с чужим кодом и когда вообще не понимаете как это работает, трассировка нужна когда вы сами пишете программу, а JUnit для уверенности. Соответственно чем больше JUnit-ов, тем лучше. Пару раз спасало - ощущения непередаваемые. Наверное большинство согласиться, что вопрос "как правильно отлаживать" можно переформулировать в "как эффективно делать трассировку". Может где-то на форуме это уже есть, может у кого-то свои собственные правила. Я же пока понял одно, что убирать трассировку из кода не надо , даже когда программу отладили и она работает правильно. Лишняя трассировка не повредит, чем больше информации - тем меньше область, в которой придется искать ошибку. Ну а если понадобилось внести трассировку, значит метод изначально спроектирован как-то неправильно или мы используем у себя как-то неправильно спроектированный метод. Пришла мысль, что трассировка должна идти напару с JUnit , ведь если мы добавляем трассировку, значит мы не уверены что метод работает правильно, а значит нам надо либо его разбить на части, в которых мы будем уверены, либо написать тест. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2007, 21:23:21 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=34470400&tid=2145983]: |
0ms |
get settings: |
14ms |
get forum list: |
28ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
75ms |
get topic data: |
22ms |
get forum data: |
5ms |
get page messages: |
76ms |
get tp. blocked users: |
3ms |
| others: | 320ms |
| total: | 557ms |

| 0 / 0 |
