Существуют ли рекомендации(техники, подходы) быстрого поиска ошибок в коде?

Question

[vostotskiy]

Здравствуйте. При сопровождении и доработке чужого кода у меня тратиться очень много времени на поиск ошибок, анализ алгоритма и тд. Зачастую это 80 % времени, потраченного на исправление багов. Возможно, это мой собственный недостаток, но можно предположить что все-таки общая закономерность. Существуют ли рекомендации, техники, подходы, позволяющие быстро выявить баги в чужом(и не только) коде, эдакие техники экспресс-дебага?
Речь идет и о серверной, и о клиентской стороне(PHP, JS).
Буду благодарен за любые наставления, ссылки и советы.
Заранее огромное спасибо за уделенное время!

Comments

[Павел Волынцев]

80% времени мы действительно тратим на чтение и анализ кода, 20% на написание.

commit diff бывает всего пару строк содержит, а за ними кроются часы.

Подход такой: если для проверки чего-то пришлось написать какой-нибудь кусочек кода с echo или var_dump, то можно попробовать зафиксировать этот проверочный набор данных и результаты в виде интеграционного или модульного теста, чтобы в будущем не проверять то же самое ещё раз.

Answer 1

[Сергей]

Тестирование?
Ключевые слова: unit тестрировани, selenium, [php, js]Unit

Comments

[vostotskiy]

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

Answer 2

[Станислав Макаров]

эдакие техники экспресс-дебага?

PHP, JS

Основная техника экспресс-дебага - не пользоваться по возможности языками со слабой динамической типизацией.

Answer 3

[Jimi Hendrix]

phpfaq.ru/debug

Answer 4

[Михаил]

Наверное, вам нужны статические анализаторы.

Answer 5

[heartdevil]

То, что много времени тратится на понимание чужого кого -- нормально. Со временем вы все равно будете быстрее править баги или дорабатывать систему. Если же у вас совсем нет сдвигов, значит у вас слабая база. Вам надо больше читать и разбирать код.

Answer 6

[Philipp]

При поиске ошибок необходимо использовать системный и структурный подходы плюс дедукция.
Например, у вас есть ошибка "Клиент не получает уведомление о заказе".
В данном случае у вас есть система заказа и система доставки почты.
Нужно выяснить, какая именно система не работает, заказ или почта.
Если другие письма доходят, то значит что-то не так с системой заказа.
Аналогично разбираем на части систему заказов до момента вызова функции отправки почты.
В данном случае нам нужен отладчик в связке с хорошей IDE.
Устанавливаете брейкпоинт и смотрите, вызывается ли функция после создания заказа. Если да, то проверяете аргументы, нет - значит ошибка происходит до этого момента. Следовательно вам потребуется стек вызовов функций/методов. Обычно он доступен через отладчик. Используя отладчик вы можете идти по стеку вызовов как сверху вниз, так и снизу вверх. Как вам будет удобнее.
Данный метод позволяет отлаживать ошибки в проектах любого уровня сложности.

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

Кроме изучения самого языка, необходимо понимать, как работает почта, DNS, базы данных, очереди, стек TCP/IP и сетевые операционные системы в целом.

Answer 7

[Максим Мосейчук]

Для поиска тех ошибок, которые были привнесены в процессе разработки (т.е. сначала работало, потом поломали), хорошо подходит бинарный поиск (git bisect или аналоги из других систем контроля версий).
Но такой подход будет успешен лишь при маленьких атомарных коммитах.

Answer 8

[xmoonlight]

После того, как Вам указали ошибку, Вам нужно "разматывать" "логический клубок" начиная с места вывода и заканчивая тогда, когда Вы найдете причину возникновения ошибки.
Учитесь "читать" (понимать) алгоритм (ветку кода) в обратном порядке.