Эндрю Хант, Дэвид Томас Программист-прагматик Путь от подмастерья к мастеру Высказывания программистов-практиков о книге "Программист-прагматик" Предисловие От авторов Кому адресована эта книга? Как происходит становление программиста-прагматика? Прагматики-одиночки и большие команды Непрерывность процесса Как составлена эта книга Исходные тексты программ и другие ресурсы Ваши отклики Благодарности Глава 1 Прагматическая философия 1 Мой исходный текст съел кот Мурзик Принятие ответственности 2 Энтропия в программах 3 Суп из камней и сварившиеся лягушки 4 Приемлемые программы Находите компромисс с пользователями Знайте меру 5 Портфель знаний Ваш портфель знаний Построение вашего портфеля Цели Возможности обучения Критическое осмысление 6 Общайтесь! Глава 2 Прагматический подход 7 Пороки дублирования Как возникает дублирование? Навязанное дублирование Неумышленное дублирование Нетерпеливое дублирование Коллективное дублирование 8 Ортогональность Что такое ортогональность? Преимущества ортогональности Проектные группы Проектирование Инструментарии и библиотеки Написание текста программы Тестирование Документация Жизнь в условиях ортогональности 9 Обратимость Гибкая архитектура 10 Стрельба трассирующими Программа, которую видно в темноте При стрельбе трассирующими вы не всегда попадаете в цель Программа трассировки и создание прототипов 11 Прототипы и памятные записки Для чего создаются прототипы Как использовать прототипы Создание прототипов архитектуры Как не надо использовать прототипы 12 Языки, отражающие специфику предметной области 13 Оценка Насколько точной является "приемлемая точность"? Из чего исходят оценки? Что сказать, если вас просят оценить что-либо Глава 3 Походный набор инструментов 14 Преимущества простого текста Что такое простой текст? Недостатки Преимущества простого текста Подводим итог 15 Игры с оболочками Утилиты оболочек и системы Windows 16 Мощь редактирования Один-единственный редактор Средства редактирования Производительность Куда же направиться? Какой же редактор выбрать? 17 Управление исходным текстом программ Команда, в которой я работаю, не использует систему управления исходным текстом Программы управления исходным текстом 18 Отладка Психология процесса отладки Умонастроение отладки С чего начать? Стратегии отладки Элемент удивления Контрольные вопросы при отладке 19 Обработка текста 20 Генераторы текстов программ Пассивные генераторы Активные генераторы текста Генераторы текста не должны быть слишком сложными Генераторы текста не всегда генерируют тексты программ Глава 4 Прагматическая паранойя 21 Проектирование по контракту Реализация принципа ППК ППК и аварийное завершение работы программы Другие случаи применения инвариантов Динамические контракты и агенты 22 Мертвые программы не лгут Аварийное завершение не означает "отправить в корзину для мусора" 23 Программирование утверждений Не отключайте утверждения 24 Случаи, в которых используются исключения Что является исключительным? Обработчики ошибок как альтернатива исключению 25 Балансировка ресурсов Объекты и исключения Балансировка и исключения Случаи, при которых балансировка ресурсов невозможна Проверка баланса Глава 5 Гибкость против хрупкости 26 Несвязанность и закон Деметера Сведение связанности к минимуму Закон Деметера для функций А не все ли равно? 27 Метапрограммирование Динамическая конфигурация Приложения, управляемые метаданными 28 Временное связывание Последовательность операций Архитектура Проектирование с использованием принципа параллелизма Развертывание 29 Всего лишь визуальное представление Протокол "Публикация и подписка" Принцип "модель-визуальное представление-контроллер» Отходя от графических интерфейсов Все такой же связанный (после стольких лет) 30 Доски объявлений Реализация концепции доски объявлений Пример приложения Глава 6 Пока вы пишете программу 31 Программирование в расчете на стечение обстоятельств Как программировать в расчете на стечение обстоятельств Преднамеренное программирование 32 Скорость алгоритма Что подразумевается под оценкой алгоритмов? Система обозначений О() Оценка с точки зрения здравого смысла Скорость алгоритма на практике 33 Реорганизация Когда осуществлять реорганизацию? Как производится реорганизация? 34 Программа, которую легко тестировать Модульное тестирование Тестирование в рамках контракта Создание модульных тестов Применение тестовых стендов Построение тестового окна Культура тестирования 35 Злые волшебники Глава 7 Перед тем, как начать проект 36 Карьер для добычи требований В поисках требований Документация требований Чрезмерная спецификация Видеть перспективу Еще одна мелочь… Поддержка глоссария Прошу слова… 37 Разгадка невероятных головоломок Степени свободы Есть более простой способ! 38 Чувство готовности Здравое суждение или промедление? 39 Западня со стороны требований 40 Круги и стрелки Какова отдача от методов? Нужно ли использовать формальные методы? Глава 8 Прагматические проекты 41 Команды прагматиков Никаких разбитых окон Сварившиеся лягушки Общайтесь Не повторяйте самого себя Ортогональность Автоматизация Чувствуйте момент, когда нужно остановиться 42 Вездесущая автоматизация Все в автоматическом режиме Компилирование проекта Автоматизация процесса сборки Автоматические административные процедуры Дети сапожника 43 Безжалостное тестирование Что тестировать Как проводить тестирование Когда тестировать Кольцо сжимается 44 Все эти сочинения Комментарии в программе Исполняемые документы Технические писатели Печатать документ или ткать его на холсте? Языки разметки 45 Большие надежды Передача надежд Небольшой довесок 46 Гордость и предубеждение Приложение А Информационные ресурсы Профессиональные общества Собираем библиотеку Интернет-ресурсы Библиография Приложение В Ответы к упражнениям
4 Приемлемые программы Для лучшего добро сгубить легко. У. Шекспир, Король Лир, действие 1, сцена 4
Существует старый анекдот об американской фирме, которая заказала 100000 интегральных схем на предприятии в Японии. В условиях контракта указывался уровень дефектности: один чип на 10000. Несколько недель спустя заказ прибыл в Америку: одна большая коробка, содержащая тысячи интегральных схем, и одна маленькая, в которой находилось десять схем. К маленькой коробке был приклеен ярлычок с надписью "Дефектные схемы".
Если бы у нас был такой контроль качества! Но реальный мир не позволяет производить многое из того, что является действительно совершенным – особенно программы без ошибок. Время, технология и темперамент – все находится в сговоре против нас.
Однако это не должно вас обескураживать. По словам Эда Иордона, автора статьи в журнале IEEE Software [You95], вы можете обучиться созданию приемлемых программ – приемлемых для ваших пользователей, служб сопровождения и с точки зрения вашего же собственного спокойствия. Вы обнаружите, что производительность вашего труда повысилась, а ваши пользователи стали чуть-чуть счастливее. Кроме того, ваши программы станут лучше за счет сокращения инкубационного периода.
Перед тем как пойти дальше, мы должны определиться в том, что собираемся сказать. Фраза «приемлемый» не подразумевает неаккуратную или неудачно написанную программу. Все удачные системы должны отвечать требованиям их пользователей. Мы просто призываем к тому, чтобы пользователям была дана возможность участвовать в процессе принятия решения, если созданное вами действительно приемлемо.