Самый сложный случай, с которым я столкнулся, работая программистом |
07.12.2017 11:16 |
Оригинальная публикация: http://secretsofconsulting.blogspot.ru/2017/10/my-most-challenging-experience-as.html Перевод: Анастасия Данилкина Читатели задали мне вопрос: «С каким самым сложным случаем вы столкнулись, работая программистом?» Мы разрабатывали систему слежения для проекта Меркурий, которая должна была отправлять человека в космос и возвращать его живым обратно. Задача «вернуть живым» была сложной, но не единственной. Были и другие трудности: - Система базировалась на всемирной сети довольно ненадежных телетайпных подключений. - У нас было два компьютера IBM 7090 плюс ещё один IBM 709, расположенный на важнейшей станции на Бермудских островах. В те дни компьютеры не были приспособлены для работы онлайн и в режиме реального времени. Например, не было стандартных способов прерывания по таймеру. Пришлось самим это реализовать для машины на Бермудских островах. Мы преодолели все эти трудности и многие другие более мелкие, но самой сложной проблемой было требование «вернуть живым». Когда мы уже достигли должного уровня аппаратной и сетевой надежности, у нас всё еще часто возникали программные ошибки. Чтобы противостоять этой проблеме, мы создали специальную группу тестирования, чего раньше никогда не было. Затем мы установили стандарт, согласно которому любая ошибка, обнаруженная группой тестирования, которую не удалось исправить, будет останавливать любой запуск. Наши тесты показали, что система может случайно потерпеть крах по неизвестным причинам, поэтому она не сможет безопасно приземлить астронавта в заданном месте. Когда произошел сбой при тестировании, два онлайн-принтера одновременно напечатали текст из 120 случайных символов. Текст был идентичен на двух принтерах, то есть сбой не был аппаратной ошибкой на одном из компьютеров IBM 7090. Это могла быть ошибка проектирования системы или ошибка в коде. Нам пришлось исследовать оба варианта, но второе предположение было более вероятным. Мы изо всех сил пытались найти источник ошибки, но после месяца бесплодных поисков менеджер проекта хотел прекратить их и обозначить ошибку как «случайное событие». Мы все знали, что ошибка не была случайностью, но он не хотел, чтобы его обвинили в задержке первого запуска. Мы верили (и до сих пор верим), что «думать» не является роскошью для разработчиков программного обеспечения, поэтому мы ушли в подполье. После продолжительной тяжелой работы Мэрилин выявил ошибку, и мы смогли исправить ее непосредственно перед первым запуском. Мораль: мы можем думать, что ошибки аппаратного и программного обеспечения сложны, но ничто не сравнится с трудностями противостояния человеческим ошибкам, особенно, когда люди, их совершающие, являются руководителями, желающими скрыть ошибки для соблюдения графика. |