Поехали:
Слайд 259
Предположим, что вызывающий вешает трубку в то время, когда вы поместили его вызов на удержание. Это редкий кейс в 1980-е. Стандарты клиентского сервиса были очень высокими. 90% вызовов на удержании пересоединялись в течении двух минут и не очень много людей бросали трубку, пока их вызов удерживали. И мы хорошо обрабатывали этот случай. Когда вызывающий бросал трубку, мы убирали его имя с дисплея, помечали линию, как доступную, все выглядело так, как будто звонок закончен. Но запись о звонке оставалась в стеке. Недоступная, но не удаленная. И стек переполнялся.
Слайд 260
Вам кажется, что мы могли бы заметить сразу эту проблему, так как наши тестировщики работали с 10 вызовами на удержании и сбрасывали вызовы.
Но проблема более тонкая.
В действительности наш код проверял стек каждый раз, когда мы добавляли или удаляли из него что-либо. И мы поймали бы этот баг. К сожалению, к этому времени прошло слишком много времени и мы были уверены, что удержание и ожидание звонка работают корректно и не ожидали обнаружить проблемы со стеком.
Баг был создан позже, когда мы увеличили размер стека до 20 звонков в очереди. Так что даже если мусор и попадал в стек, у нас все равно было в нем место для настощих звонков. Также мы добавили сброс стека в некоторые места программы, например в состояние режима ожидания телефона. Так мы убеждались что если в стек и попадет мусор, то он будет очищен.
Это не было необходимо, так как стек работал, но мы сделали это на всякий случай, в рамках защитного программирования, вы учитываете возможность внесения дефектов в код в дальнейшем и хотите автоматически обнаруживать и восстанавливать сбои.
В следующем году один из нас действительно внес баг и этот защитный код сделал его безвредным и незаметным для остальных.
Слайд 259
Предположим, что вызывающий вешает трубку в то время, когда вы поместили его вызов на удержание. Это редкий кейс в 1980-е. Стандарты клиентского сервиса были очень высокими. 90% вызовов на удержании пересоединялись в течении двух минут и не очень много людей бросали трубку, пока их вызов удерживали. И мы хорошо обрабатывали этот случай. Когда вызывающий бросал трубку, мы убирали его имя с дисплея, помечали линию, как доступную, все выглядело так, как будто звонок закончен. Но запись о звонке оставалась в стеке. Недоступная, но не удаленная. И стек переполнялся.
Слайд 260
Вам кажется, что мы могли бы заметить сразу эту проблему, так как наши тестировщики работали с 10 вызовами на удержании и сбрасывали вызовы.
Но проблема более тонкая.
В действительности наш код проверял стек каждый раз, когда мы добавляли или удаляли из него что-либо. И мы поймали бы этот баг. К сожалению, к этому времени прошло слишком много времени и мы были уверены, что удержание и ожидание звонка работают корректно и не ожидали обнаружить проблемы со стеком.
Баг был создан позже, когда мы увеличили размер стека до 20 звонков в очереди. Так что даже если мусор и попадал в стек, у нас все равно было в нем место для настощих звонков. Также мы добавили сброс стека в некоторые места программы, например в состояние режима ожидания телефона. Так мы убеждались что если в стек и попадет мусор, то он будет очищен.
Это не было необходимо, так как стек работал, но мы сделали это на всякий случай, в рамках защитного программирования, вы учитываете возможность внесения дефектов в код в дальнейшем и хотите автоматически обнаруживать и восстанавливать сбои.
В следующем году один из нас действительно внес баг и этот защитный код сделал его безвредным и незаметным для остальных.
Комментариев нет:
Отправить комментарий