Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
kernigan_paik.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
2.91 Mб
Скачать

Дополнительная литература

Несмотря на то что ряд технических деталей, описанных в книге "Ми­стический человекомесяц" Фредерика Брукса (Frederick P. Brooks, Jr. The Mythical Man Month. Addison-Wesley, 1975; Anniversary Edition, 1995) уже устарел, она не перестала быть захватывающе интересной и во многом столь же актуальной сегодня, как и двадцать лет назад.

Практически в каждой книге по программированию есть что-то ин­тересное о проектировании интерфейсов. Практическим пособием, со­зданным на основе большого, потом и кровью добытого опыта, является книга "Разработка крупномасштабных программ на C++" Джона Лакоса (John Lakos. Large-Scale C++ Software Design. Addison-Wesley, 1996). В этой книге обсуждаются проблемы создания и управления дейст­вительно большими программами на C++. В создании программ на С поможет труд Дэвида Хэнсона "Си: интерфейс и реализация" (David Hanson. С Interfaces and Implementations. Addison-Wesley, 1997).

Отличным рассказом о том, как писать программы в команде, являет­ся книга Стива Мак-Коннелла "Быстрая разработка" (Steve McCon-nell's. Rapid Development. Microsoft Press, 1996). В ней, кстати, особое внимание уделяется роли прототипа программы.

О проектировании графических пользовательских интерфейсов на­писано немало книг, авторы которых затрагивают различные аспекты этого процесса. Мы советуем:

• Kevin Mullet, Darrell Sano. Designing Visual Interfaces: Communication Oriented Techniques. Prentice Hall, 1995;

• Ben Shneiderman. Designing the User Interface: Strategies for Effective Human-Computer Interaction. 3rd ed. Addison-Wesley, 1997;

• Alan Cooper. About Face: The Essentials of User Interface Design. IDG, 1995;

• Harold Thimbleby. User Interface Design. Addison-Wesley, 1990.

5. Отладка

bug ("жучок", "баг").

b. Дефект или неполадка в машине, плане и т. п. Происх. — США.

"Пэл Мэл Газет", 1889,11 марта, 1/1. Мистер Эдисон, как я слышал, провел две

бессонных ночи, отыскивая "жучка" в своем фоногра­фе, — это выражение означает

решение сложной проблемы, его ис­пользование подразумевает, что где-то внутри

спряталось какое-то воображаемое насекомое, которое и вызывает все проблемы.

Oxford English Dictionary, 2nd Edition

В предыдущих четырех главах мы продемонстрировали много различного кода и при этом притворялись, что весь этот код работал долж­ным образом с первого раза. Естественно, это было не так: на самом деле было множество "багов". Слово "баг" появилось вовсе не среди программистов, но считается одним из самых распространенных терминов в программировании. Почему программирование столь сложно?

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

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

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

Какова роль языка? Основной движущей силой в эволюции языков программирования была попытка предотвратить ошибки с помощью возможностей языка. Некоторые такие возможности уменьшают шанс появления целых классов ошибок: проверка диапазонов индексов, огра­ничение использования указателей или полный отказ от них, сборка му­сора, строковые типы данных, типизированный ввод-вывод, строгая проверка типов. Однако некоторые возможности языка напрашиваются на ошибку, например оператор goto, глобальные переменные, свободно используемые указатели, автоматические преобразования типов. Програм­мистам следует знать зоны повышенного риска в своих языках и быть особенно осторожными при их использовании. Следует также включить все проверки компилятора и слушаться его предупреждений.

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

Как бы нам ни хотелось обратного, но основное время при программи­ровании тратится на тестирование и отладку. В этой главе мы обсудим, как сократить время, которое вы тратите на отладку, и как использовать это время наиболее продуктивно; к вопросам тестирования мы вернемся в главе 6.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]