Ви їх знаєте, ті помилки, які НЕ мають сенсу. Де здається, що гремлін просто заскочив глибоко у твої фішки і щось заплутав. Ви гуляєте, пишете речі, дзвоните дядькові?
Ви їх знаєте, ті помилки, які НЕ мають сенсу. Де здається, що гремлін просто заскочив глибоко у твої фішки і щось заплутав. Ви гуляєте, пишете речі, дзвоните дядькові?
Відповіді:
Що стосується справді жахливих проблем, то моя стратегія зазвичай полягає в наступному.
Експериментуйте та google. Продовжуйте намагатися вирішити проблему. Більшість часу це вирішує проблему через годину чи менше.
Так що це не спрацювало. Відпочинь. Випити кави, поговорити про щось, що не має відношення до колеги. Виштовхнути проблему з розуму. Коли ви дивитесь на проблему через 5 або 10 хвилин, ви дивитесь на неї з дещо іншого погляду. Більшість часу це працює.
У цьому випадку це не так. Тож витрачайте на це ще 10 - 30 хвилин. Тоді зателефонуйте колезі. Але перед цим зробіть кілька записок; ви хочете продемонструвати проблему, відтворити її, потім перелічіть те, що ви спробували, і головне довести, що ви їх спробували. Тому спочатку робіть сухий пробіг. Встановіть у коді деякі позначки книги, закрийте зайві відкриті документи тощо. Таким чином, ви можете вирішити проблему самостійно, або, коли ви продемонструєте проблему, не будете витрачати свій час.
Попросіть колегу змусити вас довести всі свої припущення. це сеттер насправді викликає? Чи справді цей метод повертає те, про що ви заявляєте? Ви думаєте, що цей об’єкт не є нульовим - покажіть їм, що він не є нульовим.
Здебільшого, демонструючи проблему, ви змусите зрозуміти, що ви не випробували всі можливості, або ваш колега побачить вашу помилку.
Якщо це не спрацьовує час, щоб стати серйозним. Документуйте саме те, що ви намагаєтеся зробити, що ви намагалися, і чому це не вийшло. Надішліть це електронною поштою всім колегам. Опублікуйте його на SO. На цьому етапі документ повинен бути ідеальним питанням ПП.
Поки ви чекаєте відповідей, google google google. Спробуйте кожну перестановку питання, яке у вас є. Відкрийте купу вкладок. Ви, мабуть, не збираєтесь отримати відповідь до цього моменту, але ви шукаєте ідеї, можливості, різні способи підходу до проблеми.
Зробіть щось інше, якщо ви витратили 5 годин на проблему, час її залишити на інший день. Можливо, ви отримаєте корисну відповідь. Можливо, коли ви наступного дня нападете на проблему, це стане очевидним.
Якщо нічого з цього не працює, настав час шукати інше рішення. Можливо, ви можете використовувати інший метод, іншу технологію. Можливо, варто розглянути можливість покинути функцію. Ви виставляєте рахунок клієнту за годину? Ви працюєте для компанії у внутрішньому додатку? Вам потрібно передати це власнику і сказати їм: "дивись, я витратив на це х годин і не досягнув жодного прогресу, чи варто вигода від вартості?". Ви не хочете звертатися до свого начальника і говорити їм, що ви витратили 16 годин на проблему лише для того, щоб вони розвернулися і сказали: це не так важливо, пропустіть це для цього випуску. вам потрібно це дізнатися раніше.
А якщо це не працює? Що ж, ваші єдині варіанти - продовжувати забивати проблему або шукати галузевої експертизи. Запитайте фахівців з технологій на Twitter. Надішліть електронну пошту своєму постачальнику технологій.
Вийдіть. Ні, не ваша робота! Просто встань та йди додому. Ви закінчили на день або вихідні. 19 разів із 20, коли ви знову повернетесь до проблеми, рішення з’явиться протягом години.
Перед тим, як пройдуть десять годин, я отримав би допомогу.
Одним словом, timebox
приділіть обмежену кількість часу, щоб над чимсь працювати, і якщо це не вирішено, перейдіть до чогось іншого і поверніться до нього наступного дня зі свіжою перспективою.
Це та інший набір очей завжди коштує більше, ніж будь-який час, коли ви можете витратити, дивлячись на щось.
Я б ніколи не витрачав більше 45 хвилин на годину, намагаючись вирішити щось за один засідання, це порушує закон зменшення віддачі.
Поясніть проблему комусь іншому.
Пояснюючи проблему комусь іншому, ви повинні уточнити її: це часто дозволяє вам побачити рішення.
(Один із британських професійних комп'ютерних журналів колись запропонував продати вирізи з картону натурального розміру старшого програміста спеціально для цієї мети.)
Я вважаю, що сон при проблемі (іноді на пару днів) також може допомогти.
У мене є три кроковий план:
Кожен етап є ескалацією, якщо попередній крок не вдався. Майже завжди є щось інше продуктивне, над яким я можу працювати над другою стадією.
Я, як правило, роблю одну з трьох:
Будь-хто з трьох робить гарну роботу, відволікаючи себе від ситуації. Я вважаю, що відволікання дозволяють моєму підсвідомому мозку щось жувати на деякий час. Через годину або близько цього, бам, є рішення :-).
Побудуйте тестову запряжку, щоб орієнтуватися на цей дефект та ізолювати його
Просто продовжуйте усунути хороший код .., реплікуючи дефект. Поки ви не націлите на точний фрагмент коду, що містить помилку. Потім простежте за кодом.
Рекомендоване читання: Прагматичний програміст, зокрема, Розділ 10: Кулі відстеження
Усі ці пропозиції чудові. Однак я використовую техніку досить часто, яку я не бачив згаданої. Складіть списки, щоб упорядкувати свої думки щодо проблеми. Якщо у мене є особливо клейка проблема, я зазвичай виписую кілька списків, таких як: Факти, Припущення, Питання, Симптоми тощо. Я вважаю, що часто в процесі організації речей таким чином я виявляю припущення, які не усвідомлював, що маю ( які часто виявляються помилковими), питання, які я не усвідомлював, мені потрібно задавати, інші перестановки, які я можу перевірити, і т.д.
Редагувати:
Коротка відповідь:
Питання: Як ви вирішуєте дійсно химерні помилки, які спантеличують вас більше 10 годин?
A: Переконайтеся, що вони ніколи не трапляються: зрозумійте ваш дизайн, знайте свій код, навчіться користуватися налагоджувачем.
Пояснення:
"Де здається, що гремлін просто заскочив у твій чіпс і щось заплутав"
Це ніколи не повинно відбуватися. Якщо це ваш код, вам слід дуже добре уявити, що викликає помилку, перш ніж ви намагаєтеся виправити її.
Крім того, коли ви пишете свій код, ви вже повинні знати, де і чому він може вийти з ладу.
Сказавши це - попросити однолітка, розмістити повідомлення про SO, відступити і відкотити свої кроки та зробити перерву - всі пропозиції, згадані вище, допоможуть.
Інша річ - це ви повинні знати свої інструменти - свій інструментарій налагодження. Реєстрація повідомлень у підозрілих точках у вашому коді, ретельний огляд стека ваших дзвінків, використання умовних точок зупинки та годинника тощо тощо. Навички налагодження не є додатковими - вони є частиною програмування.
У мене була подібна проблема - очевидна пошкодження пам’яті в «Objective-C», з якою я боровся багато годин. Але потім я та мої колеги просто погуляли на обід, і я пояснив проблему (і один конкретний біт, пов’язаний із десеріалізацією об’єкта в його методі init), і в основному пояснив всю проблему самому собі.
(технічні подробиці: в основному я ініціалізував і повернув об'єкт на щось інше, ніж на себе, тому було два алоки, але повернувся лише один об’єкт. Пам'ять змістилася і збожеволіла, вибилася, і налагоджувач насправді не знав, що з цим робити це теж).
Прийми ванну.
Будь-які Родні Маккей шанувальників?
Однак, якщо серйозно, якщо серед усіх цих відповідей є одна спільність, варто зробити перерву і зробити щось інше .
Мені подобається вважати це перенесенням проблеми на вашу підсвідомість. Навіть якщо ми інакше не усвідомлюємо, наш розум (здається) продовжує працювати над проблемою, навіть коли ми робимо щось інше, наприклад, приймаючи ванну .
Поєднання всього перерахованого:
На деякий час відійдіть від нього, щоб він міг сидіти на спині пальника. Спи, відпочивай, їж, гуляй, що завгодно.
Більше вивчіть проблему, що ще робить це неправильно, які інші симптоми ви можете виявити?
Дослідіть проблему, подивіться, що ви можете знайти. Не забудьте спробувати різні ключові слова
Спробуйте щось інше . Робота навколо. Різна техніка налагодження. Валідатор. Інший комп’ютер.
Поговоріть з кимось . Навіть якщо вони не в змозі допомогти або навіть не програмісту, іноді розмова викликає лампочку ідеї
Перезавантажте! Якщо потрібно, спробуйте перезапустити комп’ютер, сервер тощо. Якщо нічого іншого, ви можете використати час для роздумів.
Запитайте StackOverflow! Ми тут, щоб допомогти
Мені дуже не сподобалася відповідь, яка найбільше голосує, тому що, хоча це колись працює, вам потрібно просто розібратися в той самий день, тож, що я рекомендував би в цьому порядку:
Підтвердьте, що це відбувається не тільки з вами. Це може заощадити багато часу. Можливо, ви видалили потрібний компонент або внесли зміни в оточення, і виняток проковтується десь у вашому коді. Якщо це відбувається тільки з вами, я б використав інструмент порівняння середовища. Нещодавно я читав про програмне забезпечення під назвою Envy, яке дозволяє робити саме це, хоча воно не є безкоштовним, воно коштує 10 USD.
Що сталося з усіма? Добре, тепер зробіть історію перегляду коду та перевірте наявність останніх змін, які могли спричинити помилку, прямо чи опосередковано.
Немає останніх змін? Якщо це дуже специфічна помилка (виняток), "stackoverflow it". Тепер це виглядає не краще, ніж "google it", але мені добре сказати, що спочатку шукаю stackoverflow для дослідження програм програмування, ніж Google. Якщо це дійсно відома проблема, велика ймовірність, що ви знайдете тут рішення. Якщо ні, то опублікуйте питання на відповідному сайті stackexchange. Ви можете отримати дуже швидку відповідь, або навіть якщо цього не зробите, ваше запитання буде там, поки ви будете проводити додаткові дослідження. Це вигода.
Якщо ви не знайшли відповідь в Інтернеті або це не є загальною помилкою, тоді покроково пройдіть код, перевіряючи, чи отримані результати кожного кроку мають сенс для очікуваного результату. Почніть переходити на кожен метод, а знизу вгору на багатоярусне рішення. (тобто, якщо ви усуваєте проблеми, почніть з коду, який отримує записи. Немає сенсу запускати в інтерфейсі користувача, якщо ви зможете швидко визначити, чи є перший крок проблемою).
Якщо після перегляду коду кілька разів ви все ще не знайшли, що не так, зателефонуйте комусь, щоб поговорити про це. Як вже говорив хтось, якщо говорити про це вголос, може запалити лампочку. Плюс парне програмування дійсно корисне.
У цей момент, якщо це можливо, пішіть далеко або на деякий час, або на день. Я вчора прочитав дуже правдивий твіт, у якому сказано: "Я лягав спати, думаючи" як ", і, звичайно,". Такий справжній.
Якщо ви все ще не маєте відповіді, смію сказати, що ви можете спробувати рефакторинг на більш дрібні завдання / методи / функції. Генрі Форд сказав щось на кшталт "Існує не така складна задача, яку неможливо виконати, розбивши її на більш дрібні завдання". На даний момент, якщо рішення занадто складне, і ви не з'ясували ні самостійно, ні за допомогою когось іншого, перефактуруйте код на більш дрібні завдання. Навіть якщо ви не закінчите робити це, це може допомогти вам знайти причину.
Додайте в свій код інструментарій.
Твіт про це ??
Вам потрібно відступити. Мій девіз: "Якщо проблема занадто сильна, то ви вирішите неправильну проблему". Які ваші припущення? не вірити нічого.
Наслідок цього - "чим дивніше проблема, тим смішніше рішення". Міцність комп'ютера - це його логіка, тому ви не можете виграти логіку. У вас є мозок і ви повинні його передумати.
У сучасний час у системі взаємодіє багато інших речей - брандмауери, AV, антишпигунські програми, автоматичні оновлення, що відбуваються щовечора - вам доведеться мати справу з рухомими цілями.