Искусство программирования для Unix

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

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

В традициях Unix генераторы кода интенсивно используются для автоматизации чреватой ошибками кропотливой работы. Классическими примерами генераторов кода являются грамматические (parser) и лексические (lexer) анализаторы. Более новые примеры — генераторы make-файлов и построители GUI-интерфейсов.

Данные методики рассматриваются в главе 9.

1.6.15. Правило оптимизации: создайте опытные образцы, заставьте их работать, прежде чем перейти к оптимизации

Самый основной аргумент в пользу создания прототипов впервые был выдвинут Керниганом и Плоджером (Plauger): '90% актуальной и реальной функциональности лучше, чем 100% функциональности перспективной и сомнительной'. Первоначальное создание прототипов помогает избежать слишком больших затрат времени для получения минимальной выгоды.

По несколько другим причинам Дональд Кнутт (автор книги 'Искусство компьютерного программирования', одного из немногих действительно классических трудов в своей области) популяризовал мнение о том, что 'преждевременная оптимизация — корень всех зол'[10], и он был прав.

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

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

В мире Unix имеется общепринятая и весьма явная традиция (ярко проиллюстрированная приведенными выше комментариями Роба Пайка и принципом Кена Томпсона о грубой силе), которая гласит: создавайте прототипы, а затем шлифуйте их. Заставьте прототип работать, прежде чем оптимизировать его. Или: сначала заставьте прототип работать, а потом заставьте его работать быстро. Гуру 'Экстремального программирования' Кент Бек (Kent Beck), работающий в другой культуре, значительно усилил данный принцип: 'заставьте программу работать, заставьте ее работать верно, а затем сделайте ее быстрой'.

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

Создание прототипов так же важно для конструкции системы, как и оптимизация — гораздо проще определить, выполняет ли прототип возложенные на него задачи, чем читать длинную спецификацию. Я помню одного менеджера разработки в Bellcore, который боролся против культуры 'требований' задолго до того, как все заговорили о 'быстром создании прототипов' (fast prototyping), или 'гибкой разработке' (agile development). Он не стал бы выпускать длинные спецификации. Он связывал сценарии оболочки и awk-код в некоторую комбинацию, которая делала приблизительно то, что ему было нужно, а затем просил заказчиков направить к нему нескольких клерков на пару дней. После чего приглашал заказчиков прийти и посмотреть, как их клерки используют прототип, и сказать ему, нравится им это или нет.

В случае положительного ответа он говорил, что 'промышленный образец может быть создан через столько-то месяцев и по такой-то цене'. Его оценки были довольно точными, однако он проигрывал в культуре менеджерам, которые верили, что создатели требований должны контролировать все.

Майк Леск.

Использование прототипов для определения того, в каких функциях нет необходимости, способствует оптимизации производительности; нет необходимости оптимизировать то, что не написано. Наиболее мощным средством оптимизации можно назвать клавишу 'Delete'.

В один из наиболее продуктивных дней я удалил тысячу строк кода.

Кен Томпсон.

Более глубоко соответствующие соображения рассматриваются в главе 12.

1.6.16. Правило разнообразия: не следует доверять утверждениям о 'единственно верном пути'

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

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

1.6.17. Правило расширяемости: проектируйте с учетом изменений в будущем, поскольку будущее придет скорее, чем кажется

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