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

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

У меня есть ошибка в этой программе / приложении, которая довольно большая (30 различных заголовочных файлов, каждый со своим собственным файлом cpp). Я пытался точно отследить, что происходит с ошибкой, а также исправить ее (даже пытался использовать некоторые хаки, чтобы просто заставить ее работать), но около десятка или более решений (у меня есть идеи о том, что вызывает проблему). ) Я ничего не выдумал, что заставило меня отследить, что это за ошибка, или исправить ошибку.

Есть ли у вас какой-нибудь совет для младшего программиста по каким-то широким методам (бегите, печатайте весь мой код на бумаге, просматривайте его ручкой и т. Д.), Который я мог бы использовать, чтобы помочь мне с этой ошибкой?

Чтобы дать немного больше контекста для моей ошибки; он включает в себя кроссплатформенный API Mosync, когда я выполняю определенную последовательность действий, текущий экран не перерисовывает (и кажется), что ранее отображенный экран все еще получает события указателя / нажатия клавиши, а не текущий экран.

Определенная последовательность:
- Отображается экран меню - нажмите «Показать кнопку предыдущих заказов»
- Отображается экран предыдущих заказов - нажмите «Загрузить файл», затем нажмите кнопку меню и откройте экран
доставки - Отображается экран доставки - нажмите кнопку меню и откройте экран
покупки - Отображается экран покупки - Ошибка здесь, вход на этот экран не отображается / не реагирует на, ListViews не прокручивается, кнопки не реагируют на нажатия, ячейки ListView не реагируют на нажатия

Кроме того, я бы хотел, чтобы другая пара глаз осмотрела мою работу и указала на ошибку, но, как я уже сказал, я команда из 1, мой босс направляет меня, он владеет компанией и имеет идеи для приложения, но делает не знаю с ++ или каких-либо недавних языков (кобаль? я думаю это все). Любой совет, как получить вторую пару глаз, не нарушая / не демонстрируя интеллектуальный код / ​​собственность компании?

... и не выходить из этой оплачиваемой стажировки - это не вариант, в контракте говорится, что если я уйду до 6 месяцев с 12-месячного контракта, я могу заплатить 30% моей годовой зарплаты

Если вы можете воспроизвести проблему 100% времени, установите точку останова на последнем шаге (как можно раньше). Если вы пройдете весь стек вызовов, я почти уверен, что вы где-нибудь найдете неожиданные значения или что-то, что следует вызывать, но это не так.

Редактировать:

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

Отладка больше связана с изоляцией и пониманием того, в чем именно заключается проблема (по сравнению с применением исправления)

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

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

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

1. Поймите, что это просто код, и где-то есть ошибка (это не просто черная магия), которую вы МОЖЕТЕ исправить.
2. Сделать перерыв
3. Очень медленно перебирайте код, анализируя каждый шаг и следя за тем, чтобы вы понимали его и то, что он делает, ничего не скрывая.
4. Получить вторую пару глаз, чтобы посмотреть на проблему.
5. Иди спать и забудь об этом до завтра (очисти голову), давай с новой точки зрения).
6. Распечатайте свой код и проанализируйте каждую строку, делая пометки на полях, понимая каждый смысл каждой строки
7. Если это не критическая ошибка, но она вызывает ошибки, о которых пользователь не должен знать, я (стыдно, но честно) поймал ошибку и проглотил ее! Если это не опасно, и вы не можете найти причину, иногда вы просто ловите ее и не позволяете пользователю узнать, что случилось. Это все о рентабельности инвестиций для клиента, а иногда это не стоит.
8. Скажите устно об ошибке, что вы собираетесь ее выследить и убить. Иногда это убежит. :-)

У меня обычно такой подход при решении ошибок.

1. Создайте хороший шаг за шагом, чтобы воспроизвести ошибку
2. Упростите шаг за шагом
3. Где в коде возникает ошибка? Например, какие функции задействованы?
4. Какой путь выбирает код при возникновении ошибки, callchain.
5. Сосредоточьтесь на месте, когда это нормально, когда это не так. Затем повторяйте это много, пока не найдете именно то место, где произошла ошибка.
6. Почему это происходит?

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

Затем я пытаюсь решить проблему и использую шаг за шагом, который вы создали на первом шаге, чтобы проверить, исправлена ​​ли ошибка.

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

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

Как говорили другие 1) быть в состоянии надежно воспроизвести его и 2) шагнуть вперед в отладчике до того момента, когда это произойдет.

Если я не могу этого сделать по какой-либо причине, у меня есть два других метода, которые требуют наличия другой версии кода, которая не демонстрирует ошибку.

1. Запустите обе версии кода параллельно под отладчиками. Шагайте им вперед, пока плохой не сделает что-то отличное от хорошего.

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

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

Если вам поручили выполнять работу под рукой младшего программиста, есть хотя бы один человек, который полагал, что вы способны справиться со всем этим самостоятельно.

Затем, прежде чем обращаться за помощью к своему начальству, запишите на макулатуре список шагов / методов, которые вы предприняли для отслеживания ошибки, как далеко вы продвинулись с ней, почему вы отказались от каждого метода и что вы узнали в каждой попытке. Также, подведите итог тому, что вы узнали о проекте до сих пор.

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

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

Нам нужно знать, насколько сложно воспроизвести, так как метод совершенно другой. Для надежно воспроизведенного дефекта, автоматизируйте, вызывая дефект. Используйте отладчики и трассировки отладки (трассы меньше всего влияют на дефекты типа состояния гонки). Получите методический. Один шаг за раз, каждый шаг предоставляет больше информации, даже это подтверждает то, что вы уже знаете. Если вы получите неожиданный результат, остановитесь, поймите это на 100%, прежде чем двигаться дальше. Это мучительно медленно, но всегда приводит вас к конечному результату, если вы уделяете ему достаточно времени.

Если вы не можете воспроизвести его, у вас есть проблема, как вы подтверждаете, что исправили это. Вставьте код отладки и оставьте его там. В конце концов, спросите себя, является ли «Закрыт: DNR» допустимым вариантом? (Сделал / не смог воспроизвести). В бизнесе, в конце концов, это решение по соотношению цена / качество.

Не думайте, что ваши библиотеки верны, подтвердите, что они есть.

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

Здесь много хороших ответов. Несколько других советов:

Интерфейсы редко живут в изоляции. Создайте тестовую программу с минимальным набором функций, необходимых для воспроизведения ошибки. Если пользовательский интерфейс хорошо спроектирован, вы сможете отделить компоненты пользовательского интерфейса, которые не работают, и запускать их изолированно в тестовой программе. Вы все еще можете воспроизвести проблему? Если так, проблема, вероятно, в вашей структуре или структуре пользовательского интерфейса. Проверьте свою структуру пользовательского интерфейса - особенно следите за невидимыми элементами. Попробуйте точно узнать, что происходит, когда вы нажимаете на этот ListView, и он не отвечает - какие обработчики событий вызываются? Имейте в виду, что в самой структуре пользовательского интерфейса могут быть ошибки - не делайте поспешных выводов, не исключайте их полностью. Быстрый тест - обновить вашу версию Mosync и проверить, проходят ли симптомы.

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

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

try {
    SaveTheWorld();
} catch (std::exception& ex) { /* oh it didn't work, let's just ignore it */ }

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

Видя, как ваша тестовая программа теперь правильно обрабатывает сбои, и вы прочитали созданный таким образом журнал, но все равно ничего не высвечивает ошибку, ищите интерфейсы, которые вы можете исследовать. Есть ли сетевая транзакция, которая должна происходить под прикрытием? Если это так, ударь его Wireshark. База данных транзакции? Попробуйте войти в журнал запросов или проверить состояние сервера базы данных. Файловая система или сетевые ресурсы поражаются? Проверьте промежуточные файлы или используйте отладчик для отслеживания операций ввода-вывода. Аппаратный ввод / вывод? Монитор и зонд. Будь эмпирическим. Пользовательский интерфейс вполне может зависнуть от какой-то фоновой операции, которую вы не ожидали.

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

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

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

Пошаговое поведение приложения, строка за строкой. Следите за значениями переменных. Следите за потоком контроля. Где поведение в первую очередь отклоняется от того, что ваше понимание говорит вам, что это должно быть? Вы понимаете, как операционная система отправляет события в ваше приложение? Если вам мешает проблема «черного ящика», можете ли вы получить исходный код для скомпилированных библиотек / фреймворков, позволяющих вам перейти на более глубокий уровень, если это необходимо?

У вас есть коммит в вашей системе контроля версий, который не выдает эту ошибку? (Вы используете контроль версий, не так ли?) Если у вас есть такой коммит, то вы можете выполнить бинарный поиск по истории, чтобы точно определить, где была введена ошибка.

Ваши цели должны заключаться в том, чтобы (1) понять - определить причину и с этой целью попытаться (2) детально изучить, понять поведение приложения (3) изолировать проблему, заставить ее уйти, а затем изучить и понять дельту, которая позволил вам сделать это

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