E.K.blog

Перемещение метода и/или поля ( Move Method / Move Field ).

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

Выделение класса ( Extract Class ).

    С течением времени, если пренебрегать вторым принципом SOLID(Принцип открытости / закрытости) и давать волю своей лени, даже хорошо спроектированный класс обрастает методами и полями, которые выполняют не совсем функции этого класса и не соответствуют единой абстракции которую олицетворяет класс  (Принцип единой ответственности). Когда у класса появляются дополнительные возможности и обязанности или некоторые методы и поля необходимы для выполнения другой задачи. В таком случае нужно провести рефакторинг 'выделение класса' и вынести методы и поля в новые классы, который будет выполнять эти обязанности. Полученные классы так же должны соответствовать первому принципу SOLID, а не быть просто контейнером для разносортной всяких бездомных методов. 

More...

Refactoring, Architecture refactiring

 Рефакторинг - это изменение кода в лучшую сторону. Улучшения стремятся привести код в соответствие с SOLID принципами.

    По своему масштабу рефаторинги могут проводится в границах следующего масштаба:

• Уровня метода/процедуры/функции
• Уровня отдельно взятого класса
• Уровня взаимодействия объектов
• Уровня ветвления выполнения(условные выражения)
• Уровня интерфейса классов
• Уровня иерархии классов

Рефактори уровня метода/процедуры/функции.

Самый популярный рефакторинг - это Выделение метода(Extract Method).

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

    Плюсы. Имя нового метода станет отличным комментарием поясняющем, что делаю вынесенные операции. Выделенный метод можно использовать в другом месте, а не copy-past-ить код, так проще вносить изменения. Исходный большой метод стал меньше и понятней.

    Минусы.  Мы можем получить ситуацию когда в выделенный метод придется передавать тучу параметров и возвращать специально созданные для этих целей структуры данных. Этого делать нельзя!

    Метод не должен получать больше 4-5 параметров, иначе его сигнатура становится не читаемой. Так что без фанатизма, если не дается кусочек рефакторингу - то и бог с ним. Пример кода.

More...

Refactoring, Architecture refactiring, архитектура

    Из меня вышел чертовски ленивый блогер. В начале января читал Фаулера "Рефакторинг. Улучшение существующего кода", что повлекло немало мыслей в моей голове. В общем и целом Фаулер повествует о том как некрасивый код делать удобным и красивым. Как менять дизайн в лучшую сторону если он не так хорош как мог бы быть. Книжка составлена как сборник рецептов на подобии если видите "это", то надо сделать "то". Пока читал книжку делал заметки, как минимум себе на память как максимум как исходник для статьи. Прошло пол года, а написать написать статью мне все лень. Посему выложу слегка отформатированные заметки.

Мысли по первым двум главам.

О Производительности:

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

    Почти всегда? если вы боретесь за производительность пострадает понятность кода. И наоборот.

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

О Проектировании:

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

More...

Refactoring, Architecture refactiring, deploiment, процесс разработки, архитектура