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