«Рефакторинг. Зачем?»

Время от времени мне доводилось отвечать на вопросы, которые в конечном счёте можно сформулировать как: «что такое рефакторинг и для чего он нужен?». Конкретные вопросы могли быть разные, например, чем объектно–ориентированное программирование лучше функционального. Этот вопрос относится к рефакторингу куда больше, чем принято считать.

Так что же такое рефакторинг? Это любое изменение программы, которое не изменяет её функциональности. Для чего же тогда делать это изменение? Дело в том, что в отличии от книг, где буковки прочно занимают свои места раз и навсегда, программный код — это нечто живое, постоянно изменяемое. В крупных проектах объём кода может составлять десятки или даже сотни мегабайт. Это сопоставимо по объему с домашней библиотекой средних размеров. Найти что–то среди такого количества информации — задача, вообще говоря, нетривиальная, ну а понять написанное — зачастую и вовсе неразрешимая. Так вот, рефакторинг направлен, прежде всего, на решение этих проблем.

Задачи рефакторинга тесно связанны с задачами написания понятного, удобного кода. Соответственно, если я пишу как следует писать или чего лучше избегать — это к рефакторингу не относится. С одной стороны. Но ведь следуя этим рекомендациям, вы можете пересмотреть свой код и исправить потенциальные ошибки. А вот это уже чистой воды рефакторинг. Поэтому я не буду особенно зацикливаться именно на рефакторинге, а буду рассказывать о хорошем, понятном коде.

Разумеется, моё представление о хорошем коде может коренным образом отличаться от вашего и тут я не претендую на статус непогрешимого. Хочу только заметить, что всё, что изложено в этой книге основано на многолетних наблюдениях и в целом, так или иначе, согласуется с общепризнанными подходами к программированию.

Примеры я буду приводить на языке Object Pascal. В основном я работаю на нём, пишу на Delphi. Предвидя нападки со стороны поклонников C-подобных языков, скажу два тезиса:

1. Подходы к организации программного кода от языка не зависят. Язык может лишь поддерживать или не поддерживать те или иные конструкции.