hackbu12
154
2021-09-13 00:52:24 작성 2021-09-13 01:11:12 수정됨
4
212

재귀함수 질문] 전역변수 vs 파라미터


요즘 코테를 많이 보고 있는 취준생입니다.

프로그래머스에서 보는 재귀함수문제 풀이들 보면 파라미터와 전역변수 사용이 제각각입니다.


예를 들어 문제 상황이 이렇다고 가정하겠습니다.

재귀함수 내 변수 A가 목표치 N이 될때까지 재귀함수가 어떠한 행동을 실행한다고 가정하겠습니다.


N은 Solution함수에 파라미터로써 제공됩니다. 그렇기에, 같은 클래스 내 재귀함수에서 참조할 수 없는 영역이죠,


DP처럼 목표치 N이 수정되어야 하는 경우라면 상관없습니다. 당연히 파라미터로 주는게 맞겠죠.

하지만, 수정이 필요없다면?...


저는 이제껏  수정이 필요 없는 변수는 전역변수로 private static으로 생성 한다음, 해당 Solution함수에서 전역변수를 초기화 해주고, 그것을 재귀함수에서 참조해서 사용했습니다. 이유는 재귀함수에 N을 파라미터로 주면 함수가 호출될 때마다 스택에 N을 생성하게 메모리나 자원 낭비가 심하다고 생각했습니다.


그런데, 사람들을 보면 잘하는 고수들도 그냥 재귀함수에 넣어서 계속 돌리더라구요.


정답이 무엇인지 모르겠습니다. 고수분들 도와주세요..




0
  • 답변 4

  • 엔지니어의꿈
    900
    2021-09-13 03:14:25

    정확히 어떤 상황인지 어떤 코드인지 몰라 정확히 말할 수 없지만 callstack을 생각해야 할 정도로 performance가 필요하면 재귀 함수 말고 루프로 함수를 짜겠죠. 기본적으로 global variable랑 mutation은 나쁘다고 생각하면 좋습니다. 따라서 그냥 패러미터로 넘기는게 좋습니다. 그리고 최적화에 대한 팁은 실제 성능성 문제가 발생한게 아니라면 과도한 최적화는 필요 없다는 것 입니다. 고로 재귀함수를 쓰면서 메모리 용량을 걱정하는 건 이치에 맞지 않는 것 같습니다. 제가 질문을 잘 이해한게 맞는지 모르겠으나 n이 primitive 타입이라면 메모리를 걱정할 이유가 없을테고 object라면 reference로 넘기니 상관 없겠죠. 그리고 global variable을 만들어 closure로 사용하면 함수를 생성할 때 closure를 따로 만들어야 합니다. 일반적으로 closure는 사용할수록 성능상 bottle neck이 됩니다. 


    대부분의 알고리즘 문제는 잡다한 최적화가 필요하지 않습니다. 최적화가 필요하다면 적절한 자료구조를 활용해서 O n을 줄여야지 잡다한 테크닉은 구글 같은 기업에서 0.001초가 수백억의 가치를 지니거나 콘솔의 성능을 영혼까지 짜내야 하는게 아닌 한 가독성이 과도한 최적화 보다 우선됩니다.

  • 꿈의연봉1800
    175
    2021-09-13 04:54:53 작성 2021-09-13 04:59:47 수정됨

    얘기를 들어보니까 자바같은데

    일단 풀던 코테 멈추시고

    레퍼런스, 스택, TCO, GC가 뭔지부터 보고오세요

  • yeori
    2k
    2021-09-13 07:56:02

    코테로 한정해서 얘기하자면 변수를 전부 전역으로 때려박든 함수의 인자로 달고 다니든 크게 고민할 지점이 없습니다.

    (코테의 목적 : 어떻게 해서든 답만 때려맞추면 됨)

    "전역 변수를 피하라"는 말이 있긴한데, 이거는 여러 사람이 함께 작업할때의 맥락에서 의미가 있습니다. 어디서든 누구나 볼 수 있는 변수라면 누군가 그 변수를 잘못 사용해서 애플리케이션이 망가지고 디버그도 매우 어려워지거든요.

    이런 경우 변수를 wrapping해서 최대한 격리하는 식으로 코딩해야 서로 편합니다(OOP같은게 다 이런 맥락에서 나온 개념들)

    물론 코테용 코드도 전역 변수를 피하면 디버그할때 확실히 이득을 볼 수 있습니다. 언어나 개발 도구에 따라서 저~어~기 위에 있는 전역 변수를 보기 힘든 경우도 있거든요. 함수의 인자로 달고 다니면 디버그할때 보기 편하니까, 인자 갯수가 늘어나도 이득이라 생각하면 스택 메모리를 좀 더 쓰더라도 감내할 수 있습니다.

    아주아주 옛날에는 메모리나 CPU속도같은 물리적 환경이 지금처럼 좋지 않아서 숏코딩이라는게 유행했었습니다. 무슨 말이냐면 같은 목적을 달성할때 변수를 하나라도 더 줄이고 라인수를 한줄이라도 더 줄여야 좋은 코드다! 이런 시절이었는데...

    지금은 뭐 메모리 부족을 걱정하는 시절이 아닌지라 공간을 더 쓰더라도 명확하게 의도를 잘 보여주는 코드가 좋다는 평가가 대세인듯합니다.

    결론은 "정답은 없다!"


  • hackbu12
    154
    2021-09-13 13:46:20

    고맙습니다! 정말 큰 도움이 되었습니다.

    아직 기본기가 많이 부족한가 봅니다.. 짚어주셔서 정말 감사합니다.

  • 로그인을 하시면 답변을 등록할 수 있습니다.