"Рефакторинг" Фаулера, "Выделение метода"

[craz]

Та не не уговорим мы его дальше читать)

 

[tz-lom]

Духовность™
книжки нужно читать до конца

 

[Духовность™]

Без конкретных примеров дальнейшее обсуждение не имеет смысла. Я постараюсь подкинуть примеров того о чем говорил.

 

[Духовность™]

Духовность™ синтаксическое обособление участков, обособленных логически.

С таким подходом можно дойти до крайности - любая программа имеет "обособленные логически" участки кода. Как с логикой "низкого" уровня, так и с логикой "высокого" уровня. И обернуть в функции или методы можно каждые 2-4 строчки кода, постепенно оборачивая код до состояния, когда он будет "читаться как стихи". Однако поддерживать этот код становится невыносимо сложно, когда метод А вызывает метод Б, который пользуется методами В и Г, последний вызывает Д. Не встречались с таким кодом? И это все - выделение метода. Теоретически правильный рефакторинг.

 

[Adelf]

Духовность™
Тебе уже советовали дочитать книгу. Там почти в любому рефакторингу есть обратный. И он пытается указать в каких случаях что применять.

 

[AmdY]

Духовность™
читаться должен основной, публичный метод. Тогда у нас есть хорошее название метода и аргументов, которое говорит что делает метод. Перейдя в метод, мы можем прочесть как он это делает. Теперь в случае его некоректной работы мы можем тупо его переписать с нуля, потому что прекрасно знаем что и как должно работать, не вникая в более глубокие данные по его реализации.

 

[whirlwind]

Духовность™ попробуй с тестами. Они будут заставлять тебя думать не на уровне приемов, но на уровне архитектуры вообще. И тогда из 5 extract method ты будешь вынужден extract class, потому что иначе просто задолбаешься тестировать свой ад. Ты получишь практический правильный рефакторинг и стабильный поддерживаемый код.

 

[craz]

Духовность™ попробуй с тестами. Они будут заставлять тебя думать не на уровне приемов, но на уровне архитектуры вообще. И тогда из 5 extract method ты будешь вынужден extract class, потому что иначе просто задолбаешься тестировать свой ад. Ты получишь практический правильный рефакторинг и стабильный поддерживаемый код.

У человека не проблема попробовать я так понимаю - у него проблема восприятия нового... Есть люди подвергающие сомнению любые авторитеты - долго, муторно, но зато знают многое досконально - другое дело надо ли это?

 

[atv]

Духовность™, в сложных случаях удобно программировать сверху вниз, например:

class CalculatePrice
{
	public function start()
	{
		if ($this->isHaveDiscount()) {
			return $this->getInitialPrice() - $this->getDiscount();
		}

		return $this->getInitialPrice();
	}

	protected function isHaveDiscount()
	{
		if ($this->userExceededDiscountLimit()) {
			return false;
		}

		if ($this->productAction()) {
			return true;
		}

		if ($this->purchaseAmountAction()) {
			return true;
		}
	}

	protected function getDiscount()
	{
		if ($this->productAction() && $this->purchaseAmountAction()) {
			return $this->largerDiscount();
		}

		if ($this->productAction()) {
			return $this->getProductActionDiscount();
		}

		if ($this->purchaseAmountAction()) {
			return $this->getPurchaseAmountActionDiscount();
		}
	}
}

Как видишь, реализации низкого уровня нет, только заглушки методов. На этом этапе сосредотачиваешься только на алгоритме высокого уровня. Разве можно сказать, что этот код непонятен и в нём трудно разобраться? Разве имеет значение, стоит в условии вызов метода или непосредственно его реализация из одной строчки? Потом, когда будет реализация, какие-то методы заменятся непосредственно их реализацией, какие-то так и останутся.

Если методы циклично вызывают друг друга, значит это рекурсия, по твоему в одном методе такой алгоритм будет лучше реализовать?

Как-то на работе с коллегой тоже зашёл разговор на тему читабельности кода. Коллега утверждал что ему проще разобраться в 100 строчках одного метода, чем в 10 методах по 10 строчек. Дошли до того, что сели за комп и начали разбираться в каком-то чужом ООП коде. Когда я посмотрел как он это делает, я понял в чём проблема. Дело в том, что восприятие кода полностью опирается на понимание последовательности выполнения кода. В методе на 100 строк коллега мог разобраться, так как там последовательность выполнения понятна, код выполняется строчка за строчкой, не считая условий, когда какая-то часть кода не выполняется. Когда же коллега пытался разобраться в ОПП коде, он просто скролил код туда сюда, просматривая все методы подряд и пытаясь что-то понять из их названия. Тогда я показал коллеге заветные клавиши перехода по методам (Ctrl + B для NetBeans), нашли точку входа в алгоритм (как правило паблик метод с которого всё начинается) и потом за три клика нашли метод, который реализовывал определённую часть алгоритма и разобрались в 10 строчках. Обратите внимание, мы не изучали попутно ещё 90 строчек кода, чтобы найти эти 10.

Отдельный разговор о профилировании кода. Анализировать результат профилирования и оптимизировать гораздо легче имея много небольших методов, чем один на 100 строк. В отдельных случаях, в особо узких местах приходиться сворачивать несколько методов в один большой, чтобы повысить производительность. Но это делается в строго определённом месте, а не по всему проекту, и не может служить оправданием для тех кто сразу лепит большие методы.

 

[whirlwind]

atv мне этот код сразу хочется переписать на strategy. Это как раз перенесет необходимость productAction и purchaseAmountAction на другой уровень - на уровень принятия решения. Предпочитаю сразу разделять алгоритм и механизм выбора соответствующего алгоритма.

 

[флоппик]

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

 

[Ragazzo]

флоппик
хабр прочитал?

 

[флоппик]

Угу. И сразу навеяло, что это тот случай

 

[atv]

whirlwind
Пример кода надуманный и писался за 10 мин. исключительно для этого топика

флоппик
ты про какой случай?