11.3.7 Эффективность

Д. Кнуту принадлежит утверждение "Непродуманная оптимизация - корень

всех бед". Некоторые слишком хорошо убедились в справедливости этого

и считают вредными все заботы об оптимизации. На самом деле вопросы

эффективности надо все время иметь в виду во время проектирования и

реализации. Это не означает, что разработчик должен заниматься

задачами локальной оптимизации, только задача оптимизации на самом

глобальном уровне должна его волновать.

Лучший способ добиться эффективности - это создать ясный и

простой проект. Только такой проект может остаться относительно

устойчивым на весь период развития и послужить основой для

настройки системы с целью повышения производительности. Здесь

важно избежать "гаргантюализма", который является проклятием

больших проектов. Слишком часто люди добавляют определенные

возможности системы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3),

удваивая, учетверяя размер выполняемой программы ради завитушек.

Еще хуже то, что такие усложненные системы трудно поддаются

анализу, а по этому трудно отличить избыточные накладные расходы

от необходимых и провести анализ и оптимизации на общем уровне.

Оптимизация должна быть результатом анализа и оценки производительности

системы, а не произвольным манипулированием с программным кодом,

причем это особенно справедливо для больших систем, где интуиция

разработчика или программиста не может служить надежным указателем

в вопросах эффективности.

Важно избегать по сути неэффективных конструкций, а так же

таких конструкций, которые можно довести до приемлемого уровня

выполнения, только затратив массу времени и усилий. По этой же

причине важно свести к минимуму использование непереносимых по

своей сути конструкций и средств, поскольку их наличие препятствует

работе системы на других машинах (менее мощных, менее дорогих).

11.4 Управление проектом

Если только это имеет какой-то смысл, большинство людей делает то,

что их поощряют делать. Так, в контексте программного проекта, если

менеджер поощряет определенные способы действий и наказывает за

другие, редкие программисты или разработчики рискнут своим

положением, встречая сопротивления или безразличия администрации,

чтобы делать так, как они полагают нужнымЬ.

Ь Организация, в которой считают своих программистов недоумками,

очень скоро получит программистов, которые будут рады и способны

действовать только как недоумки.

Отсюда следует, что менеджер должен поощрять такие структуры,

которые соответствуют сформулированным целям проекта и реализации.

Однако на практике слишком часто бывает иначе. Существенное

изменение стиля программирования достижимо только при соответствующем

изменении в стиле проектирования, кроме того, обычно и то и другое

требует изменения в стиле управления. Мыслительная и организационная

инерция слишком просто сводят все к локальным изменениям, хотя

только глобальные изменения могут принести успех. Прекрасной

иллюстрацией служит переход на язык с объектно-ориентированным

программированием, например на С++, когда он не влечет за собой

соответствующих изменений в методах проектирования, чтобы

воспользоваться новыми возможностями языка (см. $$12.1), и, наоборот,

когда переход на "объектно-ориентированное проектирование" не

сопровождается переход на язык реализации, который поддерживает

этот стиль.