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

Обещанное продолжение цитат из замечательной книги Мартина Фаулера “Рефакторинг. Улучшение существующего кода”.

 

 

 

 

 

 

Если что-то плохо пахнет, это что-то надо поменять
                                 - Мнение бабушки Бек, высказанное
        при обсуждении проблем детского воспитания
Глава 3. Код с душком

Увидев одинаковые структуры кода в нескольких местах, можно быть уверенным, что если удастся их объединить, программа от этого только выиграет
Глава 3. Дублирование кода

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

Весь смысл объектов в том, что они позволяют хранить данные вместе с процедурами их обработки. Классический пример дурного запаха - метод, который больше интересуется не тем классом, в котором он находится, а каким-то другим. Чаще всего предметом зависти являются данные. Не счесть случаев, когда мы сталкиваемся с методом, вызывающим полдюжины методов доступа к данным другого объекта, чтобы вычислить некоторое значение. К счастью, лечение здесь очевидно: метод явно напрашивается на перевод в другое место.
Глава 3. Завистливые функции

Брайан Фут (Brian Foote) предложил название "теоретическая общность" (speculative generality) для запаха, к которому мы очень чувствительны. Он возникает, когда говорят о том, что в будущем, наверное, потребуется возможность делать такие вещи, и хотят обеспечить набор механизмов для работы с вещами, которые не нужны. То, что получается в результате, труднее понимать и сопровождать. Если бы все эти механизмы использовались, их наличие было бы оправдано, в противном случае они только мешают, поэтому избавляйтесь от них.
Глава 3. Теоретическая общность

Цепочки сообщений появляются, когда клиент запрашивает у одного объекта другой, у которого клиент запрашивает еще один объект, у которого клиент запрашивает еще один объект и т.д. Это может выглядеть как длинный ряд методов getThis или последовательность временных переменных. Такие последовательности вызовов означают, что клиент связан с навигацией по структуре классов. Любые изменения промежуточных связей означают необходимость модификации клиента.
Глава 3. Цепочки сообщений

Почувствовав потребность написать комментарий, попробуйте сначала изменить структуру кода так, чтобы любые комментарии стали излишними.
Глава 3. Комментарии

Делайте все тесты полностью автоматическими, так чтобы они проверяли собственные результаты
Глава 4. Ценность самотестирующегося кода

Получив сообщение об ошибке, начните с создания теста модуля, показывающего эту ошибку.
Глава 4. Тесты модулей и функциональные тесты

Тестирование приносит ощутимую пользу, даже если осуществляется в небольшом объеме. Ключ к проблеме в том, чтобы тестировать те области, возможность ошибок в которых вызывает наибольшее беспокойство. При таком подходе затраты на тестирование приносят максимальную выгоду.
Глава 4. Добавление новых тестов

Лучше написать и выполнить неполные тесты, чем не выполнить полные тесты
Глава 4. Добавление новых тестов

Опасение по поводу того, что тестирование не выявит все ошибки, не должно помешать написанию тестов, которые выявят большинство ошибок.
Глава 4. Добавление новых тестов

Всегда есть риск что-то пропустить, но лучше потратить разумное время, чтобы выявить большинство ошибок, чем потратить вечность, пытаясь найти их все.
Глава 4. Добавление новых тестов

Маленькие методы действительно полезны, если выбирать для них хорошие имена. Иногда меня спрашивают, какой длины должно быть имя метода. Думаю, важна не длина, а семантическое расстояние между именем метода и телом метода. Если выделение метода делает код более понятным, выполните его, даже если имя метода окажется длиннее, чем выделенный код.
Глава 6. Выделение метода. Мотивировка.

Данная книга учит тому, как использовать короткие методы с названиями, отражающими их назначение, что приводит к получению более понятного и легкого для чтения кода. Но иногда встречаются методы, тела которых столь же прозрачны, как названия, либо изначально, либо становятся таковыми в результате рефакторинга. В этом случае необходимо избавиться от метода. Косвенность может быть полезной, но излишняя косвенность раздражает.
Глава 6. Встраивание метода. Мотивировка.

Когда код имеет четкую структуру, часто находятся более мощные оптимизирующие решения, которые без рефакторинга остались бы незамеченными.
Глава 6. Замена временной переменной вызовом метода. Техника.

Все переменные, выполняющие несколько функций, должны быть заменены отдельной переменной для каждой из этих функций. Использование одной и той же переменной для решения разных задач очень затрудняет чтение кода.
Глава 6. Расщепление временной переменной. Мотивировка.

Я никогда не пробовал спать на потолке. Говорят, есть несколько способов. Наверняка одни из них легче, чем другие. С алгоритмами то же самое. Если обнаруживается более понятный способ сделать что-либо, следует заменить сложный способ простым.
Глава 6. Замещение алгоритма. Мотивировка.

Разумное и правильное проектное решение через неделю может оказаться неправильным. Но проблема не в этом, а в том, чтобы не оставить это без внимания.
Глава 7. Перемещение объекта. Мотивировка

Одним из ключевых свойств объектов является инкапсуляция. Инкапсуляция означает, что объектам приходится меньше знать о других частях системы. В результате при модификации других частей об этом требуется сообщить меньшему числу объектов, что упрощает внесение изменений.
Глава 7. Сокрытие делегирования. Мотивировка.

Важно внести ясность в смысл слова неизменяемый (immutable). Если есть класс, представляющий денежную сумму и содержащий тип валюты и величину, то обычно это объект с неизменяемым значением. Это не значит, что ваша зарплата не может измениться. Это значит, что для изменения зарплаты необходимо заменить существующий объект денежной суммы другим объектом денежной суммы, а не изменять значение в существующем объекте. Связь может измениться, но сам объект денежной суммы не изменяется.
Глава 8. Замена ссылки значением. Мотивировка.

В хорошо организованной многоуровневой системе код, обрабатывающий интерфейс пользователя, отделен от кода, обрабатывающего бизнес-логику. Это делается по нескольким причинам. Может потребоваться несколько различных интерфейсов пользователя для одинаковой бизнес-логики; интерфейс пользователя становится слишком сложным, если выполняет обе функции; сопровождать и развивать объекты предметной области проще, если они отделены от GUI; с разными частями приложения могут иметь дело разные разработчики.
Глава 8. Дублирование видимых данных. Мотивировка.

Одна точка входа обеспечивается современными языками, а в правиле одной точки выхода на самом деле пользы нет. Ясность - главный принцип: если метод понятнее, когда в нем одна точка выхода, сделайте ее единственной, в противном случае не стремитесь к этому.
Глава 9. Замена вложенных условных операторов граничным оператором. Мотивировка.

В компьютерах, как и в жизни, иногда происходят неприятности, на которые надо как-то реагировать. Проще всего остановить программу и вернуть код ошибки. Это компьютерный эквивалент самоубийства из-за опоздания на самолет. Хотя я и пытаюсь снова шутить, но в решении компьютера о самоубийстве есть свои достоинства. Если потери от краха программы невелики, а пользователь терпелив, то можно и остановить программу. Однако в важных программах должны приниматься более радикальные меры.
Глава 10. Замена кода ошибки исключительной ситуацией. Мотивировка.

Преимущество исключительных ситуаций в том, что они четко отделяют нормальную обработку от обработки ошибок. Благодаря этому облегчается понимание программ, а создание понятных программ, как, я надеюсь, вы теперь верите, это достоинство, которое уступает только благочестию.
Глава 10. Замена кода ошибки исключительной ситуацией. Мотивировка.

Ральф Джонсон преподал мне важный урок, касающийся исследований: когда кто-то (рецензент статьи, участник конференции) заявляет, что он не понимает, или просто "не врубается", это наша вина. Наша обязанность постараться развить и донести свои идеи.
Глава 13. Проверка в реальных условиях

Это типичная дилемма исследователя, когда современное состояние науки опережает современное состояние практики.
Глава 13. Проверка в реальных условиях

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

Крупный рефакторинг - это способ навлечь на себя катастрофу. Каким бы ужасным ни выглядел беспорядок, приучите себя ограничиваться краями проблемы.
Глава 15. Складывая все вместе

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

Часть 1

Часть 2