Коли ви приїжджаєте вранці, то виявляєте, що ваше програмне забезпечення вже не працює, навіть незважаючи на те, що це було, коли ви виїхали вчора ввечері.

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

Звичайними підозрюваними є:

• Ви думали, що це працює вчора, але після повного робочого дня ви були занадто сліпими, щоб зрозуміти, що це не працює.

• Сьогодні вранці ви більше не можете посилатися на те, що було в кеш-пам'яті IDE вчора.

• Робоча станція перезавантажилася минулої ночі або очищена / tmp каталоги операції нічного обслуговування.

• Щось змінилося в базі коду: перевірте, чи хтось (можливо, ви самі) вчинив зміни між вашою останньою компіляцією вчора та вашою останньою компіляцією сьогодні.

• Щось змінилося в бібліотеках підтримки: перевірте, чи були ці бібліотеки перекомпільовані чи оновлені. Причина може бути всередині проекту для конкретних бібліотек або поза ним, якщо нова версія зовнішнього незалежного пакету була розгорнута.

• Щось змінилося в середовищі тестування: нова версія віртуальної машини, модифікована заглушка, зміни на віддаленому сервері баз даних ...

• Щось змінилося в ланцюжку компіляції: зміни в Makefiles, новій версії IDE, компілятора, стандартних бібліотек ...

1) Якщо це не працює сьогодні, він не працював і вчора.

Ви думали, що це працює, але це не так.

2) Є проблема, і її треба вирішити .

Не думайте про те, хто несе відповідальність за це чи про звинувачення інших.

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

Щоб уникнути такої ситуації, ви повинні провести належне тестування та налагодження .

Визначте "працюючий" і протестуйте межі підпрограм вашого коду.

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

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

Спроба знайти когось, щоб передати провину, неконструктивна і не вирішує проблем. Не робіть цього.

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

Як саме ви дізнаєтеся, що це за справа, і як це можна виправити, залежить від специфіки ситуації, але це завжди допомагає бути методичним у усуненні причин, тобто не змінюйте відразу 5 речей і перестаньте шукати, якщо це допомагає - з’ясуйте, яка конкретна річ спричинила проблему, і, можливо, напишіть, як її виправити, щоб ви могли це переглянути, коли це повториться через 3 тижні відтепер

Використання відповідних засобів діагностики (налагоджувач, профілер, інструменти мережевого аналізу) також може призвести до великої зміни.

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

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

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

Іноді насправді нічого спільного зі мною - хтось оновив залежність, не згадуючи про неї, WindowsUpdate встановив щось, що змінило середовище, щоб мій код не працював; Фонових можливостей дуже багато, але зазвичай це справа комплектування та прийняття того, що, як і більшість людей, я в основному ідіот.

Використовуйте контроль версій. Зробіть різницю або використовуйте функцію звинувачення VCS.

• diff: Кожен VCS. Показує відмінності різних версій, ум
• blame: наприклад git. Показує вам по черзі, хто що змінив

Якщо немає контролю над версіями, окрім того, що це ваша чи ваша вина, ви можете переглянути дати зміни файлів і, можливо, заглянути в засоби реєстрації вашої ОС.

Крім цього: перекомпілюйте все, переконайтеся, що також перекомпілюйте допоміжні бібліотеки.

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

Якщо змін взагалі немає, настав час подивитися, що змінилося в системі. Наприклад, недавно комп'ютери Mac OS оновились до нової версії Apache, яка призвела до недійсності деяких конфігурацій.

Що ж, ось приклад реального життя коду, який "працював вчора", а не сьогодні ... Це з початку цього місяця.

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

Інша підказка полягає в тому, що ми перебуваємо у Великобританії, база даних була у США ...

Отже, моя відповідь на ваше запитання про те, що спершу перевірити, - це двічі перевірити, як ви форматуєте свої дати, адже якщо ви змішаєте дні та місяці, поля будуть працювати ідеально, але лише 1 день на місяць :-)

Виправте помилку (однак зазвичай це робите). Тоді якщо ви знайдете, хто це спричинив, надішліть їм ввічливий електронний лист, щоб повідомити, що пішло не так.

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

Єдине, якщо ви підозрюєте, що вони є необережними, якщо ви зробите велику справу з пари помилок.

... Ви запускаєте тести регресії та зосереджуєтесь на тих, хто не вдається.

Насправді те, що ви забули зробити вчора перед від'їздом, це трапляється.

У вас немає? Добре .. що там, де ти кажеш? Звинувачуючи ? Ну ... це може спрацювати, значить

Перше, що потрібно робити, коли щось перестає працювати - це запитати себе - що відрізняється? Що змінилося?

Коли щось працювало минулої ночі, але не вдалося сьогодні вранці, одне, що очевидно змінилося, - це дата та час :)

Я б спробував подумати, чи є якась частина логіки, над якою я працюю, залежить від дат і на яку може вплинути проходження часу. Дивно, скільки разів це причина таких проблем.

Якщо це не вдається, вам обов'язково слід скористатися іншими чудовими порадами, наданими тут.

