9/97: Сначала проверьте свой код, а уж потом вините других

Это перевод Check Your Code First before Looking to Blame Others. Автор: Allan Kelly.

Из "97-ми вещей, которые должен знать каждый программист".

Разработчики (все из нас!) часто не верят, что их код не работает. Это просто настолько невероятно, что на этот раз это, должно быть, баг в компиляторе.

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

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

Предполагая, что ваши инструменты уже широко используются, они "повзрослели", развёрнуты в различных ситуациях - есть очень мало причин, чтобы сомневаться в их качестве. Конечно же, если инструмент выпущен недавно, мало используется или это вообще какая-нибудь версия 0.1 Open-Source кода, то у вас есть хорошая причина подозревать причину проблемы в этом коде (но равновероятно причиной может быть и альфа-версия коммерческого продукта).

Если вы осознаете, как редки баги в компиляторе, то вы вложите своё время и энергию в поиск и устранение причины ошибки в своём коде, чем в попытки доказать, что компилятор неисправен. Тут применимы все обычные советы отладки: изолируйте проблему, вставляйте отладочные вызовы, обстраивайте код тестами, проверяйте сигнатуры функций, библиотеки, версионность, расскажите о проблеме кому-то ещё, ищите порчу памяти и стека, ошибки преобразования типов, попробуйте код в разных окружениях и разных машинах, в разных конфигурациях (debug и release).

Ставьте под сомнения свои собственные предположения и предположения других. По-возможности проверьте их (например, зафиксируйте assert-ами). Утилиты от различных производителей могут иметь различные предположения о порядке вещей — равно как и разные утилиты одного производителя.

Когда кто-то другой сообщает вам о проблеме, которую вы не можете воспроизвести - посмотрите, что они делают. Быть может, они делают что-то такое, о чём вы даже не задумывались, или делают что-то знакомое, но в необычном порядке.

Ну и личное правило такое: когда у меня есть баг, который я никак не могу прижать, и я уже начинаю валить на компилятор - то самое время искать повреждение стека. Это особенно так, если добавление кода-трассировки просто перемещает проблему в другое место.

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

Поэтому, прежде чем кричать "компилятор - отстой", вспомните совет Шерлока Холмса: "Как только вы исключите из рассмотрения невозможное, то, что останется, как бы маловероятно оно ни было, должно быть истиной" и предпочитайте его совету Dirk Gently: "Как только вы исключите из рассмотрения маловероятное, то, что останется, как бы невозможно оно ни было, должно быть истиной".