просмотров:2018 | комметариев: 2

Мартин Фаулер "Рефакторинг: улучшение существующего кода"


В данный момент, как раз занят прочтением книги Фаулера "Рефакторинг". В связи с этим, решил сюда записывать некоторые соображения, цитаты, примеры. Думаю, таким образом лучше понять/запомнить материал и будет потом что-то вроде небольшой шпаргалки.

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

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

Задачи обобщения   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

При рефакторинге лучше двигаться маленькими шагами

просмотров:2018 | комметариев: 2
rrrFer
10 января 2015, 07:26
О, интересная статья, чуть дополню :)
1) Книжка Роберта Мартина по рефакторингу гораздо интереснее;
2) Книжка Фаулера на 100% капитанская. Из интересных моментов я там отметил лишь:
- покрывать тестами не все, а лишь то, что может сломаться (это совет, но он дискуссионный - все тот же Бек не согласен);
- цитата Бека "Рефакотринг не добавляет новые возможности, но новые возможности не должны менять структуру кода";
- рефакторинг стоит проводить при: добавлении функции, исправлении ошибки, разборе кода;
- CRC-карты (интересная штука);
- Рефакторинг "расходящиеся модификации" - класс меняется слишком часто, возможно у него слишком большая зона ответственности. Зона ответственности = причина для изменения. Класс должен иметь одну причину для изменения;
Губарев Михаил
10 января 2015, 10:49
Спасибо за толковое мнение о книге и дополнение к статье. Про Зону ответственности и CRC-карты нужно будет прочитать.
Да, в книге Фаулер порядком капитанит. Много воды, но все равно для меня эта книга полезная, т.к. упорядочивает накопленный багаж знаний.
Благодарю за наводку, Роберта Марта почитаю.
просмотров:2018 | комметариев: 2

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

Ваше имя:
 
Текст комментария:
 
+ 1 =