Своєрідна коротка відповідь (писати), але якось довга, щоб зрозуміти суть цього: Чому програми виходять з ладу: Посібник із систематичної налагодження Андреаса Зеллера (який може виглядати занадто академічним, але це не так)

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

Тоді йди поговорити з ним чи з нею.

Є лише дві можливі причини, чому ваш код не працює сьогодні, але працює вчора.

Подивіться на дані

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

Я колись мав якийсь код для введення замовлення, який працює тижнями. Я одного дня пішов додому, і він помер. На наступний день слідство показало, що у мене виявлена ​​помилка, захована у ланцюзі викликів функцій. Слабо набраною мовою я оголосив ціле число, коли я повинен був використовувати довгий int. Мова здійснювала перетворення між цими двома автоматично, поки не змогла, оскільки число перевищило те, що входило б у ціле число. Система вийшла з ладу за номером замовлення 32768.

Подивіться, що змінилося

Подивіться, що змінилося з моменту його роботи. Чи розділ ІТ витіснив оновлення ОС? Чи змінив інший кодер код, який використовує ваша програма? Чи змінився дозвіл користувача? Часто, якщо ви знайдете, що змінилося, ви знайдете помилку.

Бінарний рубати

особливо добре працює при складних помилках JavaScript. В основному прокоментуйте половину коду, подивіться, якщо ви отримуєте помилку, якщо ви робите це в тій половині коду. Половину знову і продовжуйте.

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

Щойно ви знайшли код провини, часто варто виділити помилку на власній тестовій сторінці.

І звичайно, що можна зробити, щоб не опинитися в такій ситуації?

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

На практиці більшість команд, які використовують CI, використовують сервер CI (див . Список Вікіпедії ). Сервер CI, як правило, налаштований для моніторингу сховища SCM та початку збірки, коли він побачить зміни. Коли збірка завершена, вона запустить серію автоматизованих тестів та опублікує результати за допомогою електронної пошти та / або веб-сторінки збірки та тестів, а також, які зміни спричинили збірку. Будемо сподіватися, що коли щось порушує збірку чи тести, у вас є лише дуже невелика зміна, яку потрібно переглянути, і це вирішиться швидше.

Тут є інші запитання щодо того, яким CI-сервером користуватися, тож я дозволяю вам їх зацікавити. Особисто я великий фанат Дженкінса.

[Що мені робити, коли речі порушуються.]

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

Моя природна реакція завжди винні інші , але з часом я прийшов до висновку , що це , як правило , мене , хто винен. Окрім усіх чудових коментарів, зазначених вище, важливо записати для себе, яка була остаточна причина. Не має значення, чи використовуєте ви Wiki, яким надаєте спільний доступ до інших членів команди, приватні Twiki, Evernote, журнал журналів чи гарну пам’ять. Важливо, що в момент, коли ви знайдете відповідь (і хочете повернутися до роботи!), Це записати причину.

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

Якщо єдиним описом проблеми є "це не працює", перше, що вам потрібно зробити, - зібрати більше інформації про симптоми проблеми.

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

Тоді ви починаєте їх виключати.

Ось що зазвичай буває, коли я беру свята :-)

Більш серйозно, я спершу сказав би їм:

• Я перегляну це, щоб побачити, що не так і що може бути коренем

• Я торкнуся бази через 30-60 хвилин, як тільки я мав шанс побачити, що відбувається

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

Що стосується звинувачувальної частини:

• якщо це просто друкарська колега, про це не потрібно згадувати: лайно трапляється, і переляк від помилки, швидше за все, навчив його уроку, і, сподіваємось, він цього не зробить знову.

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

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

Це те, що я працюю локально, автоматично щогодини з 8 ранку до 18 вечора:

rdiff-backup /path/to/mystuff /path/to/mybackup

Просто, так?

Якщо вам коли-небудь доведеться відновити, скористайтеся

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-резервне копіювання зберігає лише ті файли, які відрізняються. Ви можете використовувати rdiff-резервне копіювання на Linux, mac та win.

Звичайно, це не має бути єдиним резервним копієм. Але це надзвичайно простий і дешевий спосіб мати локальну резервну копію.

Тепер я б не рекомендував це як звичайний метод виправлення помилок, але якщо все інше не вдалося, це резервна копія.

Помилка, можливо, вже існувала, але її приховували зовнішні фактори або глибокі проблеми системи.

Це сталося зі мною. Помилка, розроблена між двома версіями нашого проекту. Буквально, єдиною зміною, яку ми внесли, було оновлення до новітньої збірки однієї з базових бібліотек.

Ми, природно, звинувачували їх. Але єдиною зміною, яку вони внесли, було повернення деяких заголовків для швидшого компіляції. Я погодився, що це не повинно було порушити систему.

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

він працював вчора, як він використовувався правильно.

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

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

Резервне копіювання!

Я вважаю, що встановлення точок перерви призупиняється і перевіряють мої дані дуже корисні, щоб точно визначити, де і як це йде погано.