Рефакторинг: мы им занимаемся, сами того не подозревая
Рефакторинг является подтверждением того,
что причиной падения производительности
до неудовлетворяющего нас уровня являемся
мы сами, а не гримасы судьбы.
Стефан Фаро
Эта книга сильно отличается от тех многих работ по программированию, которые я читал, изучал, на которые писал рецензии. Основные свойства технической литературы — изложение, обучение и «справочность».
И поэтому специалист, который уже находится в теме излагаемых вопросов, может читать книгу по частям, а не сначала, пропускать тексты и главы, получать только ту информацию, которая интересует его в данный момент. Так построено большинство IT-изданий, включая произведения классиков – Тома Кайта, Стивена Фернштейна, Кевина Луни, Дага Бурлесона и др. Исключение, конечно, учебники, их полагается осваивать постепенно, глава за главой.
Книга же Стефана Фаро принадлежит к другому, довольно редкому виду изданий, которые надо читать (обязательно) от начала и (не обязательно) до конца именно как литературное произведение с динамично развивающимся сюжетом. Допустимо ли такое в технической литературе? Да, но редко. Тем ценнее рассматривая книга.
Сразу поясню: я постоянно называю только одного автора — Стефана Фаро, от лица которого ведется повествование. Но необходимо упомянуть и его партнера, Паскаля Лерми, чья помощь в написании этой книги была столь значительна, что он справедливо указан в качестве соавтора.
Из Википедии: «Рефакторинг (реорганизация кода) — процесс изменения внутренней структуры программы, не затрагивающий ее внешнего поведения и имеющий целью облегчить понимание ее работы. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению ее согласованности и четкости».
Сразу становится понятной позиция Стефана Фаро:
· Когда возникает вопрос рефакторинга кода, можно быть уверенным, что либо проблема уже возникла, либо она появится в ближайшее время.
· Известно, что нужно улучшить в плане функциональности, но нужно понять природу проблемы.
· При анализе производительности первое, что нужно диагностировать: не достиг ли один из трех основных ресурсов (загрузка процессора, использование памяти, операции ввода/вывода) проблемного уровня. Это покажет, что нужно улучшить и как это сделать.
· Меня привлекла идея рассказа о SQL с собственной профессиональной точки зрения.
Тем самым перед нами не что иное, как роман-исследование. Начинается он с пролога (глава 1 «Оценка»), где автор заявляет, что «рассматривает различные способы увеличения производительности, которые иногда оказываются эффективными и не зависят от настройки параметров базы данных или обновления оборудования». Глава вторая («Проверка работоспособности») и третья («Пользовательские функции и представления») посвящены, по оценке автора, мечте любого менеджера – быстрым победам, когда изменения производятся на стороне базы данных, а не приложения (давно же известно, что сравнительная эффективность настройки приложения и базы данных составляет знаменитую формулу 80/20).
Далее идет речь об изменениях, которые можно внести в приложение:
Глава 4. «Концепция тестирования. Приводится правильная концепция данного процесса (при модификации кода важно обеспечить получение тех же результатов, что до внесения изменений).
Глава 5. «Рефакторинг операторов. Обсуждается правильный подход к написанию SQL-предложений и излагаются способы, как превратить оптимизатор в друга, а не врага.
Глава 6. «Рефакторинг задач». Рассматриваются использование SQL там, где он работает лучше, реструктуризация кода, введение управляющих структур в SQL и другие темы. Так что, овладев SQL-мышлением, можно «рассчитывать на успех», утверждает Фаро.
Глава 7. «Рефакторинг потоков и баз данных. Последняя надежда для тех, кто все еще не удовлетворен производительностью. Скорее всего, это шутливая посылка автора, поскольку полностью довольных производительностью нигде и никогда не встречается. Но сам Фаро, изменяя потоки, вводя параллелизм, логически и физически корректируя структуру базы данных, в качестве последнего шанса пытается повысить производительность. Недаром одна из подглавок названа «Потрясая основы». Бог ему в помощь!
Глава 8. «Как это работает. Практика рефакторинга». Она же – эпилог-заключение этого SQL-романа. Подводит итоги и дает рекомендации на будущее. Очень мудрое замечание: «Повышение производительности является итеративным процессом. Очень часто за проблемами, которые приходится решать, скрываются другие проблемы». Осмелюсь предположить, что от такого тезиса не отказался бы и автор «Диалектики» великий Аристотель.
Опубликовано 29.09.2013