1

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

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

Вопрос к гуру рефакторинга: по вашему мнению, стоит ли игра свеч? Нужно ли делить 50-строчную фунцию на пять 12-строчных, которые вызываются только в одном месте? Либо, стоит держать уникальный код рядом?

coolsv
  • 1,068
  • 8
  • 20
  • 6
    Хотел ответить, что да, но поймал себя на мысли, что в моем коде попадаются 50-строчные функции, в которых фрагменты подписаны комментариями. Так что мое мнение такое, что должно быть так: с первого взгляда на название должно быть понятно, что функция делает, и с первого взгляда на код, как она это делает. Если это не так, то надо рефакторить. Но вообще это такой вопрос, что у каждого будет свое понятие о красоте кода. – trollingchar Jul 11 '19 at 14:57
  • На пять 12-строчных я бы вряд-ли стал делить, но если есть функционального законченный кусок строк на 20, я бы, скорее всего,, его вынес. Ну и,, как и предыдущий оратор, стараюсь законченные фрагменты в функции разделять пустыми строками и комментариями – Юрий Козлов Jul 11 '19 at 15:01
  • По идее надо разбивать в любом случае. Разбивка делается и для вас и для других разрабов, которые будут код читать. А читаться он должен как книга (только сверху вниз), чтобы не оставалось вопросов что тут написано и для чего даже без комментариев – Алексей Шиманский Jul 11 '19 at 15:02
  • 1
    @trollingchar Достойно ответа, поддерживаю. – Anton Abrosimov Jul 11 '19 at 15:02

1 Answers1

1

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

Многие концепции разработки ПО и вообще проектирования систем ставят простоту реализации на первое место по важности. Например, "Чем хуже, тем лучше" и другие. Рискну распространить понятие "простота реализации" и на простоту чтения кода.

Добавлю еще о том, как можно оценить простоту чтения кода. Можно, например, спросить коллег. Но учитывая субъективность оценки, и то, что наиболее вероятный читатель этого кода - это вы сами (через некоторое время), я бы советовал оценить читабельность кода самостоятельно. В том случае, если есть сомнения в том, что код станет более понятным после рефакторинга, я не советую производить рефакторинг, пока сомнения не исчезнут. Этим вы сэкономите время на более полезные правки.

Vladimir Pankov
  • 201