понедельник, 4 января 2010 г.

Рефакторинг. Улучшение существующего кода. Часть 1

Refactoring С момента выхода оригинального издания этой книги прошло десять лет и уже давно понятия "рефакторинга" стало неотъемлемой частью арсенала каждого разработчика. Также уже довольно давно сбылась мечта авторов этой книги и поддержка рефакторинга уже не ограничивается единственной IDE для Smalltalk, а доступна практически в каждой современной IDE. Некоторые разработчики могут подумать, что в связи с этим ценность этой книги стала уменьшаться, но это не так. Главная ее ценность была и остается в том, что такое "код с душком", почему важно качество кода, какое влияние оказывает рефакторинг на процесс проектирования, какова роль модульных тестов, понять когда следует проводить рефакторинг, а когда от него вообще стоит отказаться и многое другое.
Поскольку цитат, как обычно для хорошей книги, набралось довольно много, то я разбил их на две части.
Итак, приступим, часть первая.

Компилятору все равно, красив код или нет. Но в процессе внесения изменений в систему участвуют люди, которым это не безразлично. Плохо спроектированную систему трудно модифицировать. Трудно потому, что нелегко понять, где изменения нужны. Если трудно понять, что должно быть изменено, то есть большая вероятность, что программист ошибется.
Глава 1. Комментарии к исходной программе

Обнаружив, что в программу необходимо добавить новую функциональность, но код программы не структурирован удобным для добавления этой функциональности образом, сначала произведите рефакторинг программы, чтобы упростить внесение необходимых изменений, а только потом добавьте функцию.
Глава 1. Комментарии к исходной программе

Перед началом рефакторинга убедитесь, что располагаете надежным комплектом тестов. Эти тесты должны быть самопроверяющимися.
Глава 1. Первый шаг рефакторинга

При применении рефакторинга программа модифицируется небольшими шагами. Ошибку нетрудно обнаружить.
Глава 1. Декомпозиция и перераспределение метода statement

Стоит ли заниматься переименованием? Без сомнения, стоит. Хороший код должен ясно сообщать о том, что он делает, и правильные имена переменных составляют основу понятного кода. Не бойтесь изменять имена, если в результате код становится более ясным.
Глава 1. Декомпозиция и перераспределение метода statement

Написать код, понятный компьютеру, может каждый, но только хорошие программисты пишут код, понятный людям.
Глава 1. Декомпозиция и перераспределение метода statement

Очень важно, чтобы код сообщал о своей цели. Я часто провожу рефакторинг, когда просто читаю некоторый код. Благодаря этому свое понимание работы программы я отражаю в коде, чтобы впоследствии не забыть понятое.
Глава 1. Декомпозиция и перераспределение метода statement

Рефакторинг (Refactoring) (сущ.): изменение во внутренней структуре программного обеспечения, имеющее целью облегчить понимание его работы и упростить модификацию, не затрагивая наблюдаемого поведения.
Глава 2. Определение рефакторинга

Цель рефакторинга - упростить понимание и модификацию программного обеспечения
Глава 2. Определение рефакторинга

Рефакторинг напоминает наведения порядка в коде. Убираются фрагменты, оказавшиеся не на своем месте. Утрата кодом структурности носит кумулятивный характер. Чем сложнее разобраться во внутреннем устройстве кода, тем труднее его сохранить и тем быстрее происходит его распад. Регулярно проводимый рефакторинг помогает сохранять форму кода.
Глав 2. Рефакторинг улучшает композицию программного обеспечения

Беда в том, что когда вы бьетесь над тем, чтобы заставить программу работать, то совсем не думаете о разработчике, который будет заниматься ею в будущем. Надо сменить ритм, чтобы внести в код изменения, облегчающие его понимание. Рефакторинг помогает сделать код более легким для чтения.
Глава 2. Рефакторинг облегает понимание программного обеспечения

Я не считаю себя замечательным программистом. Я просто хороший программист с замечательными привычками
Высказывание Кента Бека
Глава 2. Рефакторинг помогает найти ошибки

Как правило, я против откладывания рефакторинга "на потом". На мой взгляд, это не тот вид деятельности. Рефакторингом следует заниматься постоянно понемногу. Надо не решать проводить рефакторинг, а проводить его, потому что необходимо сделать что-то еще, а поможет в этом рефакторинг.
Глава 2. Когда следует проводить рефакторинг?

Делая что-то в первый раз, вы просто это делаете. Делая что-то аналогичное во второй раз, вы морщитесь от необходимости повторения, но все-таки повторяете то же самое. Делая что-то похожее в третий раз, вы начинаете рефакторинг.
Глава 2. Правило трех ударов

Подрывная деятельность? Не думаю. Разработчики программного обеспечения - профессионалы. Наша работа состоит в том, чтобы создавать эффективные программы как можно быстрее. По моему опыту, рефакторинг значительно способствует быстрому созданию приложений. Если мне надо добавить новую функцию, а проект плохо согласуется с модификацией, то быстрее сначала изменить его структуру, а потом добавлять новую функцию. Если требуется исправить ошибку, то необходимо сначала понять, как работает программа, и я считаю, что быстрее всего можно сделать это с помощью рефакторинга. Руководитель, подгоняемый графиком работ, хочет, чтобы я сделал свою работу как можно быстрее; как мне это удастся - мое дело. Самый быстрый путь - рефакторинг, поэтому я и буду им заниматься.
Глава 2. Как объяснить это своему руководителю?

Вычислительная техника - это дисциплина, в которой считается, что все проблемы можно решить благодаря введению одного или нескольких уровней косвенности.
Деннис Де Брюле
Глава 2. Косвенность и рефакторинг

В некоторых случаях рефакторинг вообще не нужен. Основной пример - необходимость переписать программу с нуля. Иногда имеющийся код настолько запутан, что подвергнуть его рефакторингу, конечно, можно, но проще начать все с самого начала.
Глава 2. Когда рефакторинг не нужен?

С применением рефакторинга акценты смещаются. Предварительное проектирование сохраняется, но теперь оно не имеет целью найти единственно правильное решение. Все, что от него требуется, - это найти приемлемое решение. По мере реализации решения, с углублением понимания задачи становится ясно, что наилучшее решение отличается от того, которое было принято первоначально. Но в этом нет ничего страшного, если в процессе участвует рефакторинг, потому что модификация не обходится слишком дорого.
Глава 2. Проектирование и рефакторинг

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

Секрет создания быстрых программ, если только они не предназначены для работы в жестком режиме реального времени, состоит в том, чтобы сначала написать программу, которую можно настраивать, а затем настроить ее так, чтобы достичь приемлемой скорости.
Глава 2. Рефакторинг и производительность

Хорошее разделение программы на компоненты способствует оптимизации такого рода в двух отношениях. Во-первых, благодаря ему появляется время, которое можно потратить на оптимизацию. Имея хорошо структурированный код, можно быстрее добавлять новые функции и выиграть время для того, заняться производительностью. (Профилирование гарантирует, что это время не будет потрачено зря.) Во-вторых, хорошо структурированная программа обеспечивает более высокое разрешение для анализа производительности. Профайлер указывает на более мелкие фрагменты кода, которые легче настроить. Благодаря большей понятности кода лекче осуществить выбор возможных вариантов и разобраться в том, какого рода настройка может оказаться действенной.
Глава 2. Рефакторинг и производительность

Все цитаты из книги Мартина Фаулера “Рефакторинг. Улучшение существующего кода”.

Часть 1

Часть 2

Комментариев нет:

Отправить комментарий