그렇죠, 개발 언어를 이해하는 것과 디버깅 능력 개발은 기본 소양인거죠

이건 기본이라고도 말할 수 없을 정도로 당연한 거라 생각됩니다.ㅎㅎ

개발 업무가 아니라하더라도 스스로 알아볼 수 있는 내용은 모두 알아보고 그래도 모르는 것에 대해서 물어보는 것이 맞습니다.

니플 // 네, 저도 너무 당연하게 그렇게 생각했는데 이 곳 질문 글을 보면 예외 트레이스를 못읽는 건 매우 흔하고, "아, 저 사람은 API 문서도 한 번 본적이 없겠구나" 싶어서 경악할 때가 자주 있더군요.

그래서 전에 몇 번 했던 이야기지만 다시 강조해서 글을 써보았습니다.

추천 10개를 누르고 싶네요.

학교 리포트하는 기분으로 물어보는 사람이 많아서 그런거 같네요

정말 간단하고 읽고 찾아가면 어디가 문제인지 나오는 오류 트레이스조차 물어보면 답답할 때가 있죠

이런 글 좋아요!

저도 기본기무새라 신나서 왔는데 

기본 자세였군요 ㅋㅋ 추천.

youngyoung // 사실 그런 식으로 질문을 해서 더 쉽고 빠르게 답을 얻을 수 있다면 아주 이해 못할 행동은 아닐 것 같긴 합니다. 배울 것도 많은 초보나 신입 개발자 입장에서 시간은 항상 모자라겠죠.

문제는 그런 개발자가 회사에서 일하면서 앞으로도 10년이 될지 20년이 될지 모르는 기간 동안 거의 매일 같이 이런 저런 오류나 처음보는 기능을 접하게 된다는 점이 아닐까 싶습니다.

즉, 그런 분들이 질문하는 내용을 보면 스택트레이스를 읽는 방법을 알고 있거나 해당 예외에 대한 API 문서를 한 번만이라도 찾아봤으면 10초 내에 원인을 정확하게 알 수 있는 경우가 많은데, 그 간단한 기본기가 습관이 안되서 개발자로 일하는 내내 스트레스를 받게 되는 것 같습니다.

10초 면 알 수 있는 걸 소스 통째로 복사하고, 스크린샷 찍고, 또 비슷하게 오류를 못보는 분들이 막연하게 던지는 의심가는 부분을 무작위로 변경해보면서 정확한 해결 방법이 달릴 때까지 기다리서나 질문글이 묻혀서 다시 올리고...

그런 걸 앞으로 10년 넘게 한다고 보면 생각만해도 끔찍하더군요.

대부분 찬성하는 의견이고 좋은글이라고 생각합니다.

다만 해당 상황을 해결 혹은 이해를 하기 위해서 원론적인 접근(root cause)으론 아무래도 시간이 많이 걸리는 경우가 있습니다.

접근 방법도 배경지식등에 따라 차이가 많이 날수 있구요.

그래서 다른 방향으로는 회피책(workaround)으로도 해결을 하려는 노력도 있다고 봅니다.

쉽게 말해 복붙이죠. 누가 알려준 정답을 그냥 가져다 쓰는 방식이나 이렇게 짜보니 이해는 안되지만 어쨋든 돌아간다

해당 동작은 어느 레벨이든 시도하게 됩니다. 쥬니어든 시니어든 말이죠. 비율의 차이가 있겠죠. 시간(마감) 이라는 정해진 리소스안에서 최대한의 (보여지는) 성과를 내기 위해서라고 생각합니다. 물론 길게보면 정석적인 접근법이 좋겠죠.

제가 얘기하고 싶은건 어느정도의 반복학습과 추상적인 동작들로 인해서 얻어지는 배움역시 개발자에게는 도움이 되고 어떨때는 빠른 해결법이 될수 있다는 말이 하고 싶습니다.

초보 개발자 시절에는 API문서 읽으라 해도 한글도 아니고 친절하지도 않고, 대부분 나가떨어지지 않을까 싶습니다. 저도 그랬구요. 현재도 공식 문서 참 보기어려운걸 항상 느낍니다. 구글이나 애플이 쓴것두요..

그래서 가이드 문서와 샘플을 제공해주고 stard guide를 제공해서 손을 움직여서 이해를 못하더라도 돌아간다는 느낌을 우선 몸으로도 알게 해주는게 학습과정에서는 필요하다고 생각합니다.

개발자라면 반드시 알아야 하는 기본기라고 글을 쓰셨기에 모두들 이 글에 대해서 무겁게 받아들이지 않았으면 하는 마음에 댓글 남겨봅니다.

기본기 

아무리 강조해도 부족하죠

저도 부족한듯 ㅡㅡ

인절미후후 // 보통 '회피책(workaround)'이라고 하는 건, 예컨대 플랫폼 자체의 한계 등으로 정상적인 처리가 어려울 때 해당 문제가 해결되기 전까지 사용하는 임시 방편을 뜻합니다.

물론 가끔은 시간이 없을 때 일단 돌아가게 만 하는 구현을 그렇게 부르는 경우도 있습니다만, 그런 경우에도 보통은 정상적인 방식이 무엇인지 이해를 하는 전제로 그에 상대적인 개념으로 임시 조치라고 하는 것이지, 올바른 접근이 무엇인지 모르는 채로 복붙하는 행동을 뜻하진 않습니다:

A workaround is a bypass of a recognized problem or limitation in a system or a policy. A workaround is typically a temporary fix that implies that a genuine solution to the problem is needed.

(참고: 위키백과의 'workaround'에 대한 정의)

제 의견이 절대적일 수는 없으니 생각이 다른 부분은 존중하지만, 전 말씀하신 내용에 공감하기 어렵습니다. 자동 번역도 있는 시대에 API 문서 보는 것이 그렇게 어려운가요? 또, 설사 어렵다 쳐도 그게 정말 오류 날 때 마다 게시판에 질문하고, 소 뒷걸음 치다 쥐잡는 식으로 이것 저것 마구잡이로 바꾸어 보는 식의 삽질보다 대단히 힘이 드는 일이던가요?

저는 그래서 초보 개발자가 API 문서나 오류 메시지를 읽는데 어려움을 겪는다면 이해할 수 있습니다. 그런데 이는 어렵게 느끼면 남들보다 더 노력해서 숙달해야할 내용이지, 일단 제쳐두고 훨씬 복잡한 프레임워크 코드부터 복사 붙여넣기 연습을 하겠다고 덤빌 내용은 아니라고 봅니다.

전 노력을 해도 API나 오류도 못 읽는 경우라면 애초에 개발을 직업으로 해선 안된다고 생각합니다.

참고로 아마도 질답 게시판에서 가장 많이 올라온 질문이자, 의미만 알면 보통 10초 안에 원인을 알 수 있는 자바의 널포인터 예외에 대한 공식 API 문서의 설명은 아래와 같습니다.

영어로 된 걸 그냥 구글 번역기에 돌렸더니 이렇게 나오는군요:

객체가 필요한 경우 응용 프로그램에서 null을 사용하려고하면 발생합니다. 여기에는 다음이 포함됩니다.

• null 객체의 인스턴스 메서드를 호출합니다.

• 널 오브젝트의 필드에 액세스하거나 수정합니다.

• 배열인 것처럼 널 길이를 가져옵니다.

• 배열인 것처럼 널 슬롯에 액세스하거나 수정합니다.

• Throwable 값인 것처럼 null을 던집니다.

여기까지 하는데 1분도 안걸렸습니다. 그리고 '객체'나 '배열', '메서드' 같은 개념을 모르면 어차피 제대로된 자바 개발이 불가능하다고 보고, 번역된 내용에서 넉넉잡고 한 30분 쯤 고민하거나 검색하면 이해 못할 내용이 있던가요?

