Разработчик Артём Микулич пишет о подводных камнях использования отладки — этапе разработки программного продукта, на котором происходит обнаружение и локализация ошибок.
Отладка — тот самый инструмент, с которым студент начинает писать первые строчки кода и идёт рука об руку на протяжении всей карьеры разработчика. С помощью отладки специалист выполняет программу пошагово, оператор за оператором, функция за функцией. Он видит все входные и выходные параметры методов, значения переменных — всё, что необходимо для анализа проблемы. Хочу акцентировать внимание на некоторых подводных камнях, с которыми разработчики могут столкнуться, используя отладку.
Многие программисты, осознанно или нет, считают отладку единственным инструментом поиска причин дефекта. Получив в распоряжение шаги для воспроизведения, они начинают отладку, поверхностно оценив круг возможных источников проблемы.
В своё время я работал на проекте, в котором сборка и запуск разрабатываемого приложения занимали много времени. Производительность была также неприемлемой: обработка некоторых действий занимала около минуты. На жалобу одного из разработчиков по поводу списанного на исправление дефекта времени («Debug отнял у меня кучу времени») руководитель дал очень хороший ответ: «Раз Debug отнимает много времени, зачем его запускать?».
Согласитесь, очень обоснованно, особенно если взглянуть на проблему не только с точки зрения потраченного на запуск/отладку времени, но и учитывая эффективность её использования.
Представьте, что вы работаете в компании по аренде автомобилей. Несколько клиентов пожаловались, что в доставшихся им машинах примерно через час после начала поездки самопроизвольно открываются окна и включается ближний свет. Подобное никогда не случалось, и вас попросили разобраться с этим вопросом.
Вы можете направиться в гараж, найти проблемные машины, завести их и пойти выпить кофе пока пройдут те 60 минут, после которых должны проявиться проблемы. Если представить оптимистичный вариант, то ровно через час вы убедитесь, что окна на самом деле начинают самопроизвольно опускаться… Неплохо! Теперь вы точно знаете, что проблема есть, и жалобы клиентов не беспочвенны. Но ведь причина так и остаётся неясной, а проблема неисправленной.
Если рассмотреть более пессимистичный вариант, то ни через час, ни позже проблема не проявится. И в результате вы даже не будете уверены, существует ли она или клиент просто ошибся. Чуть более опытный работник компании может посоветовать перевести часы в автомобилях, чтобы не ждать, а сымитировать прошедший час. Хотя не факт, что это как-то вам поможет.
Подобным образом поступают многие разработчики, запуская отладку после беглого ознакомления с описанием проблемы. Как иллюстрирует пример, бесконечное ожидание момента, когда дефект воспроизведется, не самое эффективное времяпрепровождение. К тому же даже в случае успеха, вы едва ли приблизитесь к пониманию причин проблемы.
Также не следует забывать о том, что часть времени уходит на подготовку входных данных. Конечно, отладку можно запустить, подключившись к основной базе данных, а не её копии. Мы так и поступили в примере с арендными автомобилями. Но в случае с промышленной разработкой такой подход должен быть исключён из арсенала разработчиков на уровне подсознания.
Во всех случаях на подготовку отладки в таком «экстремальном» режиме нужно потратить время. Таким образом, в распоряжении разработчика остаётся отладка на копии базы, и вероятнее всего, она не будет содержать полностью готовых данных для воспроизведения дефекта, и их придётся создавать самостоятельно.
Попробуем посмотреть на проблему с другой стороны. У нас есть оформленная жалоба, из которой можно почерпнуть полезную информацию. Например, по номеру автомобиля мы узнаем дилера (есть такая таблица в базе данных), у которого автомобиль был куплен. Сделаем запрос к этому дилеру, уточним, не было ли у них подобных жалоб. Проверим, когда имело место последнее техническое обслуживание (снова таблица в базе данных). Узнаем, что проблемные машины обслуживались на одной станции относительно недавно, а также то, что у обеих вносили изменения в настройки электронного блока управления. Это уже мало похоже на совпадение.
Заметьте, что с каждым шагом круг возможных источников проблемы сужается. Даже если не каждое предположение приводит к успеху, мы движемся в верном направлении и тратим при этом минимум времени. Это можно сравнить с временными затратами на борьбу с дефектами на этапах разработки архитектуры и тестирования готового приложения: чем раньше ошибка обнаружена, тем проще и дешевле её исправить. Кроме того, анализ позволяет исключать из рассмотрения целые блоки кода, в то время как в отладке всё внимание сосредоточено на одной строке кода в единицу времени.
При аналитическом подходе, нам, разработчикам, достаточно «включить голову», чтобы прийти к правильным выводам. Всё, что нужно — использовать свои знания в предметной области, опыт, написанный код и базу данных. Анализ кода и данных о дефекте является более эффективным средством исследования проблемы, чем бездумный запуск отладки. Ведь лишний раз внимательно глядя в код или базу данных, мы повышаем свой уровень знания, а следовательно, в следующий раз поиск ошибки или разработка нового функционала будет проходить быстрее. К тому же появляется возможность обнаружить другой потенциальный дефект или неточность.
Наконец, сузив область потенциально проблемного кода, мы можем найти иной, более простой способ воспроизведения и тестирования проблемы, к примеру, запуск хранимой процедуры с определенными входными параметрами.
Таким образом, я бы отметил два side-effect’а использования отладки:
1.Затраченное время
а. сборка и запуск приложения
б. создание тестовых данных
2.Низкая скорость анализа: разработчик концентрируется и затрачивает время на отладку определенного блока кода, и если последний не содержит источника дефекта, отладку нужно начинать заново.
Совсем недавно услышал, как один из разработчиков рассказывал байку о том, как приложение в режиме отладки заняло более шести гигабайт оперативной памяти. Поэтому в качестве третьего side-effect’а можно отметить и затраты машинных ресурсов при отладке. Хотя этот аспект с учётом современного уровня развития компьютерной техники становится всё менее и менее актуальным.
Подытоживая, хочу сказать, что отладка всегда была и будет одним из основных, ежедневно используемых инструментов разработчика. Тем не менее всегда следует спрашивать себя:
- Будет ли эффективной в данной конкретной ситуации?
- Можно ли начать с анализа кода или данных в базе?
В большинстве случаев хотя бы на один из этих вопросов будет дан положительный ответ. А это значит, что, отказавшись от отладки и перейдя к анализу, можно найти решение проблемы быстрее и к тому же получить бонус — более глубокое знание кода и других составляющих приложения.
*Мнение колумнистов может не совпадать с позицией редакции.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.