Если бы мне предложили подвести итог своей карьере программиста с помощью двух суровых истин, я бы сказал так:
- Все, что может пойти не так, пойдет не так.
- Code smells (прим.ред. термин, обозначающий код с признаками (запахами) проблем в системе).
И единственное, что сможет противостоять этим горьким реалиям — это отладка.
Да, именно отладка. В начале своей карьеры никто (или почти никто) не питает особой любви к отладке. Зачастую она вызывает лишь разочарование и страх. Мы бы предпочли и дальше создавать крутые штуки (А кто не любит создавать крутые штуки!?), вместо того, чтобы часами корпеть над исправлением одной-единственной ошибки.
Тем не менее, все профессиональные разработчики считают отладку крайне важным делом. Потому что они прекрасно понимают, что отладка — это бесценный источник опыта. Существует всего несколько ситуаций, при которых вы сможете испытать свои навыки в той же мере, в какой это происходит при отладке.
Истинная проблема отладки заключается в том, что она не поддается временным промежуткам. Вы можете примерно рассчитать, сколько времени уйдет на проектирование, разработку и т.д, но отладка “сделана из другого теста”. На процесс отладки может уйти час, день или даже неделя, но вы и на шаг не приблизитесь к обнаружению и устранению проблемы.
Вот почему вы должны начать рассматривать процесс отладки, как возможность обучиться чему-то новому. Конечно, страдания все еще будут преследовать вас, но вы научитесь держать их под контролем, правильно осуществляя отладку.
В этой статье я расскажу о нескольких способах, которые помогут научиться правильно проводить отладку.
Сначала разберитесь с тем, как устроена система
Очень часто мы, первым делом, “понимаем как устроена проблема” и только потом “понимаем как устроена система”. Однако все должно быть наоборот.
Какое-то время назад я отлаживал проблему в SAP Smart Form. Некоторые значения неправильно отображались в форме, поэтому я отлаживал всю форму целиком в течение двух дней, но так и не смог найти проблему. Излишне говорить, что я был разочарован. В этой проклятой форме не было никаких ошибок. Но затем меня вдруг осенило.
Я заметил, что форма одновременно вызывается из двух мест в коде. При дальнейшем анализе я обнаружил, что проблема заключалась в вызывающем коде (calling code), а не в форме. Я решил проблему в один миг. Всего-то требовалось подправить одну незначительную деталь в другом месте.
Вы должны понимать, что должна делать система, как она спроектирована и, в некоторых случаях, почему она была спроектирована таким образом. Если вы не понимаете, как устроена какая-то часть системы, значит, скорее всего, проблема находится именно там.
Устраняйте каждую проблему по отдельности
Некоторое время назад я работал над большим SAP проектом по переносу данных (data migration). Дедлайн был на носу, работы было по горло, и в этот критический момент я столкнулся с проблемой под названием “Повреждение данных”.
Некоторые из перенесенных данных были повреждены, а выяснить, что пошло не так — чересчур проблематично, так как у тебя миллионы перенесенных записей.
В конце концов я решил проблему с помощью прототипирования. Я создал небольшой прототип, который показывал похожие симптомы, но с подмножеством данных. Работа с этим прототипом вывела меня на основную причину повреждения данных, и я смог ее устранить.
Суть заключается в сужении поиска.
При работе со всей системой очень трудно отделить те мелочи, которые влияют на вашу конкретную проблему, от тех, которые этого не делают.
Но решение есть и оно заключается в использовании идеи “разделяй и властвуй”. Не пытайтесь работать со всей системой сразу. Отделите от основной системы тот компонент или модуль, с которым у вас возникли проблемы, и начните его отладку.
У “изоляции проблемы” есть множество преимуществ: вы можете сосредоточиться на вопросах, имеющих непосредственное отношение к проблеме; вы быстро справитесь с проблемой, потому что работаете с минимальным количеством кода.
Помните, что жуку (багу) трудно спрятаться, когда его убежище разрезают напополам.
За один раз изменяйте в коде только одну часть
Представьте такую ситуацию: вам нужно удалить зуб, поэтому вы идете к стоматологу. Стоматолог, пытаясь решить проблему, начинает возиться со всеми зубами, а не только с больным. Вы зазря стонете от боли, когда один за другим ваши зубы подвергаются ударам стоматологического молоточка.
Как вы будете себя чувствовать в такой ситуации? Думаю, вы будете задавать себе такой вопрос: “Что, черт возьми, происходит? Этот парень вообще знает, что делает?”
Плохая отладка работает точно так же.
За раз делайте только одно дело. Я знаю разработчиков, которые пытаются исправить плохой код, просто изменяя несколько участков кода подряд. Они могут изменить три или четыре участка и обнаружить, что все стало работать. Это круто, за исключением того, что они понятия не имеют, какой участок был плохим. Но еще хуже то, что все эти изменения кода могут сломать то, что изначально работало хорошо.
Помните, что вы всегда сможете точно сказать, какие эффекты имели те или иные изменения, если вы будете вносить их по одному за раз. И если изменение, кажется, не имеет никакого эффекта, немедленно верните все назад!
Проверьте, действительно ли ваши действия исправили ошибку
Золотое правило отладки заключается в том, что, если вы не исправили проблему, она никуда не исчезла.
Все хотят верить в то, что ошибка просто исчезла. Человек несколько раз терпел неудачу, но потом что-то случилось и все его злоключения закончились. И, конечно, отсюда следует вывод: “Может этого больше никогда не повторится”. Повторится.
Извините, что разочаровываю, но в реальном мире не бывает чудес.
Если вы считаете, что исправили ошибку, верните ее назад. Убедитесь, что все снова неправильно работает. Затем исправьте ее. Убедитесь, что все снова правильно работает. Повторяйте данный цикл до тех пор, пока не докажете, что устранили проблему.
Исправления иногда ведут себя забавным образом. Бывает, что они просто “прячутся”, а не решают проблему. И к тому времени, когда мы поймем, что исправление и не собирается взаимодействовать с проблемой, конечный продукт будет отправлен клиенту, который, очевидно, из-за всего этого будет не в лучшем расположении духа.
Помните, что если система дает сбой только в тот момент, когда вы возвращаете ошибку, значит вы можете быть уверены, что ваше исправление действительно работает.
И наконец, ведите журнал технических решений
Это может прозвучать банально, но это очень важный инструмент для решении проблем, который многие упускают из виду. Одни и те же проблемы возникают и повторяются в быту, на работе и даже в отношениях. Нет смысла заново изобретать велосипед раз за разом.
Трудно заранее предсказать, какой тип информации поддерживается в журналах технических решений, учитывая различные требования от компании к компании. Однако, как правило, можно рассматривать следующие пункты:
· Проблема #
· Инициатор (кто зарегистрировал вызов)
· Номер телефона или добавочный номер инициатора #
· Дата/Время Начала
· Краткое описание
· Влияние/Значение
· Тип (ошибки)
· Владелец (системы)
· Текущее состояние (открыто, в процессе, закрыто)
· Следующий шаг
· Дата следующего шага
· Дата окончания работы
· Запрос на разрешение проблемы, разработку #
Благодаря журналу проблем и найденных технических решений, вы сможете быстро найти решение, которое использовали в прошлом, а не сидеть в ступоре, говоря: “Эй, я сталкивался с этим раньше, но я понятия не имею, как я исправил это в прошлый раз”. Излишне говорить, что это не только сэкономит вам время, но и повысит вашу самооценку и уверенность до небес.
Как сказал Ричард Паттис:
“При отладке новички добавляют код для исправления положения, а профессионалы удаляют неисправный код.”
Перевод статьи Ravi Shankar Rajan: How Debugging Can Make You a Better Developer.
