Как исправлять сложные баги

Любому разработчику приходиться сталкиваться с багами в своем проекте. Иногда попадаются такие, которые трудно исправить. Самая частая причина этого - трудно найти причину их возникновения. С этой статья я рассмотрю свой подход к исправлению таких багов.

Самый первый шаг

Первый шаг - нужно воспроизвести ошибку. Вы должны точно знать, при каких условиях она возникает. Иначе, далее вы просто не сможете найти её причину. Нельзя исправить что-то, если вы не знаете что исправлять.

Далее, я выделил для себя 2 подхода поиска, я называю их: аналитический и экспериментальный.
Аналитический - это когда вы сужаете круг поиска за счет своих знаний и фактов, которые вам известны. Вы собираете уже имеющиеся логи, используете свои знания того, как устроена система, и за счет своих рассуждений определяете, где искать проблему. Также вы смотрите в коде, и пытаетесь интерпретировать код у себя в голове и вычислить место, где находится причина бага.

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

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

Ситуации, когда не удается воспроизвести ошибку

Иногда бывает и такое. Вы точно знаете, что ошибка есть. Вам, например, жалуются пользователи или вы сами её обнаруживаете. Но повторить её не удается.

Приведу пример. Иногда у пользователя, после создания объявления, не открывается само объявление с ошибкой о том, что оно не существует. Это происходит какое-то время, потом оно начинает открываться. Происходит это редко и стабильно не воспроизводится. Проблема оказалась в ошибке репликации базы. Сохранение происходит в основную базу (мастер), но чтение происходит из вспомогательных. И из-за большой нагрузки на базу, данные не успевают записаться из мастера в вспомогательную базу. В данном случае может помочь информация о нагрузке на базу. Также, во время большой нагрузки, в логах могут часто сыпаться ошибки о таймауте на запросы в базу. И конечно, важно знать как работает база, чтобы понимать, что такая ошибка возможна.

Тут выход только один. Собрать максимальное количество данных, придумать как можно больше гипотез и проверить каждую. Чем больше данных соберете, тем больше гипотез придумаете и отбросите. Нахождение способа воспроизвести ошибку и есть сама задача в этом случае. После того, как вы проверили гипотезу и нашли способ её воспроизвести, исправьте ошибку и подождите, будут ли ещё жалобы. Возможно причин ошибки несколько, и, поскольку неизвестно, как на самом деле произошла ошибка, лучше минимизировать их количество и подождать новых.

Исправляйте причину ошибки, а не симптом

Часто ошибки являются лишь симптомом какой-то более сложной ошибки. Хочется убрать ошибку как можно быстрее, и не разбираться в её причинах. Если исправить только симптом, то сама проблема окажется закопанной ещё глубже. Из-за нее могут возникнуть другие проблемы, и найти её в будущем будет сложнее. К тому же, то место, где вы её исправили, будет неоправданно усложнено лишней логикой. Это приведет к усложнению кода. А это - к замедлению вашей работы над этим проектом в будущем.

Вывод

Ситуации, в которых могут возникнуть баги, бывают очень разные. И подходы в их решении могут отличаться. Но, практически в любом случае, мы начинаем с одного и того же. Я лишь постарался это описать из своего опыта.
Больше экспериментируйте при поиске причины и старайтесь разбираться в технологиях, которые используете. Не зная этого, можно просто упустить причину проблемы.