В области разработки безопасного и надежного программного обеспечения в последнее время наблюдается новый всплеск активности. Чтобы гарантировать создание устойчивой, безопасной системы, избежать ошибок проектирования, необходимо предпринимать определенные превентивные меры. Эта книга посвящена приемам и методам эффективной диагностики программного обеспечения. В ней приводится ряд типовых ошибок — повторяющихся соотношений между сообщением об ошибке и вызвавшем его дефекте программы. Книга будет интересна всем, кто знаком с программированием на языке Java и хотел бы научиться находить и исправлять ошибки в программах.
СОДЕРЖАНИЕ
Об авторе
О техническом рецензенте
Благодарности
Предисловие
Кому адресована эта книга
Структура книги
Веб-ресурсы
От издательства
Глава 1 Гибкие методы вхаотическом окружении
Тенденции в разработке, реализации иподдержке программного обеспечения
Увеличение спроса на надежные безопасные системы.
Осознание ограничений традиционных методов разработки
программного обеспечения
Доступность открытых программных проектов
Спрос на языки программирования
с платформо-независимой семантикой
Обучение в быстро меняющемся мире
Анатомия паттернов ошибок: зачем это нужно
Что мы узнали
Глава 2 Ошибки, спецификации иреализации
Что такое программная ошибка?
Спецификация как монолитный трактат
C++
Python
ML
Pascal
Преимущества спецификации
Реализация— это не спецификация
Построение экономичной спецификации спомощью “историй”
Тесты для устранения ошибок в спецификации
Блочные тесты не всемогущи
Что мы узнали
Глава 3 Процессы отладки иразработки
Отладка как научный эксперимент
Программное обеспечение специфицируется, собирается
и выпускается пошагово
Структура программы поддерживается максимальнопростой
Программирование осуществляется парами
Пользователь на месте всегда доступен
Исходный текст программы принадлежитвсемразработчикам
Наличие тестов для “всего, что может сломаться”
Включайте отладочные тесты внаборыблочныхтестов44
Будущее: тест-ориентированные языки
Что мы узнали
Глава 4 Процессы отладки итестирования
Тестируемость программы
Храните программу в модели, а не в представлении
Используйте статический контроль типов
дляобнаружения ошибок
Используйте медиаторы для инкапсуляции
функциональности в линиях разломов
Пишите методы с небольшими сигнатурами
иаргументами по умолчанию
Используйте методы доступа, неменяющиесостоянияпамяти
Специфицируйте внепрограммные компоненты
припомощи интерфейсов
Сначала пишите тесты
Интерфейс GlobalModel
Что мы узнали
Глава 5 Научный метод отладки
Программное обеспечение какбессмертнаямашина
Паттерны ошибок позволяют ускоритьдиагностику
Что мы узнали
Глава 6 О паттернах ошибок
Почему важно знание паттернов?
Почему именно эти паттерны ошибок?
Как организованы паттерны
Краткий справочник по отладке программ
Глава 7 Фальшивая черепица
Об этой разновидности ошибки
Симптомы
Причина, лечение и профилактика
Командный паттерн
Другие препятствия для вычленения кода
Родовые типы
Аспект-ориентированное программирование
Что мы узнали
Глава 8 Везде нулевые указатели!
Они неинформативны
Они неуловимы
Глава 9 Болтающийся компонент
Композитный и одноэлементный паттерныпроектирования
Об этом паттерне ошибки
Симптомы
Причина
Лечение и профилактика
Что мы узнали
Глава 10 Нулевой флаг
Об этом паттерне ошибки
Симптомы
Причина
Лечение и профилактика
Устойчивость против недостатка диагностических фактов
Лучшее место для обработки исключений
А как насчет старых программ?
Что мы узнали
Глава 11 Двойной спуск
Об этом паттерне ошибки
Симптомы
Причина
Лечение и профилактика
Что мы узнали
Глава 12 Лживое представление
Об этом паттерне ошибки
Симптомы
Причина
Лечение и профилактика
Автоматизируйте физическую манипуляцию
графическим интерфейсом пользователя
Избегайте этих методов
Лгут не только графические интерфейсыпользователя!
Что мы узнали
Глава 13 Вредительские данные
Об этой разновидности ошибок
Симптомы
Синтаксическая причина
Семантическая причина
Лечение и профилактика
Что мы узнали
Глава 14 Сломанный диспач
Об этой разновидности ошибок
Симптомы
Причина
Лечение и профилактика
Что мы узнали
Глава 15 Тип-самозванец
Об этой разновидности ошибок
Симптомы
Причина
Лечение и профилактика
Гибридные реализации
Что мы узнали
Глава 16 Расщепленный чистильщик
Об этой разновидности ошибок
Симптомы
Причина
Лечение и профилактика
Что мы узнали
Глава 17 Фиктивная реализация
Об этой разновидности ошибок
Симптомы
Причина
Обнаружение фиктивной реализации
Лечение и профилактика
Объединение исправлений
Что мы узнали
Глава 18 Осиротелый поток
Об этой разновидности ошибок
Симптомы
Причина
Лечение и профилактика
Осиротелые потоки играфическиеинтерфейсыпользователя
Блочные тесты и многопоточность
Что мы узнали
Глава 19 Недостаточная инициализация
Об этой разновидности ошибок
Симптомы и причина
Лечение и профилактика
Лучше исправьте саму ошибку
Что мы узнали
Глава 20 Ошибки, связанные сзависимостью отплатформы
О зависимости от платформы
Ошибки, зависимые от производителя
Ошибки, зависимые от версии
Ошибки, зависимые от операционной системы
Что мы узнали
Глава 21 Диагностический контрольный перечень
Общие понятия
Контрольный перечень разновидностей ошибок
Глава 22 Паттерны проектирования дляотладки
Максимизация использования статическогоконтроля
Когда только возможно, используйте для полей
ключевое слово final
Используйте для методов ключевое слово final втехслучаях,
когда они не должны переопределяться
Включайте классы для значений по умолчанию
Используйте контролируемые исключения, чтобыгарантировать,
что все клиенты обрабатываютисключительные ситуации
Определяйте новые типы исключений, чтобыточнееобрабатывать исключительные ситуации
Разбивайте классы, экземпляры которых принимают
одно из нескольких фиксированных состояний,
наразличные субклассы в иерархии Composite195
Минимизируйте количество операторов преобразованиятипов
и проверки instanceof
Используйте одноэлементный паттерн проектирования
для минимизации использования операторов instanceof
Минимизация количества ошибок в программе
Вычленяйте общие фрагменты программы
По мере возможности создавайте чистофункциональные методы
Сигнализируйте об ошибке сразу, кактолькоонаобнаружится
Обнаруживайте ошибки как можно раньше
Помещайте в программу формальные утверждения
Тестируйте программу как можно ближе к состоянию,
вкотором ее будет применять пользователь
Не последнее слово
Глава 23 Ссылки
Веб-сайты
Книги
Приложение Конструкторсписков анализатора строк
Словарь терминов
Алфавитный указатель
ОТРЫВОК
Глава 1. Гибкие методы вхаотическом окружении
Мы обсудим контекст, в котором разрабатывается современное программное обеспечение, и установим некоторые недостатки имеющихся подходов к программированию и отладке.
Тенденции в разработке, реализациии поддержке программного обеспечения
В последние годы появились новые тенденции, оказавшие существенное влияние на способы разработки, реализации и поддержки программного обеспечения:
Увеличение спроса на надежные, безопасные системы.
Осознание ограничений традиционных методов разработки программного обеспечения.
Доступность открытых программных проектов, бесплатно распространяемых вместе с исходными текстами программ.
Спрос на языки программирования с платформо-независимой семантикой.
Увеличение спроса на надежные безопасные системы
Спрос на надежные, безопасные системы вырос чрезвычайно. Каждый пользователь наполняет термины «надежные» и «безопасные» своим смыслом. Под словом «надежный» я подразумеваю системы, которые не ломаются, даже когда пользователь допускает ошибку. «Безопасными» я называю системы, не ломающиеся даже в случае преднамеренной атаки. Например, рассмотрим веб-сервер резервирования авиабилетов. Предположим, пользователь нечаянно пытается зарезервировать билет на невозможную дату (например, 30 февраля). Если система надежна, она не выйдет из строя. Вместо этого она
выведет сообщение об ошибке и позволит пользователю повторить попытку (или, что еще лучше, сам интерфейс пользователя не позволит даже ввести неверную дату). Теперь предположим, что злоумышленник перехватывает информацию кредитной карты пользователя, бронирующего авиабилет, а потом пытается воспользоваться этой информацией. Если система безопасна, она не позволит злоумышленнику осуществить задуманное. Между понятиями «надежность» и «безопасность» нет четкой границы. Достаточно глупыйзлоумышленник будет остановлен даже простой надежной системой.
Достаточно тупой пользователь может случайно совершить последовательность действий, последствия которых можно пресечь только с помощью безопасной системы. Однажды, когда я только начал знакомиться с операционной системой UNIX, я нечаянно вставил в сценарий запуска команду, запускавшую еще одно окно оболочки. Как только я открыл окно оболочки, окна оболочки стали создаваться одно за другим, все больше и больше, пожирая сетевые ресурсы, и, в конце концов, вывели из строя несколько серверов. Это продолжалось до тех пор, пока системный администратор, подумав
ший, что его сеть подверглась атаке, не отключил учетную запись пользователя, ответственного за случившееся (то есть мою). Прошло немало времени, прежде чем он мне разрешил снова войти в систему.
Ввиду роста Интернет-коммерции, а также повсеместного использования сетевого обслуживания и развития встроенных систем (многие из которых предназначались для пользователей с небольшим опытом работы с компьютерами или вообще без опыта) нетрудно понять, почему спрос на надежные и безопасные системы продолжает расти.
Осознание ограничений традиционных методов разработки программного обеспечения
В последнее время все большее распространение получает осознание ограничений традиционных методов разработки программного обеспечения, нацеленных на интенсивное плановое проектирование и строгое разделение ролей между программистами (разработчик структуры системы программного обеспечения, кодировщик, тестер ит.д.). Как правило, по мере того как группа разработчиков знакомится с преимуществами и недостатками различных подходов, меняются и сами программные проекты. Подобные знания можно получить только в процессе непосредственного создания систе
мы. Априорное моделирование не может их заменить. В результате многие куски, написанные по плану, оказываются непригодными, а усилия, затраченные на их создание,— потраченными впустую.
Помимо этого, ролевое разделение программистов часто мешает обмену опытом. Даже если кодеры обнаруживают недоработки проекта, может оказаться, что убедить в этом разработчиков проекта довольно трудно. Кроме того, тестеры могут быть недостаточно знакомы с программой, чтобы достаточно тщательно протестировать ее. В результате такого разделения программистов на роли мы имеем плохо спроектированное и плохо оттестированное программное обеспечение, которое никому не доставит радости. К тому же оно еще и работать не будет.
Даже в идеальных условиях — при разумных и гибких сроках окончания работ по созданию программного обеспечения, при изобилии программистов высочайшей квалификации и при безукоризненно сформулированных (и неизменных) требованиях к программному обеспечению — традиционная схема создания программного обеспечения дает сбои. Но в реальной жизни программы никогда не пишутся в идеальных условиях. Они создаются при наличии самых различных усложняющих факторов, таких как:
Реалии бизнеса. Условия реального бизнеса часто приводят к тому, что на рынок попадают системы, ни должным образом протестированные, ни должным образом задокументированные. Когда выход продукта задерживается на две недели, а выполнено все, кроме стадии тестирования, можно поклясться, что на тестирование будет отведено немного времени.
Недостаток опыта в проектировании. У разработчиков многих новых систем часто нет опыта в создании подобных систем. Как правило, это вызвано не просчетами руководства, а огромным дефицитом опытных разработчиков программного обеспечения.
Отсутствие обратной связи с пользователями. Пользователи программного обеспечения, как правило, не могут четко определить свои требования, часто потому, что они сами еще не знают толком, что им нужно. Вбольшинстве случаев это не потому, что они «плохие пользователи». Как правило, причина в том, что многие программные проекты представляют собой первые системы подобного рода, и у пользователей просто нет опыта, который мог бы помочь им определить, какие функции программы были бы для них наиболее полезны.
Реальный мир разработки программного обеспечения представляет собой хаос. В результате, традиционные жесткие процессы создания программ начинают уступать место более гибким адаптивным методам, таким как экстремальное программирование. Гибкие методы должны помочь удовлетворить спрос на повышение надежности. В частности, перемещение акцента на тестирование отдельных модулей может существенно увеличить надежность программной системы.
Доступность открытых программных проектов
Другая тенденция, влияющая на надежность программного обеспечения, состоит в увеличении массы свободно распространяемого открытого программного обеспечения. Концепция открытых источников (open-source) и программы, написанные сообществом open-source, бросают вызов коммерческим моделям традиционных компаний, занимающихся разработкой программного обеспечения, создавая конкурентоспособный продукт с нулевой рыночной стоимостью и зачастую (благодаря открытости исходных текстов программ) лучшего качества. Наиболее яркий пример представляет собой операционная
система Linux, предоставляющая альтернативу существующим коммерческим операционным системам и превосходящая многих конкурентов в плане устойчивости и надежности.
Спрос на языки программирования сплатформо-независимой семантикой
Последние годы наблюдается волна спроса на языки программирования с платформо-независимой семантикой, а также на виртуальные машины, исполняющие программы, написанные на этих языках. Наиболее известным подобным языком является Java. Двоичные файлы, созданные Java-программистами, обладают беспрецедентным уровнем переносимости, способной в несколько раз снизить затраты на разработку программного обеспечения, так как разработчикам не нужно заниматься поддержкой раздельных исходных файлов или даже компиляцией отдельного двоичного кода для каждой платфо
рмы.
Обучение в быстро меняющемся мире
Появление методов гибкого программирования и проектов с открытым исходным текстом может помочь удовлетворению растущего спроса на надежное программное обеспечение. Но качество и надежность создаваемого программного обеспечения неизбежно зависит от квалификации и опыта занятых в проекте программистов, а спрос на опытных программистов значительно превышает предложение.
СОВЕТ
Обучение разработчиков программного обеспечения распознаванию паттернов (шаблонов) ошибок представляет собой способ повышения квалификации и эффективности многих программистов.
Чтобы справиться с дефицитом квалифицированных кадров, нам нужен способ быстрой передачи практических навыков в разработке устойчивых систем, внормальных условиях приобретаемых за многие годы опыта.
Некоторые из этих экспериментальных знаний состоят из различных паттернов разработки, доказавших свою работоспособность в разных контекстах. Эти паттерны теперь преподаются на курсах информатики, наравне с базовыми алгоритмами и структурами данных. Но довольно существенная часть рабочих знаний, приобретенных опытными разработчиками, отсутствует в подобных инженерных паттернах.
Часть этих рабочих знаний заключается в способности эффективно находить и устранять ошибки, присутствующие в программах,— другими словами, в эффективной отладке.
Эффективная отладка программ представляет собой далеко не тривиальное искусство. В самом деле, отслеживание и устранение программных дефектов (ошибок) составляет существенную часть времени, которое разработчик тратит на реализацию проекта. Если эту задачу можно выполнять более эффективно, то получаемое в результате программное обеспечение будет более надежным, а разработка его займет меньше времени.
Занимаясь обучением новых разработчиков, как в промышленности, так и в учебных заведениях, я отметил некоторые общие тенденции в том, как они учатся отлаживать программное обеспечение. Начинающие программисты зачастую мешают сами себе, пытаясь определить потенциальный источник ошибки. Как правило, они:
1. Винят в ошибке, скорее, не собственную программу, а операционную систему.
2. Убеждают себя в том, что ошибка, свидетелями которой они стали, в принципе, невозможна и что это не что иное, как галлюцинация.
3. Начинают метаться, случайным образом изменяя свою программу, пока не исчезнут симптомы ошибки. В результате ошибка программиста перерастает в дефект программы.
С появлением опыта разработчики в меньшей степени склоняются к подобному поведению. Если начинающих программистов познакомить с подобными формами неадекватного поведения, они могут научиться избегать их прежде, чем приступят к серьезному программированию. Но чтобы стать хорошим отладчиком (что необходимо, чтобы стать гибким, эффективным разработчиком), недостаточно просто избегать неверных схем поведения.
Анатомия паттернов ошибок: зачем это нужно
Так же как хорошее владение программистскими навыками включает в себя знание множества конструктивных паттернов (которые могут комбинироваться и применяться в разных обстоятельствах), хорошая техника отладки предполагает знание общих причин программных ошибок и способов их устранения. В моей колонке для сайта developerWorks корпорации IBM я впервые назвал эти общие причины паттернами (шаблонами) ошибок (bug patterns).
Паттерны ошибок (типовые ошибки) представляют собой устойчивые зависимости между сообщением об ошибке и вызвавшим его дефектом в программе. Знание этих паттернов и их симптомов помогает программисту быстро распознавать определенные дефекты, а также не допускать их появления, прежде всего.
Паттерны ошибок связаны с антипаттернами, представляющими собой паттерны проектирования программного обеспечения, не выдержавшие испытания временем. Подобные отрицательные примеры образцов проектирования представляют собой весомое дополнение к традиционным положительным паттернам разработки. Но до тех пор пока антипаттерны используются в качестве рабочих паттернов, паттерны ошибок являются паттернами неверного поведения программы, вызванного ошибками программирования. Нас интересует не весь процесс проектирования в целом, а процесс написани
я и отладки программ.
Сложность состоит в том, что для того, чтобы научиться распознавать эти паттерны на личном опыте, программисту могут потребоваться годы. Если мы идентифицируем эти паттерны и обучим им программистов, мы сможем повысить квалификацию и эффективность многих программистов.
Эта концепция присуща не только программированию. Медики уже давно полагаются на сходные устойчивые зависимости при постановке диагноза болезни. Они обучаются этому, работая в тесном контакте с более опытными врачами во время интернатуры. Сам курс обучения медиков сфокусирован на обучение диагностике болезней.
Научившись распознавать паттерны ошибок, начинающий программист может быстрее устанавливать причину программной ошибки и устранять эту ошибку. Более того, явно идентифицируя эти корреляции и обсуждая их, разработчики выигрывают от обмена опытом отладки программ, тем самым быстрее становясь профессионалами в своей области.
Что мы узнали
В этой главе мы:
Обсудили сегодняшний метод создания программного обеспечения и причины использования этого метода.
Исследовали тенденции в разработке программного обеспечения.
Узнали о традиционных и инновационных методах преподавания программирования.
Обнаружили причину важности паттернов ошибок для программистов и разработчиков, создающих программы на современных языках программирования.
В главе2 мы определим понятие программной ошибки, объясним, почему спецификация так важна для контроля программных ошибок, поймем различие между спецификацией и реализацией, рассмотрим использование «историй» и тестирование модулей при разработке спецификаций, а также познакомимся с эффективными средствами разработки спецификаций.
Типичные ошибки проектирования. Библиотека программиста. / Э. Аллен - СПб: Питер, 2003. - 224 с.
|