Ненавижу дебажить код.
Ненавижу дебажить код.
Код стратегий, код чего угодно. По типу задачи (задача найти баг или оценить код на предмет: есть ли баги) – задача моя – т.е. я такое люблю – найди то, не зная что, так не зная как. Но блин – итак много задач, эти задачи они как бы не входили в твои планы, это как бы внеплановые задачи. Задача найти баги – плановая – но каждый конкретный новый баг – это внеплановая фигня – поэтому она напрягает. Это не задача, двигающая вперед, а задача, решение которой тебя возвращает в текущую точку развития после откидывания назад. Когда возникнет такая возможность, в первую очередь делегирую QA.
Больше меня напрягает искать баги когда нет формальных свидетельств их наличия. Код компилируется, трейды совершаются, но ты, блин, очень не уверен, что в таком объёме кода нет ни одного бага)). Приходится планомерно проверять корректность. Пожалуй я начинаю переходить именно к такому подходу: планомерно всё проверять, а не на финальном этапе вдруг выяснить, что «похоже, что-то работает не так как надо». Думаю, с опытом процесс будет всё системней, а как следствие данную систему можно оптимизировать и она будет протекать всё легче, всё менее затратней, всё приятней в конце концов.
Ещё хочется верить, что опыт приводит к уменьшению кол-ва ошибок, ну и повторное использование кода (читай, библиотеки) тоже.
Хуже, когда багов нет, а в логике алгоритма косяк, причем там где не ожидаешь.
Николай, подскажите, у вас с опытом кол-во багов и вот таких косяков в логике становится меньше? И какие вообще приемы, способы, методы используете чтобы избегать и чтобы легче находить?
Забавно, что слово «баг» пошло от застрявшего жучка в контактах реле допотопного компа, а теперь его трактуют весьма вольно:)
Вольная трактовка от геймеров пошла, видимо.
По мне, так я вообще это слово стараюсь не использовать.
Вместо этого использую словосочетание «какая-то куйня». Я не проф-программер, мне можно)
Меня мотивирует вести журнал багов. Как только случилось что-то нехорошее, или даже то, что кажется подозрительным, записать это в систему баг-трекинга (но когда один работаешь, то проще в какую-нибудь табличку; мне самому в итоге лучше всего писать это в Mindjet). Критические баги надо исправлять сразу, остальные могут и подождать. Периодически в эту табличку нужно заглядывать и брать один из багов на ликвидацию.
Еще хороший прием - тотальное логгирование. Пусть роботы пишут по несколько ГБ текстовых логов в день, какая проблема, ужмете их раром и перенесете в папочку на будущее. Но когда ошибка случается, чаще всего вся информация, нужная для ликвидации бага уже там содержится.
Иногда информации для ликвидации багов в текстовых логах недостаточно и понять, что к нему привело невозможно. В таком случае можно сделать еще сообщений в логах и при следующем появлении этого бага уже станет понятнее.
Когда исправляешь баг — переносишь его из своего списка в другой список «выполнено». Периодически заглядывать нужно и туда. Баг казался неисправимым, проявлялся непредсказуемо, целый год мешал жить, а потом смотришь — он в разделе «устранено». Это дополнительная мотивация.
Ну и, конечно, программы надо стараться писать так, чтобы баги было проще исправлять. Это и архитектура, и комментарии в коде и различные проверки того, что «не должно было случиться никогда».
Еще прием — исправлять один серьезный баг и тут же один мелкий. И хоть все системы тайм-менеджмента учат сначала заниматься срочными и важными делами, потом важными, а потом уже всеми остальными, но если мелкие баги накапливаются, то они начинают мешать жить с невероятной силой и мешать отлавливать более крупные.
А вот если система «математическая», тут не знаю… Беда.
но обычно такие ошибки находятся достаточно легко.
Рекомендую ТСЛаб — тут вообще всё на полуавтомате.
Внес очередное изменение, напиши(поправь) на него тест, остальные тесты пробежали ок значит нет регрессии.
Часто написать хороший тест сложнее чем реализовать функционал.
Это дешевле чем картина когда кто то фиксит 1 баг порождая вагон и тележеку новых.
Ну и логи логи и еще раз логи, если ты вынужден дебажить значит твой код требуется более тщательно логировать на нужном для этого уровне.
Удобно когда каждый коммит в репозиторий запускает сборку проекта и автотесты+интеграционные(на отдельной машине) с результатом по мылу всей команде, сразу видно кто всю малину…
Добавлю одну мысль: Написание теста перед написанием основного кода очень структурирует в голове основную задачу.
в конце концов иной раз можно целый день гоняться за каким-нибудь "<" вместо ">" и т.п.
просто на самом деле начинаешь проверять всё. сделал кусочек, проверил, сделал другой — проверил. собрал вместе — снова ещё пяток раз проверил. ну, если не лень, конечно.
настраиваю себя как рекомендовал Рей Далио: что каждая ошибка, это паззл, который в случае отгадки даёт награду.
проще говоря — только исправляя ошибки можно сделать жизнь лучше.
почитал комменты. я тоже веду журнальчик. если замечу с роботом что-то странное, сразу записываю. сейчас висящих задач вроде как нет.
вообще… есть норма… 20 строк отлаженного кода в день…
У меня проект уже достаточно большой и я его тестирую, часто дублируя функции, написанные разными способами. На выходе имеются два текстовых файла, которые должны в точности совпадать, сравниваются в WinMerge. Выглядит это так:
Видимо, это тоже какая-то форма TDD.