Советы по отладке с очень небольшим количеством информации? [закрыто]

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

Со всем этим я могу справиться большую часть времени без проблем.

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

По сути, это сводится к следующему:

• Большая и сложная кодовая база, с которой я не знаком на 100%
• Много-много способов что-то может пойти не так
• Очень мало информации о том, как появилась ошибка

У кого-нибудь есть какие-либо советы, хитрости, предложения и т. Д., Как отлаживать подобные вещи?

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

Если у ваших клиентов возникают проблемы с описанием шагов, попросите у них видео с экрана. Есть несколько бесплатных продуктов, которые могут их создавать, например Jing. Это намного облегчает, когда вы можете точно наблюдать за тем, что они делали.

РЕДАКТИРОВАТЬ: Цзин был хорошей идеей, когда я написал это несколько лет назад. С тех пор они изменили свой установщик, чтобы загрузить вашу систему с «бонусным» программным обеспечением, которое вы никогда не запрашивали, поэтому я больше не могу его рекомендовать. Хотя вокруг полно приличных рекордеров экрана.

Хорошее начало может быть эта книга .

Я использую приведенное ниже определение, поскольку кажется, что разработчик больше не поддерживает его.

Устаревший код - это исходный код, который больше не поддерживается.

У меня была похожая проблема несколько лет назад, и самым большим повышением производительности и очистки кода стала интеграция отслеживания ошибок в систему.

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

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

Мой самый серьезный совет - начать рефакторинг, где вы можете. Я не могу сосчитать, сколько раз я видел копию функциональности, только чтобы узнать, что это не 100% полная копия. Это была копия на 99,9% и одна маленькая незначительная ошибка, которая привела к ошибке. Начните добавлять модульные тесты ко всему, и если у вас есть отдел QA, попробуйте подготовить несколько сценариев автоматического тестирования для тех частей кода, с которыми вы работаете.

С другой стороны, посмотрите, сколько журналирования может внедрить в код. То есть, если у него мало способов ведения журнала, вы можете добавить флаг к коду, чтобы начать собирать более подробное ведение журнала для своих собственных целей отладки. Это то, что вы можете сделать так, чтобы пользователь включал и выключал, если вы можете запустить диалог. Это помогло мне больше раз, чем я могу сосчитать. Я обычно получаю "это не работает" без картины проблемы. Я просто говорю «пришлите мне файл журнала».

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

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

Продолжайте итерацию, пока не поймете кодовую базу.

Излишне говорить, что это то, что вы должны сделать заранее, а не в ответ на сообщение об ошибке.