загрузка...

Прагматические проекты


Поскольку вы уже работаете над проектом, нам придется отойти от вопросов, связанных с личностной философией и написанием программ, чтобы поговорить о более серьезных вещах в масштабах проекта. Мы не собираемся углубляться в специфику руководства проектами, а рассмотрим несколько критических областей, которые способны создать или разрушить любой проект.
Как только число сотрудников, работающих на проектом, превышает единицу, вам приходится устанавливать некие основные правила и делегировать части проекта соответствующим образом. В разделе "Команды прагматиков" мы покажем как это можно делать, соблюдая принципы прагматической философии.
Единственным и самый важным фактором, придающим последовательность и надежность процессам на уровне проекта, является автоматизация процедур. В разделе "Вездесущая автоматизация" мы объясним, почему это именно так, и приведем некоторые примеры из реальной жизни.
Выше говорилось о тестировании в ходе написания программ. В разделе "Безжалостное тестирование" мы переходим на следующую ступень философии и инструментов, применяемых в масштабе проекта, в особенности, если нет отдела контроля качества, находящегося у вас на побегушках.
Единственная вещь, которую разработчики не любят больше, чем тестирование, – это документация. Независимо от того, есть ли у вас технические писатели, помогающие вам, или вы пишете документацию сами, мы покажем в разделе "Все эти сочинения", как сделать эту работу менее болезненной и более продуктивной.
Успех проекта находится перед глазами наблюдателя – спонсора проекта. Восприятие успеха – это самое главное, и в разделе "Большие надежды" мы покажем вам некоторые хитрости, которые порадуют сердце любого спонсора проекта.
Последней подсказкой в этой книге является прямое следствие всех остальных. В разделе "Гордость и предубеждение" мы поощряем вас подписывать свою работу и гордиться тем, что вы делаете.
41
Команды прагматиков
В группе L Стоффел руководит шестью первоклассными программистами – это руководящая работа, которую можно приравнять к управлению бродячими котами.
Журнал "Washington Post" от 9 июня 1985 г.
Пока в книге мы рассматривали прагматические методики, которые помогают отдельной личности стать лучшим программистом. Могут ли эти методы работать в приложении к командам?
Отвечаем на это громким "да!" В личностном прагматизме есть свои преимущества, но эти преимущества преумножаются, если личность работает в команде прагматиков,
В этом разделе мы кратко рассмотрим, как прагматические методики могут применяться к целым командам. Эти замечания – лишь начало. Как только собирается команда разработчиков-прагматиков, работающих в среде, предоставляющей определенные возможности, они быстро развивают и совершенствуют свою собственную командную динамику, которая работает на них.
Рассмотрим некоторые из предыдущих разделов с точки зрения команд.
Никаких разбитых окон
Качество является прерогативой команды. Для самого прилежного разработчика, попавшего в команду, которая безразлична к работе, окажется сложным сохранять энтузиазм, необходимый для устранения проблем, требующих кропотливости. Проблемы будут только усугубляться, если команда активно уговаривает разработчика не тратить время на устранение этих проблем.
Команда в целом не должна допускать наличия разбитых окон – этих маленьких недостатков, которые никем не устраняются. Команда обязана взять на себя ответственность за качество продукта, поддерживая разработчиков, исповедующих философию "не живите с разбитыми окнами", описанную в разделе "Энтропия в программах", и поощряя ее изучение теми, кто пока не открыл ее для себя.
В некоторых методологиях коллективной работы предусмотрен менеджер по качеству – сотрудник, которому команда делегирует ответственность за качество продукта, отправляемого заказчику. Это просто смешно: качества можно достигнуть только в результате индивидуальной лепты, вносимой каждым членом команды.
Сварившиеся лягушки
Помните несчастную лягушку, сидевшую в кастрюле с водой, из разделе "Суп из камней и сварившиеся лягушки"? Она не заметила постепенного изменения в окружающей среде и в конце концов сварилась. То же самое может произойти с отдельными личностями, которые теряют бдительность. Трудно уследить за общим состоянием среды в разгаре работы над проектом.
Команда может свариться значительно быстрее, чем отдельная личность. Люди предполагают, что кто-то другой занимается неким вопросом или что руководитель команды наверняка одобрил изменение, которое просил внести пользователь. Даже самые целеустремленные группы могут не обратить внимания на существенные изменения, происходящие с их проектами.
Боритесь с этим. Убедитесь, что каждый активно отслеживает изменения в состоянии среды. Может быть, стоит нанять "ответственного за состояние воды". Этот сотрудник должен постоянно следить за увеличением сферы покрытия, уменьшением масштабов времени, дополнительными средствами, новыми средами – всем тем, чего не было в первоначальном соглашении. Сохраняйте метрики по новым требованиям (см. раздел "Еще одна мелочь…"). Команде не нужно наотрез отказываться от изменений – просто надо знать, что они происходят. В противном случае лягушкой в горячей воде окажетесь именно вы.
Общайтесь
Очевидно, что разработчики в группе должны разговаривать друг с другом. В разделе "Общайтесь!" даны некоторые советы для облегчения подобного общения. Однако не забывайте, что сама по себе команда находится в рамках определенной организации. Команде как субъекту приходится четко взаимодействовать с остальным миром.
Для посторонних худшими проектными командами являются те, которые кажутся угрюмыми и чересчур сдержанными. Они проводят бессистемные встречи, на которых никто не хочет выступать. Их документы – сплошная путаница, среди них нет хотя бы двух похожих, и каждый разработчик пользуется своей терминологией.
Лучшие проектные команды обладают ярко выраженной индивидуальностью. Люди ожидают встреч с ними, поскольку знают, что увидят хорошо подготовленную презентацию, от которой всем станет лучше. Производимая ими документация отличается четкостью, точностью и последовательностью. В такой команде нет разноголосицы
[44]. У нее даже может быть чувство юмора.
В маркетинге существует простой трюк, помогающий командам взаимодействовать как одно целое: создание брэнда. Когда вы начинаете некий проект, придумайте имя для проектной команды, в идеале – нечто из ряда вон выходящее. (В прошлом мы называли проекты в честь попугаев-киллеров, охотящихся на овец, оптических обманов и мифических городов.) Потратьте полчаса на придумывание самого идиотского логотипа и используйте его в ваших служебных записках и отчетах. В разговорах с людьми свободно упоминайте название вашей команды. Это звучит глупо, но все это придаст вашей команде некую самобытность, а миру – что-то запоминающееся, с чем можно ассоциировать вашу работу.
Не повторяйте самого себя
"В разделе "Пороки дублирования" говорилось о трудностях, связанных с устранением дублирования работы, выполняемой разными членами команды. Это дублирование ведет к тому, что усилия тратятся впустую и все выливается в кошмарные ситуации при сопровождении. Ясно, что здесь нужно четкое взаимодействие, но в ряде случаев необходимо приложить и дополнительные усилия.
Некоторые команды включают в свой состав библиотекаря проекта, который несет ответственность за координацию документации и хранение текстов исходных программ. Другие члены команды могут использовать этого сотрудника в качестве "истины в последней инстанции", когда они занимаются поиском чего-либо. Хороший библиотекарь также способен предсказать возникновение дублирования, прочитав материал, с которым они работают.
Если проект слишком велик для одного-единственного библиотекаря (или если никто не хочет брать на себя его функции), назначьте нескольких человек "фокусными точками" различных функциональных аспектов работы. Если кто-то хочет обговорить тему обработки даты, он знает, что по этому вопросу нужно обращаться к Мэри. Если же речь идет о базе данных, то следует обращаться к Фреду.
И не забудьте о значении программного обеспечения для коллективной работы и локальных телеконференциях в сети Usenet для обмена информацией и создания архивов вопросов и ответов.
Ортогональность
Традиционная организация команды основана на устаревшем методе создания программного обеспечения, известного под названием "метода водопада". Отдельным членам команды назначаются роли, основанные на их должностных обязанностях. В команде имеются бизнес-аналитики, проектировщики, программисты, тестировщики, технические писатели и т. п.
[45]В этом случае существует явная иерархия – чем ближе вы допущены к конечному пользователю, тем выше ваше положение.
В стремлении довести все до крайности, некоторые объединения разработчиков диктуют строгое разграничение ответственности: тем, кто составляет программы, не разрешено общаться с теми, кто их тестирует, а им, в свою очередь, не разрешено общаться с главным архитектором и т. д. Некоторые организации еще более усложняют задачу, заставляя различные подгруппы отчитываться через отдельные цепочки управления.
Ошибочным является мнение о том, что различные действия при работе над неким проектом – анализ, проектирование, написание программы и тестирование – могут происходить изолированно друг от друга. Такого не бывает. Это различные точки зрения на одну и ту же проблему, и их искусственное разделение может вызвать целый ворох проблем. Программисты, отделенные двумя или тремя уровнями от реальных пользователей написанной ими программы, скорее всего не знают о контексте, в котором используется результат их труда. Они будут не в состоянии принять обоснованные решения.
Подсказка 60: Организуйте команду на основе функциональности, а не должностных обязанностей
Мы одобряем разбиение команды исходя из функциональных возможностей. Разделите ваших сотрудников на небольшие группы, каждая из которых будет нести ответственность за конкретный функциональный аспект конечной версии системы. Каждая группа обладает обязательствами перед другими группами, участвующими в проекте, что определено их согласованными обязательствами. Строгий набор обязательств изменяется с каждым новым проектом, как и распределение людей по группам.
В данном случае функциональная возможность необязательно означает сценарий использования конечным потребителем программного продукта. Сюда относится и уровень доступа к базе данных, и справочная подсистема. Мы ищем сплоченные, в большой степени самостоятельные коллективы людей по тем же критериям, которые мы обязаны использовать при декомпозиции программы. Существуют признаки, предупреждающие о том, что организация команды неверна; классическим примером этого являются две подгруппы, работающие над одним и тем же программным модулем или классом.
В чем же состоит польза от подобного функционального стиля организации? Организуя ресурсы, применяя те же методики, что и при организации программы, используя контракты (см. "Проектирование по контракту", несвязанность (см. "Несвязанность и закон Деметера") и ортогональность (раздел "Ортогональность"), мы способствуем изоляции команды в целом от влияния изменений. Если пользователь внезапно решится на замену поставщиков баз данных, то это скажется только на команде, занимающейся базами данных. Если отдел маркетинга внезапно примет решение об использовании готового средства календарного планирования, то это будет ударом только для группы разработчиков этого средства. При надлежащем исполнении подобный подход к группам может существенно снизить число пересечений в работе отдельных личностей, снизить затраты времени, повысить качество и уменьшить число дефектов. Этот подход помогает сделать команду разработчиков более сплоченной. Каждая группа знает, что только они несут ответственность за конкретную функцию.
Однако этот подход работает только при наличии ответственных разработчиков и сильного руководства. Создать пул автономных групп и позволить им разбалтываться в отсутствие руководства – это кратчайший путь к катастрофе. Проекту необходимы как минимум два руководителя – один технический, другой административный. Технический руководитель определяет философию и стиль разработки, распределяет обязанности между группами и является арбитром в неизбежных «дискуссиях» между членами команды. Он также осуществляет контроль за ситуацией в целом, стараясь найти ненужную общность задач между группами, которая снижает ортогональность общих прилагаемых усилий. Административный руководитель, или руководитель проекта, намечает ресурсы, необходимые группам, контролирует ход выполнения работ, отчитывается о проделанной работе и помогает в определении приоритетов с точки зрения потребностей бизнеса. Административный руководитель может действовать и в роли полномочного представителя команды при общении с внешним миром.
Команды, выполняющие большие проекты, нуждаются в дополнительных ресурсах: библиотекаре, который упорядочивает и хранит тексты программ и документацию, компоновщике инструментальных средств, обеспечивающем работоспособность обычных инструментальных средств и операционных сред, оперативную поддержку и т. д.
Подобная организация команды напоминает старую концепцию "бригады главного программиста", впервые описанную в 1972 г. [Ваk72].
Автоматизация
Автоматизация является отличным способом обеспечить полноту и точность всего, что делает команда. Зачем компоновать текст программы вручную, если ваш редактор может делать это автоматически, пока вы набираете текст? Зачем заполнять формуляры тестирования, если процедура сборки может осуществлять тестирование автоматически?
Автоматизация является существенным компонентом любой проектной команды – настолько важным для нас, что мы посвятили ей следующий раздел, целиком. Чтобы убедиться в том, что процессы автоматизированы, назначьте одного или несколько членов группы компоновщиками инструментальных средств для конструирования и развертывания средств, автоматизирующих всю тяжелую работу. Они будут создавать файлы сборки, сценарии оболочек, шаблоны редактирования, вспомогательные программы и т. п.
Чувствуйте момент, когда нужно остановиться
Помните, что коллективы состоят из отдельных личностей. Дайте возможность каждому сотруднику проявить себя во всем блеске. Создайте структуру, достаточную для их поддержки и выполнения проекта в соответствии с требованиями. Но затем, подобно живописцу из раздела "Приемлемые программы", не поддавайтесь искушению добавить больше краски на холст.
Другие разделы, относящиеся к данной теме:
• Энтропия в программах
• Суп из камней и сварившиеся лягушки
• Приемлемые программы
• Общайтесь!
• Пороки дублирования
• Ортогональность
• Проектирование по контракту
• Несвязанность и закон Деметера
• Вездесущая автоматизация
Вопросы для обсуждения
• Оглянитесь вокруг в поисках успешных команд, работающих вне сферы разработки программного обеспечения. Каков фактор их успеха? Применяют ли они какой-либо из процессов, описанных в данном разделе?
• В следующий раз, когда вы начнете работать над проектом, постарайтесь убедить коллег в том, что проекту необходим брэнд. Дайте вашей организации время, чтобы привыкнуть к этой мысли, и затем проведите быстрый аудит, чтобы увидеть, изменило ли наличие брэнда что-нибудь как внутри команды, так и в общении с внешним миром.
• Командная алгебра: В школе мы решали задачи, наподобие этой: "Если четырем рабочим требуется 6 ч на то, чтобы выкопать канаву, то сколько времени потребуется на это восьми рабочим?" Какие факторы из реальной жизни повлияют на ответ задачи: "Если четырем программистам требуется 6 месяцев на разработку приложения, то сколько времени потребуется на это восьми программистам?" Назовите число сценариев, в которых время на разработку действительно сокращается.
42
Вездесущая автоматизация
Прогресс цивилизации состоит в расширении сферы действий, которые мы выполняем не думая.
Альфред Норт Уайтхед
На заре автомобильной эры инструкция по запуску автомобиля «Форд-Т» составляла две с лишним страницы. В современных автомобилях достаточно лишь повернуть ключ – процедура запуска является автоматической и надежной. Водитель, действующий по инструкции, может «залить» свечи зажигания, а автоматический стартер подобного не допустит.
Хотя информатика все еще напоминает автопромышленность времен выпуска модели «Форд-Т», мы не можем позволить себе в обычной работе раз за разом выполнять набор инструкций, расположенный на двух страницах. Неважно, что это – процедура сборки и выпуска готовой версии, рассмотрение текста программы или же любая повторяющаяся задача, возникающая в ходе проекта, – все это должно выполняться автоматически. Возможно, нам придется изготовить стартер и топливный инжектор "с нуля", но как только это будет сделано, с этого момента будет достаточно лишь повернуть ключ зажигания.
Мы хотим также гарантировать полноту и повторяемость при работе над проектом. Выполняемые вручную процедуры не гарантируют полноту; повторяемость также не гарантируется, особенно если аспекты конкретной процедуры открыты для интерпретации другими людьми.
Все в автоматическом режиме
Однажды мы посетили фирму-заказчик, где все разработчики использовали одну и ту же интегрированную среду разработки. Их системный администратор снабжал каждого разработчика набором инструкций по установке добавочных средств для этой среды. Эти инструкции занимали много страниц – 'щелкни мышью здесь, прокрути туда, отбуксируй это, щелкни здесь мышью два раза, повтори".
Не удивительно, что компьютер у каждого разработчика загружался по-своему. Когда разные разработчики прогоняли одну и ту же программу, в поведении приложения проявлялись малозаметные отличия. Дефекты возникали на одной машине, а на других все было нормально. При прослеживании разницы в версиях любого из компонентов обычно выявлялись неожиданные вещи.
Подсказка 61: Не используйте процедуры, выполняемые вручную
В отличие от компьютеров, люди не обладают повторяемостью в своих действиях. Мы этого от них и не ждем. Сценарий оболочки или пакетный файл выполнят те же самые инструкции, в том же порядке, раз за разом. Он может отслеживаться системой управления исходным текстом, так что возможно изучать изменения в процедуре и по прошествии времени ("но ведь она всегда работала… ").
Другим излюбленным средством автоматизации является cron (или «at» в системе Windows NT). Он позволяет планировать периодический прогон задач без участия пользователя – обычно этот прогон делается ночью. Например, представленный ниже файл crontab указывает, что команда nightly, используемая в проекте, должна запускаться каждый день в 00:05, что процедура резервного копирования backup должна запускаться в 03:15 по будням и что команда expense_eports должна выполняться в полночь первого числа каждого месяца.
С помощью cron можно планировать процедуры резервного копирования, сопровождение web-сайтов и любых других операций, которые нужно проводить без участия пользователя, т. е. автоматически.
Компилирование проекта
Компилирование проекта – это работа, которая должна быть надежной и повторяемой. Обычно проекты компилируются с помощью файлов сборки даже в интегрированной среде разработчика. В использовании файлов сборки есть ряд преимуществ. Это подготовленная по сценарию автоматическая процедура. Можно добавлять специальные программные процедуры для генерации текста программы и запускать регрессионные тесты в автоматическом режиме. Интегрированные среды имеют свои преимущества, но, пользуясь только ими, бывает трудно добиться нужного уровня автоматизации. Мы хотим осуществлять проверку, сборку, тестирование и передачу программы заказчику с помощью одной-единственной команды.
Генерирование текста программы
В разделе "Пороки дублирования" мы призываем к генерированию текстов программ для получения знания из обычных источников. Для облегчения этого процесса мы можем задействовать механизм анализа зависимости в программе make. Добавление правил в файл сборки для автоматической генерации файла из некоего другого источника не представляет особой сложности. Предположим, что есть некий файл XML, из которого необходимо сгенерировать файл Java, а результат скомпилировать.
.SUFFIXES: .Java .class .xml
.xml.java:
perl convert.pl $<>$@
.java.class:
$(JAVAC) $(JAVAC_FLAGS) $<
Наберем make test.class, и программа make автоматически найдет файл с именем test.XML, сформирует файл. Java, выполнив сценарий Perl, а затем скомпилирует этот файл, создав test.class.
Можно использовать подобные правила также для автоматической генерации исходного текста, файлов заголовка или документации из иной формы (см. "Генераторы исходных текстов").
Регрессионные тесты
Можно воспользоваться файлом сборки для прогона либо регрессионных тестов, либо отдельного модуля, либо подсистемы в целом. Вы легко можете протестировать весь проект целиком при помощи одной-единственной команды на вершине исходного дерева или же протестировать отдельный модуль, воспользовавшись той же командой в единственном каталоге. Более подробно регрессионное тестирование рассматривается в разделе "Безжалостное тестирование".
Рекурсивная сборка
Многие проекты устанавливают специальные рекурсивные иерархические файлы для сборки проектов и тестирования. Но не забывайте о некоторых потенциальных проблемах.
Программа make вычисляет зависимости между различными объектами, которые она должна собрать. Но она может проанализировать только зависимости, существующие в пределах одного-единственного обращения к программе make. В частности, рекурсивная программа make не обладает информацией о зависимостях, которые имеются у других обращений к программе make. Если вы будете осторожны и точны в своих действиях, то вы получите надлежащие результаты, но при этом можно проделать много лишней работы или проглядеть зависимость и не перекомпилировать ее, когда это необходимо.
Кроме того, зависимости сборки могут отличаться от зависимостей тестирования и вам могут понадобиться дополнительные иерархии.
Автоматизация процесса сборки
Сборка представляет собой процедуру, которая использует пустой каталог (и известную среду компиляции) и формирует проект с нуля, создавая то, что вы хотели бы видеть в качестве конечного результата, отправляемого заказчику, например, эталонный лазерный диск или самораспаковывающийся архив. Обычно сборка проекта включает следующие этапы:
1. Исходный текст программы извлекается из архива.
2. Проект формируется с нуля, обычно из файла сборки верхнего уровня. Каждая сборка помечается определенным номером выпуска/версии или отметкой даты.
3. Создается копия для распространения. Эта процедура может повлечь за собой фиксирование права собственности на файл и разрешения на его использование, создание всех примеров, документации, файлов README и всего того, что будет отправлено вместе с готовым продуктом именно в том формате, который требуется при передаче заказчику
[46].
4. Проведите указанные тесты (процедура make test).
Для большинства проектов этот этап сборки осуществляется автоматически каждую ночь. «Ночная» сборка обычно выполняет больше полных тестов, чем отдельный сотрудник при сборке определенной части проекта. Важным моментом является то, что при полной сборке должны запускаться все тесты, имеющиеся в наличии. Вы хотите убедиться в том, что программа не прошла регрессионный тест вследствие изменений, которые были сделаны в программе сегодня. Идентифицируя проблему ближе к источнику, вы с большей вероятностью сможете отыскать и устранить существующую проблему.
Если вы не проводите регулярное тестирование, то можете обнаружить, что приложение не работает вследствие изменения, внесенного три месяца назад. Удачи вам – в поиске этого изменения.
Окончательные сборки
Окончательные сборки, которые вы намереваетесь отправить заказчику в виде готовых продуктов, могут предъявлять требования, отличающиеся от регулярной «ночной» сборки. Окончательная сборка может требовать, чтобы библиотека исходных файлов была заблокирована или снабжена номером выпуска, чтобы флаги оптимизации и отладки были установлены по-другому и т. д. Мы предпочитаем использовать отдельный рабочий файл make (типа make final), который устанавливает все эти параметры сразу.
Помните, что если компиляция продукта отличается от компиляции предыдущей версии, то вы обязаны провести тестирование согласно этой версии заново.
Автоматические административные процедуры
Наверное, было бы недурно, если бы программисты могли реально посвящать все свое время программированию. К сожалению, это бывает очень редко. Нужно отвечать на сообщения электронной почты, выполнять бумажную работу, помещать документы в Интернет и т. д. Вы можете решиться на создание сценария оболочки, который будет делать всю грязную работу, но не забывайте запускать этот сценарий, когда необходимо.
Поскольку память – это вторая по счету вещь, которую мы теряем с возрастом
[47], мы не хотим полагаться на нее слишком сильно. Мы можем запускать сценарии, которые будут выполнять для нас процедуры в автоматическом режиме, основываясь на содержимом исходного текста программы и документов. Наша цель состоит в том, чтобы поддерживать автоматическую, не требующую вмешательства пользователя последовательность операций содержательного характера.
Генерирование web-сайта
Многие команды разработчиков используют внутренний web-сайт для обмена информацией в ходе выполнения проекта, и мы полагаем, что это прекрасная идея. Но мы не хотим тратить много времени на поддержку web-сайта и не желаем, чтобы информация, содержащаяся на нем, устаревала. Информация, вводящая в заблуждение, хуже, чем отсутствие какой бы то ни было информации вообще.
Документация, извлекаемая из программы, анализа требований, проектных документов и любых чертежей, графиков или диаграмм, должна регулярно публиковаться на web-сайте. Мы предпочитаем публиковать эти документы автоматически – это является частью ночной процедуры сборки или добавочным блоком в процедуре возвращения исходного текста программы в библиотеку.
Однако если это сделано, содержание web-сайта должно генерироваться автоматически из информации, хранящейся в централизованной библиотеке, и публиковаться без вмешательства человека. На самом деле это еще одно применение принципа DRY: информация существует в одной форме – в виде исходного текста и документов в библиотеке. При просмотре с помощью web-браузера они так и выглядят – просто визуальное представление. Вам не придется поддерживать это представление вручную.
Любая информация, сгенерированная в процессе ночной сборки, должна быть доступна на web-сайте разработчиков: результаты самой сборки (они могут быть представлены в виде краткого отчета на одной странице, содержащего предупреждения компилятора, ошибки и текущее состояние), регрессионные тесты, рабочая статистика, программные метрики, а также любые другие результаты статического анализа и т. д.
Административные процедуры утверждения
Некоторые проекты участвуют в административном документообороте, требования которого необходимо соблюдать. Например, рассмотрение проекта или текста программы должно быть спланировано и доведено до конца, документы необходимо утверждать и т. д. Можно использовать автоматизацию и – особенно это касается web-сайта – облегчить бремя, налагаемое бумажной работой.
Предположим, что вы хотели автоматизировать планирование рассмотрения и процедуру утверждения текста программы. В каждый файл с исходным текстом вы могли бы поместить специальный маркер:
/* Status: needs_review */
Простой сценарий должен пройти весь исходный текст до конца и провести поиск всех файлов, находившихся в состоянии needs_review, которое указывало на их готовность к рассмотрению. Затем вы могли бы поместить список этих файлов в виде web-страницы, автоматически послать электронную почту соответствующим адресатам или даже назначить встречу, используя программу календарного планирования.
Вы можете организовать некую форму на web-странице, чтобы рецензенты регистрировали свое утверждение или несогласие. После рассмотрения состояние может быть автоматически изменено на reviewed. Использовать или не использовать сквозной контроль текста программы всеми участниками – это зависит от вас; всю бумажную работу вы можете проделывать автоматически независимо от этого. (В своей статье в журнале САСМ (апрель 1999 г.) Роберт Гласе обобщает результаты исследования, которое, похоже, указывает на то, что критическое рассмотрение текста программы отличается эффективностью, в отличие от рассмотрения в ходе собраний [Gla99a].)
Дети сапожника
Дети сапожника всегда без сапог. Зачастую те, кто занимается разработкой программ, используют наихудшие инструментальные средства для выполнения своей работы.
Но у нас имеются все исходные материалы для того, чтобы создать лучшие инструменты. У нас есть программа cron. У нас есть программа make для платформ Windows и Unix. У нас есть и Perl, а также другие языки сценариев высокого уровня для быстрой разработки заказных инструментальных средств, генераторов web-страниц, исходных тестов программ, тестовых стендов и т. д.
Пусть компьютер делает скучную земную работу – он сделает это лучше, чем мы. У нас есть задачи поважнее и потруднее.
Другие разделы, относящиеся к данной теме:
• Мой исходный текст съел кот Мурзик
• Пороки дублирования
• Сила простого текста
• Игры с оболочками
• Отладка
• Генераторы исходных текстов
• Команды прагматиков
• Безжалостное тестирование
• Все эти сочинения
Вопросы для обсуждения
• Посмотрите на свои ежедневные действия. Есть ли у вас повторяющиеся задачи? Набираете ли вы одну и туже последовательность команд раз за разом? Попробуйте написать несколько сценариев оболочки для автоматизации процесса. Всегда ли вы щелкаете мышью по определенной последовательности пиктограмм, повторяя эту операцию снова и снова? Можете ли вы создать макрокоманду, которая будет это делать за вас?
• Какая часть вашей бумажной работы, связанной с проектом, может быть автоматизирована? Учитывая большие расходы на содержание штата программистов
[48], определите, какая часть проектного бюджета тратится впустую на административные процедуры. Можете ли вы обосновать временные затраты на создание автоматизированного решения, основываясь на общей экономии затрат, которая достигается при его внедрении?
43
Безжалостное тестирование
Большинство разработчиков ненавидят тестирование. Они стремятся тестировать осторожно, подсознательно ощущая, в каком месте программа может сбоить, и избегая слабых мест. Но прагматики ведут себя по-другому. Мы обладаем мотивацией к отысканию дефектов именно сейчас, чтобы нам не пришлось испытывать позор, когда кто-то другой найдет наши ошибки позже.
Поиск дефектов можно уподобить ловле рыбы с помощью сети. Мы используем мелкие, небольшие сети (модульные тесты) для ловли пескарей и большие, крупные сети (комплексные тесты) для ловли акул-убийц. Иногда рыбе удается выскользнуть, поэтому мы заделываем все найденные дыры в надежде поймать как можно больше скользких дефектов, плавающих в бассейне нашего проекта.
Подсказка 62: Тестируйте раньше. Тестируйте часто. Тестируйте автоматически
Как только у нас появляется текст программы, мы сразу хотим начать его тестирование. Крошечные пескарики имеют отвратительную привычку быстро становиться огромными акулами-людоедами, а поймать акулу намного сложнее. Но мы не хотим осуществлять все это тестирование вручную.
Многие команды разрабатывают сложные планы тестирования своих проектов. Иногда они даже их используют. Но мы обнаружили, что команды, использующие автоматизированные процедуры тестирования, имеют больше шансов на успех. Тесты, запускающиеся в ходе каждого процесса сборки, являются более эффективными по сравнению с планами тестирования, которые лежат на полке.
Чем раньше обнаружен дефект, тем дешевле обходится его устранение. "Чуть-чуть напишешь, чуть-чуть проверишь" – популярное изречение в мире Smalltalk
[49], и мы можем принять эту мантру как нашу личную, создавая одновременно (или даже раньше) с написанием рабочей программы программу ее тестирования.
На самом деле удачный проект содержит больше программ тестирования, чем рабочих программ. Временные затраты на написание тестовой программы себя оправдывают. В конечном счете это оказывается намного дешевле, и вы действительно имеете возможность создания практически бездефектного продукта.
Кроме того, осознание, что вы прошли тест, дает вам большую степень уверенности в том, что этот фрагмент программы "готов".
Подсказка 63: Программа не считается написанной, пока не пройдет тестирование
Тот факт, что вы закончили работу с фрагментом программы, вовсе не означает, что можно идти к шефу или заказчику, чтобы сообщить ему о «готовности». Фрагмент не готов. Прежде всего, программа в реальности никогда не бывает готовой. И, что более важно, пока она не пройдет все имеющиеся тесты, вы не можете утверждать, что она может использоваться кем бы то ни было.
Необходимо рассмотреть три основных аспекта тестирования в масштабе всего проекта: что тестировать, как тестировать и когда тестировать.
Что тестировать
Существует несколько видов процедур тестирования программного обеспечения, которые вам приходится выполнять:
• Модульное тестирование
• Комплексное тестирование
• Подтверждение правильности и верификация
• Тестирование в условиях нехватки ресурсов, ошибки и их исправление
• Тестирование производительности
• Тестирование удобства использования
Этот перечень ни в коей мере не является полным, и в некоторых специализированных проектах потребуются другие виды процедур тестирования. Но это дает нам хорошую отправную точку.
Модульное тестирование
Модульный тест представляет собой программу, занимающуюся тестированием некоего модуля. Эта тема освещена в разделе "Программа, которую легко тестировать". Модульное тестирование является основой для всех других видов тестирования, которые обсуждаются в данном разделе. Если части не работают по отдельности, то скорее всего они не будут хорошо работать и вместе. Все используемые модули обязаны пройти собственное модульное тестирование перед тем как продолжать работу.
Как только все соответствующие модули прошли индивидуальное тестирование, вы готовы к новому этапу. Вам придется проверить, как модули используют друг друга и взаимодействуют между собой по всей системе.
Комплексное тестирование
Комплексное тестирование показывает, что основные подсистемы, из которых состоит проект, работают и нормально взаимодействуют друг с другом. При наличии удачных и хорошо проверенных контрактов обнаружить любые проблемы интеграции не составляет особого труда. В противном случае интеграция становится благодатной почвой для размножения дефектов. Фактически в многих случаях она является единственным и самым крупным источником дефектов в системе.
В реальности комплексное тестирование является продолжением модульного тестирования, описанного выше, с той лишь разницей, что теперь вы проверяете, как целые подсистемы соблюдают свои контракты.
Подтверждение правильности и верификация
Как только в вашем распоряжении появляется рабочий пользовательский интерфейс или прототип, вам приходится отвечать на существенный вопрос: пользователи сказали вам, что они хотели бы увидеть, но то ли это на самом деле?
Отвечает ли продукт функциональным требованиям системы? Это также нуждается в тестировании. Бездефектная система, которая отвечает на неправильные вопросы, не приносит пользы. Необходимо осознавать схемы доступа конечного пользователя и их отличие от тестовых данных разработчика (в качестве примера обратите внимание на историю о рисовании кистью из раздела "Отладка")
Тестирование в условиях нехватки ресурсов, ошибки и их исправление.
Теперь вы понимаете, что система будет вести себя корректно в идеальных условиях, вам придется испытать, как она ведет себя в реальных условиях. В реальном мире ресурсы ваших программ не безграничны – они исчерпываются. Ваша программа может столкнуться со следующими ограничениями:
• Объем памяти
• Объем дискового пространства
• Мощность процессора
• Тактовая частота
• Скорость дискового обмена
• Пропускная способность сети
• Цветовая палитра
• Разрешающая способность экрана
Вы можете реально проверить нехватку дискового пространства или объема памяти, но как часто вы проверяете другие ограничения? Будет ли ваше приложение работать на экране с разрешением 640*480 и 256 цветами? Может ли оно выполняться на экране с разрешением 1600*1280 с 24-битным цветом и при этом не быть размером с почтовую марку? Завершится ли пакетное задание до момента запуска программы архивации?
Вы можете обнаружить наличие ограничений в операционной среде, таких как спецификация видеоподсистемы, и приспособиться к ним соответствующим образом. Однако не все сбои можно восстановить. Если программа обнаруживает нехватку памяти, то вы ограничены в своих действиях: вам не хватит ресурсов, чтобы завершить программу способом, отличным от аварийного завершения.
Когда система выходит из строя
[50], будет ли это делаться изящно? Постарается ли она сделать лучшее, на что она способна в данной ситуации, – сохранить свое состояние и предотвратить потерю данных? Или она выдаст пользователю сообщения типа "Общая ошибка защиты" или "core dump" (отключение ядра системы)?
Тестирование производительности
Тестирование производительности, нагрузочное тестирование или тестирование в реальных условиях эксплуатации может также оказаться важным аспектом проекта.
Задайте себе вопрос, отвечает ли программа требованиям производительности в условиях реального мира – с ожидаемым числом пользователей, подключений или транзакций в единицу времени. Является ли она масштабируемой?
При работе с некоторыми приложениями вам могут понадобиться специализированные тестовая аппаратура или программное обеспечение для реалистичной имитации нагрузок.
Тестирование удобства использования
Тестирование удобства использования отличается от процедур тестирования, обсужденных выше. Оно осуществляется с реальными пользователями в реальных условиях окружающей среды.
Рассмотрим удобство использования с точки зрения человеческого фактора. Имелись ли какие-либо недоразумения в ходе анализа требований, на которые необходимо обратить внимание? Подходит ли программное обеспечение пользователю, становясь продолжением его рук? (Мы хотим, чтобы не только наши собственные инструменты были изготовлены по руке, но чтобы и те, которые мы создаем для пользователей, подходили им.)
Как и при подтверждении правильности и верификации, вам приходится осуществлять тестирование удобства использования как можно раньше, пока есть время на внесение изменений. Для крупномасштабных проектов вы можете привлечь специалистов в области человеческого фактора.
Несоответствие критериям удобства использования является дефектом такого же порядка, как деление на ноль.
Как проводить тестирование
Мы рассмотрели то, что подлежит тестированию. Теперь мы обратим внимание на то, как это делается, включая следующее:
• Регрессионное тестирование
• Тестовые данные
• Тестирование систем с графическим интерфейсом
• Тестирование самих тестов
• Исчерпывающее тестирование
Тестирование проектных решений/методологии
Можете ли вы провести тестирование проектных решений в самой программе и методологии, которую вы использовали при сборке программного обеспечения? Некоторым образом можете. Вы делаете это, анализируя метрики – измерения различных аспектов программы. Самой простой метрикой (и чаще всего, наименее интересной) является число строк кода – насколько велика сама программа?
Существует большое количество других метрик, которые вы можете использовать для исследования программы:
• Показатель цикломатической сложности Маккейба (измеряет сложность структуры решений)
• Коэффициент разветвления по входу при наследовании (количество базовых классов) и по выходу (количество производных модулей; используется в качестве родителя)
• Набор откликов (см. раздел "Несвязанность и закон Деметера")
• Отношения связывания класса (см. [URL 48])
Некоторые метрики предназначены для того, чтобы дать вам "проходной балл", тогда как другие полезны только в сравнении. Это означает, что вы вычисляете метрики для каждого модуля в системе и смотрите, как конкретный модуль относится к своим братьям. Здесь обычно используются стандартные статистические методики.
Если вы обнаруживаете модуль, чья метрика значительно отличается от всех остальных, вам необходимо задать вопрос, приемлемо ли это. Для некоторых модулей "нарушение хода кривой" может быть вполне нормально. Но для тех, у которых нет хорошего оправдания, это может свидетельствовать о потенциальных проблемах.
Регрессионное тестирование
Регрессионное тестирование сравнивает выходные данные текущего теста с результатами (или известными значениями) предыдущих. Мы можем гарантировать, что дефекты, устраненные сегодня, не нарушат ничего из того, над чем мы работали вчера. Это важное средство страховки, и оно сокращает число неприятных сюрпризов.
Все тесты, о которых мы говорили до настоящего момента, могут запускаться как регрессионные тесты с гарантией, что мы не откатываемся назад, когда разрабатываем новую программу. Мы можем запускать регрессии для тестирования производительности, контрактов, достоверности и т. д.
Тестовые данные
Где мы достаем данные для запуска всех этих тестов? Существует только два типа данных: реальные и синтезированные данные. В действительности нам необходимо использовать оба типа, поскольку их различная природа будет способствовать выявлению разных дефектов в программном обеспечении.
Реальные данные исходят из некоего реального источника. Возможно, они были получены из существующей системы, конкурирующей системы или некоего прототипа. Они представляют типичные пользовательские данные. Большие сюрпризы возникают, как только вы открываете значение термина «типичный». При этом скорее всего являются дефекты и недоразумения в анализе требований.
Синтезированные данные генерируются искусственно, возможно, с определенными статистическими ограничениями. Вам могут понадобиться синтезированные данные по одной из следующих причин:
• Вам необходимо много данных, возможно, больше, чем содержится в любом из имеющихся образцов. Вы сможете использовать реальные данные в качестве «саженца» душ генерации большего набора данных и добиться уникальности определенных полей.
• Вам необходимы данные для того, чтобы выделить определенные граничные условия. Эти данные могут быть полностью синтезированными: поля, содержащие дату 29 февраля 1999 г., огромные размеры записей или адреса с иностранными почтовыми индексами.
• Вам необходимы данные, которые демонстрируют определенные статистические свойства. Вы хотите увидеть, что случается, если сбой происходит с каждой третьей транзакцией? Вспомните алгоритм сортировки, который замедляется и ползет, когда обрабатывает предварительно отсортированные данные. Чтобы продемонстрировать эту слабость, вы можете представить данные в случайном или упорядоченном виде.
Тестирование систем с графическим интерфейсом
Тестирование систем, насыщенных графическими интерфейсами, часто требует наличия специализированных инструментальных средств. Эти средства могут основываться на простой модели захвата/воспроизведения данных или могут потребовать специально для этой цели написанных сценариев для управления графическим интерфейсом. Некоторые системы объединяют элементы обеих моделей.
Менее сложные инструментальные средства предписывают высокую степень связывания тестируемой версии программы и самого тестового сценария: если вы перемещаете диалоговое окно или уменьшаете размер экранной кнопки, процедура тестирования может не найти всего этого и оказаться неудачной. Большинство современных инструментальных средств тестирования графических интерфейсов используют ряд методик, чтобы обойти эту проблему и попытаться приспособиться к незначительным различиям в компоновке.
Однако вы не можете автоматизировать все. Энди работал над графической системой, которая позволяла пользователю создавать и отображать недетерминированные визуальные эффекты, моделирующие различные природные явления. К сожалению, в ходе тестирования нельзя просто захватить растровое изображение и сравнить с предыдущим прогоном, потому что приложение было спроектировано так, что каждый раз оно выполнялось по-разному. В подобных ситуациях у вас может не быть выбора, кроме как положиться на ручную интерпретацию результатов теста.
Одним из преимуществ, возникающих при написании несвязанной программы (см. "Несвязанность и закон Деметера") является большая доля модульного тестирования. Например, для приложений, занимающихся обработкой данных, которые имеют внешний графический интерфейс, конструкция должна быть несвязанной в достаточной степени, чтобы можно было тестировать логику приложения в отсутствии графического интерфейса. Эта идея аналогична необходимости тестировать компоненты в числе первых. Как только достоверность логики приложения подтверждается, задача по поиску дефектов, которые выявляются при наличии пользовательского интерфейса, не представляет труда (скорее всего, эти дефекты были созданы программой интерфейса пользователя).
Тестирование самих тестов
Поскольку мы не можем писать совершенные программы, то из этого следует, что мы не можем написать и совершенные программы для тестирования. Нам необходимо тестировать сами тесты.
Рассматривайте набор тестовых пакетов как сложную систему безопасности, предназначенную для подачи звукового сигнала тревоги при выявлении дефекта. Ведь нет лучшего способа проверки безопасности системы, как попытаться вломиться в нее?
После того как вы написали тест для обнаружения конкретного дефекта, вызовите этот дефект преднамеренно и удостоверьтесь, что тест его обнаружил. Это гарантия того, что тест обязательно выловит этот дефект в реальных условиях.
Подсказка 64: Используйте диверсантов для тестирования самих тестов
Если вы серьезно относитесь к тестированию, то вы должны нанять диверсанта проекта, чья роль состоит в том, чтобы воспользоваться отдельной копией исходного дерева, преднамеренно внести дефекты и проверить, что при тестировании они будут выловлены.
При написании тестов убедитесь, что сигналы тревоги раздаются тогда, когда они обязаны раздаваться.
Исчерпывающее тестирование
Вы уверены в том, что ваши тесты являются корректными и обнаруживают созданные вами дефекты. Но как вы узнаете о том, насколько исчерпывающе вы провели тестирование ядра программы?
Ответ здесь краток: «никак», вы никогда это не узнаете. Но на программном рынке есть продукты, которые могут вам помочь. Эти средства анализа степени покрытия отслеживают программу при тестировании и регистрируют, какие строки были выполнены, а какие нет. Эти средства дают общее представление о том, насколько исчерпывающей является процедура тестирования, но не стоит ожидать, что степень покрытия составит 100 %.
Даже если выполненными окажутся все строки программы, это еще не все. Важно то число состояний, в которых может находиться программа. Состояния не являются эквивалентом строк программы. Предположим, что есть функция, обрабатывающая два целых числа, каждое из которых может принимать значения от 0 до 999.
int test(int a, int b) {
return a / (a + b)
}
Теоретически эта функция, состоящая из трех строк, имеет 1000000 логических состояний, 999999 из которых будут работать правильно, а одно – неправильно (когда а + b равно нулю). Если вам известно лишь то, что данная строка программы выполнена, то вам придется идентифицировать все возможные состояния программы. К сожалению, это очень сложная проблема. Настолько сложная, что "пока вы ее решите, солнце превратится в холодную глыбу".
Подсказка 65: Тестируйте степень покрытия состояний, а не строк текста программы
Даже при высокой степени покрытия программы данные, используемые вами в процедуре тестирования, все еще оказывают огромное влияние, и, что более важно, порядок, в котором вы выполняете программу, может оказать самое сильное воздействие.
Когда тестировать
Многие проекты стремятся отложить процедуру тестирование на последний момент – тот, где оно будет срезано в преддверии контрольного срока
[51]. Нужно начать тестирование намного раньше наступления этого срока. Как только появится какая-либо рабочая программа, ее необходимо протестировать.
Большинство процедур тестирования должно выполняться автоматически. Важно заметить, что под термином «автоматически» мы имеем в виду и автоматическую интерпретацию результатов теста. Более подробно этот аспект рассматривается в разделе "Вездесущая автоматизация".
Мы предпочитаем проводить тестирование как можно чаще и всегда делаем это перед возвращением исходного текста в библиотеку. Некоторые системы управления исходным текстом, наподобие Aegis, могут осуществлять это автоматически. В других случаях мы просто набираем
% make test
Обычно не представляет труда запускать регрессии на всех отдельных модульных и комплексных тестах и проделывать это так часто, как это необходимо.
Но для ряда тестов частый прогон может представлять сложность. Для проведения нагрузочного тестирования могут потребоваться специальные настройки или оборудование и некоторая часть ручной работы. Эти тесты могут проводиться с меньшей частотой – возможно, еженедельно или ежемесячно. Но важно то, что они прогоняются на регулярной, запланированной основе. Если это нельзя сделать автоматически, то удостоверьтесь, что тесты включены в план вместе со всеми ресурсами, назначенными для данной задачи.
Кольцо сжимается
И наконец, мы хотели бы раскрыть единственный и самый важный принцип тестирования. Он очевиден, и практически в каждом учебнике говорится о том, что это нужно делать именно так. Но в силу некоторых причин в большинстве проектов этого все еще не делается.
Если дефект проскальзывает через сеть существующих тестов, вам необходимо добавить новый тест, чтобы поймать его в следующий раз.
Подсказка 66: Дефект должен обнаруживаться единожды
Если тестировщик обнаруживает дефект, это должно быть в первый и последний раз – обнаружение дефекта человеком. Автоматизированные тесты должны быть модифицированы для проверки наличия этого дефекта, начиная с момента его первоначального обнаружения, всякий раз, без каких-либо исключений, не обращая внимания на степень тривиальности, жалобы разработчика и его фразу "Этого больше не случится".
Потому что это снова случится. А у нас просто нет времени гоняться за дефектами, которые автоматизированные тесты не могли обнаружить. И нам придется тратить время на написание новой программы – с новыми дефектами.
Другие разделы, относящиеся к данной теме:
• Мой исходный текст съел кот Мурзик
• Отладка
• Несвязанность и закон Деметера
• Реорганизация
• Программа, которую легко тестировать
• Вездесущая автоматизация
Вопросы для обсуждения
• Можете ли вы осуществить автоматическое тестирование вашего проекта? Многие команды вынуждены дать отрицательный ответ. Почему? Слишком сложно определить приемлемые результаты? Не приведет ли к затруднениям попытка доказать спонсорам, что проект "сделан"?
Сложно ли проверить логику приложения независимо от графического интерфейса? Что можно сказать о графическом интерфейсе? О связывании?
44
Все эти сочинения
Лучше выцветшие чернила, чем отличная память.
Китайская пословица
Как правило, разработчики не размышляют над документацией слишком долго. В лучшем случае она является для них досадной необходимостью; в худшем случае она считается задачей с низким приоритетом в надежде на то, что руководство забудет о ней в конце работы над проектом.
Прагматики воспринимают документацию как неотъемлемую часть общего процесса разработки. Написание документации может быть облегчено, если вы не дублируете усилия, не теряете времени попусту и держите документацию под рукой, а если это возможно, – то в самой программе.
Эти мысли не отличаются оригинальностью и новизной; идея о брачном союзе программы и документации к ней появляется уже в работе Доналда Кнута о грамотном программировании и в утилите JavaDoc фирмы Sun. Мы хотим уменьшить противоречие между программой и документацией и вместо этого считать их двумя визуальными представлениями одной и той же модели (см. "Всего лишь визуальное представление"). На самом деле мы хотим пойти немножко дальше и применить все наши прагматические принципы к документации так, как мы применяем их к программам.
Подсказка 67: Считайте естественный язык одним из языков программирования
Существует два основных вида документации, которая готовится для проекта: внутренняя и внешняя. Внутренняя документация включает комментарии исходных текстов, документы, касающиеся проектирования и тестирования, и т. д. Внешняя документация – это то, что отправляется заказчику или публикуется для внешнего мира, например, руководство пользователя. Но вне зависимости от целевой аудитории или роли автора (разработчик он или технический писатель), вся документация является отражением программы. При наличии несоответствий программа – это то, что имеет значение.
Подсказка 68: Встраивайте документацию в проект, а не накручивайте ее сверху
Начнем с внутренней документации.
Комментарии в программе
Создать форматированные документы из комментариев и объявлений в исходном тексте довольно просто, но вначале нужно убедиться, в тексте программы действительно есть комментарии. Программа должна иметь комментарии, но слишком большое их количество может быть так же плохо, как и малое.
В общем, комментарии должны обсуждать, почему выполняется та или иная операция, ее задачу и ее цель. Программа всегда демонстрирует, как это делается, поэтому комментирование – избыточная информация и нарушение принципа DRY.
Создание комментариев в тексте исходной программы дает отличную возможность документировать неуловимые фрагменты проекта, которые не могут документироваться где-либо еще: технические компромиссы, почему было принято то или иное решение, какие альтернативные варианты были отвергнуты и т. д.
Мы предпочитаем увидеть простой комментарий в заголовке (на уровне модуля), комментарии к существенным данным и объявлениям типов и краткие заголовки для каждого из классов и методов, описывающие, как используется именно эта функция и все ее неочевидные действия.
Имена переменных должны выбираться четко и со смыслом. Например, имя foo, не имеет смысла, так же как doit или manager, или stuff. «Венгерский» стиль именования (в котором вы кодируете информацию о типе переменной в самом ее имени) крайне нежелателен в объектно-ориентированных системах. Не забывайте, что вы (и те, кто идет за вами) будут читать текст программы много сотен раз, но писать ее будут лишь несколько раз. Не торопитесь, и напишите connectionPool вместо ср.
Имена, вводящие в заблуждение, еще хуже, чем бессмысленные. Приходилось ли вам слышать, как кто-нибудь объясняет несоответствия в унаследованном тексте программы типа: "Подпрограмма с именем getData на самом деле записывает данные на диск"? Человеческий мозг будет периодически все путать – это называется эффектом Струпа [Str35]. Вы можете поставить на себе следующий эксперимент, чтобы увидеть эффект подобных помех. Возьмите несколько цветных ручек и напишите ими названия цветов спектра. Но при этом название цвета должно быть написано только ручкой другого цвета. Вы может написать слово «синий» зеленым цветом, слово «коричневый» – красным и т. д. (В качестве альтернативы имеется набор цветов спектра, уже помещенный на наш web-сайт www.pragmaticprogrammer.com.) Как только вы написали названия цветов, постарайтесь как можно быстрее произнести вслух название цвета, которым написано каждое слово. В определенный момент вы собьетесь и станете читать названия цветов, а не сами цвета. Имена очень важны для восприятия, а имена, вводящие в заблуждение, вносят беспорядок в программу.
Вы можете документировать параметры, но задайте себе вопрос, а нужно ли это делать во всех случаях. Уровень комментариев, предлагаемый средством JavaDoc, кажется весьма приемлемым:
/**
* Найти пиковое (наивысшее) значение в указанном интервале дат
* @param aRange Range of dates to search for data.
* @param aThreshold Minimum value to consider.
* @return the value, or null if no value found
* greater than or equal to the threshold.
*/
public Sample findPeak(Date Range aRange, double aThreshold);
Вот перечень того, чего не должно быть в комментариях к исходному тексту программы.

Перечень функций, экспортируемых программой в файл.Существуют программы, которые анализируют исходный текст. Воспользуйтесь ими, и этот перечень никогда не устареет.

Хронология изменений.Для этого предназначены системы управления исходным текстом программы (см. "Управление исходным текстом"). Однако, будет полезно включить информацию о дате последнего изменения и сотруднике, который внес это изменение
[52].

Список файлов, используемых данным файлом.Это можно более точно определить при помощи автоматических инструментальных средств.

Имя файла.Если оно должно указываться в файле, не поддерживайте его вручную. Система RCS и ей подобные могут обновлять эту информацию автоматически. При перемещении и удалении файла вам не хочется вспоминать о необходимости редактирования заголовка.
Одним из наиболее важных фрагментов информации, который обязан появиться в исходном файле, – это имя автора, не обязательно того, кто осуществлял последнюю редакцию, но имя владельца. Приложение обязательств и ответственности к исходному тексту программы творит чудеса, сохраняя людей честными (см. "Гордость и предубеждение").
Проект также может потребовать наличия определенных ссылок на авторские права или других юридических стереотипов в каждом исходном файле. Сделайте так, чтобы программа редактирования вставляла эти элементы автоматически.
При наличии обширных комментариев инструментальные средства, подобные JavaDoc [URL 7] и DOC++ [URL 21], могут извлекать и форматировать их для автоматического создания документации на уровне API. Это является одним из конкретных примеров более универсальной методики, которой мы пользуемся, – исполняемые документы.
Исполняемые документы
Предположим, что есть спецификация, которая перечисляет столбцы в таблице базы данных. Тогда мы получим отдельный набор команд SQL для создания реальной таблицы в базе данных и, по всей вероятности, некую структуру записи на языке программирования для хранения содержимого строки в таблице. Одна и та же информация повторяется три раза. Стоит изменить один из этих трех источников – и два других немедленно устареют. Это явное нарушение принципа DRY.
Для решения этой проблемы необходимо выбрать авторитетный источник информации. Это может быть спецификация, инструментальное средство для построения схем баз данных или некий третий источник. Выберем в качестве источника спецификацию. Теперь она является моделью нашего процесса. Нам необходим способ экспортирования информации, содержащейся в ней, в виде различных визуальных представлений, например, в виде схемы базы данных и записи на языке программирования высокого уровня
[53].
Если документ хранится в виде простого текста вместе с командами описания документов (например, в виде HTML, LATeX. или troff), то в этом случае можно использовать такие инструментальные средства, как Perl, для извлечения схемы и ее автоматического переформатирования. Если документ хранится в двоичном формате текстового процессора, то ознакомьтесь с некоторыми вариантами действий, приведенных во врезке, данной ниже.
Теперь документ – неотъемлемая часть разработки проекта. Единственным способом изменения схемы является изменение документа. Вы гарантируете, что спецификация, схема и программа находятся в согласии. Вы сводите к минимум работу, которую необходимо выполнить для внесения каждого изменения, и можете обновлять визуальные представления изменений автоматически.
Как быть, если мой документ не хранится в формате простого текста!
К сожалению, в настоящее время все больше проектной документации составляется с помощью текстовых процессоров, сохраняющих файл на диске в некоем определенном формате. Мы говорим "к сожалению", потому что это существенно ограничивает возможности автоматической обработки документа. Но у вас в запасе имеется еще два варианта:

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

Сделайте документ подчиненным.Вместо того, чтобы использовать документ в качестве определяющего источника, возьмите другое представление. В примере с базой данных вы хотели бы использовать схему в качестве авторитетной информации. Тогда создайте средство, которое экспортирует эту информацию в ту форму, которую документ может импортировать. Однако при этом будьте внимательны. Вы должны быть уверены, что эта информация импортируется всякий раз, когда документ выводится на печать, а не единожды, при создании этого документа.
Аналогичным образом можно генерировать документацию на уровне API из исходного текста программы, пользуясь инструментальными средствами, такими как JavaDoc и DOC++. Моделью является исходный текст программы: компилироваться может одно визуальное представление модели; другие представления предназначены для вывода на печать или просмотра на web-странице. Наша цель – работа над моделью (неважно, является ли эта модель самой программой или же каким-либо иным документом), и мы должны добиться того, чтобы все эти представления обновлялись автоматически (см. "Вездесущая автоматизация").
Внезапно документация оказывается не столь уж плохой.
Технические писатели
До этого момента мы говорили лишь о внутренней документации, той которую составляют сами программисты. Но что происходит, если в вашем проекте участвуют профессиональные технические писатели? Слишком часто программисты просто «перекидывают» материал техническим писателям и дают им возможность заработать себе на жизнь, создавая руководства пользователей, рекламные материалы и т. д.
Это является ошибкой. То, что программисты не составляют такие документы, вовсе не означает, что мы можем поступиться прагматическими принципами. Мы хотим, чтобы писатели восприняли те же основные принципы, что и прагматики, – соблюдали принципы DRY, ортогональности, а также концепцию "модель-визуальное представление", применяли автоматизацию и сценарии.
Печатать документ или ткать его на холсте?
Издаваемой бумажной документации присуща одна проблема: она может устареть, пока будет напечатана. Документация в любой ее форме – лишь моментальный снимок.
Поэтому мы стараемся создавать всю документацию в форме, которая может быть помещена в информационную сеть, на web-страницу вместе с гиперссылками. Такое представление документации легче сохранять в обновленном виде, чем отслеживать все существующие бумажные экземпляры, уничтожать их и распространять обновленные версии. Это также является лучшим способом обращения к нуждам широкой аудитории. Однако не забывайте помещать дату или номер версии на каждой web-странице. В этом случае читатель сможет разобраться, что соответствует текущему моменту, что изменилось недавно, а что осталось неизменным.
Во многих случаях вам приходится представлять одну и ту же документацию в различных форматах: в печатном, в виде web-страницы, экранной справки, а может быть, и как слайд-шоу. Обычное решение в большой степени полагается на технологию "вырезать и вставить" на и создание нескольких независимых документов из одного оригинала. Это неудачная идея: представление документа не должно зависеть от его содержания.
Если вы пользуетесь системой описания документов, то обладаете гибкостью, чтобы реализовать столько различных выходных форматов, сколько вам нужно. Вы можете использовать

Chapter Title
для генерации новой главы в отчетной версии документа и названия нового слайда в слайд-шоу. Можно воспользоваться технологиями типа XSL и CSS
[54]для генерирования множественных выходных форматов из этого описания.
Если вы используете текстовый процессор, то, по всей вероятности, будете располагать аналогичными возможностями. Если не забывали использовать стили для идентификации различных элементов документа, то, применяя различные таблицы стилей, вы можете существенным образом изменить внешний вид окончательного результата. Большинство современных текстовых процессоров позволяет конвертировать документы в форматы типа HTML для публикации на web-сайтах.
Языки разметки
Мы рекомендуем рассмотреть некоторые из современных схем описания документации для крупномасштабных проектов по документированию.
Многие авторы, пишущие на технические темы, используют в настоящее время средство DocBook для описания своих документов. DocBook представляет собой стандарт описания документов на основе SGML, который тщательно идентифицирует каждый компонент в документе. Документ можно обрабатывать процессором DSSSL для его преобразования в любое число различных форматов. Проект документации Linux использует DocBook для представления информации в форматах RTF, ТеХ, info, PostScript и HTML.
Пока ваше первоначальное описание достаточно насыщено, чтобы выразить все необходимые концепции (включая гиперссылки), перевод публикации в любую другой форму не составит труда и будет выполняться автоматически. Вы можете создавать интерактивную справку, руководства, описание основных свойств продукта для помещения на web-сайт и даже календарь с ежедневными советами – все из одного и того же источника, который находится в системе управления исходным текстом и собирается в ходе процедуры ночной сборки основной программы (см. "Вездесущая автоматизация").
Документация и программа – это различные визуальные представления одной и той же основополагающей модели, но лишь визуальные представления имеют право разниться. Не позволяйте документации превращаться в гражданина второго сорта, которому запрещено участвовать в основном документообороте проекта. Обращайтесь с документацией так же бережно, как вы обращаетесь с программой, и пользователи (а также сотрудники службы сопровождения) будут петь вам осанну.
Другие разделы, относящиеся к данной теме:
• Пороки дублирования
• Ортогональность
• Преимущества простого текста
• Управление исходным текстом
• Всего лишь визуальное представление
• Программирование в расчете на стечение обстоятельств
• Карьер для добычи требований
• Вездесущая автоматизация
Вопросы для обсуждения
• Приходилось ли вам писать пояснительный комментарий для исходного текста программы, который вы только записали? Почему нет? Не было времени? Не уверены, что программа действительно работает – пробуете некую идею в виде прототипа? Впоследствии вы выбросите эту программу, не правда ли? Ведь при этом она не попадет в проект без комментариев и в экспериментальном виде, не так ли?
• Иногда неудобно документировать проектное решение исходного текста программы, поскольку это решение вам не совсем ясно – оно еще на стадии развития. Вы полагаете, что не должны тратить свои усилия впустую, описывая, как работает что-то, еще до того, как оно действительно начинает работать. Не похоже ли это на программирование в расчете на стечение обстоятельств? (См. одноименный раздел.)
45
Большие надежды
Подивитесь сему, небеса, и содрогнитесь, и ужаснитесь, говорит Господь.
Иеремия (2,12)
Компания объявляет о рекордной прибыли, а цена на ее акции падает на 20 %. Вечерняя телепрограмма финансовых новостей объясняет, что компании не удалось оправдать надежды аналитиков. Ребенок открывает дорогой рождественский подарок – и в слезы: там нет дешевой куклы, на которую он так надеялся. Проектная команда творит чудеса, реализуя феноменально сложное приложение, и лишь для того, чтобы получить ушат воды со стороны пользователей, поскольку в системе отсутствует справка.
В абстрактном смысле приложение успешно, если оно корректно реализует свои спецификации. К сожалению, это и оплачивается лишь абстрактно.
В действительности успех проекта измеряется тем, насколько он соответствует надеждам своих пользователей. Проект, не оправдавший их надежд, обречен на неудачу, неважно, насколько хорошо он соответствовал срокам. Однако, подобно родителям ребенка, ожидающего дешевую куклу, вы заходите слишком далеко и терпите неудачу.
Подсказка 69: Слегка превышайте надежды ваших пользователей
Однако выполнение этой подсказки требует некоторых усилий.
Передача надежд
Пользователи обычно приходят к вам с некоторым видением того, что они хотят. Оно может быть неполным, противоречивым или технически невыполнимым, но оно принадлежит пользователям, и, подобно ребенку в Рождество, они вкладывают в него некоторые эмоции. Вы не можете просто проигнорировать их видение.
По мере того как вы осознаете потребности пользователей, вы обнаруживаете области, в которых не сможете удовлетворить их требования, или области, где их требования слишком консервативны. Ваша роль частично заключается в передаче этого состояния. Работайте со своими пользователями так, чтобы их понимание того, что вы им поставляете, было точным. Этим необходимо заниматься на протяжении всего процесса разработки. Никогда не теряйте из виду те бизнес-задачи, которые предполагается решать с помощью вашей программы.
Некоторые консультанты называют этот процесс "управление ожиданиями" – активное управление тем, что пользователи надеются получить от их систем. Мы полагаем, что это несколько высокомерная позиция. Наша роль заключается не в том, чтобы управлять надеждами наших пользователей. Необходимо работать с ними, чтобы прийти к общему пониманию процесса разработки и конечного результата, наряду с теми ожиданиями, которые еще не выражены словами. Если команда свободно общается с внешним миром, то этот процесс практически автоматизирован; все должны понять, что ожидается и как это будет построено.
Существует ряд методик, которые могут использоваться для облегчения этого процесса. Из них наиболее важными являются "Стрельба трассирующими" и "Прототипы и памятные записки". Обе методики позволяют команде конструировать то, что может увидеть пользователь. Обе являются идеальными способами передать ваше понимание требований пользователей, обедают возможность вам и вашим пользователям практиковаться в общении друг с другом.
Небольшой довесок
Если вы работаете в тесном взаимодействии с вашими пользователями, разделяя их надежды и сообщая им о том, что вы делаете, то при завершении проекта практически не возникнет сюрпризов.
ЭТО ПЛОХО. Постарайтесь удивить ваших пользователей. Заметьте, их не надо пугать, их надо восхищать.
Дайте им немного больше, чем они ожидают. Небольшое усилие, которое потребуется, чтобы добавить в систему некое средство, ориентированное на пользователя, окупится доброжелательностью не один раз.
Прислушивайтесь к вашим пользователям в ходе работы над проектом, чтобы получить намеки на те средства, которые действительно могут их восхитить. Вот некоторые средства, добавляемые без особого труда, которые порадуют среднего пользователя:
• Всплывающая подсказка
• «Горячие» комбинации клавиш
• Краткое справочное руководство в качестве дополнения к руководству пользователя
• Расцвечивание
• Анализаторы журнала регистрации
• Автоматическая инсталляция
• Инструментальные средства проверки целостности системы
• Возможность запускать несколько версий системы в целях тренировки
• Экран-заставка, настроенный для фирмы-заказчика
Все эти вещи относительно поверхностны и особо не нагружают систему. Однако каждый из этих «довесков» говорит пользователям о том, что команда разработчиков позаботилась о создании отличной системы, предназначенной для использования в реальной жизни. Просто не забывайте о том, что работа системы не должна быть расстроена этими нововведениями.
Другие разделы, относящиеся к данной теме:
• Неплохие программы
• Стрельба трассирующими
• Прототипы и памятные записки
• Карьер для добычи требований
Вопросы для обсуждения
• Иногда самыми жесткими критиками проекта являются те, кто над ним работал. Случалось ли вам испытывать разочарование, когда ваши собственные надежды не были оправданы тем, что вы создали? Как это могло произойти? Может быть здесь присутствует нечто большее, чем логика.
• Что говорят ваши пользователи, когда вы поставляете им готовую программу? Пропорционально ли их внимание к различным аспектам данной программы усилиям, которые вы в эти аспекты вложили? Что их восхищает?
46
Гордость и предубеждение
Вы восхищали нас довольно долго.
Джейн Остин, Гордость и предубеждение
Программисты-прагматики не уклоняются от ответственности.
Вместо этого они испытывают радость, принимая вызовы и распространяя свой опыт. Если мы несем ответственность за проектное решение или фрагмент программы, мы делаем работу, которой можем гордиться.
Подсказка 70: Ставьте вашу подпись под работой
В прошлом мастеровые гордились, подписывая свою работу. Вы должны следовать их примеру.
Проектные команды все еще состоят из людей, и это вызывает сложности. В некоторых проектах идея монопольных прав на программу может вызывать трения. Люди могут начать обособляться или не выказывать желания работать над общими фундаментальными элементами. Проект может закончиться феодальной раздробленностью. У вас возникнут предубеждения относительно и вашей программы, и ваших коллег.
Этого-то мы и не хотим. Вы не должны ревниво защищать свою программу от тех, кто вторгается в ее пределы; вы должны платить людям той же монетой и относиться к программам других разработчиков с уважением. Золотое правило ("Поступай с другими так, как бы ты хотел, чтобы они поступали с тобой") и взаимоуважение среди разработчиков является важным для действия подсказки, приведенной выше.
Анонимность, особенно при работе с крупномасштабными проектами, может оказаться благодатной почвой для небрежности, ошибок, лени и неудачных программ. Слишком легко рассматривать себя лишь в качестве винтика в большой машине, высказывая неубедительные извинения в бесконечных отчетах о состоянии, а не просто создавая хорошие программы.
У программы должен быть владелец, но он не обязательно является физическим лицом. Успешный метод eXtreme Programming [URL 45], разработанный Кентом Беком, рекомендует коллективную собственность на программу (но это требует дополнительных процедур типа парного программирования в целях защиты от анонимности).
Мы хотим, чтобы вы гордились правом собственности. "Я это написал, и я стою за своей работой". Ваша подпись должна стать признанным знаком качества. Люди должны увидеть ваше имя в заголовке программы и рассчитывать на то, что она будет солидной, хорошо составленной, проверенной и документированной. Эта должна быть поистине профессиональная работа. Написанная настоящим профессионалом.
Прагматиком-программистом.
Приложение А
Информационные ресурсы
Авторы затронули в книге весьма широкий круг вопросов программирования, и этому есть объяснение: вопросы рассматривались с высоты птичьего полета. Но если бы им было уделено то внимание, которого они заслуживают, то объем книги стал бы больше на порядок.
Книга начинается с утверждения, что программисты-прагматики должны постоянно учиться. В данном приложении приводится перечень источников информации, которые могут им в этом поспособствовать.
В разделе "Профессиональные общества" приведены координаты IEEE (Institute of Electrical and Electronical Engineers – Институт инженеров по электротехнике и радиоэлектронике) и ACM (Association of Computing Machinery – Ассоциация по вычислительной технике). Мы рекомендуем программисту-прагматику вступить в ряды одного (или обоих) из этих обществ. Ниже в разделе "Собираем библиотеку" указаны периодические издания, книги и интернет-сайты, которые содержат высококачественную и ценную информацию (или просто-напросто забавны по своему содержанию).
В книге содержится много ссылок на программные ресурсы, доступные через Интернет. В разделе «Интернет-ресурсы» приводятся их адреса (URL) с кратким описанием. Но в силу природы Интернета многие из этих адресов могут устареть к моменту выхода книги в свет. Для того чтобы найти более свежие ссылки, можно воспользоваться одной из поисковых систем или же посетить наш интернет-сайт: www.pragmaticprogrammer.com и просмотреть соответствующий раздел.
И наконец, в приложении содержится библиографический список.
Профессиональные общества
У программистов существует два профессиональных объединения мирового уровня. Association of Computing Machinery – ACM
[55](Ассоциация по вычислительной технике) и Institute of Electrical and Electronical Engineers – IEEE
[56](Компьютерное общество института инженеров по электротехнике и радиоэлектронике). Всем программистам рекомендуется вступить в одно (или оба) из этих обществ. Кроме того, разработчики, проживающие вне США, могут вступить в соответствующие национальные объединения (примером может служить British Computer Society – BCS – Британское компьютерное общество).
Члены профессиональных обществ пользуются рядом преимуществ. Конференции и собрания дают возможность общения людям с общими интересами, а специальные секции и технические комитеты позволяют участвовать в выработке стандартов и рекомендаций, используемых во всем мире. Многое можно почерпнуть из их публикаций, в которых ведутся «высоколобые» дискуссии по практическим вопросам и «приземленные» разговоры по компьютерной теории.
Собираем библиотеку
Мы серьезно относимся к чтению книг. Как было замечено в разделе "Портфель знаний", хороший программист учится постоянно. Постоянное нахождение программиста в курсе выходящих книг и периодики способствует такому обучению.
Периодические издания
Люди, подобные авторам книги, хранят старые журналы и периодику до тех пор, пока вес стопки не будет достаточен для превращения нижних экземпляров в алмаз. Вот некоторые периодические издания, рекомендуемые авторами.

IEEE Computer.Рассылается по подписке членам Компьютерного общества Института инженеров по электротехнике и радиоэлектронике. Этот журнал сосредоточен на практических аспектах, но не чужд и теории. Некоторые номера посвящены конкретной тематике, другие же представляют собой просто сборники интересных статей. Говоря языком связистов, журнал обладает хорошим соотношением "сигнал-шум".

IEEE Software.Не менее ценная публикация Компьютерного общества Института инженеров по электротехнике и радиоэлектронике, издаваемая раз в два месяца и нацеленная на программистов-практиков.

Communications of the ACM.Основной журнал, получаемый всеми членами Ассоциации по вычислительной технике; на протяжении десятилетий является отраслевым стандартом и опубликовал больше основополагающих статей, чем любой другой источник.

SIGPLAIM.Журнал выпускается секцией языков программирования, входящей в ассоциацию АСМ, распространяется среди членов АСМ. В нем часто публикуются спецификации языков программирования, наряду с тематическими статьями для всех, кто любит "копать вглубь".

Dr. Dobbs Journal.Ежемесячный журнал, распространяемый по подписке и продающийся в киосках. Этот журнал непрост для восприятия, но его статьи охватывают как практические аспекты, так и чистую теорию.

The Perl Journal.Поклонникам Perl стоит подписаться на этот журнал (www.tpj.com).

Software Development Magazine.Ежемесячный журнал, посвященный общим вопросам управления проектами и разработки программного обеспечения.
Еженедельные профессиональные издания
Существует несколько еженедельных газет для разработчиков и менеджеров. Эти газеты в основном представляют собой сборники фирменных пресс-релизов, перекроенных в статьи. Тем не менее, их содержание представляет ценность – оно позволяет быть в курсе событий, не отставать от объявлений о выходе новых продуктов и следить за возникновением и распадом отраслевых альянсов. Но от них не стоит ожидать наличия глубоко проработанных технических материалов.
Книги
Книги по компьютерной тематике весьма дороги, но при тщательном выборе они становятся хорошим вложением денег. Вот некоторые из них, понравившиеся авторам:
Анализ и проектирование

Object-Oriented Software Construction, второе издание.Эпическое произведение Бертрана Мейера, посвященное основам объектно-ориентированного программирования, общим объемом 1300 страниц [Меу97Ь].

Design Patterns.Конструктивный шаблон описывает метод решения конкретного класса задач на более высоком уровне по сравнению с фразеологизмом на языке программирования. Эта неоклассическая книга [GHJV95], написанная "бандой четырех" (группа авторов Erich Gamma, Richard Helm, Ralph Johnson и John Vlissides. – Прим. пер.), содержит описание 23 базовых конструктивных шаблонов, включая Proxy, Visitor и Singleton.

Analysis Patterns.Сокровищница высококлассных архитектурных шаблонов, выбранных из множества реальных проектов и переработанных в виде книги. Относительно быстрый способ перенимания опыта моделирования, полученного в течение многих лет [Fow96].
Команды и проекты

The Mythical Man Month.Классическое произведение (не так давно переработанное) Фреда Брукса, о "подводных камнях", появляющихся в ходе организации команд разработчиков [Вго95].

Dynamics of Software Development.Серия коротких очерков о разработке программного обеспечения в больших командах, сосредоточенных на динамике взаимодействия членов команды между собой, а также между самой командой и внешним миром [МсС95].

Surviving Object-Oriented Projects: A Manager's Guide."Вести с переднего края", сообщенные Алистером Кокбэрном, иллюстрируют многие опасности и ловушки, подстерегающие вас при управлении объектно-ориентированным проектом, особенно если это ваш первый проект. Г-н Кокбэрн дает подсказки и методики, позволяющие читателю решать наиболее общие проблемы [Сос97Ь].
Среды программирования

Unix.У.Р. Стивенс написал несколько прекрасных книг, включая "Advanced Programming in the Unix Environment" и "Unix Network Programming" [Ste92, Ste98, Ste99].

Windows.Книга Маршалла Брэйна "Win32 System Services" [Bra95] является кратким справочником по низкоуровневым интерфейсам прикладных программ. Труд Чарльза Петцольда "Programming Windows" [Pet98] стал своего рода Библией для разработчиков графических сред пользователя Windows.

С++.Получив проект на языке С++, нужно бежать (а не идти) в книжный магазин и хватать книгу Скотта Мейера под названием "Effective С++" и к ней, возможно, книгу "More Effective С++" [Меу97а, Меу96]. При построении систем существенных размеров может понадобиться книга Джона Лакоса "Large-Scale С++ Software Design" [Lak96]. В поисках более сложных методик стоит обратиться к труду Джима Коплина под названием "Advanced С++ Programming Styles and Idioms" [Сор92].
Кроме того, книги из серии Nutshell издательства O'Reilly (
www.ora.com) дают оперативное и всестороннее освещение разнообразных тем и языков, таких как perl, уасс, sendmail, внутренней организации Windows и регулярных выражений.
Интернет
Найти в Интернете нужную информацию трудно. Вот несколько ссылок, которые проверяются авторами как минимум раз в неделю.

