Никогда не переходите к неизвестному пути, в том числе и в программном обеспечении?[Принцип Toyota] [закрыт]

Question

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

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

Итак, вот этот подкаст.Я думаю, что это интересно

http://itc.conversationsnetwork.org/shows/detail3798.html

Answer 1

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

Несколько примеров:

Я действительно работал над проектом, где это было практически осуществимо, и это очень помогло.Когда мы были близки к отправке и заканчивались ошибки, которые нужно было исправить, мы запускали нашу игру в "режиме с нулевым количеством игроков", где компьютер всю ночь напролет воспроизводил себя со всеми вариациями персонажей и локаций.Если бы он утверждал, то отображал бы случайный ключ, который запустил совпадение.Когда мы приходили утром на работу, мы записывали ключ с нашего экрана (обычно там был один) и запускали его снова, используя этот ключ.Затем мы просто наблюдали за этим, пока не появлялось утверждение, и выслеживали его.Важно то, что мы могли бы воссоздать все исходные входные данные, которые привели к ошибке, и повторять их столько раз, сколько захотим, даже после перекомпиляции (в определенных пределах...количество выборок из генератора случайных чисел изменить не удалось, хотя у нас был отдельный RNG для неигровых вещей, таких как visual fx).Это работало только потому, что каждое совпадение начиналось после теплой перезагрузки и принимало в качестве входных данных только очень небольшой объем данных.

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

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

Answer 2

С программным обеспечением это менее важно.Если что-то идет не так в программном обеспечении, вы обычно можете воспроизвести неисправность и проанализировать ее в автоматическом режиме.Даже если это происходит только 1 раз из 1000, вы часто можете включить все протоколирование и запустить его 1000 раз (простой тест на выдержку).

На производственной линии это намного дороже и отнимает много времени, практически невозможно.

Иметь в наличии как можно больше информации на тот случай, если что-то пойдет не так, это неплохо, но для меня это не так важно, как для Toyota.

Answer 3

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

Answer 4

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