Що робити, коли ви вичерпали всі шляхи, щоб виправити помилку

Я молодший програміст (4 місяці кар'єрного досвіду дотепер), який працюю над мобільним додатком Cross Platform (команда на 1 особу - так це я лише сам).

У мене є помилка в цій програмі / додатку, яка досить велика (30 різних файлів заголовків, у кожного теж власний cpp-файл). Я намагався відстежити, що саме відбувається з помилкою, а також виправити її (навіть намагався використовувати деякі хаки, щоб просто працювати), але приблизно з десяток і більше рішень (у мене є ідеї, що спричиняють проблему ) Я придумав, що нічого не змусило мене відстежувати, що саме є помилкою або виправляти помилку.

Чи є у вас поради для молодшого програміста деяких широких прийомів (піти на пробіжку, надрукувати весь мій код на папері та перейти через нього ручкою тощо), яку я міг би використати, щоб допомогти мені з цією помилкою?

Щоб дати трохи більше контексту для моєї помилки; він передбачає кросплатформенний API Mosync, коли я виконую певну послідовність дій, поточний екран не перемальовується (& здається), що попередньо відображений екран все ще отримує вказівник / клавішу подій натискання, а не поточний екран.

Конкретна послідовність:
- Відображення екрана меню - натисніть кнопку "Показати кнопку попередніх замовлень"
- Відобразити попередній екран замовлень - натисніть кнопку "Завантажити файл", потім натисніть кнопку меню та відкрити екран
доставки - Відображення екрана доставки - натисніть кнопку меню та відкрити екран
закупівлі - Відображення екрана покупки - Помилка тут, введення на цей екран не відображається / не реагує на, ListViews не прокручує, кнопки не реагують на кліки, клітини ListView не відповідають на кліки

Також я хотів би, щоб інша пара очей переглядала мою роботу і вказувала на помилку, але, як я вже сказав, я команда 1, мій начальник керує мною, він володіє компанією і має ідеї для програми, але робить не знаю c ++ або будь-яких останніх мов (кобальний? Я думаю, це все). Будь-яка порада, як отримати другу пару очей, не порушуючи / демонструючи інтелектуальний код / ​​власність компанії?

... і відмова від оплачуваної стажування не є варіантом. У контракті сказано, що якщо я вийду до 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 і перевірити, чи симптоми симптоматичні.

Якщо цього не зробити: що залишилось у вашій програмі тестування? Зрозумійте всі компоненти того, що залишилося, особливо будь-які запущені нитки. Щось робить обслуговування бази даних у фоновому режимі? Якийсь спілер файлу? Код моніторингу поведінки користувачів NSA? Чи працює інтерфейс користувача з деякими з цих компонентів (можливо, поза кадром)? Від яких фонових операцій залежить інтерфейс користувача?

Поки ви читаєте код - на який вам слід витрачати чималий час, враховуючи складність помилки - слідкуйте за деякими поганими методами, які можуть затьмарити вашу помилку. Зокрема, ви бачите щось із цього?

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

Це неймовірно погана практика, і як таке, досить звичне явище (ей, дивись, це не вийшло з ладу!). Переконайтесь, що ви оновите будь-який код, що робить це, щоб принаймні записати його - бажано повністю видалити обробку помилкових винятків. (Основне правило полягає в тому, що якщо ви не знаєте, що таке виняток, ви не готові впоратися з ним.) Якщо він взаємодіє з API-стилями C, слідкуйте за викинутими значеннями повернення коду помилки та переконайтесь, що ви перевіряєте інформацію про стан помилок із будь-яких інструментів, з якими ви взаємодієте.

Бачачи, як ваша тестова програма тепер правильно справляється з відмовами, і ви прочитали журнал, який ви створили таким чином, але все ще нічого не підкреслює помилку, шукайте інтерфейси, які можна перевірити. Чи є трансакція мережі, яка має відбуватися під кришками? Якщо це так, ударіть його Wireshark. База даних транзакцій? Спробуйте виконати деякий журнал запитів або перевірити стан сервера бази даних. Файлова система чи мережеві спільні акції? Перевірте проміжні файли або використовуйте налагоджувач для відстеження вводу / виводу. Апаратне введення / виведення? Монітор та зонд. Будьте емпіричним. Користувальницький інтерфейс цілком може бути відключений під час фонової операції, яку ви не передбачали.

Нарешті: не панікуйте. Зберігайте круто і слідкуйте за тим, що ви спробували. Якщо ви все ще не можете його знайти, це доведеться стати "відомою проблемою", яку слід відстежувати в дощовий день. Вам потрібно багато матеріалів, щоб виправдати це рішення, якщо воно повинно йти таким шляхом.

У схемі речей відтворювані помилки (відносно) прості! Чому? Тому що ви завжди можете зламати код до мінімального рівня, поки помилка не зникне, а потім повернутися до роботи, щоб з'ясувати, який код викликає його. Так що це один метод. Це відтворюється, у вас під вашим контролем там є творіння. Ви можете поцупити його і експериментувати. Ви можете навіть розсікати його, якщо хочете.

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

Покрокуйте поведінку програми, рядок за рядком. Слідкуйте за значеннями змінних. Слідкуйте за потоком контролю. Де поведінка спочатку відхиляється від того, що ваше розуміння говорить вам про те, що воно повинно бути? Ви розумієте, як операційна система надсилає події до вашої програми? Якщо вас заважає проблема "чорної скриньки", чи можете ви отримати джерело для складених бібліотек / фреймворків, що дозволяє вам перейти на більш глибокий рівень, якщо вам доведеться?

Чи є у вас система контролю версій, яка не видає цю помилку? (Ви використовуєте контроль версій, чи не так?) Якщо у вас є така фіксація, ви можете виконати двійковий пошук історії, щоб точно з’ясувати, де саме була введена помилка.

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

Але точно не сидите там тижнями, якщо ви дійсно застрягли. Ви також повинні сказати комусь у вашій організації. Запросіть допомогу там, де ви можете, і пройти певний момент, безумовно, вам належить сказати керівництву, що ви відчуваєте, що потрапили до бар'єру для просування. Але ви, швидше за все, зможете вирішити це, якщо вдарити по ньому з різних куточків, все зосереджено на навчанні та розумінні.