Пользователь
0,0
рейтинг
22 марта 2013 в 16:53

Разработка → Код с душком (рефакторинг М. Фаулера) tutorial

Всем привет.

Небольшая шпаргалка для новичков, и всех остальных кто забыл, по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.


Зачем? Когда и как?


Тут особо углубляться не хочется, т.к. всё зависит от многих факторов: знания, необходимость, сроки, конкретный проект и т.д. и т.п.
Главное чего стоит не забывать и придерживаться, что всё хорошее, полезно в меру.

Код с душком


От чего надо избавляться в процессе рефакторинга и при написании новых программ.

  1. Дублирование кода.
  2. Длинный метод.
  3. Большой класс.
  4. Длинный список параметров.
  5. Расходящиеся модификации.
    Если при добавлении нового функционала приходится модифицировать несколько методов и значительную часть кода в классе.
  6. Стрельба дробью.
    Если при добавлении нового функционала приходится вносить одинаковые изменения в большое число классов.
  7. Завистливые функции.
    Метод интересуется больше не тем классом, в котором находится, а другим.
  8. Группы данных.
    Похожие группы данных, в разных частях кода.
  9. Одержимость элементарными типами.
  10. Операторы типа switch.
    Незабываем про ООП.
  11. Параллельные иерархии наследования.
    Дублированный код.
  12. Ленивый класс.
    Не используемый или содержащий мало методов (оставшийся после рефакторинга/проектирования).
  13. Теоретическая общность.
    Переизбыток абстракциями тоже вреден.
  14. Временное поле.
    Если у класса есть переменные, которые используются в одном методе из пяти, то лучше эту переменную передавать в тот самый метод через параметр, а не через конструктор или какой другой способ.
  15. Цепочка сообщений.
    Глубокая последовательность вызовов до необходимой информации, через объекты по иерархии классов.
  16. Посредник.
    Большую часть методов класс делегирует другому классу.
  17. Неуместная близость.
    Классы не должны выставлять наружу закрытые части, т.е. внутреннюю кухню. При наследовании, подклассы должны знать минимум необходимой информации о родителе.
  18. Альтернативные классы с разными интерфейсами.
    Дублирование логики.
  19. Неполнота библиотечного класса.
    Не бойтесь расширять функционал библиотечных классов: extension методы или декорировать объект библиотечного класса.
  20. Классы данных.
    Делите на логические единицы. Доступ на изменение данных должен быть осмысленным.
  21. Отказ от наследства.
    Если наследнику нужна лишь малая часть информации (данных, методов) о родителе.
  22. Комментарии.
    Свидетельство кода с «запахом», нужно рефакторить. Возможно код остаётся на будущий рефакторинг или описывает сложные манипуляции

Я не привожу решения этих проблем, поскольку за базу можно взять, то что описано в книге. А с учётом опыта, что-то своё.
Читайте далее, техника: Составление методов.

Какой профит.


Простота в поддержке и понимании кода, а также в написании тестов.

Послесловие


Добавлю, что это лишь необходимый минимум.
В зависимости от сложности проекта и архитектуры в нём, на Арену будут выходить более тяжеловесные принципы, паттерны и методологии.
Денис @den_labs
карма
14,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (8)

  • +1
    Ленивый класс, это не неиспользуемый класс, это класс, у которого слишком мало методов.
    • 0
      Что плохого в таком классе?
      • +1
        А это все зависит от того, нужен ли он таким. Как правило такие классы, могут остаться после рефакторинга.
    • 0
      Да, вы тоже правы, поправил описание.
  • 0
    По случайности вчера был на одном мероприятии, где рассказывали о рефакторингею В конце мероприятия раздовали такие карты

    Интересная безделушка, содержащая пункты из поста.
    • 0
      Простите за русский. *рефакторинге и раздавали
    • 0
      На мероприятии не был, но фишка хорошая.
      Интересно, можно ли купить у нас такие карты.
  • +1
    По теме рефакторинга.

    Напомню, что аж 16 человек высказали желание весело порефакторить некоторый Javascript-код, чтобы потом посмотреть на различные подходы друг у друга. Но ни одной практической итерации не произошло ни на одном из 2 предложенных участков кода. Чтобы в следующий заход так не случилось, нужно что-то конструктивное придумать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.