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

Д. Кнуту принадлежит утверждение "Непродуманная оптимизация - корень всех бед". Некоторые слишком хорошо убедились в справедливости этого и считают вредными все заботы об оптимизации. На самом деле вопросы эффективности надо все время иметь в виду во время проектирования и реализации. Это не означает, что разработчик должен заниматься задачами локальной оптимизации, только задача оптимизации на самом глобальном уровне должна его волновать.       Лучший способ добиться эффективности - это создать ясный и простой проект. Только такой проект может остаться относительно устойчивым на весь период развития и послужить основой для настройки системы с целью повышения производительности. Здесь важно избежать "гаргантюализма", который является проклятием больших проектов. Слишком часто люди добавляют определенные возможности системы "на всякий случай" (см. $$11.3.3.2 и $$11.4.3), удваивая, учетверяя размер выполняемой программы ради завитушек. Еще хуже то, что такие усложненные системы трудно поддаются анализу, а по этому трудно отличить избыточные накладные расходы от необходимых и провести анализ и оптимизации на общем уровне. Оптимизация должна быть результатом анализа и оценки производительности системы, а не произвольным манипулированием с программным кодом, причем это особенно справедливо для больших систем, где интуиция разработчика или программиста не может служить надежным указателем в вопросах эффективности.       Важно избегать по сути неэффективных конструкций, а так же таких конструкций, которые можно довести до приемлемого уровня выполнения, только затратив массу времени и усилий. По этой же причине важно свести к минимуму использование непереносимых по своей сути конструкций и средств, поскольку их наличие препятствует работе системы на других машинах (менее мощных, менее дорогих).

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

Если только это имеет какой-то смысл, большинство людей делает то, что их поощряют делать. Так, в контексте программного проекта, если менеджер поощряет определенные способы действий и наказывает за другие, редкие программисты или разработчики рискнут своим положением, встречая сопротивления или безразличия администрации, чтобы делать так, как они полагают нужнымЬ. Ь Организация, в которой считают своих программистов недоумками, очень скоро получит программистов, которые будут рады и способны действовать только как недоумки. Отсюда следует, что менеджер должен поощрять такие структуры, которые соответствуют сформулированным целям проекта и реализации. Однако на практике слишком часто бывает иначе. Существенное изменение стиля программирования достижимо только при соответствующем изменении в стиле проектирования, кроме того, обычно и то и другое требует изменения в стиле управления. Мыслительная и организационная инерция слишком просто сводят все к локальным изменениям, хотя только глобальные изменения могут принести успех. Прекрасной иллюстрацией служит переход на язык с объектно-ориентированным программированием, например на С++, когда он не влечет за собой соответствующих изменений в методах проектирования, чтобы воспользоваться новыми возможностями языка (см. $$12.1), и, наоборот, когда переход на "объектно-ориентированное проектирование" не сопровождается переход на язык реализации, который поддерживает этот стиль.