От джуна до сеньора: Как стать востребованным разработчиком

Отладка

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

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

Самый простой (и старый) способ отладки – это непосредственный вывод на экран. Это может быть вывод информации о текущем состоянии кода в консоль, в браузер, в интерфейс приложения. Это быстрый и действенный способ: вы просто выводите на экран состояние переменных, результат выполнения функций и все, что сочтете необходимым. Однако я очень (ОЧЕНЬ) рекомендую настроить инструменты для отладки (отладчик), если они доступны для вашего языка программирования. Иногда настройка отладочных инструментов занимает какое-то время, но, поверьте мне, это сэкономит вам невероятное количество времени и нервов в дальнейшей работе.

Одно из самых главных табу – недосмотреть и оставить в проекте отладочный код (к примеру, вывод отладочной информации или искусственную паузу в выполнении кода). Это может не только нарушить работу приложения (вы удивитесь, насколько часто забытый в коде sleep становится в дальнейшем невероятной «оптимизацией», когда его наконец находят и удаляют), но еще и скомпрометировать данные клиентов, которые будут отображены в логах или записаны в файл и прочитаны людьми, для которых они не предназначены. Настройка отладочного инструментария избавит вас от таких опасных ситуаций.

Тренируйтесь работать с отладчиком, не идите коротким путем, решая проблему разбрасыванием выводов на экран по всему коду. Во-первых, это решение только кажется самым быстрым: в какой-то момент вы все равно столкнетесь с ситуацией, когда одного лишь вывода на экран будет недостаточно. Во-вторых, вы упускаете невероятно ценную возможность увидеть код так, как его видит интерпретатор вашего языка или операционная система при выполнении. Регулярная работа в отладчике при поиске ошибок или анализе кода позволит вам почувствовать себя машиной – видеть то, что видит она при выполнении кода, следовать тем же путем. Это поможет выработать интуицию и способность замечать потенциальные ошибки при написании кода.

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

Тезисы

■ Старайтесь обходиться без выводов на экран.

■ Найдите время на настройку отладчика, оно окупится с лихвой.

■ Пользуйтесь отладкой регулярно, не позволяйте себе утратить навыки.

■ Профилируйте, чтобы понять, насколько эффективно ваше приложение.

Задание

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

История из жизни

Из всех историй отладки мне запомнилась одна, когда мне казалось, что я вот-вот лишусь рассудка. Я отлаживал свое Windows-приложение, которое, в силу условий, поставленных клиентом, должно было использовать одну из стремительно устаревающих технологий OLE (если вы пишете с использованием OLE – простите, эта претензия не лично к вам). Моя головная боль началась в тот момент, когда я понял, что у приложения «течет память». Как и любой порядочный разработчик, я, разумеется, начал подозревать в этом свой код. Спустя неделю, лишившись огромной части нервных клеток и изрядно поседев, я смог найти утечку в одной из системных DLL Windows, датированную 1995 годом выпуска. Скажу честно, я искренне попытался найти авторов и сообщить им о найденной проблеме, но безрезультатно. Меня не покидает мысль, что все, кто хоть что-то помнил об этой библиотеке, либо сняли руки с клавиатуры, либо уже покоятся с миром. Покойтесь мирно, но нервов мне, конечно, жаль.