Slashdot.Под заголовком "News for nerds. Stuff that matters" (Новости для дебилов. Материал со значением) скрывается один из крупнейших сайтов сообщества Linux. Помимо регулярно обновляемых новостей из мира Linux сайт предлагает информацию по модным технологиям и проблемам, которые волнуют разработчиков.
www.slashdot.org

Cetus Links.Тысячи ссылок на тему объектно-ориентированного программирования.
www.cetus-links.org

WikiWikiWeb.Центральная база данных шаблонов и обсуждение шаблонов (в Портленде, США). Не являясь особо выдающимся ресурсом, данный сайт представляет собой интересный эксперимент по коллективному редактированию идей.
www.c2.com
Интернет-ресурсы
Приведенные ниже ссылки на ресурсы, доступные в Интернете, были действительны во время работы над книгой, но (Сеть есть Сеть!) к моменту выхода ее в свет могут сильно устареть. В этом случае можно попробовать общий поиск по именам файлов или же зайти на сайт Pragmatic Programmer (www.pragmaticprogrammer.com) и проверить имеющиеся на нем ссылки.
Текстовые редокторы
Emacs и vi – не единственные межплатформенные редакторы, но они распространяются бесплатно и находят широкое применение. Пролистав любой специализированный журнал (например Dr. Dobbs), можно найти ряд коммерческих альтернатив вышеуказанным редакторам.
Редактор Emacs
Редакторы Emacs и XEmacs имеют версии как для платформы Unix, так и для Windows.
[URL 1] Редактор Emacs
www.gnu.org
Новейший «крупнокалиберный» редактор, обладающий всеми возможностями своих предшественников. Кривая обучения Emacs почти вертикальна, но вас ждет щедрое вознаграждение по мере овладения тонкостями работы. Редактор также содержит отличную программу чтения почты и новостей, адресную книгу, календарь и дневник, приключенческую игру…
[URL 2] Редактор XEmacs
www.xemacs.org
Отпочковавшись от классического редактора Emacs несколько лет назад, XEmacs отличается более корректными внутренними командами и более изящным интерфейсом.
Редактор vi
Существует как минимум 15 различных клонов редактора vi. Редактор vim переносится на большинство платформ и является хорошим выбором при работе в различных программных средах.
[URL 3]The Vim Editor
ftp://ftp.fu-berlin.de/misc/editors/vim
Цитата из документации: "Редактор vi содержит большое количество усовершенствований: многоуровневая отмена команд, многооконный интерфейс с буферами, выделение синтаксиса, редактирование в командной строке, дополнение имен файлов, экранная справка, визуальный выбор объектов, и т. д."
[URL 4] Редактор elvis
www.fh-wedel.de/elvis
Усовершенствованный клон редактора vi с поддержкой X.
[URL 5] Emacs Viper Mode
http://www.cs.sunysb.edu./"kifer/emacs.html
Viper представляет собой набор макрокоманд, которые придают редактору Emacs внешнее сходство с редактором vi. Некоторые могут поставить под сомнение разумность шага, заключающегося в расширении самого большого редактора в мире с целью эмулирования другого редактора, характерной чертой которого является компактность. Другие, напротив, считают, что он объединяет в себе лучшее из двух цивилизаций – Emacs и vi.
Компиляторы, языки программирования и средства разработки
[URL 6] The GNU C/C++ Compiler =» www.fsf.org/software/gcc/gcc.html
Один из наиболее популярных в мире компиляторов С и С++. Он также работает с Objective-C. (Во время работы над книгой проект egcs, который вначале отпочковался от gcc. находился в процессе воссоединения с последним.)
[URL 7] The Java Language from Sun
java.sun.com
Домашняя страница Java, включающая загружаемые SDK, документацию, средства обучения, новости и т. д.
[URL 8] Perl Language Home Page
www.perl.com
Эти ресурсы, относящиеся к языку Perl, предоставляются фирмой O'Reilly.
[URL 9] The Python Language
www.python.com
Объектно-ориентированный язык программирования Python является интерпретируемым и интерактивным, обладает хитроумным синтаксисом и большим количеством верных поклонников.
[URL 10) SmallEiffel
SmallEiffel.loria.fr
Компилятор GNU Eiffel работает на любом компьютере, снабженном компилятором ANSI С и средой выполнения Posix.
[URL 11] ISE Eiffel
www.eiffel.com
Фирме Interactive Software Engineering принадлежит авторство программы Design by Contract; она реализует на коммерческой основе компилятор Eiffel и сопутствующие инструментальные средства.
[URL 12] Sather
www.icsi.berkeley.edu/'sather
Sather является экспериментальным языком программирования, ведущим свое происхождение от Eiffel. Его задача – поддерживать функции высшего порядка и итерационной абстракции, а также Common Lisp, CLU или Scheme и быть таким же эффективным, как С, С++ или Fortran.
[URL 13] Visual Works
www.objectshare.com
Основной ресурс для среды VisualWorks Smalltalk. Некоммерческие версии для Windows и Linux распространяются бесплатно.
[URL 14] The Squeak Language Environment
www.squeak.cs.uiuc.edu
Squeak представляет собой бесплатно распространяемую и переносимую реализацию – Sma!ltalk-80, написанную на Squeak; может генерировать код на С для повышения производительности.
[URL 15] The ТОМ Programming Language
www.gerbil.org/tom
Весьма динамичный язык, ведущий свое начало от Objective-С.
[URL 16] The Beowulf Project
www.beowulf.org
Проект посвящен построению высокопроизводительных компьютеров из сетевых кластеров, состоящих из недорогих Linux-блоков.
[URL 17] iContract – Design by Contract Tool For Java
www.reliable-systems.com
Данное инструментальное средство использует формализм предварительных условий, выходных условий и инвариантов, реализовано в виде препроцессора для Java. Использует наследование, реализует кванторы существования и многое другое.
[URL 18] Nana – Logging and Assertions for С and С++
www.cs.ntu.edu.au/homepages/pjm/nana-home/index.html
Улучшенная поддержка проверки утверждений и регистрации в С и С++. Nana также обеспечивает некоторую поддержку для программы Design by Contract.
[URL 19] DDD – Data Display Debugger
www cs.tu-bs.de/softech/ddd
Бесплатный графический интерфейс конечного пользователя для отладчиков Unix.
[URL 20] John Brant's Refactoring Browser
www.cs.uiuc.edu/users/brant/Refactory
Популярный браузер, применяемый при реорганизации (язык Smalltalk).
[URL 21] DOC++ Documentation Generator

