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

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

Обычные подозреваемые:

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

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

• Рабочая станция перезагрузилась прошлой ночью или очистила каталоги / tmp после ночной операции обслуживания.

• Что-то изменилось в базе кода: проверьте, зафиксировал ли кто-то (возможно, вы) изменения между вашей последней компиляцией вчерашнего дня и вашей последней компиляцией сегодня.

• Что-то изменилось в библиотеках поддержки: проверьте, были ли эти библиотеки перекомпилированы или обновлены. Причина может быть внутри проекта для определенных библиотек или снаружи, если была развернута новая версия, по-видимому, независимого пакета.

• Что-то изменилось в среде тестирования: новая версия виртуальной машины, измененная заглушка, изменения на удаленном сервере баз данных ...

• Что-то изменилось в цепочке компиляции: изменения в Makefiles, новая версия IDE, компилятора, стандартных библиотек ...

1) Если он не работает сегодня, он тоже не работал вчера.

Вы думали, что это работает, но это не так.

2) Есть проблема, и она должна быть решена .

Не думайте о том, кто несет за это ответственность или обвиняет других.

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

Чтобы избежать этой ситуации, вы должны сделать правильное тестирование и отладку .

Определите «рабочий» и проверьте границы ваших программных подпрограмм.

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

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

Попытка найти кого-то, кто передаст вину, неконструктивна и не решает проблемы. Не делай этого.

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

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

Использование соответствующих диагностических инструментов (отладчик, профилировщик, инструменты сетевого анализа) также может иметь большое значение.

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

Со временем я понял, что вполне возможно, что на самом деле феи не имеют к этому никакого отношения и что, возможно, мое «время идти домой, этого будет достаточно» последняя сборка не получит подробного тестирования и внимания, которые, возможно, заслуживают ,

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

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

Используйте контроль версий. Сделайте разницу или используйте функциональность вины вашего VCS .:

• diffКаждый VCS. Показывает различия разных версий
• blame: например мерзавец. Показывает построчно, кто что изменил

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

Кроме того: Перекомпилируйте все, не забудьте также перекомпилировать вспомогательные библиотеки.

Конечно: если вы нашли источник ошибки, сохраняйте спокойствие, спросите, почему было внесено изменение, объясните свою проблему и предложите решение, которое сделает вас обоих счастливыми. Не кричите на него / него, это будет ядом для вашей продуктивности.

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

Ну, вот реальный пример кода, который «работал вчера», а не сегодня ... Это было в начале этого месяца.

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

Другая подсказка в том, что мы находимся в Великобритании, база данных была в США ...

Итак, мой ответ на ваш вопрос о том, что проверять первым, состоит в том, чтобы дважды проверить, как вы форматируете свои даты, потому что, если вы перепутаете поля дня и месяца, они будут работать отлично, но только 1 день в месяц :-)

Исправьте ошибку (как вы обычно это делаете). Затем, если вы обнаружите, кто это вызвал, отправьте им вежливое электронное письмо, сообщающее, что пошло не так

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

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

... вы проводите регрессионные тесты и сосредотачиваетесь на тех, которые терпят неудачу.

На самом деле это то, что вы забыли сделать вчера перед отъездом, это происходит.

У вас нет? Хорошо .. что где ты говоришь? Обвинять ? Ну ... это может сработать, тогда

Первое, что нужно сделать, когда что-то перестает работать, это спросить себя: что отличается? Что изменилось?

Когда что-то сработало прошлой ночью, но не сработало сегодня утром, очевидно, что изменилось одно - дата и время :)

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

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

Отчасти короткий ответ (для написания), но довольно долго, чтобы понять суть этого: Почему программы терпят неудачу: Руководство по систематической отладке, написанное Андреасом Зеллером (что может показаться слишком академичным, но это не так)

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

Тогда иди поговори с ним или с ней.

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

Посмотрите на данные

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

У меня когда-то был код ввода заказа, работающий отлично в течение нескольких недель. Я пошел домой однажды, и он умер. Расследование на следующий день показало, что в цепочке вызовов функций скрыта ошибка. В слабо типизированном языке я объявил целое число, когда мне следовало использовать long int. Язык выполнял преобразование между двумя автоматически, пока не смог, потому что число превысило то, что вписалось бы в целое число. Сбой системы по номеру заказа 32768.

Посмотрите, что изменилось

Посмотрите, что изменилось с тех пор, как это сработало. Вышел ли в отдел ИТ обновление ОС? Другой кодер изменил код, который использует ваша программа? Изменилось ли разрешение пользователя? Часто, если вы найдете то, что изменилось, вы найдете ошибку.

Бинарная отбивная

Особенно хорошо работает для сложных ошибок JavaScript. В основном, прокомментируйте половину кода, посмотрите, если вы получите ошибку, если вы делаете, это в этой половине кода. Снова наполовину и продолжайте.

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

После того, как вы нашли виновный код, часто стоит выделить ошибку на собственной тестовой странице.

И конечно, что можно сделать, чтобы не оказаться в такой ситуации?

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

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

Здесь есть и другие вопросы о том, какой CI Server использовать, поэтому я позволю вам найти их заинтересованными. Лично я большой поклонник Дженкинса.

[Что я должен делать с вещами, которые ломаются.]

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

Моя естественная реакция - всегда обвинять других, но со временем я осознал, что обычно я виноват. В дополнение ко всем превосходным комментариям, приведенным выше, важно, чтобы вы сами записали, какой была последняя причина. Неважно, используете ли вы вики, которой делятся другие члены команды, частную Twiki, Evernote, журнал или хорошую память. Важно то, что в данный момент вы найдете ответ (и хотите вернуться к работе!), Чтобы записать причину.

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

Если единственное описание проблемы «это не работает», первое, что вам нужно сделать, это собрать больше информации о симптомах проблемы.

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

Тогда вы начинаете исключать их.

Вот что обычно происходит, когда я беру каникулы :-)

Более серьезно, я бы сначала сказал им:

• Я посмотрю в это, чтобы увидеть, что не так и что может быть корнем

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

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

Что касается обвиняющей части:

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

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

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

Это то, что я запускаю локально, автоматически каждый час с 8 утра до 6 вечера:

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

Просто, а?

Если вам когда-нибудь придется что-то восстанавливать, используйте

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

rdiff-backup хранит только файлы, которые отличаются. Вы можете использовать rdiff-backup на Linux, Mac и Win.

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

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

Ошибка, возможно, уже существовала, но была скрыта внешними факторами или глубокими системными проблемами.

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

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

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

это работало вчера, поскольку оно использовалось правильно.

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

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

Резервный!

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