Предполагается, что новичок, берущийся за этюд, уже написал несколько программ и знает сравнительно хорошо хотя бы один язык. Здесь не ставится задача научить конкретным приемам программирования, структурам данных или языкам. Если для решения задачи требуются какие-то специальные знания, трудные места обсуждаются достаточно подробно, а источники дополнительной информации указаны в библиографии. Более того, мы не описываем какой-либо конкретный стиль программирования и не обсуждаем вопросы структурного программирования. Вероятно, большинство читателей слушает лекции или посещает семинарские занятия и может воспользоваться советами преподавателя. Занимающиеся самостоятельно могут почерпнуть сведения по технике и стилю программирования из источников, перечисленных в конце главы.
Каждый этюд распадается на разделы (некоторые из них необязательные). В первом разделе описывается реальная ситуация, во втором — конкретная программа, которую предстоит написать. Обычно ситуация разъясняется достаточно подробно, а постановка задачи — совсем короткая. Затем следует обсуждение трудностей, которые могут встретиться при реализации, и намеки на возможные пути решения. Рассматриваются только существенные моменты. Затем следуют разделы, в которых обсуждается выбор языка и длительность исполнения этюда[4]. Временные оценки, которые рассчитаны на аспирантов первого года обучения, выделяющих для решения задачи четверть своего рабочего времени, могут оказаться малы для программистов, работающих не столь увлеченно. Кроме того, временные оценки могут увеличиваться под влиянием условий доступа к машине. В конце этюда часто содержится расширение поставленной задачи и аннотированная библиография. Решение, найденное с использованием дополнительной литературы, более полезно для студента.
Конечно, результатом работы над этюдом должна быть понятная и четкая программа, стиль и комментарии которой соответствовали бы задаче и выбранному языку. Но этого мало. Еще необходим набор тестов, достаточный для демонстрации работы программы и ее реакции на экстремальные ситуации и неправильное обращение. Наряду с самой программой требуется краткое словесное описание методов решения. Особый упор в нем следует сделать на положенные в основу решения алгоритмы и структуры данных. Наряду с описанием программы программист должен с достаточной степенью правдоподобности хотя бы неформально проиллюстрировать ее правильность (при недостатке времени можно ограничиться рассмотрением ключевых мест). Наконец, должен быть произведен подсчет затраченных ресурсов, как людских, так и машинных; особое внимание следует обратить на обоснование затрат. Также следует указать, чему программист научился на примере этой задачи (на этот вопрос легко ответить, если сформулировать его в виде: «Что я в следующий раз сделаю иначе?»). Такой объем документации может показаться избыточным. Заметим, однако, что умению вовремя поставить точку тоже очень полезно научиться. Решение небольшой задачи не следует перегружать документацией. Один знакомый автору преподаватель определяет оценку на 40% тем, что студент убедил его в правильности программы, на 50% легкостью, с которой его удалось убедить, и только на 10% отличным программированием. Очень хорошая оценка — это 80% и более. А поскольку часть документации — результаты машинных прогонов, такая отметка означает, что программа произвела благоприятное впечатление и на преподавателя, и на ЭВМ.
4
Предлагаются такие общедоступные языки, как Фортран, Кобол, Алгол, язык ассемблера, APL, XPL, PL/I, Бейсик, Паскаль, Лисп, Снобол и др. Это не означает, что не подходит какой-нибудь менее известный или менее распространенный язык, тем более что в наших рекомендациях мы руководствовались собственными вкусами. В любом случае приветствуется использование языков и трансляторов более высокого уровня, типа WATFIV, PL/C или SPITBOL, требующих и более серьезного к себе отношения. Можно также использовать задачу для изучения нового языка («полное погружение» — метод тяжелый, но эффективный).