«Это работало вчера, я клянусь!» Что вы можете сделать? [закрыто]

59

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

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

Nikko
источник
10
Обвинение никогда не было отличной идеей. Поскольку вы не проработали вопрос или проблему, невозможно предположить, что программа сама не выдала ошибку. Например: если веб-сайт на хост-сервере достигает ограничения полосы пропускания, он сам отключается. Поэтому вы не можете никого обвинять, пока не убедитесь, что код не вел себя должным образом.
Панкадж Упадхяй
1
ну, это не переполнение стека, так что это более общий вопрос. Обвиняющая часть - это немного шутка :)
Никко
28
@ Никко - вчера это тоже не сработало. Вот что часто случается в разработке программного обеспечения :)
Joris Timmermans
4
Чтобы не оказаться в сложившейся ситуации, не спешите с тестированием, чтобы развернуть его в последние несколько минут дня. И снимите ваши розовые тонированные / опасные солнцезащитные очки во время тестирования.
Steve314
18
Это как-то связано с DateTime.Now () ???
Саравут Позитвинью

Ответы:

96

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

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

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

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

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

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

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

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

mouviciel
источник
82
Вы забыли «божественное вмешательство» и «частица высокой энергии прошла через сервер и случайно переставила биты». И солнечные извержения.
Хельдар
17
Вы забыли: «Вы используете <вставьте свой наименее любимый язык здесь>, что, как известно, ненадежно.
Конфигуратор
4
@ Хелдар - не забывайте, что вредоносные спрайты, гремлины и др.
5
5
@configurator: вот почему вы всегда должны писать на своем языке. Спросите Сполски о Васаби! проверяет, находится ли Этвуд рядом и убегает
Хельдар
13
другая классическая ловушка - смена даты. Это, конечно, особенно верно для «лимитных» дат (первый или последний день месяца / недели, 29 февраля и т. Д.).
Бранн
49

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

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

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

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

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

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

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

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

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

Хосе Фаэти
источник
7
Я хочу дать вам два возражения - один за "Если он не работает сегодня, он тоже не работал вчера". и один для "есть проблема, и она должна быть решена". Обе являются ключевыми идеями, которые слишком многие забывают.
MattBelanger
2
«Если он не работает сегодня, он тоже не работал вчера». -> Это случилось со мной вчера, когда я делал кодирование внешнего интерфейса, которое основывалось на cookie. Отлично работал, когда cookie уже был установлен. Выяснилось, что он больше не создается должным образом на следующий день, после того как истек срок его действия и пытается его воссоздать.
Грэм
@Graham: см. «Если между вчерашним и сегодняшним днем ​​[...] ничего не изменилось, это означает, что вы должны лучше тестировать код, прежде чем фактически заявить, что он работает». Вы должны лучше тестировать свой код, думать о том, что должно произойти, думать о том, что МОЖЕТ произойти. Возможно, с лучшим пониманием проблемы, этого бы не случилось.
Хосе Фаэти
Что касается 1): Может быть,
критическое
Не совсем верно ...: PI случайно сломал приложение, вставив в мое приложение некоторые файлы кэша, которые были объектами, которые были сериализованы совершенно неправильно. Приложение было в порядке, и оно работало нормально. Просто я сделал git pull, потому что файлы кэша были игнорированы, программа обновилась, и ей потребовались объекты в другом формате. Вы все еще получаете upvote хотя;)
Laykes
26

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

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

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

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

Michael Borgwardt
источник
Это также может помочь сохранить письменные заметки при анализе проблемы.
звездный синий
25

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

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

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

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

glenatron
источник
1
Это очень скромный и самоуничижительный ответ, который многие из нас должны принять. :) Обычно я записываю подобные ситуации так: «Эй, Мо, Эй, Ларри, я пытался думать, и ничего не происходило!» в конце дня. Я также использую метод «Это работает! Быстро, проверьте его и отправляйтесь домой, прежде чем вы захотите улучшить его» в конце дня, чтобы избежать подобных ситуаций.
Дженнифер С.
3
В одном месте, где я работал, с утра никто не сработал. Оказалось, что когда мы загружали свои машины, Skype захватывал порт, который приложение хотело использовать при первом запуске.
thepeer
Возможно, пикси - не более чем неинициализированная переменная? Иногда отладочная версия может работать при сбое версии выпуска (происходит сбой или ведет себя по-другому).
Джаред Апдайк
20

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

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

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

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

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

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

оборота френеля
источник
1
Diff Ftw. это то, что я всегда делаю.
Адитья П
2
@AdityaGameProgrammer: я использую его несколько раз в день, просто чтобы посмотреть, над чем я работал вчера или перед перерывом :)
phresnel
Нет контроля версий ?! Это действительно ужасающая перспектива.
thepeer
+1 за рассказ о git blame... не знал, что он существует, но это потрясающе
Раду Мурзе,
11

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

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

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

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

Стив
источник
5

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

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

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

Том Сквайрс
источник
5

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

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

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

Zjr
источник
5

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

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

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

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

оборота уриг
источник
2
Ошибки, связанные с такими временными особенностями, как переход на летнее время и обратно, являются любимыми (в октябре и марте) ...
Джулия Хейворд,
4

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

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

user1249
источник
4

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

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

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

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

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

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

Эндрю Нили
источник
3

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

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

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

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

чим
источник
конечно, если ваш проект охватывает несколько файлов, это может быть расширено * кашлем, случайным кашлем * удалением половины файлов вашего проекта, что, безусловно, является эффективным инструментом для снятия стресса (хотя убедитесь, что у вас есть резервная копия).
Ли Райан
Да, определенно убедитесь, что у вас есть резервная копия!
Чим
3

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

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

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

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

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

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

jwernerny
источник
Да, на работе мы используем Дженкинс, и это действительно полезно. Мы можем отслеживать сборки на разных системах и сразу увидеть, что не получается. У нас даже есть настоящий гаражный маяк, который начинает мигать при сбое сборки.
Никко
3

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

Муравей
источник
2

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

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

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

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

temptar
источник
2

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

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

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

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

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


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

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

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

wildpeaks
источник
2

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

Это то, что я запускаю локально, автоматически каждый час с 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.

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

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

olafure
источник
3
контроль версий проще
thepeer
@thepeer: абсолютно согласен. Тем не менее, есть вещи, которые не поддаются контролю исходного кода (особенно в расписании микро-фиксации), такие как большие двоичные файлы. Я просто счастлив, что могу избегать таких проектов большую часть времени
sehe
@thepeer: я действительно не думал, что кто-то посчитает это альтернативой контролю версий. Это было бы моей идеей организованного хаоса :) Таким образом, у вас есть копия ваших вещей, как это было вчера. Неважно, кто и что совершил в системе контроля версий. Ваш последний коммит также мог быть более 2 дней назад. В некоторых проектах определенные файлы игнорируются системой контроля версий.
olafure
@sehe: с git, который я сейчас использую, у вас есть свой личный репозиторий, так что нет повода не совершать на каждом этапе пути.
thepeer
@olafure: любая приличная система контроля версий должна позволять вам проверять / клонировать полное состояние системы в любой заданный момент.
Thepeer
2

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

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

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

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

оборота Мэтью Скотен
источник
1

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

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

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

Резервный!

Роберт
источник
-2

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

DKC
источник