전 그래서 이 정도 노력하는게 예를들어, 널포인터만 발생하면 매번 스크린샷에 소스 통째로 복사에 질문 글 올리고 답 올라올 때까지 무한정 기다리고 하는 것보다 대단하게 어렵다고 느끼는 걸 이해하지 못하겠습니다.

제가 볼 때는 학원 등에서 아무도 그게 중요하다고 안알려주고 들입다 스프링 연습부터 시키거나 해서 단지 습관이 안되어 있을 뿐인 것 같습니다.

API 보는걸 습관처럼 해야한데 아직 많이 부족하네요.

좋은글 감사합니다.

좋은 글 감사합니다.

잘 읽고가요! 

@fender

글쓴이 의견이 틀리다는 얘기는 절대 아닙니다.

제가 댓글을 단 내용 역시 임시책으로 해결하면서 개발을 계속 하라는 얘기가 아닙니다.

우선적으로 개발을 시작할때 원론적인 접근만으로 문제를 해결하려고 하면 시작의 허들자체가 높아서 포기할 가능성이 높으니 이런저런 시도를 해보라는 의미였습니다.

그러면서 자연스럽게 해당 내용의 본질을 알수 있도록 노력하길 바라는게 제 의견입니다.

그리고 제목과 내용 타겟이 미묘하게 다른 부분이 있어서 해당 내용에 대해서 정확히 짚고 싶은 부분은 있습니다.

개발자라면 반드시라고 쓰셨으나 내용으로 보건데 타겟은 깊은 생각없이 우선 질문올리고 복붙으로 해결하려는 쥬니어 개발자에 대한 글로 보여집니다.

저는 해당 내용의 타겟으로 얘기하고 있지 않습니다.

숙련된 개발자라고 할지라도 임시책으로 문제를 해결하는 케이스는 있다고 생각합니다.

물론 기본적으로는 공식 자료라던가 근본적인 해결을 찾으려 노력합니다.

전 노력을 해도 API나 오류도 못 읽는 경우라면 애초에 개발을 직업으로 해선 안된다고 생각합니다.

 - 이 글 역시 대부분 동감합니다만 애초에 개발을 직업으로 하면 안된다는건 좀 과격한 의견이라고 보여지네요.

인절미후후 // 

개발자라면 반드시라고 쓰셨으나 내용으로 보건데 타겟은 깊은 생각없이 우선 질문올리고 복붙으로 해결하려는 쥬니어 개발자에 대한 글로 보여집니다. 저는 해당 내용의 타겟으로 얘기하고 있지 않습니다.숙련된 개발자라고 할지라도 임시책으로 문제를 해결하는 케이스는 있다고 생각합니다.

제가 본문에서 개발자가 알아야하는 기본기로 제시한 건 딱 두 가지, 즉 API 문서를 보는 방법을 익힐 것, 그리고 예외를 보는 방법을 배울 것입니다.

한 번 그런 기본기를 배웠다면 숙련된 개발자가 된 다음에 갑자기 API나 스택 트레이스 읽는 법을 잊어 버리진 않을 겁니다.

제 생각에는 제가 제목과 본문의 내용이 일치하게 쓰지 않았다기 보단, 인절미후후님이 제 글을 대략 "개발자라면 절대로 임시조치를 하면 안된다"는 정도로 잘못 읽으신 게 아닌가 싶습니다.

애초에 개발을 직업으로 하면 안된다는건 좀 과격한 의견이라고 보여지네요.

사람마다 능력이 다 다르니 남들보다 어떤 분야의 배움이 늦는 건 비난 받을일은 아닙니다. 하지만 비난 여부와 별개로 각 분야별로 정상적으로 업무를 처리하기 위한 최소한의 소양이라는 건 있습니다.

극단적인 예를들어, 곱셈을 못하는 사람이 전문 개발자가 되려 한다면 어떻게 생각하시나요?

물론, API를 보는 것이 곱셈하는 것보다야 어렵겠지만, 익숙해지는데 시간이 오래걸린다는 차원이 아니라 아예 노력해도 못하겠다, 또는 그 정도 노력할 의지가 없다는 수준이면 전문 개발자가 되는데 부적격한 건 마찬가지라고 봅니다.

사실 전 예컨대 스택트레이스 읽는 법도 어려워서 못배우겠다는 사람이라면, 그와 비교도 안되게 복잡한 의존성주입 프레임워크 기반으로 실제 기업에서 쓰는 다계층 웹서비스를 구축하겠다는 것 자체가 말이 안되는 일이라고 봅니다.

fender님 말씀에 백번 공감합니다.

몇 분만 검색해도 방법을 충분히 찾을 수 있고 약간의 시간만 들이면 배울 수 있는 디버깅을 뒤로하고 모래사장에 바늘 찾기 하는 분들은 신입, 경력을 가리지 않고 마주치는 것 같습니다.

@fender

여러가지 부가 설명 감사합니다 상황을 이해하는데 도움이 많이 되었습니다.

서로의 백그라운드가 다른 관계로 용어에 대한 정의부터 많이 다른 상황에서 이야기가 전개된듯합니다.

감사합니다 선배님 글과 댓글 읽으며 정신차립니다

API 문서 읽는법 강의 있으면 수강하고 싶습니다..

그런 강의는 없더라구요..ㅠㅠ

수십개의 API 도큐먼트를 보았지만 제 경우는 예제가 없으면 실제 코드에 적용하는게 쉽지 않더라구요.

한두개 예제 있으면 응용하는건 하겠는데, 예제가 아예 없는 경우에 이거보고 어떻게 쓰라는거지..?

라는 생각 밖에 안들더라구요.

API 문서 이해를 잘하는 특별한 방법이 있을까요?

보보8 // 우선 개발 과정에서 소소하게 습관을 들이는 것이 중요합니다. 예컨대 IDE에서 바로 선택 항목에 대한 API 문서가 나오게 하거나 브라우저에 언제라도 접근할 수 있게 책갈피 해놓는 것으로 시작하는 걸 추천드립니다.

그렇게 해놓고 개발하는 중에 접하는 메서드의 사용법이 궁금하다거나 콘솔에 예외 클래스를 포함하는 오류가 발생했을 때 바로 문서를 찾아서 읽어보는 연습을 하면 좋습니다.

그리고 API 문서 마다 나름의 체계가 있습니다. 예를들어 자바 API라면, 계층도, 상속 받은 메서드나 필드, 자체적으로 정의한 메서드 등이 구분되어 표시되어 있는데, 나중에는 그런 체계도 한 눈에 들어오게 됩니다.

처음에는 예컨대 단순히 'NullPointerException'의 의미는 무엇인가? 같은 단순한 내용을 찾게 되지만, 나중에는 객체지향이나 디자인 패턴 지식과 결합하면 한 눈에 어떤 라이브러리나 프레임워크의 기능을 파악하는데 유용하게 활용하는 기술이 될 수 있습니다.

예를들어 처음 보는 프레임워크가 있다면, 우선 홈페이지에서 간단한 설명을 읽어보고 API 문서를 열어서 어떤 패키지가 있는지 살펴보고, 패키지 안에 어떤 인터페이스가 있는지, 또 핵심 유형의 계층 구조가 어떤지 살펴보면 매우 효율적으로 해당 프레임워크의 전반적 구조를 이해할 수 있습니다.

그래서 처음에는 단지 API를 자주 찾아보는 걸로 시작해서 IDE에서 '유형 계층 보기(Show Type Hierarchy)' 같은 기능과 병행해서 습관을 들이면 나중에는 새로운 기술을 배울 때도 크게 도움이 됩니다.

그 단계까지 가지 않더라도 API를 보는 습관은 여러모로 도움이 됩니다. 예를들어 자바에서 흔히 사용하는 리스트의 모든 항목을 다른 리스트로 옮겨야 할 때, 누군가는 아무 생각없이 for 문으로 복사를 할테고, 다른 누군가는 무조건 구글에 이런 저런 검색어를 입력하면서 답을 찾아 해메겠지만, API를 보는 습관이 있다면 바로 ArrayList의 메서드 목록을 죽 훑다가 쉽게 addAll을 찾을 것입니다.

물론 IDE의 자동 완성을 활용해도 좋습니다. 단지 이 경우는 자동 완성 뿐 아니라 앞서 언급한 계층 보기 등 다른 기능도 활용해서 API 문서가 제공하는 모든 정보를 IDE 내에서 확인할 수 있도록 연습할 필요는 있습니다.

stackoverflow에 질문 올릴때는 그래서 1st/2nd attempt를 해본 코드도 같이 올리라고들 하죠

fender // 계층보기 감사합니다~^^

역시나 문서는 자주보는 수 밖에 없는거네요.ㅠㅠ

저도 API 문서는 잘 정리된 인기 개발자 블로그의 글보다 더 가치 있다고 생각합니다. 실제 개발자가 만든 문서니깐 말이죠

그래서 API 문서 보려고 노력하는데요... 그놈의 언어의 장벽이... 

왠만한 건 다 영어로 되어 있어서.. 그렇다고 구글 번역기 돌려도 번역이 정확하진 않구요...

그래서 단어 하나하나 찾아서 스스로 번역 할 때도 있는데, 그러다보면 시간이 어느새 새벽이 되고 아침이 되고... 그러더군요... 그런 문제 때문에 독해 위주로 영어를 공부하고 있습니다만... 홈페이지 구현 문제도 있기 때문에 집중이 잘 안 되더군요 ㅠㅠ

본문 내용처럼 API을 읽는것도 중요하고

제발 무슨무슨 언어 써봤다, 공부했다 이런것보단

어떻게 개발했냐가 중요한거 같은데...

대부분의 사람들이 언어주의로 빠진듯 해서 아쉽네요;

저의 경우 저런 것들을 딱히 배워서 아는 내용은 아닌데, 저걸 모르면, 걍 학교/학원에서 시킨거만 공부하고 혼자 무엇을 만들어볼 생각을 안한거라 볼 수 밖에 없겠네요.

취미는 취미, 직업은 직업이라고 하는 분들이 많은데, 개발만큼은 취미로 좀 끄적여 본 분들이 해봐야 한다고 생각함.. 집에가서 컴퓨터 안켠다는걸 어찌 그리 자랑스럽게 얘기하는 사람들이 많은지 이해 불가..

맞는말씀이네요.

신입때 그렇게 했는데 반성하게 됩니다.ㅠㅜ

그냥 답글이 안 달리면 서칭을 하게 되고 자연스래 api문서를 보게 되고 그렇게 기본 소양이 갖춰진다고 생각합니당

프로그래밍으로 본인이 원하는 거, 생각하는 거를 직접 만들어보면 자연스레 갖춰지는 건데 학교, 학원에서 코딩마저 주입식으로 배우니까 그렇게 되는게 아닌가 싶어욤

실제로 그런 질문의 대다수는 실무자가 아니라 학생분들이기도 하구욤

기본기가 부족하다! 물어보는 최소한의 자세가 안돼있다! 마인드는 자칫하면 텃세가 될 수 있으니 경계하는게...

작성자분의 생각가진 분들이 많아졌음 좋겠습니다.

동의합니다..

fender님 경치가 12k 시넹...ㄷㄷ

RTFM 리턴하기전에 잘 좀 읽으십시오 휴먼

불만있습니까? 당신의 뉴런, 퍼셉트론으로 대체되었다

fender님의 글을 읽고 이제 어느정도나마 에러코드를 읽고 왜 문제가 나는지 생각하는 연습을 해서 점점 성장하는 느낌을

받는데 api 문서는 어떻게 읽어야하고 어떻게 응용해야할지 감이 잘 오지 않습니다.어렵네요

프로그래밍 언어를 자연어에 비교하면, API 문서는 쉽게 말해서 사전 같은 것입니다. 외국어를 공부하다 모르는 단어가 있으면 사전을 찾아서 정확한 정의와 예문을 찾듯, 코딩을 하다 모르는 클래스나 메서드를 접하면 API에서 해당 클래스의 계층 구조나 메서드의 용도나 동작, 그리고 예시를 찾아보시면 됩니다.

제가 하는짓거리

에러가 난다 -> 대충 읽고 에러를 복사한다 (대부분 맨 마지막줄) -> 모르겠으면 구글링 한다 -> 끗

언어랑 외모는 달라도 휴먼은 다 같은 휴먼이라 물어보는 에러도 다 같더라고요

스텍오버플로 가면 앵간하면 해결!!

단, 노하우 같은건 없더라고요

예전에 제가 올렸던 글입니다(^_^)

https://okky.kr/article/224329?note=224329

스스로를 되돌아 보게 됩니다. 감사합니다.

API 문서를 읽는 능력과 습관.. 정말 기본이면서도

띵하면서 기본기를 잊고 있었던 느낌입니다.

제 자신을 되돌아보게 해주는 글이 였어요 감사합니다.

P.S

혹시 API 문서들이 거의 영어일텐데.. 영어를 못하면

번역기를 써서 읽고 유추해야되는지 아니면 영어를 공부해서라도 한땀한땀 API에 나와있는

클래스나 기능들을 해석해야하나요?

그럴려면 내장함수 하나 해석하는데도 시간이 꽤 걸리지 않을까 싶어서요.. 끝이 안보인달까

1122cc // 개인적으로는 영어 독해 공부는 추천 드리고 싶습니다. 아무래도 기술 관련해서는 우리말로 번역되는 정보는 양도 적고 최신 내용이 아닐 가능성이 높습니다.

영어 공부 관련해서 전에 쓴 글이 있으니 관심있으시면 참조하시기 바랍니다:

• 개인적으로 추천하는 효율적인 영어 독해 공부 방법

제 생각에는 꾸준히 영어 공부를 하면서, 당장 필요할 때는 구글 번역기의 힘을 빌어서 API 보는 습관을 키우시면 괜찮을 듯 합니다.

감사합니다 막 신입 개발자로 취업해서 늘 오류를 복사하면서 찾는 제 자신을 보며, 무엇인가 겉도는 느낌이었습니다!

개발에 기본을 알려주셔서 감사합니다

동감합니다

몇개의 프로젝트를 자체 개발하면서 운영중입니다.
원하지는 않았지만 개발에 참여해야하는 상황이네요.
영어와 중국어로된 API도 봐야하는 상황입니다.
봐야하는 양이 많다보니 회피책은 기본이 된것 같습니다.

이 글을 공지사항으로!!!

아아..! 눈부셔! 먹구름 사이로 정체 모를 빛이 나고 있어!!

진짜 오류트레이스는 왠만하게 이상한거 아니면 다 뭐가 잘못됬는지 보이는데....추천하고 갑니다ㅎㅎ

fender님 글에 매우 동의하면서 인절미님 댓글에 공감도 됩니다 ㅎㅎ
프로그래머도 근본은 과학자라고 생각하는데 과학적인 사고를 꺼리는 분들을 많이 
접합니다. 개발자 세계에서도 반지성주의는 팽배한 것 같아요.

뜨끔합니다. 좋은 글 감사합니다. api 와 오류 메시지를 읽는 습관 메모메모

삽질이 전문이다보니 api 문서를 열씨미 삽질해도 기미가 안보이다가 한가닥이 딱 맞아 떨어질때는 희열을 느끼죵 ~

좋은 글보고 가용~

이건 개발 환경마다 약간 다를 수 있다고 생각되네요. Nodejs 환경에서 프로그래밍 하면 자바와 달리 정말 기상천외한 오류가 많습니다. 환경 설정이 약간만 달라도 오류가 생기고 대부분의 모듈이 오픈 소스인지라 자바와 달리 documentation이 부족한 경우가 많습니다. 그럼 해당 git repository에 가서 직접 개발자에게 물어야 하고 조금 특이한 프레임워크나 툴을 쓰면 새로운 버그를 발견하는 경우도... 심지어 module 자체는 괜찮은데 모듈의 의존성에 해당하는 모듈이 업데이트 되면서 새로 문제가 생기던가.

예전에 Hyper라는 오픈소스 프로젝트 참여할 때 yarn으로 윈도우에서 환경 설치하면 env 값에 문제가 생겨 고생하다가 그 당시는 잘 몰라 익숙한 리눅스로 개발하자는 생각에 WSL에 electron 구동하려다 계속 이상이 생겨 나중에야 WSL이 지원을 못하는 걸 WSL 쪽 github issue에서 발견한게 생각나네요. 당시 너무 시달려서 윈도우 포맷하고 우분투를 설치해서 돌렸던 기억이 아직도 생생하네요... 생겨 API document가 상대적으로 빈약한 js의 경우 구글링이 빠른 경우가 많습니다. 이렇게 시달리다 보면 왜 Docker를 극찬하는지 알게 됩니다.

결론은 API document와 그 빈약한 문서를 이해하기 위해 구글링도 함께 하게 되더군요....

스칼라가좋아 // 기본적인 API 문서 해석도 못하고 스택트레이스 보고 디버그도 못하는 수준의 개발자가 정말 깃헙 이슈 찾아보고 영어로 개발자한테 직접 물어보면서 문제 해결하는 게 가능할 거라고 보시나요?

API를 볼 줄 안다고 구글링 안해도 된다는 주장을 한 적은 없습니다. API를 볼 줄 아는 건 제목에 적었듯 개발자의 기본 소양이고, 그런 개발자도 말씀하신 사례와 같이 구글링에 의존할 때가 있는 것이지, 구글링이 API 보는 능력이나 스택트레이스 읽는 법 같은 기본기를 대체하진 않는다는 뜻입니다.

fender // 저도 님의 의견에 동의합니다. 다만, 앞에 말했듯이 개발환경마다 정보를 습득하고 문제를 해결하는 패턴이 달라진다 정도의 의견입니다. (고로 님에 의견해 반대한 적도 없습니다. 주장이 동의나 반대 둘 중 하나일 필요는 없으니까요) 예를 들어, DB2 같은 경우 구글링을 해도 나오는게 없어서 강제로 IBM Reference만 보게 되는 경우도 있고 그런 특이 경우를 언급한 것입니다. 저는 이 사이트에 온지 얼마 되지 않았고 프로그래밍도 국내에서 배운 것이 아니라 OKKY나 한국의 개발 문화가 어떤지는 잘 모릅니다. 말씀하신 내용을 들으면 한국의 진입장벽은 상당히 낮은 것처럼 들립니다. 캐나다에서는 적어도 프로그래머가 되기 위해선 관련 학과를 나와서 학과 상위권은 물론이고 포트폴리오부터 기술면접까지 어느 정도 뒷받침이 되어야만 합니다. 프로트 엔드 엔지니어를 뽑을 때도 화이트 보드 테스트를 합니다. 대기업이 아니라 일반적인 기업을 가기 위해서 철저한 소양을 요구해서 쥬니어 포지션을 구하는게 쉽지가 않습니다. 그럼에도 기본기가 안되서 낙오되는 사람이 많은데. 님이 말한 수준의 사람들이 개발자를 할 수 있다는게 상당히 이상하게 들립니다. 그런 분들은 학교 프로젝트 경험상 같이 일하는 동료들에게 피해를 주는 수준인데 어떻게 개발자로 일할 수 있는지 궁금하네요.

스칼라가좋아 // 아무래도 어떤 주장을 하는 글타래에 "상황에 따라 다를 수 있다"는 전제로 반례를 든다면 기본적으로 본문에 반대하는 입장으로 해석할 수 밖에 없지 않을까요?

님이 말한 수준의 사람들이 개발자를 할 수 있다는게 상당히 이상하게 들립니다. 그런 분들은 학교 프로젝트 경험상 같이 일하는 동료들에게 피해를 주는 수준인데 어떻게 개발자로 일할 수 있는지 궁금하네요.

말씀하신대로 매우 이상한 상황이 맞고, 본문의 글은 바로 그런 이상하게 왜곡된 환경에서 국비교육 학원 등을 통해 기초는 다 건너 뛰고 딱 정해진 틀에 맞춰서 페이지 찍어내는데 최적화된 훈련을 받을 수 밖에 없는 그런 분들을 위해 쓴 글입니다.

본문의 도입부에서 그 부분을 이야기했는데, 아마도 국내 환경에 익숙하지 않으시다보니 내용을 최소한의 기본은 갖춘 개발자들이 검색으로 문제를 푸는지 문서로 푸는지 문제에 대한 일반론으로 읽으신 것 같습니다.

우리나라 개발자들 보면, 도중에 하기 싫으니까 무슨 방법으로든 어떻게든 대충 떼울라고만 하고 그런 사람들 참 많습니다.

왜 이런 증상이 일어났는지 오류 로그를 자세히 확인하면서 오류를 조치하는것이 어느 회사를 가거나 무슨 개발을 하든 가장 기본인데 왜 이걸 계속 안하려고만 합니까!

그런식으로 하면 실력 절대로 향상 못됩니다.

계속 그런식으로만 할거면 한시라도 빨리 개발자 포기하고 다른 직업 구해서 먹고 살수 있도록 노력하는게 정답입니다.

잔소리충 포함 인간 기본 안 된것들이 더 짜증남.

조금 주제에서 벗어날수도 있겠지만.. 

저는 검색'도' 해야 한다고 생각해요. 물론 API문서와 스스로 찾아가는 노력도 중요하긴 하지만

다른사람이 생각하는 의견도 들어보는게 장기적으로 봤을 때 도움이 되는 경우가 많거든요

검색을 하다보면 엉뚱한 주제의 글을 찾아보게 되기도 하지만 그 행위 자체가 찾고자 하는

결과에 도움이 되지 않을 수 있으나 다양한 시도와 방법을 간접경험 할 수 있다고 생각해요

우리가 커뮤니티에 와서 글들을 읽어 보고 있는 것 처럼요~^^

카피 & 붙여넣기가 답

구글링도 하고 찾아보고 API문서도 보고 질문도 하고 다시 API문서도 보고 반복하다보면 익숙해지는것같습니다~~ (저도 익숙해지는중..ㅠㅠ)

API, 오류트레이스 보기 이런 게 좋기는 한데 지적하는 문제와는 좀 맞지 않는 것 같네요.

기본기 운운이요.

그건 그냥 사람 성향의 문제지 교육 시스템의 문제는 아니라고 봅니다.

꼭 개발분야가 아니더라도 어렵게 찾지 않고 누군가에게 쉽게 답을 찾으려고 하는 경우는 많아요.

예를 들면 전자제품이든 자동차든 매뉴얼 읽어보는 사람이 얼마나 될까요?

제품을 사고 매뉴얼을 읽어보는 건 둘째치고, 문제가 생겼을 때 일단 서비스센터에 전화한다거나 수리점에 간다거나 하지 매뉴얼을 찾아보는 사람은 그렇게 많지 않습니다.

좀 다른 얘기인데 매뉴얼이란게 굉장히 친절한 경우도 있지만 그렇지 않은 경우도 많습니다.

특히 초보에게는요.

매뉴얼이 있음에도 수많은 입문서가 존재하는 이유도 그렇습니다.

사전(영어사전,국어사전 등)도 예를 들면 충분히 설명이 되어있어도 그 묘한 느낌이 잘 설명이 안 되는 경우도 많습니다.

그래서 구글에서 찾아보면 비슷한 사유로 질문하는 경우도 많습니다.

반창고 // 비유를 잘못하신 것 같습니다. 개발자는 자동차의 운전자가 아니라 최소한 정비사이고 보통은 자동차 만드는 회사의 엔지니어입니다.

개발자가 오류 트레이스를 못읽는 건, 자동차 정비사란 사람이 수리는 고사하고 본넷도 못여는 거나 같은 수준의 이야기입니다. 일단 열어서 들여다 봐야 뭐가 고장난지 알죠. 그거 하라고 돈받고 서비스 제공하는 사람이 정비사고 말입니다.

문서 이해하는데 오래 걸릴 수도 있고, 오류 트레이스 남들보다 힘들게 배울 수도 있고, 영어 약해서 사전 찾아보는 거 다 좋습니다. 그런데 그렇게 해도 API 못읽고 트레이스 이해 못하거나, 귀찮아서 그건 죽어도 못 배우겠단 사람은 그냥 딱 잘라서 개발자 하면 안됩니다.

API읽고 트레이스 이해하는 건, 의사라면 혈압이 뭔지 알고 잴 줄 아는 거고, 정비사라면 본네트 열어서 엔진 들여다 볼 줄 아는 정도의 기본입니다.

병원에 가서 고혈압이 있다고 하니 의사가 "혈압이 뭔가요?"하면 그건 의사 성향의 문제가 아니라 자격의 문제인 겁니다.

초보한테는 API 문서나 오류 트레이스 읽는 게 어렵다고 하셨는데, 초보라면 차라리 이클립스나 스프링을 몰라도 좋으니 그걸 먼저 배우는 게 맞습니다.

개발툴이나 프레임워크 선택이야 말로 성향과 유행의 문제이지만, API나 오류 읽는 법은 초보가 개발 입문해서 제일 먼저 배워야 할 내용입니다.

표현이 너무 과격하고, 초보자와 비전공(학원출신 등)을 무시하는 듯한 인상이 있기 때문에 단 댓글이었습니다.

API를 읽고 오류를 척척 분석하는게 초보에게 그리 쉬운 일이 아닙니다.

어느정도 배경지식이 있고 경험도 있어야 합니다.

개발도 그렇고 다른 분야도 그렇고 배우는 과정이 다 동일하지 않습니다.

습득 및 문제해결에 뛰어난 사람도 있고 아닌 경우도 있습니다.

당연히 문제를 해결하는 방법에도 차이가 있고 발전하는 방법 및 속도에도 차이가 있겠죠.

뛰어난 개발자가 있으면 그렇지 않은 개발자도 있는 겁니다.

다 뛰어난 개발자만 존재할 수는 없어요.

자기 생각하고, 이상적인 것과 다르다고 너무 힐난하지는 말길 바랍니다.

반창고 // 제가 말하는 건 누구나 다 라이브러리 프레임워크 척척 만들어내는 고수가 되라는 건 아닙니다. 근데 API나 오류 보는 건, 하수건 고수건 '개발자'라는 이름을 달면 당연히 가장 기본으로 배워야할 내용이란 겁니다.

누구나 메시가 될 수 없다면 인정할 수 있습니다. 그런데 그럼 프로 축구선수 지망생이 드리블 못해도 되나요?

축구선수가 드리블하는 건 '이상'이 아니라 '기본'입니다. 위에서도 말했지만, 재능에 따라 그걸 빨리 배우고 늦게 배우고 하는 차이는 다 인정할 수 있는데, "드리블 너무 어렵더라, 난 드리블 안하고 그냥 서있다가 패스만 할래" 그러면서 프로축구 선수가 될 수는 없다는 겁니다.

프로그램 개발이라는 건 단순화 해서 말하면 레퍼런스 보고 코드를 짜서 돌려보고 안되면 오류 잡는 과정의 반복입니다. 그리고 레퍼런스 볼 줄 아는게 API 문서 읽는 거고, 오류 잡는 과정의 가장 기초가 트레이스 읽는 겁니다.

그 두 가지는 인터넷 검색 같은 걸로 대체할 수 있는 게 아닙니다.

그리고 솔직하게 비전공 학원 출신은 공부해도 구글 번역에 복붙 한 번만 하면 한글로 나오는 API 문서도 어려워서 못 읽을 수준이라고 한다면, 그 분들을 무시하는 건 제가 아니라 반창고님이 아닐까요?

영어로되어있어서

API 도큐먼트나 스택오버플로우글 읽기에 부담되어서 그러는 사람들도있는데

그런분들에게는 크롬브라우저에 우클릭->한국어로번역 기능이 많은 도움이되리라 생각합니다

의외로 모르시는분들이 많더라고요

부르주ㅇr // API 문서를 읽는 법 자체는 그렇게 어렵지 않습니다. 분량이 방대해서 그렇지 패턴은 계속 반복되는 것이기 때문에 그냥 클래스와 메서드 한 둘 만 잡아서 문서를 완벽하게 이해할 만큼 읽어보면 아마 다른 클래스나 메서드도 눈에 잘 들어오실 듯 합니다.

문서를 읽는 방법을 떠나서 문서를 읽고 해당 라이브러리의 구조를 잘 이해하는 팁이라면 클래스의 계층 구조부터 살펴보시는 것을 추천 드리고 싶습니다. 클래스가 어떤 부모의 특성을 물려 받았고 어떤 인터페이스를 구현했는지만 알아도 해당 클래스의 기능에 대해 상당히 많은 추론을 할 수 있습니다.

fender // 개인적인 생각은 이렇습니다.

 저는 윈도우 진영개발자입니다. 아시다싶이 MSDN에 누구보다 많은 베스트 프랙티스가 있고 문서화가 잘되어 있죠 다만 저도 처음에는 눈에 들어오지 않았습니다. 이 분야에서도 WPF 의 MVVM패턴 프레임워크 국내 레퍼런스라고는 찾아볼수 없고 국외에서도 그렇게 흔하다고는 할수없습니다. 

그리고 그후에 github에서 이부분의 불편함을 해소하려고 국문으로 많은 노력을 하고 있구요.
이 분야에서는 나름 자부합니다.

처음에는 눈에 보이지 않고 스택 트레이스요? 몰랐습니다.
지금은 아주 당연한거고 MSDN 또는 파생된 docs들 밥먹듯이 보지요

다만 fender님이 동종 업계 경력자 선배이고  이글을봤다면 혹은 저에게 말했다면 저는 개발자의 꿈을 진작 접었을것갔네요.
이런글들 보면 뭐랄까 개발자가 뭐 아주 엄청난 직업인가? 싶습니다. 
 
볼줄모르면 딱잘라서 개발자 하지 말아야한다고요? 주니어들은  대댓글에서 말씀하셨다싶이 개발자라는 타이틀은 달고있는데 모르잖아요? 접어야하나요?  대체 개발자가뭔가요? 자신들의 주관이나 성숙도는 배제된건가요? 

저는 이런글들이 뭔가 허들을 만드는것이라고 생각합니다. API문서 못봐도됩니다. 그냥 자신이 만들고 싶은 프로그램만들고 회사의 도메인문제에서 문제를 찾고 해결하고 편의를 제공하는재미가 있으면 개발자를 할수 있는 자질은 아주 충분하다고 봅니다 나머지는 위 조건이 유지된다면 자연히 지속됩니다.

영어권 커뮤니티에서도 인디안 유투버가 최고 강사니 스택오플이 최소 선생이니 하는 유머가 그냥 매우 일반적인 유머입니다. 대체  이러이러한 사람들은 개발자 하지 말아야한다는 본인 피셜은 매우큰 반감이 드네요 ㅎ

tikili // 글의 취지를 오독하신 것 같습니다. 처음 개발 배울 때 모르는 게 많은 건 당연합니다. 당연하지 않은 건 매우 기본적이고 중요한 내용도 "너무 어렵다"고 배울 시도조차 하지 않는 것이죠.

"딱잘라서 개발자를 하면 안된다"는 건 맥락을 생략하고 그 부분만 잘라서 인용하셨는데, 다른 분들 오해하실까봐 전체 문장을 다시 소개하면 이렇습니다:

문서 이해하는데 오래 걸릴 수도 있고, 오류 트레이스 남들보다 힘들게 배울 수도 있고, 영어 약해서 사전 찾아보는 거 다 좋습니다. 그런데 그렇게 해도 API 못읽고 트레이스 이해 못하거나, 귀찮아서 그건 죽어도 못 배우겠단 사람은 그냥 딱 잘라서 개발자 하면 안됩니다.

이걸 보고 "개발자라면 처음부터 스택트레이스는 술술 읽을 줄 알아야 한다"라거나, "개발자는 스택오버플로 따위 보지 말고 개발해야 한다" 부류의 주장으로 이해하셨다면 그건 제 잘못은 아닌 듯 합니다.

위에서 직접 번역기를 돌려서 영어를 모르는 사람도 시도만 하면 얼마나 쉽게 API를 읽을 수 있는지를 직접 소개하기 까지 했는데, 이를 두고 말씀처럼 "개발자가 뭐 아주 엄청난 직업인가?" 싶은 생각이 들고 개발자를 접고 싶을 정도로 반감이 드는 사람이 있다면, 전 솔직히 개발자 그만두는 것이 맞다고 생각합니다.

저는 좋은 개발자가 되기 위해 반드시 학벌이나 전공 여부가 중요한게 아니다란 이야기도 자주 했습니다만, "구글 번역기 돌려서 한 번 읽어보라"는 이야기가 그 정도로 엄청나게 어렵고 거부감이 드는 사람은 아마 높은 확률로 좋은 개발자는 못 될 거라 생각합니다.

개발자 하는데 무슨 특별한 자격이 필요한 건 아니지만, 최소한 번역기 클릭은 할 줄 알고 결과로 나오는 한글 문장은 읽을 줄 알아야 하는 거 아닌가요?

한글 영문 문제가아닙니다. ..

"오래걸리더라도 사전찾아서 봐야한다 / 번역기 돌려서 봐라 / 그런데 그렇게해도 못읽으면 개발자하면안된다"

이말대 대체 어떤 오독이 있습니까?
그냥 API보려고 노력해봐도 안되면 개발자 그만둬라 인데 당장 개발할게 눈앞이고 툴자체도 익숙하지 않고 기간은 급급해오고 이때도 API문서보고 차근차근 오래걸리더라도 노오력을 해야하나요? 

하면서 인터넷찾고 공부하고 주말에 공부하고 그러다보면 익숙해지고 패턴이 보이고 문제점도 찾고 그러다보면 설계도 하고하는거지요

문제가 되야할부분은 API를 보냐 안보냐가 아니라  시간이 꽤 흘렀고 익숙해졌음에도 문제가 생겼을떄 근본부터 해결하는것이 아닌 검색을 통해서 현상만 일시적으로 해결하는식으로 일하려는 개발자입니다.  API를 읽지못하는 개발자가 아니라요.

아시다 싶이 어치피 근본부터 해결하기위해서는 어차피 흘러흘러 공식 레퍼런스를 봐야할수밖에 없습니다.

API를 볼수있는니 없느니는 매우표면적인 문제입니다. 이런 표면적인것으로 개발자를 하면된다 안된다는 판단할일이 아니라고 보여지네요.

논외로 반창고님도 지적하셨는데 
"혹시 멋모르고 국비 지원 학원 등을 통해 스프링을 속성으로 배우고 취업을 노리거나 막 업계에 발을 들인 초보 개발자라면, 다른 모든 걸 제쳐두고 API 문서와 오류 읽는 방법부터 익히고 습관화 하는 걸 추천드립니다."

이부분은 저도 조언이라기 보단 무시하는것으로 보이네요 왜 타겟이 학원인지? 전공자도 마찬가지로 보이는데요 ㅎㅎ

"그리고 솔직하게 비전공 학원 출신은 공부해도 구글 번역에 복붙 한 번만 하면 한글로 나오는 API 문서도 어려워서 못 읽을 수준이라고 한다면, 그 분들을 무시하는 건 제가 아니라 반창고님이 아닐까요?"

라고 대댓글 다신 부분도 이상하네요 우선 전제가 너무 마음대로 깔려있습니다
" 솔직하게 비전공 학원 출신은 공부해도 구글 번역에 복붙 한 번만 하면 한글로 나오는 API 문서도 어려워서 못 읽을 수준이라고 한다면" 전공자도 마찬가지입니다 ㅋ 저도 전공자구요 ㅎㅎ

학원출신을 전공자로 바꿔도 똑같은것같은데요 어느부분이 반창고님이 그분들 무시한건지 하나도 모르겠네요. ㅎㅎ

그리고 협압 → API의 지식 이부분의 비유도이상하네요 

글이 fender님이 처음 하시고자했던 추천, 권장, 권고 등으로 마무리되었으면 좋았겠지만 대댓글이 본문일부에서 과격함있네요. 

tikili // 영어가 문제가 아니라구요? 그럼 더 이해를 못하겠는데요. "객체가 필요한 경우 응용 프로그램에서 null을 사용하려고하면 발생합니다"가 정말 님 생각엔 충분히 노력해도 이해 못할 정도로 심각하게 어려운 내용인가요?

아니면 예외 트레이스 읽는 법이 길어도 한 두 시간 쯤 시간 들여 공부해도 이해 못할 만큼 대단히 복잡한 내용인가요?

제 상식으로는 저 수준의 한글 문장 조차 노력을 충분히 해도 이해 못하는 사람이 어떻게 의존성 주입 같은 거창한 개념을 포함하는 엔터프라이즈 프레임워크를 배워서 기업이 실무에 쓸 인프라를 만든다는 건지 도저히 이해가 가지 않는군요.

그리고 그런 식으로 API 안보고 오류 확인도 안하는 습관이 들어버린 개발자가 시간이 지나면 어떻게 뜬금없이 말씀처럼 "MSDN은 밥먹듯 보는" 수준으로 진화를 한다는 건지도 도저히 이해 못하겠습니다.

공부도 기본이 있고 습관이 되야 할 수 있는 것입니다.

모든 걸 떠나서, 입문 단계에서 시간이 있을 때, 그리고 아직 안좋은 습관이 들기 전에 저런 기본을 배우라는 제 충고를 그토록 고깝게 들으시는 분이, 이미 실무에 진입해서 일정 빡빡한 개발자한테 API 읽는 법 공부해서 근본부터 해결을 안하면 문제라고 이야기 하시면 그건 모순이 아닌가요?

취준생이 오류 읽는 법 한 두 시간 찾아볼 여유도 없다면 SI 프로젝트에서 구르는 개발자는 이제와서 처음부터 기초 공부 다시 할 만큼 시간이 넘쳐 납니까?

님말 듣고 API 공부, 오류 읽는 법 따위 무시하고 어찌어찌 구글링으로만 이 바닥에서 3년 쯤 살아남은 개발자가 있다면, 그런 개발자한테는 3년 채웠으니 이제는 API 못 보면 넌 허접하다라고 욕해도 된다는 건지...

님이 같이 일하는 개발자들은 공부 안하고 3년 쯤 묵혀 두면 갑자기 무슨 번데기 됐다가 수퍼 개발자로 변태라도 하나요?

답변드립니다.

1. 영어가 문제가 아니라구요? 그럼 더 이해를 못하겠는데요. "객체가 필요한 경우 응용 프로그램에서 null을 사용하려고하면 발생합니다"가 정말 님 생각엔 충분히 노력해도 이해 못할 정도로 심각하게 어려운 내용인가요?

→ 예로드신내용이 너무 주장 맞춤 예제이네요

예로 신입개발자(환경의 신입)가 WPF MVVM패턴을 구성하기위해서 PRISM프레임워크를 씁니다. MediaElement를사용하고 테스트를 하려는데 잘안됩니다. 어디를 보아야할까요?

" 뷰가 실행 컨텍스트의 일부로 WPF 구성 요소를 실행하거나 실행하는 데 영향을 주거나 종속되는 경우 문제가 됩니다. 이러한 종속성 없이 뷰 논리를 격리하여 단위 로직을 테스트할 수 있도록 하려면 뷰와 논리에 대해 별도의 클래스가 필요한 실행 컨텍스트에 대한 종속성을 제거하기 위해 뷰모형을 만들 수 있어야 합니다." 

위 내용을 보고 "아하"하고 해결할수있나요?

지금이야 경험이 있고 맥락상 무슨 말인지 이해가 가죠 이런 부분이 신입이 처음에 다짜고짜 노력한다고 이해가됩니까? 구글링하고 질문하고 경험해보고 부딪쳐봐야 익혀지는것이죠. 

2. 아니면 예외 트레이스 읽는 법이 길어도 한 두 시간 쯤 시간 들여 공부해도 이해 못할 만큼 대단히 복잡한 내용인가요?

→  전제가 왜 이렇게 되었죠? "처음에는 눈에 보이지 않고 스택 트레이스요? 몰랐습니다." 다른 댓글 본문에서 말한 이부분을 저렇게 해석하신건가요?

3. 제 상식으로는 저 수준의 한글 문장 조차 노력을 충분히 해도 이해 못하는 사람이 어떻게 의존성 주입 같은 거창한 개념을 포함하는 엔터프라이즈 프레임워크를 배워서 기업이 실무에 쓸 인프라를 만든다는 건지 도저히 이해가 가지 않는군요.
그리고 그런 식으로 API 안보고 오류 확인도 안하는 습관이 들어버린 개발자가 시간이 지나면 어떻게 뜬금없이 말씀처럼 "MSDN은 밥먹듯 보는" 수준으로 진화를 한다는 건지도 도저히 이해 못하겠습니다.

→ 혼용해서 생각하시는것같습니다. 처음에는 몰랐지만 → 지금도 모르다 →MSDN밥먹듯이 본다? 이렇게 생각하시는건가요? ㅎㅎ 처음에는 몰랐지만 →익숙해졌다→ 지금은 MSDN을 밥먹듯이 본다이죠

4. 어떻게 의존성 주입 같은 거창한 개념을 포함하는 엔터프라이즈 프레임워크를 배워서 기업이 실무에 쓸 인프라를 만든다는 건지 도저히 이해가 가지 않는군요.

→  3번이 답변이 됐을거라고 생각합니다. 개인적으로DI가 거창한 개념이라고 생각하지도 않고  현재 잘적용해서 많은 장비들이 운용되고 있습니다. 3번의 답변참고하시면될것같네요 ㅎㅎ

제가 "아시다 싶이 어치피 근본부터 해결하기위해서는 어차피 흘러흘러 공식 레퍼런스를 봐야할수밖에 없습니다." 이렇게도 써놨는데 말이죠 

5. 그리고 그런 식으로 API 안보고 오류 확인도 안하는 습관이 들어버린 개발자가 시간이 지나면 어떻게 뜬금없이 말씀처럼 "MSDN은 밥먹듯 보는" 수준으로 진화를 한다는 건지도 도저히 이해 못하겠습니다.

→ "그리고 그런식" 대체 이것의 전제는 무엇인가요??? 전제가 항상이러시네요
 뜬금없이겠습니까? 아니면 제가 API를 절대 보지 말라고 주장을했습니까 ㅎㅎ "표면만 해결하려는 개발자들이 문제"라고 제가 주장했던것처럼 표면만 해결하려고 하지 않고 공부하다보면 자연스럽게 API를 볼수밖에 없고 그러다보면 익숙해진다는거지요 제가 자연스럽게 API를 보지않아도된다는 사람처럼 전제가되었네요?

6. 공부도 기본이 있고 습관이 되야 할 수 있는 것입니다.
모든 걸 떠나서, 입문 단계에서 시간이 있을 때, 그리고 아직 안좋은 습관이 들기 전에 저런 기본을 배우라는 제 충고를 그토록 고깝게 들으시는 분이, 이미 실무에 진입해서 일정 빡빡한 개발자한테 API 읽는 법 공부해서 근본부터 해결을 안하면 문제라고 이야기 하시면 그건 모순이 아닌가요?

→ 이상하네요 ㅎㅎ API를 보는것만이 공부입니까? 아니면 제가 API를 보지 말라고 했습니까? API를 무시하라고 했습니까 비약이 심하시네요.  

처음에는 눈에 안들어오니 API가 눈에 안들어오면 여기저기 질문 올리고 스오플에서 질문보고 답변보고 해보고 만들어보고 그러다보면 맥락이 이해가가고 API가 눈에 들어온다 이 주장이  위처럼 들리셨나요? 대체 무엇이 모순이죠?

7. 취준생이 오류 읽는 법 한 두 시간 찾아볼 여유도 없다면 SI 프로젝트에서 구르는 개발자는 이제와서 처음부터 기초 공부 다시 할 만큼 시간이 넘쳐 납니까?

→ 대체  어느부분에 제가 저렇게 말했죠? 제가 API습관들이는거 자체를 하지 말라고했나요? 

8. 님말 듣고 API 공부, 오류 읽는 법 따위 무시하고 어찌어찌 구글링으로만 이 바닥에서 3년 쯤 살아남은 개발자가 있다면, 그런 개발자한테는 3년 채웠으니 이제는 API 못 보면 넌 허접하다라고 욕해도 된다는 건지...
님이 같이 일하는 개발자들은 공부 안하고 3년 쯤 묵혀 두면 갑자기 무슨 번데기 됐다가 수퍼 개발자로 변태라도 하나요?

→  또.. 말씀하신 "님말 듣고" 전제는 무엇인가요? 제가 API를 안읽고 안보고 무시하고 일을 처리하나요?제글을 댓글을 제대로 안보신것같네요. 저는 API참조하고 이것저것 참조해가면서 일하는데말이죠...기간 3년은 어디서 나왔나요? 1년이고 10년이고 상관없습니다. 

다시 한번 말씀드리지만 정말 문제인것은 프레임워크에 익숙해졌음에도 문제가 생겼을때 표면만 해결하려는 개발자입니다. 그렇지 않은 개발자라면 당연히 익숙해지면 API를 볼수밖에 없습니다.

말씀하시는 논리전개 방식이 마치 제가 "우주 외계인이 없다고 말할수는 없다" 라고주장하면  이걸 "우주에는 외계인이 있다"라는 주장으로 받아 들이시는것같습니다. 저는 우주를 모두 탐사해보는것은 불가능하니 없다고 단정지을수 없다고 말하는것임에 말이죠.

전제무엇...

tikili // 점점 논리가 산 넘고 강건너 우주로 향하고 있는 것 같습니다. 본문 내용을 읽어는 보신 게 맞나요? 아니면 덧글에서 "개발자를 접어야 한다"는 표현만 보고 반사적으로 발끈해서 반박부터 하다보니 논리가 꼬이신 건가요?

본문의 제 주장은 매우 단순합니다. 예외를 읽는 법, API를 보는 능력은 모든 개발자의 기본이니 무턱대고 스프링 같은 거 뜻도 모르고 외우지 말고 작은 것부터 습관을 들이는게 좋다, 그 뿐입니다.

그런데 도대체 "API 읽는 법 배우면 WPF/PRISM 프레임워크 같은 건 다 이해한다는 거임?" 같은 '반론'은 어디서 튀어나온 건지, 또 "API 보는 법 부터 배우라"고 했다고 제가 무슨 대단한 텃새라도 부린 양 이렇게 까지 강하게 반박을 하셨으면서 이제와서 "내가 API 보지 말랬느냐"고 반문하면 뭘 어쩌란 건지 모르겠습니다.

제 덧글을 보고 "DI가 거창하지 않다"라고 '반박'하시는 건 솔직히 독해력의 문제라고 봅니다. 아니면 무조건 반박하고 싶은 마음이 앞서서 본인이 무슨 이야기를 무슨 논리로 논박하는지도 놓치셨든지요.

한 번 논리를 되짚어 볼까요?

A: 막 입문한 개발자라면 스프링 같이 어려운 것 부터 덤비지 말고 API 보는 법, 예외 읽는 법 같은 기본 부터 배워라.
B: 입문 단계 개발자한테는 그 것도 어렵다.
A: 영어 때문에 그런 거면 구글 번역기라도 쓰면 된다.
B: 영어가 아니라 그 자체가 어렵다. 시간도 촉박한데 API 볼 시간이 없을 수도 있다.
A: 구글 번역해서 NPE 같은 예외 설명 읽는 것도 어려우면 스프링 DI 같은 건 더 어렵다.
B: 나 DI 안어려운데? 근데 PRISM 같은 건 신입한테 보여주면 API 읽는 법 배웠다고 이해할 수 있냐?
A: (도대체 지금 뭔 소리를 하는 거야?) 아니, API 읽는 법도 바쁘고 어렵다고 안 배운 개발자가 그럼 시간 지나면 어떻게 그런 걸 다 알게 된다는 건가?
B: 내가 언제 API 보지 말라고 했음? 나는 잘만 보는데?
A: ......

이런 '논리' 전개에서 뭔가 이상함을 못 느끼셨다면 그만하죠. 뭐 제가 논리가 없이 우긴다고 생각하셔도 님 자유구요. 이 정도로 논리가 우주로 향하는 '토론'이라면 전 이길 자신도 없고 그래야하는 이유도 못 찾겠습니다.

예를든것이 우주라는 단어가 나왔다고해서 우주로 향하는 토론인가요?ㅎㅎ

API 보는 법 부터 배우라"고 했다고 제가 무슨 대단한 텃새라도 부린 양 이렇게 까지 강하게 반박을 하셨으면서 이제와서 "내가 API 보지 말랬느냐"고 반문하면 뭘 어쩌란 건지 모르겠습니다

저는 계속 일관된 주장을 하고있습니다.

B: 나 DI 안어려운데? 근데 PRISM 같은 건 신입한테 보여주면 API 읽는 법 배웠다고 이해할 수 있냐?
A: (도대체 지금 뭔 소리를 하는 거야?) 아니, API 읽는 법도 바쁘고 어렵다고 안 배운 개발자가 

이 부분이 납득이 안가시는것같은데 저떄 말한건 글에 언급되었듯이 신입기준입니다. 신입이 환경도 익숙치않고 시간도 없는데 눈에 들어오지도 않는데 현실적으로 API를 어떻게 노력하면서 보고있느냐? 입니다.따라서 이것저것하다고 마인드셋만 정상이면 API는 추후 자동으로 보게된다입니다.

tikili // 

저는 이런글들이 뭔가 허들을 만드는것이라고 생각합니다. API문서 못봐도됩니다.

당장 개발할게 눈앞이고 툴자체도 익숙하지 않고 기간은 급급해오고 이때도 API문서보고 차근차근 오래걸리더라도 노오력을 해야하나요?

아니 대체 API보지말라는 아니 근처의 주장이라도 어디있죠?

전 이만 빠지겠습니다. 저하고 싸우기 이전에 본인의 분열된 자아부터 통합하시기를.

맥락을 파악못하시는건가요 모르는척하시는건가요?

그뒤에 바로 이어진

"그냥 자신이 만들고 싶은 프로그램만들고 회사의 도메인문제에서 문제를 찾고 해결하고 편의를 제공하는재미가 있으면 개발자를 할수 있는 자질은 아주 충분하다고 봅니다 나머지는 위 조건이 유지된다면 자연히 지속됩니다."

 왜 삭제하시고 딱 저부분만 올리시는거죠  납득이 안가네요 매 글마다....

차근차근 오래걸리더라도 노오력을 해야하나요?

위글도 신입이 바쁜상황을 전제하에 말하는 앞에 부분은 다 어디갔나요?

악마의 편집도 아니고

대체 API보지말라는 아니 근처의 주장이라도 했나요? fender님 마음대로 전제를 정하시고 설명하면 매번 이런식이시네요 . 

저는 계속하여

처음부터 제대로된 개발자라면 이것저것하고 익숙해지면 API는 자연스럽게 보게된다입니다.
(그렇지 않은 개발자는 문제이다)

라는 주장을 계속하고 있는데 말이죠.

어떤분인지 알겠습니다. 수고하십시오.

tikili // 

위글도 신입이 바쁜상황을 전제하에 말하는 앞에 부분은 다 어디갔나요?

아니, 그래서 제가 머리 좋은 사람이면 넉넉 잡고 30분이면 배울 수 있는 예외 트레이스 읽는 법, API 문서 찾는 법 배우는 것도 어렵고 바빠서 못할 신입이면 도대체 뭔 재주로 스프링 DI는 실무 수준으로 배우냐고 했잖아요?

아... 님이 그건 또 '쉽다'고 했죠? ㅎㅎ

그게 공부 안해도 자연스럽게 알게 되는 거면 여기 질답 게시판만 가도 바글바글한 예외도 못 읽는 현업 개발자들은 다 무슨 자연을 거스르는 저주 받은 존재들인가...

예외 읽는 법 30분 투자해서 배우는 건 못해도 스프링 DI 따위는 쉽게 이해하는 신입 개발자가 그렇게 많으면 님이 직접 장문으로 조언 글이라도 써서 그런 개발자들 구제라도 해보시던가요.

왜 남이 기껏 입문자들 생각해서 공들여 쓴 글에 와서 시비인지 모르겠습니다.

아... 님이 그건 또 '쉽다'고 했죠? ㅎㅎ

'쉽다'고 언제 어디에 했나요 이부분이 중요한 부분도 아니구요...참....이런거까지 ㅋㅋ
혹시 마음속으로 그렇게 들으신건아닌가요?

개인적 DI가 거창한 개념이라고 생각하지도 않고  현재 잘적용해서 많은 장비들이 운용되고 있습니다

제가쓴 윗글을 보고 본인이  되짚어 본다면서

B: 나 DI 안어려운데? 근데 PRISM 같은 건 신입한테 보여주면 API 읽는 법 배웠다고 이해할 수 있냐?

이렇게 본인스스로 각색하셔서 쓰시고 스스로 자신이 각샌한 부분을 제가 '쉽다'라고 주장했다고 믿으시는것같습니다.

항상 이런식으로 생각하시고 다음글에서 또 전제 마음대로 정하고 맥락을 벗어나며
전 그걸 설명하고 계속 반복인것같습니다. 

fender님이 어떤분인지도 알겠고 더이상 대화가치를 못느끼겠습니다.
아래 추가 댓글 마음대로 다십시오 다만 여테까지 쓰신글 및 댓글 절대 수정/삭제마시기 바랍니다.

수고하십시오.