전재형
2017-05-05 01:48:29
58
21294

그대가 엉터리 개발자라는 신호들


http://www.zdnet.co.kr/column/column_view.asp?artice_id=20141024082051


공감가는 글을 발견하여 공유합니다.


간추리자면


1. 코드를 머리로 돌릴 수 있는 능력의 부재다.

2. 자기가 사용하는 언어의 프로그래밍 모델을 제대로 이해하지 못하는 것이다

3. 학습능력의 부재다. 중요한 것은 공부를 하는 방법, 즉 메타 지식에 해당하는 학습능력 자체다.

4. 포인터(pointer)에 대한 이해부족. 최근의 추세에 맞게 재구성하자면 타입시스템(type system)에 대한 이해부족이라고 이야기해도 좋을 것이다.

5. 재귀(recursion) 알고리즘을 이해하는 능력이 없는 것이다.

6. 코드에 대한 불신이다. 엉터리 개발자들은 정작 믿지 않아야 하는 코드를 신뢰하고, 믿어도 좋은 코드를 불신한다.


저도 뜨끔하는 부분이 있네요 ㅎㅎ.. 특히나 6번항은 아직 저도 숙달이 덜 되어서, 무엇이 중요한 코드인지 이해하는데 오래걸리는것같아요.





8
  • 댓글 58

  • 장지락
    679
    2017-05-05 07:15:33 작성 2017-05-05 07:20:57 수정됨

    1번은 동의하기 어렵군요!

    "짧고(간단) 명료하고 (실행적 시공간 및 구현적 의미의) 효율적인 코드"라는 전제가 없다면, 코드를 머리로 돌려보는 것은 고문입니다.

    그냥 짠 사람한테 일을 넘기거나, 동일한 기능의 코드를 다시 짜는게 더 빠를 때가 종종 있는데 이 판단을 신속히 잘하는 사람이 능력잡니다.


    5번 재귀호출 알고리즘이 필요할때도 있지만...

    입력 N수가 엄청나게 커지더라도 작동해야 하는게 상용 소프트웨어이므로 대안이 없을 경우를 제외하고 보통 반대합니다.

    그리고 특출한 능력자들보다 평범한 사람들이 훨씬 더 많습니다. 재귀호출을 하면 곧 바로 이해하는 사람들 얼마 없습니다.


    6번은 좀 웃긴 이야깁니다. 엉터리 개발자는 믿고 안믿고를 떠나서 무슨 짓이든 서슴없이 합니다!

    그래서 '엉터리' 잖아요?

    -1
  • 욥욥욥
    943
    2017-05-05 15:40:20

    공감합니다

    -1
  • 개나소나고생
    8k
    2017-05-06 16:03:24

    저도 윗분처럼 6번은 공감을 못하겠네요.더구나 레거시 코드를 가지고 유지보수 하시는 분이라면 6번을 고지 곧대로 믿으면 탈이 나더라구요.

    -1
  • aeba
    2017-05-06 18:46:38

    @장지락

    "입력 N수가 엄청나게 커지더라도 작동해야 하는게 상용 소프트웨어"

    그래서 꼬리재귀를 쓰는거 아닌가요…

  • 장지락
    679
    2017-05-07 10:42:58

    aeba//

    지금껏 15년동안 일하면서 재귀호출로 문제를 해결한 경우 거의 없습니다. 오히려 문제 유발하는 상황이 더 많아 걷어내는게 더 많았지요.

    꼬리재귀 방식도 사용하는 언어 및 컴파일러 최적화 스펙등을 잘 살펴야 하는 것이고 이런방식은 대안이 있으면 굳이 사용할 필요가 없다는게 제 개인경험상 입장입니다.

  • aeba
    2017-05-07 11:39:28

    @장지락

    gcc/g++은 TCO를 해주긴 하지만 정말 해준건지 어셈블리를 뜯어보지 않으면 모르고(일반적인 방법으로는 확인할 길이 없고), 자바나 파이썬은 아예 안해주니까 그런 언어에서는 루프를 쓰는게 맞습니다. 그런 언어로는 트램폴린같은 테크닉을 쓰지 않으면 스택이 터지기 마련이니 그럴 정도면 재귀를 더 잘 지원하는 다른 언어를 사용하는게 맞겠죠.

    그래도 하노이의 탑이나 꼬리재귀조차 이해시키는데 한계가 있는 사람은 문제가 있다라는 원글에는 동의합니다. 실제로 개인이 쓴다 안쓴다를 떠나서, 무언가 배우는거에 대한 태도의 문제라고 느껴지기도 하고요.

    그리고 요새들어 함수형 패러다임이 뜨고 있어서 재귀에 대한 이해가 더 중요해지는 것 같습니다. Java 8에 새로 등장한 스트림만 봐도 알 수 있죠.

  • 장지락
    679
    2017-05-07 13:34:24

    몇몇 항목들로 타인 그것도 신입/입문자들 공격하듯 평가하기 보다 소속집단과 그곳에 소속한 비겁한 자신에 쓴소리를 할 수 있는 용기, 스스로 솔선할 수 있는 자존감, 신입이나 실력이 모자라는 자들에대한 이해와 공감이 더 필요하다 생각해요!

    더 쉽게 말하자면 전 "어떤 동료든 없는것 보단 있는게 좋다"가 제 입장이에요. 동료가 없다면 모든 일과 책임은 오롯이 당신만의 것이고 반면 평가와 급여는 시간이 지날 수록 "혼자도 할수 있는 일"로 치부될 겁니다.

  • 전재형
    2017-05-07 17:34:40

    재귀는 거의 필수적이고 기초적인 알고리즘 접근방법이 아닌가요?


    다음과 같은 로직이 필요한 경우. 어떻게 설계하시겠어요?


    특정 디렉토리(가령 C드라이브)에서 파일확장자가 docx인 모든 파일을 찾아라.


    위와 같이 단순한 문제를 재귀가 아닌 반복문으로 접근한다면?

  • 전재형
    2017-05-07 17:37:37

    저는 주변동료가... 위문제를


    깊이 10까지의 디렉토리 탐색을 1번 탐색, 2번탐색... 10번탐색 이렇게 까지하고 그만두는

    코드를 본적 있어요...


    위를 보면서 '이건 아니잖아'라고 생각을 했어요...

  • 더미
    16k
    2017-05-07 18:46:56

    재귀가 강력하면서도 문제가 발생할수 있는 방법이긴 하죠..

  • 다시시작
    659
    2017-05-08 11:21:48

    전 초특급 엉터리군요..

    1~6까지 뭐하나 확실히 난 아니다 라고 말할수 있는게 없네요 ^^;

  • iops
    1k
    2017-05-08 13:48:47

    당연히 하위 디렉터리를 찾는거와 같은 트리 순회 구조에서는 재귀를 써야하지만

    일반적인 프로그램에서 이런 재귀를 쓸일이 사실 거의 없습니다.

    실제 세계에는 애초에 여러군데를 scan해야 하는 케이스가 솔직 많지 않잖아요.

    만일 읽는다 하더라도 읽어야 하는 폴더를 비동기로 읽게 설계해야지 재귀로 느리게 한번에 다 읽게 하는건 문제가 있지요.

    오히려 잘못된 재귀를 남용하면 stackoverflow발생만 증가시키죠. 물론 FP에서는 필요하겠지만요.

    내가 데이터베이스 btree를 만든다던지 검색엔진 trie를 만든다던지 윈도우 탐색기를 만든다던지 하지 않는다면 더 볼일없는게 재귀입니다.


    너는 그런거도 모르니 엉터리야 라는 글에는 저는 동조할 수 없네요.

    -1
  • 몰라요
    71
    2017-05-08 17:18:49

    저도 6은 살짝 갸우뚱하네요.. 

    하위 디렉토리 파일탐색이야 기본 API에서 제공을 해주니 직접 짤일이 있을까싶네요 




  • 전재형
    2017-05-08 23:18:51

    두고두고 쓰는게.. 재귀인데 거의 쓸일이 없다니요.


    물론 재귀가 하는 일을 반복문으로 커버가능한 영역이 많다는것을 알고 있습니다.


    하지만 재귀를 쓰는 가장 강력한 이유는

    로직을 더 명확히 하기 위해서이죠.

    로직의 리더빌리티라고 표현해냐 할까요.



  • 전재형
    2017-05-08 23:21:10

    함수형 프로그래밍에서 반복문을 싸그리 재귀로 대체하거나 하는 것도 같은 이유라고 알고 있습니다.

  • 전재형
    2017-05-08 23:23:00 작성 2017-05-08 23:24:57 수정됨

    조금더 문제를 확장시키면, 더 좋은 코드를 짜기 위한 노력이라고 표현하는게 맞을까요?


    OOP를 굳이 왜 쓰나요? 절차적으로 프로그램을 만들어도 동일 기능이 잘돌아가는데...


    그리고 굳이 자바1.8의 스트림을 굳이 쓸 필요 있나요.. 그냥 반복문으로 다 해결되는데..


    위와 같은 맥락에서 재귀는 매우 강력한 자원임에 틀림없는 것같습니다.

  • 장지락
    679
    2017-05-09 09:26:10

    전재형//

    오직 함수형 언어 뿐인듯 말씀하시네요! 그럼 제목에 "함수형~" 수식을 덧붙였어야 되는거 아닙니까?

    타인을 평하는 글을 올리시면서 타인의 의견을 경청하지 않을 요량이라면 왜 올리신 건지?

    -1
  • iops
    1k
    2017-05-09 10:15:59

    저는 재귀자체를 부정하는 것이 아니라 단지 재귀하나 모른다고

    엉터리 개발자라는 수식을 붙이려는게 잘못됬다는 겁니다.

    실제 작성한 완성된 프로그램에서 재귀가 들어간 코드가 얼마나 되나요? 아마 10%? 아마1%도 안될거라 생각됩니다만 그 1%도 안되는 코드 때문에 엉터리 소리를 들어야 할까요?

    마치 예전에 웹개발자도 개발자인가요? 자바스크립트도 언어인가요? 논쟁과 같은 느낌이 듭니다.

    재귀도 못쓰는 하노이탑도 못짜는 개발자는 엉터리 개발자다 라는 의견에 동의를 못한다는 뜻입니다.


    그리고 실제로 재귀를 멍청하게 사용하는 코드도 너무 많이 봐왔습니다.


    서버가 제대로 기동했는지 체크하기 위해 재귀를 쓴다던지 ajax로 데이터를 받아왔는지 체크하려고 재귀를 돌리는 코드도 봤기때문에...

    재귀는 java에서 쓰기전에 반드시 우회할 수 있는 방법이 있는지 먼저 곰곰히 생각해보고 정 없다면 써야합니다. 재귀가 뭐 엄청 대단한거도 아니고 이걸로 그레이드를 나누려고 해서는 안됩니다.


    작성자분이 스트림하고 비교를 했는데 그럼 스트림 API도 모르면 엉터리 개발자다 라고 주장하면 그건 맞는건가요? 당연히 아니겠지요.

    OOP처럼 언어 기반 전반에 걸쳐서 깔려있는 철학을 모른다는것도 아니고 겨우 재귀 안쓴다고 엉터리 개발자라니 그 주장에 동의하지 못한다는 것입니다.

  • 변기
    18
    2017-05-09 11:29:37

    마틴 아저씨가 코드는 잊어버리고 읽기 좋은 코드를 짜라고 했단 말이에요. 누구 말을 따라야돼

  • 전재형
    2017-05-09 11:57:16 작성 2017-05-09 11:58:41 수정됨

    장지락 

    어째서 이야기를 그렇게 끌고 가는지 모르겠네요.


    제가 긁어온 글에서. 저 원작자 아저씨가

    "재귀정도는 알아야 좋은 개발자지."라고 얘기했고

    당신은 아니다. 굳이 모른다 하더라도 실력없는 개발자라고 말할수 없다. 라고 했고요.

    거기에 대해서 저는 이런이런 상황에서 그리고. 함수형 언어에서. 스트림에서 모두 재귀를 활용하고 있으며, 재귀를 반복문으로 대체해서 쓸때보다 재귀를 쓸때 얻는 이득이 명확하다라고 얘기합니다.


    이 이야기의 흐름이 당신이 볼때는 남의 말을 잘 듣지않고 내 이야기만 하는 사람이 하는 말로 보입니까?


  • 전재형
    2017-05-09 11:59:54

    당신응 당신의 경험을 토대로 별로 쓰임이 없었다 였고.

    저는 저의 경험을 바탕으로 많이 쓰이던데. 왜 안 쓴다고 말하는거지. 라고 말하고 있는 거죠

  • 전재형
    2017-05-09 12:01:53

    그리고 저는 제 얘기만 하면 설득력이 없을까봐.

    재귀가 쓰여야만 하는 예제도 가져오고. 다른 언어가 어덯게 쓰는가도 얘기하고. 자바의 스트림이 재귀를 활용한다도 얘기했는데...


    감정섞인 말은 안하고 싶습니다만.

    장지락씨의 말은 저를 감정적으로 공격하는 것처럼 들리네요

  • 욥욥욥
    943
    2017-05-09 13:44:32

    같은 글을 보고도 사람에 따라 관점이나 의견이 다르군요..

    일단 본문은 크리스 웨넘이라는 사람이 이야기하고 임백준님이 본인의 경험과 일치한다고 게시한 칼럼입니다.

    위 두분이 오키에서 많이 언급되는 우리나라 같은 개발 환경을 얼마나 알거나 경험했을지는 모르겠지만 댓글에 나온 내용중 제 의견을 적어봅니다


    <첫 번째>

    첫 번째는 코드를 머리로 돌릴 수 있는 능력의 부재다. 엄청난 분량의 코드를 생각만으로 돌릴 수 있는 사람도 있고, 아주 짧은 코드만 돌릴 수 있는 사람도 있는데, 어쨌든 코드를 머리로 돌리는 능력은 개발자에게 기본이다. 이것은 바둑을 두는 프로기사에게 바둑판 위에 놓이지 않은 미래의 수를 읽어내는 능력이 필요한 것과 마찬가지다.

    코드를 머리로 돌려야할 경우가 있습니다.

    당장 생각나는 것만 적어봅니다.

    1. 개발전 코드 구상

    2. 추가 개발 시 문제점 예상

     - 위 두개는 중요하죠. 미래의 수를 읽어내는 것은 매우 중요합니다.

    3. 오류가 발생할 경우

     - 오류가 발생하면 뜬금없는 곳을 보면서 헤매는 사람이 있고

       예상되는 코드를 콕 집어내는 사람이 있습니다.

       물론 다른 능력도 연관 있을 것이고 결국 코드를 봐야겠지만

       머리속으로 순간적으로 코드를 돌려볼 수 있으니 가능하다고 생각합니다.

       그 분량의 정도에 따라 차이도 있을 것입니다.


    <다섯 번째>

    다섯 번째는 재귀(recursion) 알고리즘을 이해하는 능력이 없는 것이다. 이것은 맨 처음에 보았던 머리로 코드를 돌리는 능력과 밀접한 관련이 있다. 재귀를 이용해서 정수의 팩토리얼 값을 구하는 정도는 대부분의 개발자가 어렵지 않게 이해한다. 피보나치수열까지도 괜찮다. 트리구조의 노드를 순차적으로 방문하는 알고리즘도 기본적인 것까지는 무리 없이 이해한다.

    하지만 하노이의 탑과 같은 알고리즘이 등장하면 숨이 막히기 시작한다. 꼬리재귀(tail recursion)가 왜 효율적인지, 일반적인 재귀 알고리즘을 어떻게 꼬리재귀 알고리즘으로 변환할 수 있는지 등을 이야기하다보면 한계를 느낀다. 이런 사람들은 개발자가 되어서 실전에 배치되어도 운영체제의 루프백(loopback) 주소라는 개념을 이해하지 못해서 애를 먹는다. 재귀라는 알고리즘의 작동방식이 머릿속에서 그려지지 않는 탓이다.

    언쟁 하시는 부분인데 이 내용은 재귀 알고리즘의 이해인데요..

    윗 분들 모두 재귀 알고리즘을 이해하고 계신 것 같네요.

    현재 언쟁은 본문의 알고리즘 이해가 아닌, 장단점이 이거니 써야한다 말아야한다는 좀 벗어난 언쟁이 아닌가 싶습니다.

    모든 방법론이나 알고리즘, 라이브러리들은 좋은 점이 있지만 사용함에 있어 적절하고 주의해야할 부분이 있습니다.

    주의할 점을 잘 고려해서 사용해야하고 그것은 재귀도 마찬가지입니다.

    분명히 필요한 곳이 있을 것이고, 문제가 되면 조건을 잘 주거나 다른 방법을 사용해야 합니다.

    사용을 하던 안하던 이해하지 못하는 개발자가 문제가 있다는 거에는 공감합니다.


    <여섯 번째>

    마지막은 코드에 대한 불신이다. 엉터리 개발자들은 정작 믿지 않아야 하는 코드를 신뢰하고, 믿어도 좋은 코드를 불신한다. 유닛테스트 코드를 작성하라고 시키면 실제로 검사되어야 하는 코드를 테스트하는 것이 아니라, 언어자체의 문법이나 라이브러리 코드의 API를 확인하는데 시간을 보낸다. 버그 투성이인 자신의 코드에 애착을 품고, 철저하게 검증된 라이브러리 코드를 의심한다.

    레거시 코드를 믿으라는 말이 아닙니다.

    자신의 코드가 아니라 검증된 언어나 라이브러리를 의심하는 것인데요.

    최근에 WEB-INF 하위에 대한 판단이나 mybatis 가지고 주장하시는 분이 비슷한 사례 같습니다.


    그리고 뭔가 평가한다는 식이면 예민해져서 욱하는 분들이 있는데

    이런 글 제목은 농 섞어서 약간 자극적으로 많이 하잖아요?

    본문에 앞뒤로 잘 둘러(?) 놓았습니다.

    이러한 신호를 이야기하는 것은 우리 주변에서 누가 엉터리 개발자인지 골라내자는 것이 아니다. 오히려 좋은 프로그래머가 되기 위해서 누구나 거쳐 가는 단계라고 보는 편이 정확할 것이다. 우리는 모두 한 때는 (어쩌면 지금도) 엉터리 개발자였다.

    ...

    다시 한 번 말하지만 이 글의 목적은 엉터리 개발자를 추궁하자는 것이 아니다. 좋은 프로그래머가 되기 위해서 우리가 밟아온 과정, 혹은 앞으로 밟아야 하는 과정을 환기하여 다 같이 행복한 프로그래밍을 하자는 것이 목적이다.

    엉터리라고 평가한다기 보단 찔리거나 안찔리거나 생각해보고 환기해보자는 글이니 너무들 기분 나빠 마세요 ㅎㅎ


    그나저나 드디어 오늘 대선이네요

    투표 합시다~

  • 장지락
    679
    2017-05-09 14:11:04 작성 2017-05-09 16:31:58 수정됨

    전재형//

    1. 제 댓글 어떤 부분에서 공격적 감정을 느끼셨나요?

    2. 본문에서 말하고 싶은 주제/대상은 매우 광범위하고 복잡한 팩터를 가졌는데 제시한 사례는 오류/반론은 없는가? 과연 정말로 일반화 시킬 수 있는가요?

    3. 엉터리 개발자냐 아니냐 등 처럼 자질에 대한 기준정보를 논하는데 고민이 너무 없지 않은가요?

    즉, 개발자 등급을 판정함에 있어 "리컬시브 호출"이 왜 기준으로 들어가나요? 백보 양보해서 기준으로 넣는다고 하고 보면 기존 절차형 언어들에서 이미 사용성이 많지 않았고 그래서 반론의 여지가 있지요?

    4. 님 댓글에서 이미 언급했듯 훌륭한(좋은) 개발자가 갖춰야 하는 항목으로는 괜찮지만 엉터리냐 아니냐의 기준으로는 적합하지 않는 다는게 제가 말하고픈 핵심 이야깁니다. 즉, 상대적 개념으로 훌륭한 개발자와 평범한 개발자로 구분할 순 있어도 엉터리 = 쓸모없는 = 해고해야 할 개발자로 판별하는 것 처럼 한 인간의 삶에 지대한 영향을 주는 행위의 평가 기준이라고 하기엔 너무 무리가 있다는 것이죠!


    -1
  • 전재형
    2017-05-09 15:04:00

    장지락//

    제가 공격당했다고 느꼈던 멘트는 다음입니다.

    "타인의 의견을 경청하지 않을 요량이라면 왜 올리신 건지?"


    조금 과장하자면.. "너는 다른 사람 말을 듣는 능력이 없어"라고 하는 것처럼 들렸던 멘트였습니다.


    말씀하신 것처럼 글을 "엉터리"의 기준 = "짤라야 하는 사람"의 기준으로 삼는다면, 아닐 수 있다고 생각합니다.

    저는 반대로 글을 읽을 때, "엉터리" 개발자로서가 아니라 "좋은 역량을 가진" 개발자로서의 기준으로 글을 봤던 것같네요.

  • 전재형
    2017-05-09 15:05:30

    어짜피. 글의 원작자 가진 개발자의 기준이기 때문에

    각 개발자마다 자신의 기준이 다를수 있을 텐데..


    제가 가진 역량을 비추어 어디가 모자란지 판단하는 기준으로 삼고자 했을 때

    참고가 되는 글이어서 게시했어요.

  • 장지락
    679
    2017-05-09 16:45:27

    전재형// 제 언급이 좀 짧아서 그렇게 느꼈나 봅니다. 그렇게 쓴 이유는 저 말고도 몇몇 다른분이 이미 이견을 표했는데도 "또 다른 증거들"를 제시하시니 님의 복심이 어떤지는 모르나 드러난 정황상 다른 이의 경험과 생각을 수용할 의지가 없어보인단 비평인거죠.

    -1
  • 전재형
    2017-05-09 17:01:43

    맞아요.

    게시한 이글이 타당하다고 (좋은 개발자의 기준으로) 생각되어서 반박한 것이지요


    당연히 재귀는 합당한 기준이 아니야. 라고 얘기를 했을 때..

    이 글을 보고 있는 다른사람들은 과연. 재귀나 알고리즘 따위는 개발자로서 공부해야하는 과목이 아냐 라고 생각되지 않겠어요?

  • 전재형
    2017-05-09 17:03:47 작성 2017-05-09 17:07:02 수정됨

    제 숨은 마음이 어떻다가 아니라. 재귀는 개발자로서 익혀야하는 중요한 기술중 하나라고 생각해요.


    문맥상 저는 이럴게 반박할수 있을 것같네요

    제가 원글을 퍼올때도. 원작자도. 저역시도. 혹은 다른 누군가도 재귀는 필요해. 라고 얘기하는데.


    어째서 재귀는 필요없어라고 말씀하시는 건가요 


    원글을 받아드리실 마음이 없으신거 아닌가요..


    모든 개발자가 동일한 생각을 공유하는게 아닌것이 분명할 텐데..


    자신은 반박하시면서. 제가 다른 방향의 증거를 내놓는 것이 못마땅하시다고 하심이 아쉽메요

  • 장지락
    679
    2017-05-09 17:10:47

    욥욥욥// 제가 이해를 못했다기 보다는 쓸데없는 걱정을 하는 것이죠.

    제 직급상으로 밑에 일백명 정도 있습니다.

    윗분들께서는 꼴치 안아프게 몇몇 단순한 지표들로 객관/공평/공정한(?) 방법으로 나름 수치화 하고 소팅해서 등수 또는 등위를 부여 평가합니다. <S, A~D 등급> 이후 급여/상여 승급에 영향을 주며 연속 3번 D점을 받으면 짜를 명분이 생깁니다.

    이때 이런 인터넷에 떠도는 글들도 자료수집의 대상이며 만일 회사서 객관적(?) 지표로 분류/포함하면 큰 힘을 발휘하죠!

    링크된 원글자가 절대 그런 의도가 아니라고 했겠죠, 그치만 비정한 현실에선 선한의도는 안개처럼 사라지고 반대로 서슬퍼런 칼날로만 작동 할 수 있습니다. 그리고 이공계 전공자들이 이런기준을 만든단 착각을 버려야 합니다.

    -1
  • 장지락
    679
    2017-05-09 17:53:38

    전재형// 제 댓글 어디에 "재귀호출 필요없다"라고 쓴 적 없어요. 다시한번 보세요. 대안이 없다면 사용해야한다고 썼어요.


    그리고... 저도 이해를 위해서 예시를 들죠.

    1. c/c++ 언어에선 무분별한 재귀호출은 품질/디버깅 문제로 통제 또는 막아야한다.

    2. 고로 최대한 많이 안쓴다. (적어도 내 경험상 그렇다.)

    3. 그래서 익숙한게 아니라서 엉터리가 아닌 평범한 개발자들 조차 이해하기 어렵다 느낀다.

    4. 그러므로 재귀호출로 알고리즘 구현을 하지 않아도 되면 하지말자!


    위 예시로 보자면 님이 동감한 "재귀호출에 대한 이해도"란 그저 선택사항이지 필수사항이 아니라는겁니다.

    여기서 "이해도"란 루프 구문 읽듯 재귀호출을 읽는 것을 의미해요.

    님께서 자신의 필드에 한해서는 그렇다고하면 동의하지만 개발자 전체에 적용해서는 안되는거죠.

    -1
  • 욥욥욥
    943
    2017-05-09 18:09:49

    // 장지락

    일단 비하의 목적이 없음을 밝힙니다.


    제 생각은 "어느정도" 지표에 "참고"해도 좋다는 의견입니다.

    가뜩이나 개발자 평가하는 기준이 어려운 마당에 이런 글들은 좋은 참고가 됩니다.

    자신이 생각하는 좋은, 나쁜 기준은 온라인에 얼마든지 의견을 낼 수 있잖아요.

    그것을 잘 판단해서 수용하는가는 각자의 몫이죠.

    장지락님은 여러사람 평가하는 입장에서 이런 류의 글이 객관적 지표로 될까바 걱정하시는 의견이라고 알아 듣겠습니다.

    혹시 이 글을 보시는 분들은 각 의견을 참고하시길 바라겠습니다.

    그런데 본문에 허점이 있다 해도, 그것을 판단할 수 없는 회사에서 이런 글이 없다고 좋은 기준이 생길 것 같지는 않습니다.


    그리고 본문 칼럼을 쓰신 임백준님은 꽤 알려진 대한민국 개발자로 알고 있습니다.


  • 장지락
    679
    2017-05-09 18:34:37 작성 2017-05-09 18:44:46 수정됨

    욥욥욥//

    임백준씨 유명하죠.

    번역서 포함 책도 많이내시고 한국 개발자들에겐 꾀 영향력 있으신 성공한 분이죠.

    '폴리글릿프로그래밍'을 주창하시니 그 일환으로 본글의 칼럼이 나온게 아닐까요?

    어쨌든 일반 개발자들보다 말의 힘이 훨씬 무거우니 앞뒤로 당부말을 달긴했지만 왜 달았겠어요...

    의도를 오해하는 사람들이 많았단 이야기겠죠.

    -1
  • 전재형
    2017-05-10 04:10:44

    장지락

    글과는 상관없이 궁금한점이 생기네요.

    경영자들은 어떤 지표로 개발자를 자르나요?


    각 필드에서 요구되는 스킬은 모두 다를텐데, 그저 퍼포먼스와 대체가능한 인력의 수급정도 등을 보고 인원 증감축을 하는게 아닌가요?


    아무런 고민 없이 이런 지표로 개발자를 자른다는 것은 해당회사가 IT사업을 할 마음이 없거나. 역량이 부족하다는 증거가 되지 않을까요..


    그리고.. 제가 생각되는 바로는 짜르자고 했을때. 이런 지표를 들이밀어 짜를 회사라면. 이런한 종류의 글을 운영진이 확인하지 않더라도 누군가는 짤려야하는 문제인걸로 예상되네요

  • 전재형
    2017-05-10 04:22:40 작성 2017-05-10 04:26:10 수정됨

    그리고 저는 장지락씨만큼의 경력이나 아랫사람을 둘만한 위치에 있지 않습니다.

    그렇다고 해서 단순 넷상에서 제가 이정도 의견도 못 낸다는 것은 말이 안된다고 생각해서 


    재귀의 필요성에 대하여 더 이야기 하도록 하겠습니다.


    앞서 얘기한 것처럼 재귀가 발생시키는 문제는 잘못 사용하면 크리티컬하게 작용할수 있지만


    코드의 의미전달을 쉽게한다는 것에 대하여(반복문 사용에 비해) 큰 메리트가 있다고 생각합니다.( 예제를 들어 얘기하지 않아도 이해하시리라고 생각합니다)


    반면에 재귀를 써서 문제가 발생한다면, 이 것은 재귀 사용의 문제가 아니라 로직상 허점인것아닌가요?


    로직상 허점을 굳이 당장에 문제가 발생하지 않는다고해서 용인하고 넘어가야하는가하는 문제는 각자 대하는 입장이 다를 것이나, 저는 오히려 문제의 발생여부를 더 빨리 확인할수 있어서 좋지 않은가라고 생각합니다.


    다만 재귀가 함수스택 관점에서 소모되는 자원의 양이 크다고 반박하시면. 물론 수긍할수 있습니다.


    하지만 대부분의 경우에 (특히 자바처럼 자원에 대해 고민이 적을수 있는 프로그래밍) 그정도로 무리가 가지 않을거라고 생각되구요.


    무리가 간다면 설계가 잘못되지 않았나 점검해볼 필요가 있는 것같습니다.


    가령 단순 트리 탐색에 재귀를 쓴다면 균형 트리를 사용하지 않는다면, 말도 안되는 재귀 호출 횟수를 경험하게 되겠지만. 보통은 그정도 되면 어떻게든 최악의 상황을 가정해서 개발하지 않을까요



    그래서 정리하자면, 반복문보다 재귀를 써서 전달력에 이점이 있다면 재귀가 더 낫다가 제 입장입니다.



    위가 모든 개발자의 코딩스타일을  대표하지 않는 만큼, 어떻게 개발할지는 본인이 판단할 문제입니다.


    하지만 많은 분들께서 말씀하신것처럼 "재귀"에 대한 이해 자체는 필요하다.라고 생각합니다.

  • 모드쿠
    659
    2017-05-10 09:49:53

    저 또한 재귀에 대한 이해 자체는 필요하다고 보지만,

    재귀를 쓴다는건 스택오버플로우가 나올 가능성이 많거든요.

    재귀에 대한 이해가 있으면 풀어서 쓰는게 맞다고 봅니다.

  • 전재형
    2017-05-10 12:02:45

    모드쿠 님.. 제가 정말 잘 몰라서 그러는데.. 일반적인 자바환경에서 정상적인 프로그램 설계일 때. 스택오퍼플로우가 발생하는 경우는 어떤 경우인가요?

  • 모드쿠
    659
    2017-05-10 12:49:21

    재귀는 본인 함수 호출하면서 계속 스택이 쌓이잖아요. 이게 메모리를 넘어서면 스택오버플로우가 생기죠.

    웹에서 어떤 버튼을 누르면 재귀 작동하는 함수가 있다고 보면, 많은 사람들이 동시 클릭해서 쓰레드가 여러개 생성시켜 재귀를 뿌린다고 볼 때도 문제가 생길 수 있겠죠. 정상적인 프로그램 설계임에도 불구하고 어떤 문제가 생길지 몰라 재귀는 안쓰게 좋다고 봅니다. 다만 재귀의 원리를 이용하는건 엄청나게 효과적이라는 걸 말하고 싶구요.


  • 모드쿠
    659
    2017-05-10 12:54:53

    위에 말씀하셨던  정상적인 프로그램 설계일 때와는 또 다른문제로 보여집니다. 완벽한 설계라도 운영으로 올리면 어떤 현상이 나타날지는 가봐야 알거든요. 재귀 알고리즘 자체는 굉장히 도움이 많이 되죠.

  • Taetrees
    551
    2017-05-10 13:11:01

    재귀를 이해는 하되 쓰는 것에는 주의가 필요하다고 봅니다.

    위의 5번 내용도 이해하는 능력을 말했지 사용에 대해서 언급한 것은 아니라고 봅니다.

    그리고 요즘 트렌드는 안전한 코딩이라고 생각하는 입장에서 스택오버플로우 발생 가능성을 무시할수는 없죠.

    호출 횟수를 제어할만하거나 예외처리가 충분히 가능하다면 가독성을 위해서 써도 되겠지요.

    어쨌든 1번 5번에서 언급하고자 했던 것은 알고리즘 능력에 대한 이야기이지 재귀가 좋네 마네의 내용은 아니라고 봅니다.

  • 전재형
    2017-05-10 14:23:39

    모드쿠, Taetrees.


    저도 본문을 읽어서 말씀하신 내용을 알고 있지만. 몇몇 분들이 재귀의 위험성에 대하여 말씀하셔서 

    왜 재귀가 위험하지? 라는 의문이 들어 질문을 드린 거에요.


    단순반복문에 비하면 재귀로 호출로 반복할수 있는 정도의 수는 단순반복문에 비하여 굉장히 작지만

    그정도로 이미 반복재귀가 일어나는 것은 로직이 잘못되었을 때를 제외하고,

    나타날수 있는 현상인가 하는게 저의 의문이에요.

  • 스타
    3k
    2017-05-10 14:28:47 작성 2017-05-10 14:30:41 수정됨

    댓글을 읽은 경험으로는 while도 쓰면 안될것 같고, for문도 쓰면 안될 것 같네요. 왜냐? 위험하니까...

    ----------------

    가끔 보는 경우인데, 내가 하면 로멘스 남이 하면 불륜 같은 이런 상황 자주 봅니다.

    상대방의 코드 리뷰 할 때는 핏대 올리면서 원론적인 이야기로 공격하지만 막상 본인 코드는 주장 만큼 아름답지 못한 사람 가끔 봅니다. 앵무새처럼 유명한 사람들 말만 따라하는게 아니라 몸소 언행일치 해서, 평소에 지켜질 수 있는 적절한 가이드 라인이라도 가지고 있었으면 좋겠습니다. 팀 가이드도 마찬가지지만요...

    --------

    필요하면 쓰라고 만들어 둔 재귀 호출을 되도록이면 쓰지 말라는 가이드도 엉터리고, 스택 오버 플로우가 날 만한 상황에서는 쓰지 말라고 하는데 재귀호출을 남발하는 것도 문제 인 것 같네요.

    --------

    어쨌거나 코드로 사람을 짜른다니 살벌하네요.

  • 모드쿠
    659
    2017-05-10 16:59:18

    왜 재귀가 위험하지?

    분명 제가 짠 로직도 완벽하다고 생각하는데, 이게 올려보면 말도안되는 오류가 나올수도 있어요. 미쳐 테스트 못한 부분도 있을 수 있구요. 99.9%가 완벽한데 0.1%때문에 그것도 스택오버플로우가 난다면 서버 떨어지는거죠. 저 또한 완벽하고 단단한 코딩을 지향하지만 재귀를 안쓰는 이유가 이때문이에요. 제가 통제할수 있는 변수를 벗어나는 수가 생길수가있거든요.


    일반적인 자바환경에서 정상적인 프로그램 설계일 때. 스택오퍼플로우가 발생하는 경우는 어떤 경우인가요?

    정상적인 프로그램 설계에 이런내용이 들어갈까요? 몇 스택까지 안전하고, 스택하나당 메모리가 얼마나 들어가며 메모리를 얼마로 잡을것이며, 몇명이 같은 재귀를 탓을때 안전한가? 금방 생각나는 내용이긴한데 이런부분까지 검토가 들어가면서 쓰기엔 메리트가 있나요? 테스트 자체도 엄청 길어지겠네요. 다시 말하면 전 재귀를 왜 굳이 써야하는지 묻고 싶어요.

  • 전재형
    2017-05-10 17:33:10

    굳이.. 재귀를 쓰는 이유에 대해서는 위에 여러문장으로 써두었어요..


    재귀를 씀으로써 테스트가 길어진다는 것에도 동의하기가 힘드네요..


    저역시도 완벽하게 설명이 힘들기 때문에. "요새 많이 쓴다. 함수형 언어를 봐라. 스트림을 봐라"

    이런씩으로 밖에 말하지 못하네요.


    의미전달력이야 말로 "재귀"를 사용하는 가장 강력한 이유라고 스스로는 생각하고 있으며

    이것으로 논리가 명확해진다 -> 디버깅이 쉽다.  때문에 재귀를 사용해야 한다라고 스스로 생각하고 있는데.. 정말 맞나 틀렸나는 제가 이후에 조금더 고민해서 예제를 만들어볼께요.


    말씀드린것처럼 제 스스로는 완벽하게 설명이 힘들기 때문에..

    링크로 제 의견을 뒷받침할 수 있는 게시글을 전달드리려 합니다.


    https://namu.wiki/w/%EC%9E%AC%EA%B7%80%ED%95%A8%EC%88%98

    무엇보다 함수가 호출될 때마다 호출 스택 메모리를 잡아먹는 경우 퍼포먼스 측면에서 반복문이 낫다. 다만 구현체에 꼬리재귀(Tail Recursion) 최적화가 되어있는 경우 꼬리재귀 요청이 스택에 걸리는 대신 이전 실행지점으로의 점프로 작동 하므로 실질적으로 루프문과 유의미한 성능 차이는 없게 된다. 꼬리재귀 최적화의 경우 함수형 언어 구현체에는 필수적으로 들어가며, 명령형 언어 컴파일러에도 구현되어 있는 경우가 있다. C, C++의 경우 GCC, clang/llvm, VC 등의 주요 컴파일러에는 다 구현 되어 있기 때문에 안심하고 사용해도 된다.

    명령형 언어에서도 재귀가 필요할 때가 있는데, 반복문으로 구현했다가는 코드가 심하게 복잡해지거나, 프로그래머가 만들다가 로직이 꼬여 안드로메다로 가는 상황이 발생하는 문제들도 있기 때문. 이 경우 재귀함수로 구현하는 것이 간단하고 훨씬 더 이해하기 쉬운 경우가 있다. 



  • 모드쿠
    659
    2017-05-10 17:56:49

    아녀 테스트가 길어진다는건 일반적인 테스트 외에 스택등에 대한 테스트가 필요하다고 보는거라서요.

    전 스택오버플로우를 피할수있다면 재귀가 낫다고 보는데 이걸 피하려면 로직테스트 외에 다른 부가 테스트를 더 해야한다는 말이었어요.

    단순예제면 무사통과할 가능성이 많아요. 맥시멈 데이터를 잡아서 하거나 웹상이면 동시에 클릭해서

    적어도 몇개의 쓰레드가 무사히 통과하는지 이런걸 봐야한다는거죠.


    디버깅이 쉬워진다는건 동의 못하겠네요. 반복문 i라는 인덱스는 정말 강력하다고 봐요.

  • 삼식이
    1k
    2017-05-10 18:40:53

    전재형//

    그대가 어글러라는 신호들

    이딴 글 싸질러 놓는것.

    -1
  • 전재형
    2017-05-10 19:06:40 작성 2017-05-10 19:09:03 수정됨

    삼식이.

    오랜만에 보는 훌륭한 분이네요.

    저런 태도는 꼰대라고 표현해도 괜찮을것같은데요

  • 몰라요
    71
    2017-05-11 01:08:19

    루프가 직관적인 로직은 반복문으로..

    재귀가 직관적인 로직은 재귀호출로.!

    (반복문으로 해결하기엔 코드가 너무나 장황해지는 상황들이 있죠)

    단, 재귀일 경우 레벨이 합리적?이라고 판단될 경우에만!

    반복문으로도 간결하게 표현할 수있는데 굳이 재귀로 표현하는 것은 자바, C#같은 언어기준으론 뻘짓

    디폴트로는 어떤 문제가 있을때 루프를 먼저 염두해두는게 맞다고 생각...

    이상 제가 가진 재귀에 대해 가졌던 지극히 주관적인 생각들...

    또 넋두리를 더하자면 실무에서 재귀를  활용해야하는 상황들이 막상 거의 없더라구요ㅜㅜ

    물론 제 미천한 경험과 경력 탓이겟지만....

    재귀를 활용해서 해결해야겠다 싶은 문제들은 이미 어디선가 너무 잘 구현되어있어서 가져다쓰면 될때가 많았고 그게 계속되다보니 재귀적 사고로 문제를 해결하겠다는 시도자체가 사라진것 같습니다...

    고로 문제해결에 대한 시야와 사고를 더 넖혀야겠다는 생각이 강하게 듭니다!!!!



  • fender
    25k
    2017-05-11 01:26:18 작성 2017-05-11 01:37:09 수정됨

    윗 분들 말씀대로 굳이 재귀를 쓸 필요가 없는 경우도 있고, 잘못 쓰면 위험한 경우도 있고, 쓰면 더 좋은 경우도 있고, 써야만 하는 경우도 있습니다.

    문제는, 후자의 경우들이 생각 만큼 드물지도 않고, 이해는 하지만 안써도 될 때 굳이 쓰지 않는 것과 이해를 못해서 필요해도 못쓰는 건 다르다는 점입니다. 굳이 함수형 언어를 언급하지 않더라도 재귀호출이 필요한 경우는 꽤 흔하게 접할 수 있습니다.

    경력이 짧다면 모를까 한 5년 이상 개발을 했는데 재귀가 반드시 필요한 코드를 단 한 번도 짜보지 않았다면, 아마도 경력 기간 내내 비슷한 분야에서 비슷한 종류의 코드만 반복적으로 뽑아냈다는 반증이기 쉽다고 봅니다.

    그리고 그 정도 경력자가 단순한 재귀 호출 정도를 이해하는데 상당한 어려움을 겪는다면, 그건 아마도 본분에서 지적한 1번, 즉 머릿속에서 코드를 돌려보는 능력이 부족하다는 이야기로 귀결되는 것이 아닌가 싶습니다.

  • 장지락
    679
    2017-05-11 10:50:16 작성 2017-05-11 10:54:22 수정됨

    전재형 // 여러 댓글로 쪼개 질문한 것 개인적인 의견을 아래와 같이 답변합니다.


    1. 엔지니어 평가 등 관련 내용

    • 일반적인 회사에서는 엔지니어랑 비엔지니어간 차별 평가 항목을 통해서 평가하게 되면 공정성 시비가 있을 수 있는 민감한 내용이므로 차별 평가로 진행하는 회사의 비율이 크지 않다고 봅니다. (예: 연구소 vs 영업 부문) 그리고 특히 중 규모(300인) 이상의 회사에서는 특히 더 할 거라 생각해요.
    • 팀/조직 성과 및 CEO의 부서 가중치가 평가에 지대한 영향을 줌.
    • 현실적으로 보면 평가 주관 조직인 인사 부서에서 개별 엔지니어가 '리컬시브 호출' 이해도를 일일이 평가할 수단이 없음.
    • 개발 팀원 평가에서 있어서는 결국은 팀장급에서 평가해야 함.
    • 팀장이 평가 한다고 해서 전반적인 연구/개발 능력과 조직 융화 또는 직급이 높다면 리더십 등을 봄.
    • 일개 테크니컬적인 요소인 '리컬시브 호출 방식' 등을 사용하고 안하고 까지 평가하지 않음.
    • 해당 팀장이 개별 엔지니어에게 이런 세세한 내용까지 판정하면 결국 팀장이 시키는 대로만 구현 하게됨.
    • 따라서 팀 단위에서 개발은 구현 방향은 팀 내부 실무자의 의견과 연구/개발 조직의 오피니언 리더들에게 좌우됨. 결국 팀장은 구현 결과에 대해서 개별 조직원에 구체적인 책임을 물을 수 없음.


    2. 직원 정리 해고 등 내용

    • 회사의 분기/연간 실적 그리고 CEO의 판단이 제일 큰 팩터임.
    • 그래서 평소 성과에 대해서 훌륭/평범 엔지니어라는 조직내 평판이 큰 영향을 줌.
    • 그러나 이런 평소 평판은 기술적인 능력치와 반드시 유관하다고 볼 수 없음.


    3. "아무런 고민 없이 이런 지표로 개발자를 자른다는 것은 해당 회사가 IT 사업을 할 마음이 없거나. 역량이 부족하다는 증거가 되지 않을까요."

    • 글쎄요... 딱히 뭐라 답변해야 할지...  허허


    4. "그리고 저는 장지락씨 만큼의 경력이나 아랫사람을 둘만한 위치에 있지 않습니다. 그렇다고 해서 단순 넷상에서 제가 이정도 의견도 못 낸다는 것은 말이 안된다고 생각해서..."

    • 의견 내시는 거 뭐라 안 합니다. 동의든 아니든 의견 자체는 좋은 거죠.


    5. 나머지 "재귀 호출" 전반에 관련한 내용

    • 당연히 필요하다면 사용해야죠.
    • 그리고 잘 이해하고 잘 사용하고 책임질 수 있으면... 훌륭한 개발자라 칭찬하고 싶습니다.
    • 그러나 제 부하직원을 평가할 때, "재귀 호출 이해도"가 부족하다고 해서 '엉터리 개발자'라는 딱지를 매기지 않겠습니다. 즉, 좀 더 훈련(트레이닝)이 필요한 그저 '평범한 개발자'일 뿐입니다.



  • Initializing
    722
    2017-05-11 17:46:15

    6번은 공감하기가....

  • Dive_Drink_Develope
    6k
    2017-05-11 19:09:08

    재귀가 위험해서 못쓴다는건 

    알고리즘의 워스트 케이스를 예측하는 능력이 부족하다는 얘기죠.


    토론 잘보고 갑니다.

  • fender
    25k
    2017-05-11 19:22:06 작성 2017-05-12 09:42:34 수정됨

    6번은 가끔 그런 개발자들이 있습니다. 완전 신입급보다는 어중간하게 경력이 붙어서 어느 정도 코딩에 자신이 생겼을 때 그런 경향을 보이는 경우가 많은데, 대충 "시간만 주면 대충 검색해서 다 만들 수 있다"거나 "언어는 문법만 다르지 거기서 거기"라는 식의 생각을 하는 시기입니다.

    이 시기엔 다른 사람이 짠 코드의 문제점도 슬슬 눈에 잘 들어오기 때문에 자신의 실력을 과대 평가하기도 쉽습니다.

    문제는 그런 자신의 평가와 별개로 실제 개발 실력이 크게 는 것은 아니기 때문에, 여전히 써보지 않은 기술이나 생소한 설계 등을 파악하는 데는 시간이 걸리곤 한다는 점입니다.

    이 경우 자신이 알고 있는 방식과 다른 방식으로 문제를 풀 수 있는 방법이 있더라도 굳이 그걸 배우려고 시간을 쓰느니 '내가 금방 만들고 만다'라고 하는 만용을 부리기 쉽습니다. 멀쩡하게 있는 검증된 JSON/XML 파서나 로깅 프레임워크, 업로드 처리 라이브러리 등을 굳이 '가볍게' 새로 만들어 쓰겠다고 고집을 부리기 쉬운 시점이 이 때입니다.

    반면에 자신이 작성한 코드엔 강한 믿음이 있는데, 스펙을 파악하지 못하거나 잘못된 설계로 오류가 발생해도 쉽게 플랫폼의 버그라고 믿어 버리는 경우가 많습니다. 자바 버전별 하위 호환성을 믿지 못하거나 버그를 찾겠다고 공연히 스프링이나 탐캣의 소스를 뜯어보는 등의 부류가 여기에 속합니다.

    물론 이를 지나치게 일반화해서 '실력이 없는 개발자는 모두 이런 식이다'라고 말한다면 잘못이겠습니다만, 인용한 책의 내용도 아마 그런 취지는 아니었을 것으로 예상합니다.

    개인적으로는 전체적으로 공감이 가는 부분이 많은 내용이었습니다.

  • 안드로더
    525
    2017-05-11 19:43:04

    제가 경험해본 바로는 재귀호출로 문제를 해결했을 때 뭔가 있어보이고 뿌듯했었던

    적이 있었습니다. 위험하다는 의견은.. 재귀호출을 사용했을 때 오히려 바로 오버플로우 에러가나는

    부분이 있어서 판별이 더 쉬운경우가 많았습니다.

    결론은 잘쓰면 좋고 굳이 안쓸려고 노력안해도.. 써야되면 쓰는거죠. 그게 머리속에 그려진다면 말이죠.

  • 웹뿌시기
    149
    2017-05-12 17:17:58

    쭉 댓글을 읽으면서 배운 것이 많습니다..

    저는 오히려 본문보다는 댓글에서 배운 내용이 많네요..


    한 때 멋도 모르고 소스를 짜던 중 재귀 함수를 구현한 적이 있었는데

    한참을 머리 통을 쥐어잡은 적이 있습니다...ㅋㅋ

    다행히 현재는 무사히 잘 돌아가고 있네요.


    덕분에 그 때 당시의 삽질했던 재귀함수에 대해서 다시 공부할 수 있는 계기가 되었습니다~

    감사드려요~

  • 익명
    245
    2018-11-04 03:40:30 작성 2018-11-04 07:05:59 수정됨

    흠~~ 뭐 쓰고 안쓰고 잘 모르겠지만

    확실히 재귀를 썼을 때 코드가 예뻐지긴 하네요


    제가 생각해낸것이 이래서 그런진 몰라도


    재귀를 썼을 때는 깊이부터 순회하고

    재귀를 썼을 때는 그 레벨의 값부터 순회하는군요?


    let obj = {
      name: "root",
      childA: {
        name: "childA",
        child: {
          name: "childA_A"
        }
      },
      childB: {
        name: "childB",
        child: {
          name: "childB_A"
        }
      },
      arr: [1,2,3,4,5]
    }

    function recursive(target) {
      for(let key in target) {
        if(typeof target[key] === "object") {
          recursive(target[key]);
        }
        console.log(target[key]);
      }
    }

    recursive(obj);

    function notRecursive(target) {
    let temp = [], tempB = [];

    for(let key in target) {
    if(typeof target[key] === "object") {
    temp.push(target[key]);
    }
    console.log(target[key]);
    }


    while(temp.length !== 0) {
    tempB = temp; temp = [];
    tempB.forEach(elem => {
    for(let key in elem) {
    if(typeof elem[key] === "object") {
    temp.push(elem[key]);
    }
    console.log(elem[key]);
    }
    });
    }
    }
    notRecursive(obj);



    재귀 말고는 트리 순회 해볼 생각도 안했는데

    유익한  글이네요 : )




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