Почему нужно прибегать к рефакторингу?

12
Предисловие
программы . В худших случаях тесты производительности до введения 
приложения в эксплуатацию показывали полное несоответствие требо-
ваниям к системе . В промежуточных случаях при росте объемов дан-
ных, добавлении новой функциональности, обновлении программного 
обеспечения или изменениях конфигурации обнаруживались дефекты, 
которые до определенного момента были незаметны, а возврат к преж-
нему состоянию не всегда мог исправить ситуацию . Все эти проблемы 
объединяют чрезвычайно сжатые сроки для увеличения производитель-
ности и постоянное давление на разработчиков .
Первые действия по разрешению проблемы обычно выполняют систем-
ные инженеры и администраторы баз данных, которых просят «покол-
довать» над параметрами . Если не обнаруживается какая-то особо се-
рьезная ошибка (такое случается), настройки операционной системы 
и базы данных часто дают только незначительный прирост производи-
тельности .
После этого традиционным следующим шагом является увеличение 
мощности оборудования . Это очень дорогой вариант, поскольку к цене 
оборудования, вероятно, добавится увеличение стоимости лицензий на 
использование программного обеспечения . Это приведет к прерыванию 
бизнес-процесса, потребуется планирование . Что самое печальное, нет 
никакой реальной гарантии рентабельности этих вложений . Случается, 
что массированное обновление оборудования не оправдывало надежд . 
Ходят ужасные истории о том, как после подобных обновлений произ-
водительность падала еще больше . Бывает, что добавление процессоров 
только увеличивает конкуренцию между процессами .
Концепция рефакторинга подразумевает необходимый промежуточ-
ный этап между настройкой и приобретением нового оборудования . 
Выше упомянутая конструктивная книга Мартина Фаулера фокусиру-
ется на объектных технологиях . Но контекст приложений баз данных 
значительно отличается от контекста прикладных программ, написан-
ных на объектно-ориентированных или процедурных языках, эти раз-
личия вносят значительные отличия в рефакторинг . Например:
Изменения, кажущиеся малыми, не всегда оказываются таковыми 
Благодаря декларативной природе языка SQL, незначительная моди-
SQL, незначительная моди-
, незначительная моди-
фикация кода часто может принести значительные изменения в то, 
как SQL обрабатывает данные, что приводит к серьезным изменени-
SQL обрабатывает данные, что приводит к серьезным изменени-
обрабатывает данные, что приводит к серьезным изменени-
ям производительности – как в лучшую, так и в худшую сторону .
Проверка правильности изменений может быть затруднена
Сравнительно несложно убедиться, что значение, возвращаемое 
функцией, одинаково во всех случаях до и после изменения кода . 
Значительно сложнее проверить, остается ли прежним содержимое 
большой таблицы после изменения главного оператора обновления .

Предисловие 
13
Контекст часто оказывается критичным
Приложения баз данных могут годами работать удовлетворительно 
без заметных проблем . Часто случается, что объем данных или на-
грузка переходят некий порог либо обновление программного обе-
спечения изменяет работу оптимизатора, после чего производитель-
ность внезапно становится неудовлетворительной . Работы по улуч-
шению производительности баз данных обычно происходят в усло-
виях кризиса .
В результате рефакторинг приложений баз данных происходит на слож-
ном фоне, но в то же время такая попытка может быть (и часто бывает) 
очень успешной .

жүктеу/скачать 1.3 Mb.

Достарыңызбен бөлісу: