Мартин Фаулер "Рефакторинг: улучшение существующего кода"
В данный момент, как раз занят прочтением книги Фаулера "Рефакторинг". В связи с этим, решил сюда записывать некоторые соображения, цитаты, примеры. Думаю, таким образом лучше понять/запомнить материал и будет потом что-то вроде небольшой шпаргалки.
Рефакторинг как термин означает изменение исходного кода программной системы без изменения ее внешнего поведения. Не нужно путать рефакторинг и оптимизацию. Оптимизация имеет, можно сказать прямо-противоположные цели. Цель оптимизации увеличить быстродействие системы, без изменения поведения программы, что зачастую приводит к затруднению понимания кода.
Рефакторинг же, должен сделать код программы более понятным. Обычно проводят рефакторинг, если логика программы становится слишком запутанной или перед реинжирингом(наращивание функционала) или когда код просто глючный и нужно найти корень зла
Задачи обобщения 07 января 2015
в двух подклассах есть одинаковые поля - переместите поле в родительский класс (та же рекомендация про методы и конструкторы с одинаковым функционалом)
в родительском классе есть методы(поля) относяшиеся только к некоторым из его подклассов - переместить в эти подклассы. Подкласс должен ВСЕГДА следовать интерфейсу родительского класса.
классе есть функционал который используется в редких случаях - создайте класс для этого подмножества функций
имеются 2 класса со сходными методами - создайте для них обший родительский класс, с обшим функционалом. Часто бывает, что методы незначительно отличаются, в этом случае нужно выделять часть метода в отдельный метод и переместить его в родительский класс
родительский класс и подкласс мало отличаются - объедените их в один
подкласс использует только часть интерфейса родительского класса - убрать наследование, сделать отдельным классом, а класс бывшего родителя передавать в конструктор(это к примеру, тут есть варианты) потому что Подкласс должен ВСЕГДА следовать интерфейсу родительского класса.
28 декабря 2014
Не следует в метод передовать большое кол-во параметров. Т.к. такой код трудно читать и модифицировать. Как вариант передавать объект или массив данных. Также неплохой вариант передавать несколько массивов с данными разделенными на группы.
В случае передачи всего объекта нужно задуматься о том, что зависимости между разными объектами это не есть гуд. Тут нужно понимать насколько критична такая зависимость.
Также не нужно передавать в метод лишних параметров. Наприме те параметры, которые можно легко "вычислить" внутри метода.
11 октября 2014
Если есть несколько методов которые выполняют похожие действия, но с разным значениями в теле метода, то лучше создать один метод и передавать значения в качестве параметров.
11 октября 2014
Если есть метод, который берет некие данные, а так же изменяет их, то нужно его разделить на 2 метода. Один берет данные, второй изменяет
Рефакторинг и производительность 12 января 2014
Рефакторинг может замедлить действие программы. Из этой ситуации есть следующий выход.
Хорошее разделение программного кода на компоненты дает выигрыш в двух отношениях. Первое появляется время которое можно потратить на оптимизацию, тк. имея хорошо структурированный код легче добавлять новый функционал. Второе, тк. код разделен на множество небольших методов, профайлер указывает на конкретные участки кода, которые проше настроить.
Итак, после того как код хорошо структурирован, программа запускается через профайлер. Обычно нужно оптимизировать несколько узких мест и все. Не более 90% кода обычно. Не нужно гадать, нужно точно знать где узкие места, поэтому запуск через профайлер обязателен.
02 января 2014
Код с душком:
1. Дублирование кода
2. Длинный метод
- если ощущается необходимость что-то прокомментировать, нужно этот код выносить в отдельный метод
- даже одну строку нужно выделять в метод, если она нуждается в разъяснениях
26 декабря 2013
Несколько слов об оптимизации, о поиске узких мест. Даже если вы отлично знаете как работает система, не гадайте на кофейной гуще, а производите замеры. В 9 случаях, из 10 полученная информация покажет, что вы ошибались.
26 декабря 2013
Рефакторинг не следует оставлять на потом. Им следует заниматься понемногу и постепенно.
24 декабря 2013
Небольшое изменение, тестирование, небольшое изменение, тестирование, небольшое изменение, тестирование. Именно такой должен быть ритм рефакторинга, чтобы он был быстрым и безопасным
24 декабря 2013
В большинстве случаев, метод должен принадлежать объекту, данные которого он использует.
22 декабря 2013
Временные переменные не есть гуд в длинных методах. От них нужно избавляться дублированием метода результат которого присвоен временной переменной. Да, да за счет снижения производительности. (стр 37)
22 декабря 2013
При рефакторинге лучше двигаться маленькими шагами



