Дневник программиста

Мне порой кажется, что существует определенная категория программистов, которые считают что самое главное в программе - это максимальная степень оптимизации. Склонен с этим мнением не согласится. Отвечая на вопрос, что самое главное, нужно смотреть с двух разных точек зрения и искать компромисс между ними. И во многих случаях получится так, что оптимизации места здесь не найдется. Две точки зрения - это прикладная программа с точки зрения конечного пользователя, и программный код с точки зрения разработчика(-ов). Конечного пользователя интересует программный продукт, набор его функций и возможностей, ему все равно выполняется ли определенный участок кода за 1 мс или за 10 мс, если он все равно не заметит разницы. Но погоня за выйгрышем этих 9 мс может обойтись разработчику достаточно дорого. Вопрос - в чем смысл? Единственный возможный - это в целях самообразования, но не более. Поймите, что качество программы от этого не вырастет ни на йоту, а может даже и упадет. Программный код же далеко не в последнюю очередь пишется для людей. И требования к нему - соответствующие. Он должен быть понятен, читаем, гибок и расширяем. Разработка почти никогда не заканчивается в момент выпуска первой версии программы, и очень важно чтобы усовершенствование программного продукта обходилась как можно дешевле. Оптимизация же может принести вред качеству кода с этой точки зрения (особенно низкоуровневая оптимизация) - мы пытаемся сделать код более оптимальным для машины, за счет уменьшения его оптимальности для человека. Выигрыш от ненужной оптимизации сомнителен, в то время как проигрыш - ощутим. ПРЕЖДЕВРЕМЕННАЯ ОПТИМИЗАЦИЯ - ЗЛО! Не чешите, пока не чешется. Но с другой стороны, обратное - преждевременная пессимизация - тоже зло. Ищите серединку опираясь на обозначенные приоритеты. Поэтому очень важно думая об оптимизации правильно расставлять приоритеты. А приоритеты эти - это юзабилити - для пользователя, и читаемость, гибкость, расширяемость кода - для разработчика. Оптимизировать нужно тогда и только тогда, когда итоговые показатели не устраивают пользователей. И то, делать это нужно - тоже правильно. Не стоит сразу же бросаться переписывать участки кода на ассемблере - это глупо. В первую очередь нужно выявить узкое место путем тестирования и замеров. Делать это нужно обязательно, даже если вам кажется что вы знаете почему ваша программа тормозит. Поверьте опыту, достаточно часто ваши догадки не оправдываются и причина кроется где-то еще. И только выявив это узкое место, найдя причину, нужно пытаться найти более оптимальный вариант, решающий ту же задачу. В большинстве случаев этот оптимальный вариант заключается в высокоуровневой оптимизации - нужно изменить сам подход к решению задачи. Я не являюсь заядлым любителем алгоритмов и при оптимизации использую скорее не математический, а инженерный подход, о котором расскажу в следующий раз.