www.zib.de/Visual/software/doc++/index.html
DOC++ представляет собой систему документирования для C/C+ + и Java, которая генерирует выходные файлы в форматах LATEX и HTML для просмотра документации непосредственно из заголовка С++ или файлов класса Java.
[URL 22] xUnit – Unit Testing Framework

www.Xprogramming.com
Представляет простую, но мощную концепцию; модуль тестирования структур xUnit является полной платформой для тестирования программного обеспечения, написанного на нескольких языках.
[URL 23] The Tel Language

www.scriptics.com
Язык Tel (Tool Command Language) является языком сценариев, разработанным для упрощения процедуры встраивания в приложение.
[URL 24] Expect – Automate Interaction with Programs
www.expect.nist.gov
Расширение expect, построенное на языке Tel [URL 23], позволяет создавать сценарии взаимодействия с программами. Помимо помощи при составлении командных файлов, которые, например, осуществляют вызов файлов с удаленных серверов или расширяют возможности оболочки, expect приносит пользу и при регрессионном тестировании. Графическая версия expectk позволяет оборачивать приложения пользователя с графическим интерфейсом в оконный интерфейс.
[URL 25] Т Spaces
www.almaden.ibm.com.cs/TSpaces
Цитата с web-страницы: "Т Spaces представляет собой сетевой коммуникационный буфер с функциональными возможностями баз данных. Он осуществляет связь между приложениями и устройствами в сети с гетерогенными компьютерами и операционными системами. Т Spaces обеспечивает следующие средства: коллективной связи, работы с базами данных, переноса файлов (основанные на URL) и оповещения о событиях".
[URL 26] javaCC – Java Compiler-Compiler
www.suntest.com
Генератор грамматического разбора, связанный с языком Java.
[URL 27] The bison Parser Generator
www.gnu.org/software/bison/bison.html
Генератор bison получает на входе описание грамматики и генерирует из него исходный текст соответствующей программы грамматического разбора на языке С.
[URL 28] SWIG – Simplified Wrapper and Interface Generator
www.swig.org
SWIG представляет собой инструментальное средство разработки, стыкующее между собой программы, написанные на языках С, С++ и Objective-C, с языками высокого уровня, такими как Perl, Python, Tcl/Tk, а также Java, Eiffel и Guile.
[URL 29] The Object Management Group, Inc.
www.omg.org
Фирма Object Management Group, Inc. является «распорядителем» различных спецификаций для разработки распределенных объектно-базирующихся систем. К числу работ этой фирмы относятся CORBA (обобщенная архитектура брокера объектных запросов) и ПОР (протокол передачи сообщений между сетевыми объектами через Интернет). Сочетание этих спецификаций дает возможность объектам связываться друг с другом, даже если они написаны на разных языках и выполняются на компьютерах различных типов.
Инструментальные средство UNIX, работающие в среде DOS
[URL 30] The UWIN Development Tools
www.gtlinc.com/Products/Uwin/uwin.html
Фирма Global Technologies, Inc., Old Bridge, NJ
Пакет UWIN предоставляет библиотеки динамической компоновки (DLL) Windows, которые эмулируют большую часть библиотечного интерфейса уровня Unix С. Используя данный интерфейс, фирма Global Technologies, Inc. перенесла большое число инструментальных средств из командной строки Unix в систему Windows. См. также [URL 31].
[URL 31] The Cygnus Cygwin Tools
www.sourceware.cygnus.com/cygwin/
Фирма Cygnus Solutions, Sunnyvale, CA
Пакет Cygnus также эмулирует интерфейс библиотеки Unix С и предоставляет большой набор инструментальных средств, работающих в режиме командной строки Unix, при работе в операционной системе Windows.
[URL 32] Perl Power Tools
www.perl.com/language/ppt/
Данный проект посвящен повторной реализации классического набора команд Unix на языке Perl, что дает возможность их использования при работе со всеми платформами, поддерживающими Perl (их довольно много).
Средствауправленияисходнымтекстомпрограмм
[URL 33] RCS – Revision Control System
www.cyclic.com
Система управления исходным текстом программ GNU для Unix и Windows NT.
[URL 34] CVS – Concurrent Version System
www.cyclic.com
Система управления исходным текстом программ для Unix и Windows NT, распространяемая бесплатно. Расширяет возможности Revision Control System, поддерживая модель «клиент-сервер» и параллельный доступ к файлам.
[URL 35] Aegis Transaction-Based Configuration Management
www.canb.auug.org.au/"mil!erp/aegis.html
Инструментальное средство управления версиями (ориентированное на процесс), которое применяет к ним существующие стандарты проекта (например, проверку прохождения тестов для возвращаемых программных кодов).
[URL 36] ClearCase
www.rational.com
Управление версиями программы, рабочей областью и полной сборкой программы, управление процессом.
[URL 37] MKS Source Integrity
www.mks.com
Управление версиями и конфигурацией. Некоторые версии включают средства, позволяющие удаленным пользователям-разработчикам одновременно работать над одними и теми же файлами.
[URL 38] PVCS Configuration Management
www.merant.com
Система управления исходным текстом программ, очень популярная при работе в Windows.
[URL 39] Visual SourceSafe
www.microsoft.com
Система управления версиями, интегрируемая с инструментами визуальной разработки фирмы Microsoft.
[URL 40] Perforce
www.perforce.com
Менеджер конфигурирования программного обеспечения "клиент-сервер".
Прочие инструментальные средства
[URL 41] Winzip – Archive Utility for Windows
www.winzip.com
Фирма Nico Mak Computing, Inc., Mansfield, CT
Утилита архивирования файлов, работающая в среде Windows. Поддерживает форматы zip и tar.
[URL 42] The Z Shell
www.sunsite.auc.dk/zsh
Оболочка, предназначенная для интерактивной работы и содержащая мощный язык сценариев. В оболочку zsh было включено много полезных средств из оболочек bash, ksh и tcsh и добавлен ряд оригинальных элементов.
[URL 43] A Free SMB Client for Unix Systems
www.samba.anu.edu.au/pub/samba/
Дает возможность совместного использования файлов и других ресурсов из операционных систем Unix и Windows. Samba включает в себя:
• Сервер SMB, предоставляющий средства для работы с файлами и для печати (схожие со средствами, предоставляемыми Windows NT и LAN Manager) клиентам SMB, в роли которых могут выступать Windows 95, Warp Server, smbfs и др.
• Сервер имен Netbios, обеспечивающий, кроме всего прочего, поддержку функций браузера. По желанию пользователя Samba может быть главным браузером в локальной сети.
• Клиент SMB (схожий с клиентом ftp), позволяющий получать доступ к ресурсам ПК(дискам и принтерам) из Unix, Netware и других операционных систем.
Статьи и публикации
[URL 44] The comp.object FAQ
www.cyberdyne-object-sys.com/oofaq2
Солидный, четко организованный список часто задаваемых вопросов по группе новостей comp.object.
[URL 45] extreme Programming
www.Xprogramming.com
Цитата с интернет-сайта: "При создании команды, способной быстро создать исключительно надежное, эффективное, четко структурированное программное обеспечение, в ХР используется весьма легковесное сочетание методик. Многие из методик ХР создавались и опробовались в части проекта СЗ фирмы «Крайслер», представляющего собой весьма успешную систему расчета заработной платы, написанную на языке Smalltalk".
[URL 46] Alistair Cockburn's Home Page
www.members.aol.com/acockburn
Стоит посмотреть раздел "Structuring Use Cases with Goals" и так называемые шаблоны сценариев использования.
[URL 47] Martin Fowler's Home Page
www.ourworld.compuseimcom/homepages/martinjowler
Мартин Фаулер является автором книги "Analysis Patterns" и соавтором книг "UML Distilled" и "Refactoring: Improvingthe Design of Existing Code". На домашней странице автора обсуждаются его книги и работа с UML.
[URL 48] Robert С. Martin's Home Page
www.objectmentor.com/home
Неплохое собрание статей ознакомительного плана по объектно-ориентированным методам, включая анализ зависимости и метрики.
[URL 49] Aspect-Oriented Programming
www.parc.xerox.com/csl/projects/aop/
Описывается методика придания функциональности программному коду с позиций ортогональности и описательности.
[URL 50] JavaSpaces Specifications
www.java.sun.com/products/javaspaces
Linda-подобная система для Java, поддерживающая распределенное сохранение состояния объекта и распределенные алгоритмы.
[URL 51] Netscape Source Code
www.mozilla.org
Исходный текст браузера Netscape.
[URL 52] The Jargon File
www.jargon.org
Eric S. Raymond
Определения дня многих общих (и не очень общих) терминов, применяемых в компьютерной индустрии, сдобренные хорошей дозой соответствующего фольклора.
[URL 53] Eric S. Raymond's Papers
www.tuxedo.org/~esr
Статьи Эрика Раймона "The Cathedral and the Bazaar" и "HomesteadingNoosphere", в которых описаны психосоциальные основы и смысл движения Open Source.
[URL 54] The К Desktop Environment
www.kde.org
Цитата с web-страницы: "KDE представляет собой мощную графическую настольную среду для рабочих станций Unix. KDE является интернет-проектом, открытым в полном смысле этого слова".
[URL 55] The GNU Image Manipulation Program
www.gimp.org
Gimp является бесплатной программой по созданию, композиции и ретушированию изображений.
[URL 56] The Demeter Project
www.ccs.neu.edu/research/demeter
Исследовательский проект, призванный упростить поддержку и развитие программного обеспечения с помощью адаптивного программирования.
Другие источники
[URL 57] The GNU Project
www.gnu.org
Фонд Free Software Foundation, Boston, MA
Фонд "Free Software Foundation" – это некоммерческая благотворительная организация, осуществляющая сбор средств на проект GNU. Целью проекта GNU является создание завершенной, бесплатной UNIX-подобной операционной системы. Многие из попутно разработанных инструментальных средств уже стали отраслевыми стандартами.
[URL 58] Web Server Information
www.netcraft.com/survey/servers.html
Ссылки на домашние страницы, находящиеся более чем на 50 web-серверах. Часть из них является коммерческими продуктами, другие же распространяются бесплатно.
Библиография
[Bak72] F.T. Baker. Chief programmer team management of production programming. IBM Systems Journal, 1 1(1 ):56—73, 1972.
[BBM96] V. Basili, L. Brand, and W.L. Melo. A validation of object-oriented design metrics as quality indicators. IEEE Transactions on Software Engineering, 22(10):751-761, October 1996.
[Ber96] Albert J. Bernstein. Dinosaur Brains: Dealing with All Those Impossible People at Work. Ballantine Books, New York, NY, 1996.
[Bra95] Marshall Brain. Win32 System Services. Prentice Hall, Englewood Cliffs, NJ, 1995.
[Bro95] Frederick P. Brooks, Jr.. The Mythical Man Month: Essays on Software Engineering. Addison -Wesley, Reading, MA, anniversary edition, 1995.
[CG90] N. Carriero and D. Gelenter. How to Write Parallel Programs: A First Course. MIT Press, Cambridge, MA, 1990.
[CN91] Brad J. Cox and Andrex J. Novobilski. Object-Oriented Programming, An Evolutionary Approach. Addison-Wesley, Reading, MA, 1991.
[Coc97a] Alistair Cockburn. Goals and use cases. Journal of Object Oriented Programming, 9(7):35-40, September 1997.
[Coc97b] Alistair Cockburn. Surviving Object-Oriented Projects: A Manager's Guide. Addison Wesley Longman, Reading, MA, 1997.
[Cop92] James O. Coplien. Advanced С++ Programming Styles and Idioms. Addison-Wesley, Reading, MA, 1992.
[DL99] Tom Demarco and Timothy Lister. Peopleware: Productive Projects and Teams, Dorset House, New York, NY, second edition, 1999.
[FBB+99] Martin Fowler, Kent Beck, John Brant, William Opdyke, and Don Roberts. Refactoring: Improving the Design of Existing Code. Addison Wesley Longman, Reading, MA, 1999
[Fow96] Martin Fowler. Analysis Patterns: Reusable Object Models. Addison Wesley Longman, Reading, MA, 1996.
[FS97] Martin Fowler and Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language. Addison Wesley Longman, Reading, MA, 1997.
[GHJV95] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
[Gla99a] Robert L. Glass. Inspections – Some surprising findings. Communications of the ACM, 42(4): 17–19, April 1999.
[Gla99b] Robert L. Glass. The realities of software technology payoffs. Communications of the ACM, 42(2):74–79, February 1999.
[Hol78] Michael Holt. Math Puzzles and Games, Dorset Press, New York, NY, 1978.
[Jac94] Ivar Jacobson. Object-Oriented Software Engineering: A Use-Case Driven Approach. Addison-Wesley, Reading, MA, 1994.
[KLM+97] Gregor Kiczales, John Lamping, AnuragMendhekar, Chris Maeda, Cris-tina Videira Lopes, Jean-Marc Loingtier, and John Irwin. Aspect-oriented programming. In European Conference on Object-Oriented Programming (ECOOP), volume LNCS 1241. Springer-Verlag, June 1997.
[Knu97a] Donald Ervin Knuth. The Art of Computer Programming: Fundamental Algorithms, volume 1. Addison Wesley Longman, Reading, MA, third edition, 1997.
[Knu97b] Donald Ervin Knuth. The Art of Computer Programming: Seminumeri-cal Algorithms, volume 2. Addison Wesley Longman, Reading, MA, third edition, 1997.
[Knu98] Donald Ervin Knuth. The Art of Computer Programming: Sorting and Searching, volume 3. Addison Wesley Longman, Reading, MA, second edition 1998.
[KP99] Brian W. Kernighan and Rob Pike. The Practice of Programming. Addison Wesley Longman, Reading, MA, 1999.
[Kru98] Philippe Kruchten. The Rational Unified Process: An Introduction. Addison Wesley Longman, Reading, MA, 1998.
[Lak96] John Lakos. Large-Scale С++Software Design. Addison Wesley Longman, Reading, MA, 1996.
[LH89] Karl J. Lieberherr and Ian Holland. Assuring good style for object-oriented programs. IEEE Software, pages 38–48, September 1989.
[Lis88] Barbara Liskov. Data abstraction and hierarchy. SIGPLAN Notices, 23(5), May 1988.
[LMB92] John R. Levine, Tony Mason, and Doug Brown. Lex and Yacc. O'Reilly & Associates, Inc., Sebastopol, CA, second edition, 1992.
[McC95] Jim McCarthy. Dynamics of Software Development. Microsoft Press, Redmond, WA, 1995.
[Mey96] Scott Meyers. More Effective С++: 35 New Ways to Improve Your Programs and Designs. Addison-Wesley, Reading, MA, 1996.
[Mey97a] Scott Meyers. Effective С++: 50 Specific Ways to Improve Your Programs and Designs. Addison Wesley Longman, Reading, MA, 1997.
[Mey97b] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, Englewood Cliffs, NJ, second edition, 1997.
[Pet 98] Charles Petzold. Programming Windows, The Definitive Guide to the Win32 API. Microsoft Press, Redmond, WA, fifth edition, 1998.
[Sch95] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley & Sons, New York, NY, 1995.
[Sed83] Robert Sedgewick. Algorithms. Addison-Wesley, Reading, MA, 1983.
[Sed 92] Robert Sedgewick. Algorithms in С++. Addison-Wesley, Reading, MA, 1992.
[SF96] Robert Sedgewick and Phillipc Flajolet. An Introduction to the Analysis of Algorithms. Addison-Wesley, Reading, MA, 1996.
[Ste92] W. Richard Stevens. Advanced Programming in the Unix Environment. Addison-Wesley, Reading, MA, 1992.
[Ste98] W. Richard Stevens. Unix Network Programming, Volume I: Networking APIs: Sockets andXti. Prentice Hall, Englewood Cliffs, NJ, 1998.
[Ste99] W. Richard Stevens. Unix Network Programming, Volume 2: Interprocess Communications. Prentice Hall, Englewood Cliffs, NJ, second edition, 1999.
[Str35] James Ridley Stroop. Studies of interference in serial verbal reactions. Journal of Experimental Psychology, 18:643–662, 1935.
[WK82] James Q. Wilson and George Kelling. The police and neighborhood safety. The Atlantic Monthly, 249(3):29–38, March 1982.
[YC86] Edward Yourdon and Larry L. Constantine. Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design. Prentice Hall, Englewood Cliffs, NJ, second edition, 1986.
[You95] Edward Yourdon. Managing projects to produce good-enough software. IEEE Software, March 1995.
Приложение В
Ответы к упражнениям
Упражнение 1 из раздела "Ортогональность"
Ответ: По нашему разумению, более ортогональным является класс Split2. Он сосредоточен на собственной задаче – расщеплении строк и игнорирует подробности, связанные с источником обрабатываемых им строк. Это не только упрощает разработку программы, но и придает ей большую гибкость. Класс Split2 может расщеплять строки, считываемые из файла, сгенерированные другой программой или передаваемые через операционную среду.
Упражнение 2 из раздела "Ортогональность"
Ответ: Если все сделано корректно, то, по всей вероятности, немодальное. Система, которая использует немодальные диалоговые окна, испытывает меньшее беспокойство о том, что происходит в любой конкретный момент времени. Скорее всего, она будет обладать лучшей инфрастуктурой взаимодействия между модулями по сравнению с модальной системой, которая может содержать встроенные предположения о состоянии системы – предположения, которые могут привести к большему связыванию и уменьшению ортогональности.
Упражнение 3 из раздела "Ортогональность"
Ответ: Здесь есть элемент лукавства. Объектная технология может обеспечить наличие более ортогональной системы, но поскольку она имеет больше средств, которые могут эксплуатироваться с нарушением режима, в реальности легче создать неортогональную систему, используя объекты, чем создавать ее при помощи процедурного языка. Ее особенности – множественное наследование, исключительные ситуации, перегрузка операторов и переопределение родительского метода (через механизм подклассов) – предоставляют достаточные возможности для увеличения связанности не столь очевидными способами.
Применяя объектную технологию и приложив небольшое дополнительное усилие, вы можете добиться наличия более ортогональной системы. И хотя вы всегда можете написать неструктурированную программу на процедурном языке, объектно-ориентированные языки, используемые в малых дозах, могут сделать ее более насыщенной.
Упражнение 4 из раздела "Прототипы и памятные записки"
Ответ: Для спасения ситуации прибегнем к устаревшим технологиям! Нарисуйте на лекционной доске несколько картинок – автомобиль, телефон и дом – с помощью фломастера. Для этого не нужно быть великим художником, вполне достаточно условных изображений. Поместите на доску памятные записки, описывающие содержимое целевых страниц в активных областях экрана. В ходе встречи вы можете совершенствовать рисунки и менять расположение памятных записок.
Упражнение 5 из раздела "Языки, отражающие специфику предметной области"
Ответ: Поскольку мы хотим, чтобы язык был расширяемым, сделаем таблицу синтаксического анализатора управляемой. Каждый элемент таблицы содержит символ команды, флаг, говорящий о необходимости аргумента, и имя подпрограммы, вызываемой для обработки этой конкретной команды.
typedef struct {
char cmd; /* the command letter */
int hasArg; /* does it take an argument */
void (*func)(int, int); /* routine to call */
} Command;
static Command cmds[] = {
{'P', ARG, doSelectPen},
('V', NO_ARG, doPenUp},
{'D', NO_ARG, doPenDown},
{'N,' ARG, doPenDir},
{'E', ARG, doPenDir},
{'S', ARG, doPenDir},
{'W', ARG, doPenDir}
};
Основная программа довольно проста: считать строку, отыскать команду, при необходимости принять аргумент, затем вызвать функцию обработчика.
while (fgetsfbuff, sizeof(buff), stdin)) {
Command *cmd = findCommand(*buff);
if (cmd) {
int arg = 0;
if (cmd->hasAr&& !getArg(buff+1, &arg)) {
fprintf(stderr,"'%с' needs an argument\n", *buff);
continue;
}
cmd->func(*buff, arg);
}
}
Функция, которая ищет команду, исполняет последовательный перебор таблицы, возвращая либо совпадающий элемент, либо NULL.
Command *findCommand(int cmd) {
int i;
for (i = 0; i if (cmds[i].cmd==cmd)
return cmds + i;
}
fprintf(stderr, "Unknown command %c'\n", cmd);
return 0;
}
И наконец, считывание числового аргумента довольно просто, если использовать подпрограмму sscanf.
int getArg(const char *buff, int 'result) {
return sscanf(buff, "%d", result) == 1;
}
Упражнение 6 из раздела "Языки, отражающие специфику предметной области"
Ответ 6: При использовании BNF спецификация времени могла бы выглядеть следующим образом:
::= |
: |
:
::= am|pm
::= |
::=
::=
::= 0|1|2|3|4|5|6|7|8|9
Упражнение 7 из раздела "Языки, отражающие специфику предметной области"
Ответ: В нашем примере мы составили программу, используя генератор bison, который представляет собой GNU-версию генератора уасс. Для ясности здесь показано только тело программы синтаксического анализатора. Полная версия есть на сайте www.pragmaticprogrammmer.com.
time: spec EOF
{ if ($1>= 24*60) yyerror("Time is too large");
printf("%d minutes past midnight\n", $1);
exit(0);
}
;
spec: hour ':' minute
{ $$ = $1 + $3;
}
| hour ':' minute ampm
{ if ($1>11*60) yyerrorf "Hour out of range");
$$ = $1 + $3 + $4;
}
| hour ampm
{if ($1>11*60) yyerror("Hour out of range");
$$ = $1 + $2;
}
;
hour: hour_num
{if ($1>23) yyerror("Hour out of range");
$$ = $1 * 60;
};
minute: DIGIT DIGIT
{$$ = $1*10 + $2;
if ($$> 59) yyerrorf "minute out of range") ,
};
ampm: AM {$$ = AM_MINS;}
| PM {$$ = PM_MINS;)
;
hour num: DIGIT {$$ = $1;)
| DIGIT DIGIT {$$ = $1*10 + $2;}
;
Упражнение 8 из раздела "Языки, отражающие специфику предметной области"
Ответ:
$_ = shift;
/"(\d\d?)(am|pm)$/ && doTime($1, 0, $2, 12);
/"(\d\d?):(\d\d)(am|pm)$/ && doTime($1, $2, $3, 12);
/"(\d\d?):(\d\d)$/ && doTime($1, $2, 0, 24);
die "Invalid time $_\n";
#
# doTime(hour, min, ampm, maxHour)
#
sub doTime($$$$) {
my ($hour, $min, $offset, $maxHour) = @_;
die "Invalid hour: $hour" if ($hour>= $maxHour);
$hour += 12 if ($offset eq "pm")
print $hour*60 + $min, " minutes past midnight\n";
exit(0);
}
Упражнение 9: из раздела "Оценка"
Ответ: Ответ должен быть изложен, исходя из нескольких допущений:
• Лента содержит информацию, которую необходимо передать.
• Известна скорость ходьбы человека.
• Известно расстояние между компьютерами.
• Временем, необходимым для переноса информации на ленту и с ленты, можно пренебречь.
• Потери данных при хранении на ленте примерно равны их потерям при передаче по каналу связи.
Упражнение 10 из раздела "Оценка"
Ответ: Учитывая допущения ответа 9: Объем информации, содержащейся на стриммерной кассете (4 Гбайт), составляет 32 х 10^9 бит, так что передача эквивалентного объема по каналу со скоростью 1 Мбайт/с заняла бы около 32000 сек. (примерно 9 ч). Если человек движется с постоянной скоростью 3,5 мили в час, то, для того чтобы канал связи превзошел курьера, два компьютера должны располагаться друг от друга на расстоянии не менее 31 мили. Если это расстояние меньше, то победа остается за человеком.
Упражнение 11 из раздела "Обработка текста"
Ответ: Ответ к данному упражнению составлен на языке Perl.
my @consts;
my $name = <>;
die "Invalid format – missing name" unless defined($name);
chomp $name;
# Read in the rest of the file
while (<>) {
chomp;
s/"\s*//; s/\s*$//;
die "Invalid line: $_" unless /"(\w+)$/;
push @consts, $_;
}
# Now generate the file
open(HDR, ">$name.h") or die "Can't open $name.h: $!";
open(SRC, ">$name.c") or die "Can't open $name.c: $!";
my $uc_name = uc($name);
print HDR "/* File generated automatically – do not edit */\n";
print HDR "extern const char *$ {ucjiame)_name[];";
print HDR "typedef enum {\n"; print HDR join",\n", @consts;
print HDR "\n) $uc_name;\n\n";
print SRC "* File generated automatically – do not edit */\n";
print SRC "const char *$ {uc name}_name[] = {\n \"";
print SRC join "\",\n \"", @consts;
print SRC "\"\n};\n";
close(SRC);
close(HDR);
Используя принцип DRY, мы не будет вырезать и вклеивать этот вновь написанный файл в нашу программу. Вместо этого мы «включим» его – данный плоский файл является главным источником этих констант. Поэтому нам понадобится файл сборки для восстановления заголовка при изменении файла. Следующий фрагмент содержится в системе отладки в исходном дереве (имеется на web-сайте).
etest.c etest.h: etest.inc enumerated.pl
perl enumerated.pl etest.inc
Упражнение 12 из раздела "Обработка текста"
Ответ: Вот ответ, написанный на языке Perl.
my $dir = shift or die "Missing directory" ,
for my Sfile (glob(u$dir/*.pr)) {
open(IP, "$file") or die "Opening $file: $!";
undef $/; # Turn off input record separator
my Scontent = ; # read whole file as one string.
close(IP);
if (Scontent Гrusestrict/m) {
rename Sfile, "$file.bak" or die "Renaming $file: $!"; open(OP, ">$file") or die "Creating $file: $!";
# Put 'use strict' on first line that
# doesn't start #
Scontent =" sr(V.#)/\nuse strict;\n\n/m',
print OP Scontent; close(OP);
print "Updated $file\n";
)
else {
print "Sfile already strict\n":
)
}
Упражнение 13 из раздела "Генераторы исходных текстов"
Ответ: Решение реализовано на языке Perl. В программе происходит динамическая загрузка модуля для генерации требуемого языка, так что добавление новых языков не представляет труда. Главная программа загружает внутреннюю часть (основанную на параметре командной строки), затем считывает ее входные данные и вызывает подпрограммы генерации текста, основанные на содержимом каждой из строк. Мы особенно не суетимся, если речь идет об обработке ошибок: если что-то не так, узнаем об этом довольно быстро.
my lang = shift or die "Missing language";
$lang .= "_cg.pm";
require <$lang> or die "Couldn't load $lang";
# Read and parse the file
my $name;
while (<>) {
chomp;
if (/^ \s*$/) {CG::blankLine();)
elsif ((/^ \#(.*)/) {CG::comment($1);}
elsif ((/^M\s*(.+)/) {CG::startMsg($1); $name = $1;}
elsif ((/^E/) {CG::endMsg($name);}
elsif (/^F\s*(\w+)\s+(\w+)$/) {CG::simpleType($1,$2);}
elsif (/^F\s*(\w+)\s+(\w+)\[(\d+)\]$/) {CG::arrayType $1,$2,$3);}
else {
die "Invalid line: $ ";
}
}
Написание языковой серверной части не составит труда: создайте модуль, который реализует шесть точек входа. Вот генератор текста на языке С:
#!/usr/bin/perl – w
package CG;
use strict;
# Code generator for 'C' (see cg_base.pl)
sub blankLine() {print "\n"; }
sub comment() {print "/*$_[0] */\n"; }
sub startMsg() {print "typedef struct {\n"; }
sub endMsg() {print "} $_[0];\n\n"; }
sub arrayType() {
my ($name, $type, $size) = @_;
print " $type $name\[$size];\n":
}
sub simpleType{) {
my ($name, $type) = @_;
print " $type $пате;\п";
}
1;
А вот генератор текста на языке Pascal:
#!/usr/bin/perl – w
package CG;
use strict;
# Code generator for 'Pascal' (see cg_base.pl)
sub blankLine() {print "V;)
sub comment() {print "{$_[0] }\n";)
sub startMsg() {print "$_[0] = packed record\n"; }
sub endMsg() {print "end;\n\n"; }
sub arrayType() {
my ($name, $type, $size) = @_;
$size--;
print" $name: array[0…$size] of $type;\n";
)
sub simpleType() {
my ($name, $type) = @_;
print" $name: $type;\n7 ',
}
1;
Упражнение 14 из раздела "Проектирование по контракту"
Ответ: Этот пример на языке Eiffel удачен. Мы требуем передачи непустых данных и гарантируем, что семантика циклического двунаправленного списка будет соблюдена. Это также способствует нахождению сохраненной строки. Поскольку это некий отложенный класс, то действительный класс, его реализующий, допускает использование любого основного механизма по своему усмотрению. Он может использовать указатели или массив, или что-то еще; пока он соблюдает контракт, мы не беспокоимся.
Упражнение 15 из раздела "Проектирование по контракту"
Ответ: Это неудачно. Математическое действие в индексном выражении (index-1) не будет работать с граничными условиями, подобными первой точке входа. Постусловие предполагает определенную реализацию; контракты должны быть более абстрактными по сравнению с указанным выше.
Упражнение 16 из раздела "Проектирование по контракту"
Ответ 16: Это удачный контракт, но неудачная реализация. Здесь высовывает свою уродливую голову ошибка типа "Heisenbug" [URL52]. Вероятно, программист допустил опечатку – набрал pop вместо top. Хотя это простой и надуманный пример, весьма трудно диагностировать побочные эффекты в утверждениях (или в любом, самом неожиданном месте в программе).
Упражнение 17 из раздела "Проектирование по контракту"
Ответ: Мы продемонстрируем функциональные сигнатуры на языке Java, обозначая предусловия и постусловия в соответствии с iContract. Сначала инвариант для класса:
/**
* @invariant getSpeed() >0
* implies isFull() // Не запускать пустое
* @invariant getSpeed()>=0 &&
* getSpeed() <10 // Проверка границ
*/
Затем предусловия и постусловия:
/**
* @pre Math.abs(getSpeed() – х) <= 1 // Единственный выбор
* @рге х>= 0 && х > 10 // Проверка границ
* @post getSpeed() == х // Проверка скорости
*/
public void setSpeed (final int x)
/**
* @pre !isFull() // Heзаполнять дважды
* @post isFull() // Убедитесь, что было выполнено
*/
void fill()
/**
* @pre isFull() // He очищатьдважды
* @post !isFull() // Убедиться, что выполнено
*/
void empty()
Упражнение 18 из раздела "Проектирование по контракту"
Ответ: В этом ряду содержится 21 число. Если вы ответили «20», то допустили так называемую ошибку "поста охраны".
Упражнение 19 из раздела "Программирование утверждений"
Ответ:
1. В сентябре 1752 г. было всего лишь 19 дней. Это было сделано с целью синхронизации при переходе с юлианского на григорианский календарь.
2. Каталог мог быть удален другим процессом, у вас нет прав доступа на его чтение, выражение &sb может быть недопустимым – вы все уловили.
3. Мы проявили малодушие, не указав типов а и b. Во время перегрузки операторов могло случиться так, что поведение знаков +, =, или != стало непредсказуемым. Кроме того, а и b могут быть псевдонимами одной и той же переменной, так что при втором присвоении произойдет перезапись значения, сохраненного во время первого.
4. В неевклидовой геометрии сумма углов треугольника не будет составлять 180°. Подумайте о треугольнике, отображаемом на поверхности сферы.
5. Минуты, приходящиеся на високосный год, могут состоять из 61 или 62 секунд.
6. Переполнение может оставить результат операции а+1 отрицательным (это также может произойти в языках С и С++).
Упражнение 20 из раздела "Программирование утверждений"
Ответ: Мы решили реализовать очень простой класс с единственным статическим методом TEST, который выводит на печать сообщение и след стека, если переданный параметр condition является ложным.
package com.pragprog.util;
import java.lang.System; //для exit()
import java.lang.Thread; //для dumpStack()
public class Assert {
/** Write a message, print a stack trace and exit if
* our parameter is false.
*/
public static void TEST(boolean condition) {
if (Icondition) {
System.out.println("==Assertion Failed==");
Thread.dumpStack();
System.exit(1);
}
}
// Testbed. If our argument is 'okay', try an assertion that
// succeeds, if 'fail' try one that fails
public static final void main(String args[]) {
if (args[0].compareTo("okay") == 0) {
TEST(1 == 1);
}
else if (args[0].compareTo("fail") == 0) {
TEST(1 == 2);
}
else {
throw new RuntimeException("Bad argument") ,
}
}
}
Упражнение 21 из раздела "Случаи, когда используются исключения"
Ответ: Нехватка памяти является исключительным состоянием, поэтому мы полагаем, что в случае (1) должно возбуждаться исключение.
Невозможность отыскания точки входа – вполне нормальная ситуация. Приложение, которое вызывает наш класс-набор, может написать программу, которая проверяет наличие точки входа, перед тем как добавить потенциальный дубликат. Мы полагаем, что в случае (2) нужно просто осуществить возврат ошибки.
Случай (3) более проблематичен – если указатель null играет существенную роль в приложении, его добавление к контейнеру может быть оправдано. Но если для хранения пустых значений нет веских оснований, то, по всей вероятности, необходимо возбудить исключительную ситуацию.
Упражнение 22 из раздела "Балансировка ресурсов"
Ответ: В большинстве реализаций языков С и С++ отсутствуют способы проверки того, что указатель действительно указывает на допустимый блок памяти. Обычная ошибка состоит в освобождении блока памяти и организации ссылки на этот блок далее в тексте программы. К тому времени этот блок памяти уже может быть перераспределен для других целей. Обнуляя указатель, программисты надеются предотвращать эти инородные ссылки – в большинстве случаев разыменование указателя null генерирует ошибку в ходе выполнения программы.
Упражнение 23 из раздела "Балансировка ресурсов"
Ответ: Обнуляя ссылку, вы уменьшаете число указателей на упомянутый объект на единицу. Как только этот счетчик становится равным нулю, объект получает право на сбор «мусора». Обнуление ссылок может играть существенную роль в продолжительных по времени программах, где программистам приходиться удостоверяться, что использование памяти со временем не возрастает.
Упражнение 24 из раздела "Несвязанность и закон Деметера"
Ответ: Файл заголовка предназначен для определения интерфейса между соответствующей реализацией и внешним миром. Сам по себе файл заголовка не обязан обладать информацией о внутренней организации класса Date – от него лишь требуется сообщить компилятору о том, что конструктор принимает класс Date в качестве параметра. Поэтому, если файл заголовка не использует Dates в подставляемых функциях, второй фрагмент будет работать просто замечательно.
А что же с первым фрагментом? Если он используется в небольшом проекте, то все нормально, за исключением того, что вы без особой надобности заставляете все элементы программы, которые используют класс Person1, также включать файл заголовка для класса Date. Как только подобное употребление становится обычной практикой в неком проекте, вскоре обнаружите, что включение одного файла заголовка заканчивается включением большей части системы, что существенно увеличивает время компиляции.
Упражнение 25 из раздела "Несвязанность и закон Деметера"
Ответ: Переменная acct передается в виде параметра, так что вызов getBalance является допустимым. Вызов amt.printFormat() таковым не является. Мы не «владеем» amt, и он не был передан нам. Мы могли устранить связывание showBalance с Money при помощи вставки, подобной представленной ниже:
void showBalance(BankAccount b) {
b.printBalance();
}
Упражнение 26 из раздела "Несвязанность и закон Деметера"
Ответ: Поскольку класс Colada создает и владеет myBlender и myStuff, то обращения к addlngredients и elements являются допустимыми.
Упражнение 27 из раздела "Несвязанность и закон Деметера"
Ответ: В этом случае processTransaction владеет amt – он создается на стеке. Происходит передача acct, поэтому допустимыми являются как setValue, так и setBalance. Но processTransaction не владеет who, поэтому вызов who->name() является нарушением. Закон Деметера предлагает заменить эту строку на следующую:
markWorkflow(acct.name (), SET_BALANCE);
Программе в processTransaction не придется узнавать, какой дочерний объект в пределах BankAccount носит это имя – эта информация о структуре не должна разглашаться через контракт BankAccount. Вместо этого мы запрашиваем у BankAccount имя на счете. Он знает, где хранится имя (может быть, в объекте Person, в объекте Business, или в полиморфном объекте Customer).
Упражнение 28 из раздела "Метапрограммирование"
Ответ: Здесь не приводятся категорические ответы – вопросы предназначались в основном для того, чтобы дать вам пищу для размышлений. И вот что мы думаем:
1. Назначения коммуникационного порта. Ясно, что эта информация должна сохраняться в виде метаданных. Но на каком уровне детализации? Некоторые коммуникационные программы системы Windows позволяют выбирать только скорость в бодах и порт (скажем, СОМ1 – COM4). Но вероятно вам придется указать размер слова, четность, стоповые биты, и настройку дуплексной связи. Старайтесь допускать самый мелкий уровень детализации, там где это разумно с практической точки зрения.
2. Поддержка выделения синтаксических конструкций различных языков в программе редактирования. Она должна быть реализована в виде метаданных. Вы же не хотите, чтобы вам пришлось переделывать программу только потому, что в последней версии языка Java было введено новое ключевое слово.
3. Поддержка редактора для различных графических устройств. Эту поддержку было бы трудно реализовать исключительно в виде метаданных. Вам не хотелось бы нагружать приложение многими драйверами устройств только для того, чтобы выбрать один из них во время выполнения программы. Однако вы могли воспользоваться метаданными для указания имени драйвера и динамической загрузки программы. Это еще один аргумент для сохранении метаданных в удобочитаемом формате; если вы используете программу для установки дисфункционального видеодрайвера, то вы не сможете переустановить его, пользуясь этой программой.
4. Конечный автомат для программы синтаксического анализа или сканера.
Это зависит от того, анализируете вы или просматриваете. Если анализируете некоторые данные, которые жестко определены в стандартах и скорее всего не будут изменены без одобрения конгресса США, то жесткое кодирование вполне годится. Но если вы сталкиваетесь с более изменчивой ситуацией, то может быть, более выгодным является внешнее определение таблиц состояний.
5. Типовые значения и результаты, используемые в модульном тестировании.
Большинство приложений определяет эти значения как встроенные в тестовый стенд, но вы можете добиться большей гибкости, перемещая тестовые данные и определение приемлемых результатов за пределы самой программы.
Упражнение 29 из раздела "Всего лишь представление"
Ответ: В программу Flight мы добавим ряд дополнительных методов душ поддержания двух списков «слушателей»: для уведомления о листе ожидания и о полной загрузке рейса.
public interface Passenger {
public void waitListAvailable();
}
public interface Flight {
...
public void addWaitListListener(Passenger p);
public void removeWaitUstUstener(Passenger p);
public void addFullListener(FullListener b);
public void removeFullListener(FullListener b);
...
}
public interface BigReport extends FullListener {
public void FlightFullAlert(Flight f);
}
При неудачной попытке добавить Passenger, поскольку рейс полностью забронирован, мы можем (как вариант) поместить Passenger в лист ожидания. При открытии вакансии производится вызов метода waitListAvailable. Затем этот метод может осуществить выбор: либо добавить Passenger автоматически, либо дать указание сотруднику авиакомпании позвонить заказчику и выяснить, заинтересован ли он еще в рейсе, и т. п. Теперь мы обладаем достаточной гибкостью, чтобы избрать линию поведения, исходя из пожеланий клиента.
Кроме того, мы хотим избежать ситуаций, при которых BigReport разбирает тонны записей, отыскивая полностью забронированные рейсы. Зарегистрировав BigReport в качестве «слушателя» Flights, каждый индивидуальный Flight может сообщать, когда он полностью (или почти полностью) забронирован. Теперь пользователи могут мгновенно получить оперативные, с точностью до минуты, сообщения из BigReport, а не ожидать часами окончания его работы, как это было раньше.
Упражнение 30 из раздела "Доски объявлений"
Ответ:
1.
Обработка изображения.Для простого распределения рабочей нагрузки между параллельными процессами более чем адекватной может оказаться общедоступная очередь работ. Вы можете рассмотреть систему "доска объявлений" при наличии обратной связи, т. е. если результаты обработки одного фрагмента изображения влияют на другие фрагменты так, как это происходит в системах искусственного зрения или сложных трехмерных преобразованиях изображений.
2.
Календарное планирование для групп.Для этого "доска объявлений" очень даже пригодится. Вы можете поместить назначенные собрания и готовность на "доску объявлений". Есть объекты, функционирующие автономно; в данном случае очень важна обратная связь, а участники могут приходить и уходить.
Можно рассмотреть возможность разделения "доски объявлений" в зависимости от того, кто осуществляет поиск: младший персонал может заботиться только о локальном офисе, отдел кадров интересоваться только англо-говорящими офисами во всем мире, а исполнительный директор – всем сразу.
В форматах данных имеется некий элемент гибкости: мы можем проигнорировать форматы или языки, которых не понимаем. Нам придется понимать различные форматы только для тех офисов, которые встречаются друг с другом, и не придется подвергать всех участников полному транзитивному замыканию всевозможных форматов. При этом связанность уменьшается там, где нужно, и мы не имеем искусственных ограничений.
3.
Средство мониторинга компьютерной сети.Это весьма сходно с программой обработки заявлений на ипотечный кредит/ссуду, описанной в примере приложения (с. 153). На доску помещаются сообщения о неисправностях, присылаемые пользователями, и автоматические генерируемые статистические данные. Сотрудник (или программный агент) может анализировать "доску объявлений", чтобы осуществлять диагностику неисправностей в сети: две ошибки в линии могут быть отнесены на счет космических лучей, но 20000 ошибок говорят о проблеме в аппаратном обеспечении. Подобно детективам, разгадывающим тайну убийства, вы можете использовать множественные объекты, анализируя и внося свою лепту в решение проблем, связанных с компьютерной сетью.
Упражнение 31 из раздела "Программирование в расчете на стечение обстоятельств"
Ответ: Эта программа представляет ряд потенциальных проблем. Во-первых, она предлагает наличие текстовой среды. Это, может быть, и прекрасно, если предположение истинно, но что, если эта программа вызывается из графической среды, где не открыты ни stderr, ни stdin?
Во-вторых, есть проблематичный оператор gets, который будет записывать столько символов, сколько он получит в переданный буфер. Злонамеренные пользователи использовали это, когда им не удавалось проделать бреши типа buffer overrun в защите многих различных систем. Никогда не пользуйтесь gets().
В-третьих, программа предполагает, что пользователь понимает английский язык.
И наконец, никто, находясь в здравом уме, не станет прятать средство взаимодействия с пользователем в недра библиотечной подпрограммы.
Упражнение 32 из раздела "Программирование в расчете на стечение обстоятельств"
Ответ: Работа программы strcpy в системе POSIX не гарантируется при наличии перекрывающихся строк. С некоторыми архитектурами она, случается, и работает, но лишь при стечении определенных обстоятельств.
Упражнение 33 из раздела "Программирование в расчете на стечение обстоятельств"
Ответ: Она не будет работать в контексте апплета при наличии ограничений доступа по записи на локальный диск. Если вы можете выбирать, работать ли через графический интерфейс или нет, то, вероятно, захотите осуществить динамический анализ текущей среды. В этом случае вы наверняка захотите поместить файл журнала вне локального диска, если к нему нет доступа.
Упражнение 34 из раздела "Скорость алгоритма"
Ответ: Ясно, что мы не можем давать никаких абсолютных ответов к этому упражнению. Однако можем дать вам пару намеков.
Если ваши результаты не ложатся на гладкую кривую, то вы захотите проверить, не используется ли мощность вашего процессора каким-либо другим процессом. По всей вероятности, вы не получите хороших показателей в многопользовательской системе, и даже если окажетесь единственным пользователем, можете заметить, что фоновые процессы периодически отбирают циклы у ваших программ. Вы также можете захотеть проверить использование памяти: если приложение начинает использовать область свопинга, то производительность резко снижается.
Интересно поэкспериментировать с различными компиляторами и установочными параметрами оптимизации. Мы обнаружили, что весьма впечатляющее ускорение стало возможно, благодаря использованию агрессивной оптимизации. Мы также обнаружили, что на более распространенных архитектурах типа RISC компиляторы фирмы изготовителя часто превосходили по быстродействию более переносимую GCC. Возможно, изготовитель посвящен в тайны эффективной генерации программ на этих машинах.
Упражнение 35 из раздела "Скорость алгоритма"
Ответ: Программа printTree использует приблизительно 1000 байт стекового пространства для буферной переменной. Для движения вниз по древовидной схеме она рекурсивно вызывает саму себя, и каждый вложенный вызов добавляет еще 1000 байт к стеку. Она также вызывает саму себя, когда добирается до вершин, но заканчивает работу сразу, как только обнаружит, что переданный указатель обнулен. Если глубина дерева равна D, то максимальный объем, необходимый стеку, составляет (грубо) 1000 x(D+ 1).
Сбалансированное двоичное дерево содержит вдвое больше элементов на каждом уровне. Дерево глубиной D содержит 1+2+4+8 +… +2^(D-1), или 2^D – 1 элементов. Следовательно, дереву, состоящему из миллиона элементов, будет необходимо [lg(1000001], или 20 уровней.
Поэтому мы рассчитываем, что наша подпрограмма будет использовать примерно 21000 байт стекового пространства.
Упражнение 36 из раздела "Скорость алгоритма"
Ответ: На ум приходит несколько процедур оптимизации. Программа printTree вызывает саму себя на вершинах дерева лишь для того, чтобы закончить работу при отсутствии потомков. Этот вызов увеличивает максимальную глубину стека примерно на 1000 байт. Можно также исключить рекурсию хвоста (второй рекурсивный вызов), хотя это и не будет затрагивать использование стека в наихудшем случае.
while (node) {
if (node->left) printTree(node->left);
getNodeAsString(node, buffer);
puts(buffer);
node = node->right;
}
Но самая большая выгода возникает при назначении одного-единственного буфера, доступ к которому осуществляется при всех обращениях к printTree. Если передать этот буфер в виде параметра для рекурсивных обращений, то будет назначено всего 1000 байт вне зависимости от глубины рекурсии.
void printTreePrivate(const Node *node, char *buffer) {
if (node) {
printTreePrivate(node->!eft, buffer);
getNodeAsStringfnode, buffer);
puts(buffer);
printTreePrivate(node->right, buffer);
}
}
void newPrintTree(const Node *node) {
char buffer[1000];
printTreePrivate(node, buffer);
)
Упражнение 37 из раздела "Скорость алгоритма"
Ответ: Это можно сделать двумя путями. Один из них заключается в том, чтобы перевернуть проблему с ног на голову. Если в массиве есть лишь один элемент, мы не осуществляем итерации в цикле. Каждая дополнительная итерация удваивает размер массива, в котором можно осуществлять поиск. Отсюда общая формула размера массива: n = 2^m, где m – число итераций. Если прологарифмировать обе части с основанием 2, получим выражение lg(n) = lg(2^m), которое из определения логарифма превращается в lg(n) =m.
Упражнение 38 из раздела "Реорганизация"
Ответ: Здесь мы могли бы предложить весьма умеренную реструктуризацию: убедитесь, что каждый тест выполняется лишь один раз, и сделайте все вычисления стандартными. Если выражение 2*basis (…)* 1.05 появляется в других местах программы, то, вероятно, его стоит сделать функцией. В данном случае мы этого делать не стали.
Мы добавили массив rate_lookup, инициализированный таким образом, что элементам, отличным от Texas, Ohio и Maine, присвоено значение 1. Этот подход облегчает добавление значений для других штатов в будущем. В зависимости от ожидаемой схемы использования мы могли бы сделать поле points также средством поиска в массиве.
rate = rate_lookup[state];
amt = base * rate;
calc = 2*basis(amt) + extra(amt)*1.05;
if (state == OHIO)
points = 2;
Упражнение 39 из раздела "Реорганизация"
Ответ: Когда вы видите, что кто-либо использует перечислимые типы (или эквивалентные им в языке Java), для того чтобы провести различие между вариантами некоего типа, во многих случаях вы можете улучшить программу за счет создания подклассов:
public class Shape {
private double size;
public Shape(double size) {
this.size = size;
}
public double getSize() {return size;)
}
public class Square extends Shape {
public Square(double size) {
super(size);
}
public double area() {
double size = getSize();
return size*size;
}
)
public class Circle extends Shape {
public Circle(double size) {
super(size);
}
public double area() {
double size = getSize();
return Math.PI*size*size/4.0;
}
}
// efc…
Упражнение 40 из раздела "Реорганизация"
Ответ: Этот случай интересен. На первый взгляд, кажется разумным, что у окна должна быть ширина и высота. Однако стоит подумать о будущем. Представим, что мы хотим обеспечить поддержку окон произвольной формы (что будет весьма трудно, если класс Window обладает всей информацией о прямоугольниках и их свойствах).
Мы бы предложили абстрагировать форму окна из самого класса Window.
public abstract class Shape {
//...
public abstract boolean overlaps (Shape s);
public abstract int getArea();
}
public class Window {
private Shape shape;
public Window(Shape shape) {
this.shape = shape;
...
}
public void setShape(Shape shape) {
this.shape = shape;
...
}
public boolean overlaps(Window w) {
return shape.overlaps(w.shape);
}
public int getArea() {
return shape.getArea();
}
}
Заметим, что в этом подходе мы предпочли делегирование созданию подклассов: окно не является «разновидностью» формы – окно «имеет» форму. Оно использует форму для выполнения своей работы. Вы убедитесь, что во многих случаях делегирование оказывается полезным для реорганизации.
Мы могли бы расширить этот пример, внедрив интерфейс Java, указывающий на методы, которые должны поддерживаться неким классом для поддержания функций формы. Эта удачная идея означает, что, когда вы расширяете принцип формы, компилятор предупредит вас о классах, которые вы затронули. Мы рекомендуем использовать интерфейсы подобным способом при делегировании всех функций какого-либо другого класса.
Упражнение 41 из раздела "Программа, которую легко тестировать"
Ответ: Вначале добавим подпрограмму main, которая будет действовать как ведущий элемент модульного тестирования. В качестве аргумента она примет простой мини-язык: <Е> будет означать опорожнение блендера, – его наполнение, цифры 0–9 будут задавать скорость вращения ротора, и т. д.
public static void main(String args[]) {
// Create the blender to test
dbc_ex blender = new dbc_ex();
// And test it according to the string on standard input
try {
int a;
char c;
while ((a = System.in.read())!= -1) {
с = (char)a;
if (Character.isWhitespace(c)) {
continue;
}
if (Character.is Digit(с)) {
blender.setSpeed(Character.digit(c, 10));
}
else {
switch (c) {
case 'F': blender.fi!l();
break;
case 'E': blender.empty();
break;
case 's': System.out.printlnfSPEED: " + blender.getSpeed());
break;
case 'f': System.out.println( + blender.isFull());
break;
default: throw new RuntimeException(
"Unknown Test directive");
}
}
}
catch (java.io.lOException e) {
System.err.println("Tesf jig failed: " + e.getMessage());
}
System.err.println("Completed blending\n");
System.exit(0);
}
Затем появится сценарий оболочки для управления тестированием.
#!/bin/sh
CMD="java dbc.dbc_sx"
failcount=0
expect okay() {
if echo "$*" | $CMD #>/dev/null 2>&1
then
...
else
echo "FAILED! $*"
failcount='expr $failcount + 1'
fi
}
expect_fail() {
if echo "$*" | SCMD>/dev/null 2> &1
then
echo "FAILED! (Should have failed): $*"
failcount='expr $failcount + 1'
fi
}
report() {
if [$failcount -gt 0]
then
echo – e "\n\n*** FAILED $failcount TESTS\n"
exit 1 # In case we are part of something larger
else
exit 0 # In case we are part of something larger
fi
}
#
# Start the tests
#
expect_okay F12345678987654321OE # Should run thru
expect_fail F5 # Fails, speed too high
expect_fail 1 # Fails, empty
expect_fail F10E1 # Fails, empty
expect_fail F1238 # Fails, skips
expect_okay FE # Never turn on
expect_fail F1E # Emptying while running
expect_okay F10E # Should be ok
report # Report results
При тестировании проверяется, не имеют ли место недопустимые переходы в скорости вращения ротора, если вы пытаетесь опорожнить работающий блендер, и т. д. Мы помещаем эту процедуру в сборочный файл, так что можно провести компиляцию и запустить регрессионный тест, просто введя команду:
% make % make test
Обратите внимание на то, что мы выходим из процедуры тестирования с 0 иди 1, так что можем использовать это и как часть более обширного теста.
В требованиях ничего не говорилось о запуске данного компонента через сценарий или даже с использованием языка. Конечные пользователи этого не увидят. Но у нас есть мощный инструмент, который можно использовать для быстрого и исчерпывающего тестирования нашей программы.
Упражнение 42 из раздела "Ошибка в определении требований" Ответ:
1. Эта инструкция похожа на реальное требование: имеются ограничения, налагаемые на приложение со стороны операционной среды.
2. Это может быть корпоративным стандартом, но не требованием. Его лучше сформулировать так: "Фон диалогового окна должен настраиваться конечным пользователем. При поставке заказчику цвет будет серым". Еще лучше было бы сформулировать его более широко: "Все визуальные элементы приложения (цвета, шрифты и языки) должны настраиваться конечным пользователем".
3. Эта формулировка не является требованием, это архитектура. Когда вы сталкиваетесь с подобным, вам придется копать очень глубоко, чтобы понять, что же думает пользователь.
4. Основное требование, вероятно, выглядит примерно так: "Система предотвращает ввод пользователем недопустимых значений в поля и предупреждает пользователя, если ввод этих значений имеет место".
5. Эта формулировка, по всей вероятности, является жестким требованием.
Решение головоломки с четырьмя точками, приведенной в разделе "Разгадка невероятных головоломок".

<< |

Еще по теме Прагматические проекты:

  1. Прагматическая мораль
  2. Прагматическая философия
  3. Прагматический подход
  4. Прагматическая паранойя
  5. Глава 10. ПРАВОВОЙ РЕЖИМ СОСТАВЛЕНИЯ ПРОЕКТОВ БЮДЖЕТОВ. Общие положения о составлении проектов бюджетов
  6. Глава 11. ПРАВОВОЙ РЕЖИМ РАССМОТРЕНИЯ И УТВЕРЖДЕНИЯ ПРОЕКТОВ БЮДЖЕТОВ Общие положения о рассмотрении и утверждении проектов бюджетов
  7. Руководитель проекта
  8. Элементы проекта
  9. Отличие проекта от программы
  10. Типология проектов