* Уже не редкость емкость дисковой памяти, превышающая спустя 5 лет указанные автором значения на два порядка, а оперативной - на порядок. - Прим.перев.

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

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

14. Малое - это прекрасно (большое == медленное)

Распухание программ является огромной проблемой. Жесткий диск вместимостью 350 Мбайт на моем лэптопе может вместить операционную систему, усеченные версии моих компилятора и редактора и больше ничего. В стародавние времена я мог разместить версии для CP/M тех же программ на единственной дискете вместимостью 1,2 Мбайта. UNIX в то время спокойно работал на 16-разрядном PDP-11 c 64 Кбайтами ядра (внутренней памяти). В наше время большинство операционных систем требуют 32-разрядных машин с минимум 1 6 Мбайтами оперативной памяти, чтобы работать с приемлемой скоростью*. Я убежден, что большая часть этого распухания памяти является результатом небрежного программирования.

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

Третьей проблемой является модульность. Одна из основ философии UNIX гласит "меньше - лучше". Большие задачи лучше выполняются взаимодействующей системой маленьких модульных программ, каждая из

которых делает хорошо лишь одно задание, но каждая из них может сообщаться с другими компонентами. (Стандарт связи и внедрения объектов Microsoft (OLE) добавляет это свойство в Windows, а OpenDoc - в Macintosh). Если ваше приложение представляет собой модульную конструкцию из маленьких программ, работающих вместе, то становится очень просто настраивать вашу программу по заказу путем смены модулей. Если вам не нравится этот редактор, то поменяйте его на новый.

Наконец, программы обычно уменьшаются в процессе усовершенствования. Большие программы, вероятно, никогда не подвергались усовершенствованиям.

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

Часть

Общие проблемы разработки программ

Эта часть книги содержит общие правила для процесса разработки программ и не касается деталей собственно языков Си и Си++. Я сделаю это в последующих частях.