Каков оптимальный обмен между рефакторингом и увеличением стека вызовов?

Question

Я ищу рефакторинг многих больших (1000+ линий) методов в приятные куски, которые затем могут быть протестированы по мере необходимости.

Это заставило меня задуматься о стеке вызовов, так как многие из моих блоков rafactored содержат в себе другие рефакторированные блоки, и мои большие методы могут быть вызваны другими большими методами.

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

Answer 1

За исключением рекурсии, я бы не стал беспокоиться о проблемах с вызовами, пока они не появятся (что, вероятно, не будет).

Что касается рекурсии: он должен быть тщательно реализован и тщательно протестирован независимо от того, как это делается, чтобы это ничем не отличалось.

Answer 2

Я думаю, это технически возможно. Но не то, о чем я буду беспокоиться, если это не произойдет, когда я проверю свой код.

Answer 3

Когда я был ребенком, а компьютеры имели 64 КБ ОЗУ, размер стека вызовов имел значение.

В настоящее время вряд ли стоит обсуждать. Память огромна, кадры стека малы, несколько дополнительных вызовов функций едва ли измеримы.

В качестве примера, Python имеет искусственно небольшой стек вызовов, поэтому он быстро обнаруживает бесконечную рекурсию. Размер по умолчанию - 1000 кадров, но это настраивается с помощью простого вызова API.

Единственный способ запускать стек в Python - это решить проблемы Project Euler, не задумываясь. Даже тогда у вас обычно заканчивается время до того, как вы закончите стек. (100 триллионов циклов занимали бы гораздо больше времени, чем человеческая продолжительность жизни.)

Answer 4

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