저는 회사를 다니면서 패턴을 '복잡한 것', '필요 없는 것' 이라고 하시는 분들을 보면

혹시 일부러 소스코드를 복잡하게 해서, 자기만 볼 수 있게 한다음 밥그릇 챙기려는 건가 싶더라구요.

클래스가 많아져서 복잡해진다.. 인정합니다. 

그럼 클래스 1개만 쓰지 왜 컨트롤러 여러 개 나누고 서비스 DAO 같은 레이어 나눠서 코딩하나요

규모가 커졌을때 감당이 안되는걸 방지하기 위해 패턴을 적용하는거라고 생각합니다.

디자인 패턴 1~2개 섞은 것을 해석 못하거나 복잡해진다고 느끼는 분들은

애초에 객체지향적인 생각 자체를 못하는겁니다. 소스코드는 안봐도 뻔합니다.

그런 생각을 못하니 복잡하다는 생각이 들 수 밖에요.

MVC라는 개념이 괜히 나온것도 아닌데 말이죠. 클래스라고 다를건 없죠.

정신병걸린사람마냥 남용하는건 반대하는 편이지만

패턴을 아예 고려 안하고 짜는거랑 정신병 걸린 사람마냥 남용하는거랑 선택하라면

전 후자에요. (후자가 좋다는게 아니라 굳이 선택한다면)

디자인 패턴이 불필요하게 복잡해지는 것은 정말 간단한 프로그래밍을 할 때 말고는 못봤습니다.

현실은 디자인 패턴이 필요한데도 몰라서 적용 안하다보니 개판인 소스가 많습니다.

모든 개발자가 박가사탕님 생각처럼 패턴이 찌끄래기라서 적용 안해야징 하고 안하는게 아니라요.

회사에서 디자인 패턴의 중요성을 모르는 사람들이 좀 계시는데, 소스코드 보면 답답합니다.

이런 물연차들이 코드리뷰 하는건 저도 반대고요. 신경이나 안쓰면 다행이죠 상대하면 암걸리거든요.

근본적인 접근이 없으면 소용없다는 것은 찬성하는쪽이네요.

왜 이런 패턴이 나왔는지 이해하고 공부해서 적용해야 하는데

'xxx패턴 : UML은 이렇게 그리며 클래스는 이렇게 이렇게 짜면 된다'

라는 방식과 같은 접근법은

조금만 복잡해져도 비슷한 패턴의 차이점을 알지 못하고 뭘 적용할지 몰라 다시 또 패턴 잊어먹은거 외우기에 급급해지겠죠.

면접에선 이런이런 패턴을 알고 있고 차이점 설명 잘해서 붙어도

막상 패턴 적용해서 개발하라하면 빌빌거릴겁니다.

어중간한 지식으로 패턴을 적용하면 이것도 리팩토링하는데 고생이고요.

아마 이런 뉘앙스로 말씀하신 것 같은데, 그렇다고 패턴이 찌끄레기급은 아닙니다..

어중간하게 공부해서 잘못 적용한 사람들의 실력을 탓해야 하는거죠.

중간에 말씀하신 어떤 알고리즘의 구현을 해본다던가

이런 방법을 통해 실력을 키워야 한다는건 적극 찬성입니다.

뭐든지 적당히가 좋은 법인데, 너무 한쪽으로 치중되어 말씀하신 것 같네요

과연 디자인패턴이 찌끄래기일까요?

GoF는 찌끄래기들일까요?

디자인 패턴의 집합체인 스프링 프레임워크는 스프링 찌끄래임워크로 명명해야 할까요?

디자인 패턴을 교육하는 대학교는 다 찌끄래기를 가르치는 학교일까요?

디자인 패턴이 잘 적용된 오픈소스는 다 찌끄래기인가요?

이런 찌끄래기같은 걸 사용하는 기업들도 다 찌끄래기같은 기업인가요?

찌끄래기 같은 디자인 패턴을 적용하지 않으면 테스트는 어떻게 하시나요?

그냥 콘솔에 print 찍어서 확인하시나요? 개발에 있어 확신이 중요한데 확신 가능 하신지요?

찌끄래기 없이 코드 지배 가능하신가요?

그럼 남이 만든 프로그래밍 언어, 남이 만든 라이브러리, 남이 만든 프레임워크, 남이 만든 운영체제는 왜 쓰나요? 그런 논리라면 남이 만든 건 다 '쓰레기 기술'일텐데 그런 것들도 모두 스스로 만들어 써야죠.

아마 '오픈소스 차용'도 같은 급으로 언급하신 걸 보아서는 어느 정도 비슷한 생각을 가지신 것 같습니다만, 아마 모두가 그런 식으로 생각을 했다면 오늘날의 소프트웨어 분야의 기술 발전은 불가능했을 겁니다.

대부분의 인간의 활동 분야가 그렇지만, 현 시대의 진보는 보통 전시대 무수한 사람들의 업적 위에 비슷한 분야에 종사하는 사람들의 협업을 통해 한 단계씩 쌓아 올리는 방식으로 이루어지는 것입니다.

가끔은 천재적인 개인이 한 번에 서너 계단을 단 번에 올리기도 하지만, 일단 방법론이 정립되고 역할 분담과 협업 체계가 정립되면 더 이상 어느 개인이 영역 전체를 모두 감당할 수 없는 시점에 다다르고, 그 때부터는 아무리 천재라도 계단이 아닌 건물을 혼자서 새로 쌓는 것은 불가능해집니다.

참고로 디자인 패턴을 무슨 아무 생각없이 복사 붙여넣기 할 수 있는 예제 쯤으로 착각하시는 것이 아닌가 하는 생각이 듭니다만, 패턴이 존재하는 이유 중 하나는 그런 개념에 익숙한 개발자들 사이에서 클래스 등의 모양이나 이름만 보고도 의도를 짐작할 수 있게하는 의사 소통의 수단이라는 점입니다.

그런 개념을 공유하면서 거대한 코드 베이스를 두고 협업하는 개발자들을 혼자만의 개념으로 기존의 기반이나 관행들을 다 무시한채로 독불장군식으로 상대해서 압도적인 생산성을 보여주겠다... 저는 박가사탕님이 그런 것이 정말 가능한 불세출의 천재 개발자인지, 또는 다른 사람들이 협업을 통해 이 분야를 얼마나 넓고 깊게 확장하고 있는지 관심이 없어서 그런 환상으로 자신의 능력을 과신하는 부류의 개발자인지는 판단할 수 없습니다.

하지만 확실한 건 대부분의 개발자는 전자와 같은 업적을 이룰 수 있는 개발계의 아인슈타인이 아니란 점입니다. 그런 개발자는 쉽게 존재할 수도 없고, 소프트웨어 분야의 발전도 이미 개인이 모든 분야를 바닥에서 천장까지 모두 꿰뚫을 수 있는 시대는 아득히 뛰어 넘었습니다.

그런 시대에 평범한 개발자가 스스로의 능력을 과신해서 리팩터링, 패러다임, 디자인 패턴, 개발 방법론, 오픈소스 프레임워크 등을 무시하고 남들과 협업을 거부하면, 아마도 박가사탕 님 주장하시는 '바닥 지식'이 없는 대신 디자인 패턴을 잘쓰는 개발자보다야 그런 우물안 개구리들이 가장 먼저 퇴출의 철퇴를 맞을 것입니다.

심지어 자본주의 세상에선 정말 불세출의 천재 개발자가 있어서 혼자만의 개념으로 그런 업적을 이루어 낼 수 있다 가정해도 현실에서 그런 개발자는 퇴출 당하기 쉽습니다.

왜냐하면 그 분야의 우수한 인력들이 공유하는 개념으로 만든 프로젝트야 결원이 생기면 그런 급의 인원을 충원해서 유지보수를 하면되지만, 패턴이고 공통 라이브러리고 다 무시하고 독불장군 식으로 개발하는 천재 개발자라면 그 사람이 나가면 프로젝트가 망하거든요.

혼자 모든 걸 다 할 수 있고 그렇게 하면 여럿이 협력으로 쌓아올린 것보다 훨씬 좋은 결과를 낼 수 있다고 주장하는 사람은 보통 천재가 아니면 바보입니다. 그리고 세상에는 천재보다야 자신을 천재라고 믿는 바보가 훨씬 흔한 법입니다.

기술지식을 왜 쌓는지 모르시나봅니다..

글의 취지를 이해하지 못했네요..

남이 만들어놓은 결과물을 이용해야죠 당연히.

하지만 그 모든 것은 “내 실력”이 아니란 겁니다.

확신없는 모든 지식은 실제로는

“작동하지 않는” 지식인 겁니다.

물론 가져다 쓸 수는 있어요.

패턴도, 내가 코딩을 하면서 자연스럽게

그 경지에 도달했을때 의미가 생기는 것이고

실력도 없는데 달달 외운다고 해서

아무런 의미가 없는 겁니다.

이미 문법만 가지고도 예상가능한 것이고

리팩토링도 다양한 프로젝트상황을 겪다보면

당연히 도달하는 것들입니다.

다른 결론에 도달할 수도 있습니다.

정답도 아닌 겁니다.

즉, 패턴, 리팩토링을 공부하는 행위는

자기 실력에 대한 착각유발,

확신없는 설계를 함으로써 자기 코드에 대한

의심증가로 디버깅의 곤란.

향후 자기가 스스로 그 경지에 도달했을 때의

재미를 반감시키는 스포일러같은 지식입니다.

사기꾼이 잘난체 할때나 쓰일 기술분야.

지식을 창출하는 개발자도 있을것이고,

활용하는 개발자도 있을것이고,

새로 만들때도 있을것이고,

기존거 응용할때도 있을것이고,

컨설턴트 한다고 뻥티기도 할것이고,

쥐뿔도 아닌거 가지고 설계자라고

모보험사에서 모가지 기부스하고

수명연장하러 정치하는 놈도 있을것이고,

인간 활동의 생태계로 이해하면 어떨까요.

좋은 개발자는 느낌이 달라요.

퇴직했는데도 차분하게 4번의 전화를 받아주던 그분처럼 ㅋ

나의 기준으로 타인을 낮추려 하지는 맙시다.

바둑에 관해 수많은 양의 서적이 있습니다.

바둑기사들이 책 달달 외워서 그 경지에

도달할까요?

대국을 통해 도달합니다.

왜냐면 수많은 알고리즘을 경험하면서

뇌 자체가 성장해야 시뮬에이션 능력이 올라가고

내가 지금 두는 한수 한수의 의미를 알게되는 거죠.

프로그래밍이 딱 그런겁니다.

여기 두면 된다 안된다. 그런 간단한 상황들이 아니라

성장된 뇌로써 시뮬레이션을 거친 확신에 찬

결정이어야 하는 겁니다. 간단한 정답은 없으니까요.

@박가사탕  

확신이란 의미, 확신의 정도는 공감해요.

명료한사고, 분명한 그림처럼요.

확신에 찬 프로그래밍을 하는 사람은

세상에 없는 새로운 설계나 제품을

만들어 낼 수 있습니다.

어설프게 남의 지식으로 만들어진 가짜 인재는

절대로 선택할 수 없는 선택지가 있습니다.

예를 들어 STL 새로 만들기 같은 짓.

그러나 누가 머라고 하든지 간에

한수 한수를 확신을 가지고 개발하는 개발자는

그 경지가 되면 만들어야 될 것을 만드는 겁니다.

Ignorance more frequently begets confidence than does knowledge: it is those who know little, not those who know much, who so positively assert that this or that problem will never be solved by science.

찰스 다윈의 말입니다.

인용수준이 본인의 그릇을 보여주네요..

논리가 안되면 그런식으로 비방하며 돌아서는

분이로군요.. ㅎ

게다가 다윈의 인생은 제가 말하고자 하는

인재상과 가까운 분이죠.

진화론은 책 몇권 읽어서 도출된 결과가 아니라

전부 자신이 전 세계를 직접 항해하고 조사해서

도출된 결과니까요. 남의 지식을 빌리지 않고

자신의 경험에서 시작되었기에

세상의 비난에도 굴하지 않고 확신에 찬

연구결과를 발표하게 된 것이니까요.

꼴랑 저 인용구 첫줄로 상대방을 비꼬기위해

자기가 무엇을 인용하고 있는지조차 모르는

무지함이야말로 확신없는 지식의 허무함을

증명하는 것이죠. 의미도 모르면서 하는

어설픈 아는체.

도올이 하버드에 가서 놀란 일이 있답니다.

칸트를 그렇게 옆집 아저씨처럼 비방하더랍니더.

우리나라에서는 절대 볼 수 없는 장면.

진화론을 다 믿고 그 위에서 탑?

그래서 노벨상이 하나도 없는 겁니다.

(사실 하나 있지만..)

인용수준이 본인의 그릇을 보여주네요..
논리가 안되면 그런식으로 비방하며 돌아서는
분이로군요.. ㅎ

인용은 리팩터링이나 디자인패턴 같이 여러 개발자들이 쌓아올린 기반 지식은 무시한채 권하시는 대로 자기만의 방법에만 집착하고 확신을 가지게 되면 위험하다는 취지에서 한 것입니다.

그런 내용을 공부하는 사람들을 두고 '사기꾼 기술'이니 '찌끄래기'니 '50전에 퇴출'이 되느니 깎아 내릴 때는 신이 났지만 제가 적은 인용구 하나엔 자존심이 상하셨나 봅니다.

원래 굳이 다른 글에 적으신 내용 끌어올 생각은 없었습니다만, "VM 언어는 느려서 그런 걸 쓰면 밥줄이 위험하다"는 둥 괴담 수준의 주장을 하시게 되는 이유가 바로 남들이 다른 분야에서 무엇을 가지고 어떤 고민을 하는지 관심이 없고 본인 실력에 대한 확신만 하늘을 찌르니 그런 조악한 수준의 편견에 빠져도 무엇이 잘못된 건지 모르게 되어 버리는 것입니다.

말에 말싸움은 자중합시다.

어차피 말은 말일뿐~~~

자존심 상할 만한 공격은 아니었구요 ㅎㅎ

VM언어를 쓰면 느려서 밥줄이 위험하다?

참 요약한번 멋들어지게 하시네요.

프레임 씌워서 같이 싸워줄 용사가 필요하신가요? ㅎ

헉고니님>

프로그래머들끼리 자기 설계에 대하여

대화할 일도 별로 없고 책임지면 되는 겁니다.

자기가 책임진 영역에 대하여.

굳이 본다면 소스코드 보면서 대화하면 되죠.

결국 VM언어는 사업 초기에 서비스를 맛보기에는 좋아도 사업이 성공할 경우 반드시 최적화에 돌입하게 되며 그걸 못해내면 천운을 잃고 그걸 하게되면 권력의 중심에는 C/C++ 개발자가 자리잡는 겁니다.

게다가 C#/Java는 디컴파일 다 됩니다. 사업 좀 될 것 같으면 알고리즘을 빼앗깁니다. 그럼 서버에서 전부하면? 서버비용때메 망하죠. 명심하셔야 합니다. 인생이 걸린 문제입니다. VM언어를 주력으로 삼으면 개발인생 망칩니다.

프레임이요? 직접 자신있게 주장하신 내용 그대로 인용했으니 제가 무슨 왜곡을 했다고 생각하시면 직접 요약해주세요.

저런 무지막지한 주장을 하게 되는 이유가 바로 내 코딩 실력만 과신하고 기술 추세가 어떤지, 다른 분야에선 최적화나 성능 문제를 어떤 식으로 고민하는지 같은 문제에는 전혀 관심이 없기 때문입니다.

그래서 그런 관점으로 아직 경험이 부족한 다른 개발자들에게 리팩터링이니 디자인패턴이니 하는 건 다 '가짜 지식'이니 날코딩 능력에 확신을 가져라 같은 조언을 하는 건 위험한 것입니다.

헉고니님의 생각이 일반적으로 맞죠.

저런 대단한 오픈소스를 내가 어찌 만들까 싶죠.

그러나 10년 한다면? 20년. 30년.

그렇게 꾸준히 노력하면 자기 브랜드 오픈소스

진짜 못해낸다고 생각하세요?

30년 금방 갑니다..

펜더님>

인용구 젤 마지막줄이 한줄 요약이네요^^

제목은 확신인데... 실질적인 내용은 확신의 위험성(=불신)과 검증에 대한 내용이네요.

맹신의 위험성이죠..

불신이 온다는 것이 바로 맹목적으로

믿고 있었단 중거죠.

한번 확신이 들면 변하지 않는 겁니다.

fender님이 고수중 한 분인줄은 알았는데

박가사탕님도 고수의 aura가 무지 상당하네요 ㅎㄷㄷ

박가사탕님 글 좀 자주 써주세요 

감사합니다.

알고리즘개발, STL 개발 같은 것과 패턴을 잘 이해하고 활용하는 것은 전혀 다른 분야입니다. 이것을 두고 이게 중요하다, 저게 중요하다라고 하는 건 엄마가 좋냐, 아빠가 좋냐 라고 하는 꼴이네요.

패턴은 초보때 보다는, 코드를 많이 짜보고 스스로 코드 설계에 대해서 고민도 좀 해보고 나서 익히는 게 낫다는 생각은 합니다. 하지만 패턴을 따로 공부할 필요 없다는 건 동의하지 않습니다. 뉴턴이 말했듯 거인의 어깨에 올라서면 더 멀리 볼 수 있는 법입니다.

공부해야 하는건 있죠..

근데 패턴같은 이상한 건 아니고

각종 알고리즘과 그 아이디어입니다.

퍼즐류에서 2차원배열을 다루는 방법.

허프만트리의 장점, 파싱을 위한 스택화.

깊이버퍼를 이용하는 방법이라든지..

삼각함수, 제곱과 제곱근에 대한 감각.

이런 것들이 아이디어가 되어

진짜 혁신적인 설계를 만들어 내는거죠.

코드 정리에나 도움이 될 수도 있고

오히려 방해나 고정관념이 될 수 있는 패턴같은게

필요한게 아니죠.

누가 책쓰기 위해서 사기친건데

기법의 이름을 멋드러지게 지어서 통한거죠.

언어의 문법에서 누구나 충분히 도출될 수 있는 것을

이름지어 놓은거에 불과합니다.

문학은 이미 있는 단어를 나열하기만 하면 누구나 쓸 수 있나요?
음악은 이미 있는 음계를 나열하기만 하면 누구나 만들 수 있나요?
수학은 이미 있는 수체계에서 누구나 이끌어 낼 수 있나요?

아무도 패턴만 중요하고 알고리즘 따위 찌끄레기 같은 지식이라는 주장을 하는 사람이 없는데 본인의 편협적인 사고를 강요하시네요.

패턴은 패턴으로만 끝날까요?
진짜 혁신은 다양성을 존중하고 여러 가능성을 모색할 때 일어납니다.

그런 책 탐독하시는 분 여럿 봤습니다만

프로그래밍 잘하는 분은 못봤어요.

프러젝트 하다가 하는 소리가

우리는 저런 오픈소스 수준의 라이브러리는

만들수 없잖아요.. 자기 불신.

이미지 사기치고 있으니까 혹시 진탕 걸릴만한

리스크의 업무는 안됩니다 남발.

결국 기획 다 망가뜨리고 지극히 평범한 기능만 개발.

하루종일 하는 일은 오픈소스 해석이 안되서

가장 적합한 샘플찾기.

그러면서 불안하니까

하루의 대부분을 서칭하는데

외국사이트에서 최신트렌드동향, 오픈소스

나온거 없나 확인하기.

자기 프로그래밍을 해야 뇌가 성장하는데

확신도 없는 남의 코딩에 내 코드 몇줄

버무리는 것만 하므로 실력상승 제로..

위에 열거한 알고리즘..

VM언어로는 퍼포먼스상 구현 안됩니다.

(물론 길찾기정도는 가능하지만)

그래서인지 VM언어 주력자중에는

알고리즘에 대한 회의도 있기에 하는 말입니다.

아니면 BM을 “알고리즘”이라고 부르던가..

그런 책 탐독하시는 분 여럿 봤습니다만
프로그래밍 잘하는 분은 못봤어요.
프러젝트 하다가 하는 소리가
우리는 저런 오픈소스 수준의 라이브러리는
만들수 없잖아요.. 자기 불신

고수준 언어로 그런 오픈소스 프로젝트를 이해하고 직접 만들기 위해 필요한 지식이 바로 리팩터링, 디자인 패턴 같은 주제입니다.

그걸 모르고 그런 주제에 덤비면 보통 C같은 자바코드로 본인만 아는 꼼수와 규칙으로 범벅된 그런 코드가 나오게 됩니다. 그런 식으로 짠 코드는 본인 말고는 아무도 건드리고 싶어하지 않아서 오픈소스로도 성공 못합니다.

위라는 것은 본문의 인코더, 파서, 랜더러등을 말합니다.

앞뒤 꽉 막힌 소리하는거 보니까 보넥스네 ㅎㅎㅎ

구본혁 또는 로보넥스라는 인물같은데?

구루가 되기위해 필요한 것은 탐독이 아닙니다.

자기 역량강화입니다.

뇌가 발전되는 겁니다. 마치 바둑기사 이세돌처럼.

사탕을 많이 먹는 사람은 이빨에 문제가 있을 겁니다.

남이 정리해놓은 결론만 줄줄 외우는 사람의

개발실력은 안봐도 짐작할 수 있습니다.

쉬운거 찾다가 인생내내 남이 이룩한 것만

찬양하고 있는 자신을 발견하게 됩니다.

자조적인 심정이 되는 순간 이미 패한겁니다.

몇일전 진짜 실력자를 봤습니다.

플래시엔진을 뜯어고쳐서 본사도 못하는

기술을 구현하였다더군요.

실력자의 자세는 이런 겁니다. 격파.

머 대단한 알고리즘이라도 칭송하면 웃기진

않겠으나 5년만 “제대로” 코딩하면 누구나

도달하는 문법적 도출을.. 거기다 전부 이름붙이고

그걸 또 멋드러지게 생각하는 개발자..

이미 구루아웃.

헐.. 논리로 안되니까

보넥스로 몰아가는 건가요..

어이가 없네요 정말..

보넥스로 몰아가는게 억울해요?

그럼 과거 20여 년동안 인터넷에서 어그로짓을 하지 말았어야죠. 범죄자들이 왜 감옥에서 출소해서 사회생활 할때 힘들까요? 님 평판은 님이 스스로 만든거에요 남탓하지 마세요. 님이 가만히 있는데 누가 님을 언급하면서 흉본것도 아니고 지금 잘 운영되고 있는 사이트에 와서 또 개똥철학을 들이 밀어서 남들을 불쾌하게 하니까 그냥 지나칠수 없었네요.

20년동안 어그로짓을 한건 보넥스란 분이죠.

제가 아닙니다.

억울한건 아니고 좀 어이가 없네요..

2000년 초반 구본혁

2005~ 2010년 보넥스

2010~ 2018년 로보넥스 1~ 7탄까지 있었나

2019?년 박가사탕~

잘못된거 있으면 지적해보세요 수정해서 저장해야 하니까

와.. 미쳤나봐..

찌끄레기란 말은 취소하겠습니다.

책은 종이로써 재활용이 되니까

재활용쓰레기죠..

재밌네요.

다만 논리에는 논리로. 그리고 그게 알맞은 실제 예시로 말하는거죠.

비논리로 싸우는 분들은 이해가 안됩니다.

음.....본문글은

디자인패턴, 알고리즘을 비판하신거라기 보다는

해학적 코드, 과도한 오버엔지니어링에 대해서 비판하신거 같은데요.

이게 비지니스 개발을 패턴인지 패턴을 위한 개발인지..가끔 해깔리는 표준이 있긴 하더군요.

전형적인 오버엔지니어링...

이게 왜 필요한지에 대한 고민없는 그냥 디자인패턴 지향..당연히 적합하지 않은 패턴..

안티패턴 입장이신거 같은데.. 저도 어느정도 공감은 하는 입장인데..

많은 개발자분들도 안티패턴도 공감 많이들 하시지 않으신가요.ㅎㅎ

저는 어느정도 동감해요...

제 자신이 어차피 남들이 할 수 잇는것들만 할꺼면 왜 프로그래밍해야 하나 싶은 생각이 들때가 많습니다.

이건 어느정도 문화의 차이인거 같긴 한대, 사람에따라서는 박가사탕님 말씀이 일리가 있는것 같아요.

제 자신에게 떳떳하지 못한느낌이 자신을 지배하게 되는경우가 있는것 같아서...

프로그램 패턴을 적용했을때, 같이 코드를 사용하는 사람들에게 설명하기 좋았던 기억이 납니다.

프로그램이란게, 만들어지고 끝나는게 아니라 계속 개선해 나가야 되는 작업들이 이어지는데 불필요하게 남발하면 손대기 힘든 경우를 많이 겪었습니다.

전어느정도 박하사탕 님말에 동의합니다.

그렇다고 팬더님말이 아니다가 아니라

두분말에 다 공감대가 형성된다는 말입니다.

솔직히 

대기업이라고 해야하나 

아니 대기업이라고 하기에는 좀 그런 기업들 뭐 말하자면 쿠팡 우아한 형제들 등등 

과연 거기서 일하는 개발자들의 수준이 어느정도일가요.

제가 알기로는 정말 잘하겠죠. 대기업에서 스카웃되서 나온분들도 많고

뭐 신입들도 코딩테스트 엄격하게 보고 뽑으니 잘하겟죠..?

그런데 잘한다는 수준이 과연 어느정도일가요..?

제가 정규직 일자리를 구하면서 느낀것은 

오랜 경험에서 나오는 프로그래밍 역량 

예를 들어 트러블슈팅같은 프로그래머서의 연차를 보는게 아니라

오픈소스 JPA를 써봤냐 스프링부트를 사용해봤냐 이게 전부 입니다.

10년이 훨씬 넘는 개발자에게 콜렉션 속도 비교해주세요 

이런걸로 기술 면접 을 봅니다.

솔직히 답변 못했습니다. 머리속으로 큰 이미지는 그리고 있고 이해도 하고있으나 

신입 기술면접시에나 달달 외울 그 답을 말로 표현하기가 어렵더군요

왜냐하면 각 그 상황에 맞는 코드가 필요한거지 이것보다는 이게 속도가 빠르니까 쓴다라고 

지금까지 그렇게 사용을 안했으니까요... 

오픈소스 믾이 사용해 봤다면 기술이 좋다는 

그 말도 안되는 논리들을 

나름 기술자들 대우가 좋다는 그런 회사들조차 저지르고 있으니

답답 할따름입니다.

어쩌다 // 개발자의 실력을 무슨 무슨 라이브러리를 써봤느냐로 판단하는 게 멍청한 일이라는 건 전적으로 동의합니다.

다만 오픈소스 사용여부로 실력을 판단하면 안된다는 것과 오픈소스를 활용하면 실력이 늘지 않는 다는 것은 다른 이야기이고, 리팩터링이나 디자인 패턴등 개발자들 사이에 통용되는 기술적 기반을 무시하고 본인 만의 무언가를 쌓아야 한다는 또 완전히 다른 주장입니다.

리팩터링이든 디자인 패턴이든 그냥 소스 복사 붙여 넣기 할 수 있는 예제 모음 같은 그런 개념은 아닙니다.

참고로 스프링 부트나 JPA등을 사용해봤는지로 전적으로 실력을 판단하면 안되겠지만 주로 사용하는 기술셋을 보고 기술 동향을 얼마나 잘 파악하고 있는지 정도는 힌트를 얻을 수 있다고 봅니다.

예를들어 프론트엔드 개발자를 뽑는데 해본 것이 제이쿼리 밖에 없는 개발자라면 단순히 리액트나 뷰 같은 특정 도구에 익숙하지 않다는데 그치는 것이 아니라, 왜 프론트엔드가 그런 방향으로 발전했는지, 또 그런 프레임워크로 개발을 하려면 어떤 개발 환경이나 관행을 따라야 하는지 등 제반 이슈들에 대한 지식이 모두 부족할 것으로 의심할 수 있기 때문입니다.

//fender

펜더님 말에 동의합니다.

하지만 말씀하신것처럼 실제 기술면접에 반영이 되는가 반문합니다.

전부는 아니라고 생각합니다 당연히 합리적인 조건을 보는 담당자들도 많다는것도 인정합니다.

하지만 제 경험으로는 펨더님이 말씀하신 큰 그림보다는

단순히 안써봤거나 모르면 루저라는 개념이 상당합니다.

그부분때문에 박가 사탕님의 말에도 어느정도 공감이 가는거구요

펜더님이 위에 논쟁에서 말한 논리를 부정하는것은 아닙니다 어찌보면 박가사탕님 말보다는 공감은 더 가고요

전 단지 제 경험에 비추어 공감가는부분과 바꼇으면 하는 부분을 적어보았습니다.

@어쩌다

사실 면접이나 코딩테스트 그런게 병신짓일수도 있죠. 사실 같이 일해보기전에는 모르죠 뭐 ㅋㅋㅋ

근데 뽑기전에 뭐라도 해보고 뽑아야되니깐 ㅋㅋ

저같으면 신입이든 경력이든 포트폴리오 보고 뽑을듯... 그것도 병신짓일수 있지만 그나마 나을듯하네요. 알고리즘 코딩테스트 보고 뽑는 회사는 코드몽키들만 넘처나든데...

패턴, 리팩토링 공부해도 실전에서 적용하여 간결하고 명확한 구조를 만들수 있는 개발자는 소수 입니다.

현실에서 OOP도 제대로 할 줄 아는 개발자도 매우 드뭅니다. 

공부는 했는데, 막상 적용하면 그 효과를 제대로 보지 못하는 개발자가 다수 입니다. 

때문에 디자인 패턴은 실전 프로젝트에서 적용하기 어렵다, 배워 봤자 쓸모 없다 하는 소리가 나오나 봅니다

@crazygun22

동감입니다 ㅎㅎ

근데 궁금한게 있는데 이렇게 해서 어떤 프로그램을 만들어 보셨나요 ?

저는 글을 읽어 보면서 어떤 프로그램을 만들었는지 그게 제일 궁금하네요. ㅎ 

공부해야 하는건 있죠..
근데 패턴같은 이상한 건 아니고
각종 알고리즘과 그 아이디어입니다.
퍼즐류에서 2차원배열을 다루는 방법.
허프만트리의 장점, 파싱을 위한 스택화.
깊이버퍼를 이용하는 방법이라든지..
삼각함수, 제곱과 제곱근에 대한 감각.

패턴은 공부 하지 말고 알고리즘은 공부하라..

오키에서 보면 알고리즘도 공부 하지 말라고 하시는 분들도 있던데요

현업에서 절대 안쓰고 코딩하다보면 다 감으로 아는 내용인데 그걸 왜 하냐...라고

패턴이나 알고리즘이나.. 주어진 문제를 해결하는데 최적의 방식입니다. 

가장 큰문제는 회사자체입니다.

예를 들어 회사 이름 말하면 어찌될지 모르니 유명한 소셜업체라고 하죠.

과연 그회사에서 필요로 하는 개발자의 실력은 어느정도면 충분할가요..?

시니어 개발자를 뽑을때 

1. 스프링을 사용해 봣냐가 중요할가요?

2. 주문서 작성시 필요한 프로그래밍이 중요할가요,..?

2는 절대 안물어봅니다 

더 중요한 사항인데도...

그러면서 오픈소스 떡칠을 한 자기들시스템은 정말 위대한 소스이며

엄청난 개발자들의 집합이라고 자랑을 합니다.

솔직히 시니어 정도의 개발자들은 하루 이틀이면 적응될 단순한 오픈소스들을

자기들에게 필요한 수준의 개발실력을 자기들도 감지 못하면서

무슨 넌 프리경력이 있으니 안되

넌 회사 이직이 많으니 안되

그러면서 자아도취에 빠져 있습니다.

고추장을 담그는 명장이 굳이 햇볕에 고추를 말리는 이유를 과학적으로 설명하기는 힘들지 몰라도 ...

↑ 본인만 깨달은 노하우를 다른사람들도 사용하기 쉽게 노력해서 만든 결과물이 패턴입니다.

왜 다른사람들이 써 놓은 책을 봅니까...
본인이 요리책도 쓰고 기술서적도 저술하고 하면 되는건데 말이죠

참고로 게임의 경우 역시 서버나 엔진은 몰라도 게임 로직 계층은 고수준 언어로 중심을 이동하는 경향이 뚜렷합니다 (이유는 본문에서 설명한 내용과 동일합니다).

특히 바인딩 언어로 C#을 사용하는 유니티의 성공 이후 C#을 지원하는 엔진이 늘고 있으며, 그 밖에도 다양한 엔진들이 이전부터 자바스크립트, 파이선, 루아 등 다양한 고수준 언어를 '스크립팅' 언어로 제공해왔습니다.

재미있는 것은 게임 관련 커뮤니티에 있으면, 과거 자바에 대한 것과 비슷한 편견에서 비롯된 논쟁을 지금도 흔하게 보게 된다는 점입니다. 예컨대 유니티는 C#을 써서 C++을 쓰는 언리얼보다 느릴 수 밖에 없다던가 하는 식의 이야기는 자주 등장하는 떡밥입니다.

참고로 게임 엔진에서 VM 언어의 성능이 충분히 쓸만한 수준으로 빨라진지는 한참 되었습니다. 오히려 속도 보다는 메모리 관련해서 무분별하게 객체를 생성한다던가 하면 GC와 관련한 버벅 거림이 발생할 수 있어 주의해야한다는 정도의 문제가 있을 뿐, C# 정도는 Mono 환경이 JVM에 비해 최적화가 잘된 편이 아님에도, 가상언어 기반의 언어는 게임에서도 이미 널리 사용되고 있습니다.

박가사탕님 너무 화내지 마세요.

펜더씨와 논쟁은 저도해봤지만 토론상대로 좋지는 않습니다.

그리고 오키는 평균적 개발자가 모인곳으로 굳이 아키텍트나 구루를 목표로 공부하는 사람이 모인곳은 아닙니다.

밥먹고 살아야죠. 

다만 여기서 박가사탕님께 반대하는 분들도 하나는 아셔야하는게 있습니다.

GoF의 논문을 보면, 기존 프로젝트를 분석하여 패턴을 정리했다 라고 명확히 합니다. GoF가 창조한게 아니라 발견/정립한것입니다.

이는 그전부터 실력자들은 자연스럽게 이리저리 변형해가며 쓰던거라는 것을 의미합니다.

하지만 정리란 근본적으로 디테일을 자르고 몸통을 남기는 거라서 꼭 여러분의  문제에 맞지 않을수있습니다. 그때는 패턴을 변형해서 쓰는게 좋습니다.

무릇 작곡가라면 틀에 박힌 곡만 쓰는게 아니라 파격적 변주곡도 쓸수있어야 하겠지요.

그리고 오키는 평균적 개발자가 모인곳으로 굳이 아키텍트나 구루를 목표로 공부하는 사람이 모인곳은 아닙니다.
밥먹고 살아야죠. 

...

GoF의 논문을 보면, 기존 프로젝트를 분석하여 패턴을 정리했다 라고 명확히 합니다. GoF가 창조한게 아니라 발견/정립한것입니다.

이는 그전부터 실력자들은 자연스럽게 이리저리 변형해가며 쓰던거라는 것을 의미합니다.

그래서 Robert C. Martin이나 Kent Beck 같은 사람들은 아키텍트나 구루 수준도 못되서 근근히 컨설팅으로 밥이나 벌어 먹고 살려고 패턴책을 그렇게 썼나 봅니다.

하긴 리팩터링이나 기존 패턴은 참조도 안하고 혼자 소프트웨어 공학 역사를 다시 쓸 정도 능력자시면, 어디 저 정도 수준에 성이 차시겠습니까만...

그리고 전 알고리즘도 디자인 패턴 같이 여러 개발자들이 찾아낸 걸 이론으로 정립한 것인 줄 알았더니 어디 하늘에서 뚝 떨어진 신성한 내용인가보군요. 그런 성격이라면 아마 고수준 언어 따위나 끄적거리는 개발자가 범접할 수 없게 대단하고 근본적인 무언가가 맞나봅니다.

역시 지엽적인 부분을 물고 늘어져서 비꼬는것이 대단하네요.

자의적으로 원하는 부분만 잘라서 편집, 의도를 변형하여 오도하는것을 

"조선일보식 편집"이라고 하죠. 

펜더씨 상대는 예전에 지겹게 했으니까, 더 에너지소모하기 싫네요. 그냥 원본 놓고 갈게요.

Gamma, Erich, et al. "Design patterns: Abstraction and reuse of object-oriented design." European Conference on Object-Oriented Programming. Springer, Berlin, Heidelberg, 1993.

http://www.citeulike.org/group/1374/article/3944215 

Beck, Kent, and Ward Cunningham. "Using pattern languages for object-oriented programs." (1987).

https://link.springer.com/chapter/10.1007/3-540-47910-4_21 

vollfeed // 아, 저 링크에 가면 디자인 패턴 따위는 저수준 언어 다룰 만큼 똑똑한 사람들은 코딩하면 그냥 아는 거니 배워봐야 자랑할 때나 쓰는 '찌끄레기 지식'이라는 주장을 뒷받침하는 근거가 있나보군요.

좋은 자료 찾으셨네요. 근데 이왕이면 내용도 한 번 읽어 보고 뿌리지 그러셨어요?

Design patterns play many roles in the object-oriented development process: they provide a common vocabulary for design, they reduce system complexity by naming and defining abstractions, they constitute a base of experience for building reusable software, and they act as building blocks from which more complex designs can be built.

이왕 인용한 김에 해석도 해드리죠:

디자인 패턴은 객체지향 개발 과정에서 다양한 역할을 담당한다: 이는 디자인에 있어서 공통적으로 사용할 수 있는 용어를 제공하며, 이름 규칙이나 추상화를 통해 복잡도를 감소시키는데 기여한다. 또한 디자인패턴은 재활용 가능한 소프트웨어를 구축하는데 기본이 되는 경험을 구성하며 보다 복잡한 디자인을 쌓아올릴 수 있는 재료로 활용할 수 있다.

제 눈에는 저건 제가 디자인 패턴 배워야 하는 이유로 들었던 근거들을 함축적으로 잘 표현한 내용 같은데, 뭐 님 말대로 구루 수준도 못되면서 '조선일보식 편집'이나 하는 제가 뭘 알겠습니까. 켄트벡 따위 우습게 보는 진짜 고수분들이 보기엔 저건 '지엽적인 부분'이고 더 자세히 읽어보면 패턴 따위 안봐도 하다보면 다 알게된다는 숨겨진 깊은 뜻이 있나 보죠.

vollfeed// 님 기분 따위는 제가 신경 쓸 일이 아닌데, 바로 그 "디자인 패턴은 찌끄레기 지식이다"라는 분의 주장을 님이 직접 옹호했고 거기에 대한 제 반론을 두고 인신공격과 함께 비방을 하니 그 점을 지적하는 겁니다.

더구나 일삼아서 그 분 덧글 일일이 찾아다니면서 추천 날리고 제 글에 비추 먹이는 수고까지 하셨으면, 적어도 그 분이 이 토론에서 무슨 주장을 하고 있었는지 쯤은 읽어 보셨어야죠. 아닌가요?

"거짓근거로 아무데나 총질" 같은 건 님이 마치 제가 이 토론이건 어디서건 디자인패턴이 절대적인 '경전' 쯤 되는 것으로 주장한 것처럼 호도하는걸 두고 쓸 수 있는 표현이구요. 참고로 그건 고상하게 '허수아비 논증'이라고도 합니다.

님 한테 대단한 예의나 식견을 바라는 건 아닙니다만, 최소한 토론에 참여하려면 싫은 사람 아이디만 보고 눈에 불을 켜고 달려들기 전에 적어도 자신이 옹호하는 주장이 무엇인지는 한 번 읽어 보는 정도 상식 쯤은 갖출 수 있다고 생각했는데 그 것도 착각이었나 봅니다.

당신과 토론할때마다 느끼는 거지만 제발 좀 맥락 좀 파악해주세요. 

나는 당신이 경전이라 언급했다 말한적없습니다. 4번 항목의 의도된 청자는 당신이 아닙니다. 개발자 들에게 애기하는 형식이지요. 따라서 당신이야말로 허수아비논증을 하는 것입니다. 적어도 제가 "펜더씨는 패턴을 경전처럼 여기는데..." 정도로 표현을 해야 당신이 말하는것이 팩트라 할수 있을 것입니다.

그리고 펜더씨는 추천은 내용에대한 토시하나 안 틀리고 동의를 할때만 합니까? 객관적으로 그것은  지나친 확대 해석입니다.

제가 추천을한 것은 구체적 표현 하나하나를 나도 똑같이 쓰기 귀찮아서가 아니라, 충분히 생각해봐야하는 문제를 지적하는 박가사탕님이 저평가 되는 것이 온당히 않다고 생각해서입니다. 한편 펜더씨의 의견은 고평가됨이 온당치 않다고 봅니다. 나도 알고 당신도 알겠지만, 오키는 확실이 펜더씨에게 기울어진 운동장입니다. 그렇다고해서 악의적 편집이나, 자신만의 의도로의 확대해석을 해서 있지도 않은 사실로 인신공격성 발언을 하지 마시기 바랍니다. 아무리 홈그라운드라도 그러면 안되죠.

제가 쓴 내용중 나쁘다 할만한 언급은 당신이 토론상대로 좋지 안다는 정도 뿐이네요. 그뒤에 당신이 먼저 달려들었죠. 제가 아닙니다. 그리고 당신이 토론상대로 별로라고 적은건 개인적 의견이긴하나 비방이니 인신공격은 아니라고 봅니다.

A: "패턴은 찌끄레기 지식! 그런건 안배워도 다 알게 되어 있음!"

B: "아닌데요? (한참 아닌 이유에 대해 토론)"

C: (A글 마다 추천, B 글 마다 비추) "A님 화내지 마셈, B가 잘못했음! 근데 여기 오는 사람들 아키텍쳐 구루 수준이 아니라 모를까봐 한마디 하는데, 패턴 그거 다 원래 있던거 모아놓은 거임"

B: "아니 그래서 패턴이 찌끄레기이고 그런 건 안배워도 안다는 거임?"

C: "내가 언제 내 입으로 그런 말했음? A 글 추천하면 A 의견에 다 동의하는 거임? 왜곡하지 마셈! (버럭 버럭)"

...어쩌란 건지...

여튼 전 저 분 상대는 그만하겠습니다. 뭐 작정하고 물어 뜯으려는 사람 상대해봤자 가뜩이나 과열된 토론 보는 분들만 더 피곤해질테고, 저 분의 예의나 상식 수준에 대한 기대는 없어도 평균적인 오키 회원들이 건설적인 토론과 억지, 말꼬리 잡기를 구분하는 능력에 대해서는 적어도 그 보단 신뢰가 있으니 말입니다.

차라리 이런저런 내용에  동의하는 거냐고 묻는 형식이면 서로 중립적으로 논의라도 할수있지,

내가 그렇게 애기한냥 표현해서 사람 깍아내려놓고 뭘 어쩌라는 건지...

내가 알고 쓰는 것과 모르고 쓰는 것.  확신에 대한 말씀은 공감이 갑니다.  하지만 모든 개발자들이 혼자서 개발하는 것 도 아닌데.. 이미 오랜시간동안 다듬어지고 보완되어온 오픈소스, 패턴등을  비하하는 건 잘못 된 생각 같습니다. 

오픈소스나 패턴등은 잘 활용하면 좋은거지 배척할 건 아니죠.  공동작업시 생산성과 성능을 보장 할 수 있는데 왜 배척을 하나요ㅋ.

오 이런 토론 아주 좋아요

토론을 해야 서로 발전하죠

우리나라는 토론을 싸움으로 인식하는 경향이 있는데

토론좀 해야 발전한다고 생각합니다.

개발자들 제발 화술좀 공부했으면 좋겠습니다.

단어선택 기분나쁘게 하고 상대방 은근 개무시하고

자기중심적으로 좌뇌만 사용해서 논리싸움만 하는거 

본인은 자기만족은 될지언정 상대방은 설득이 안되네요.

개발자와 대화하기 시른 1인 ㅎㅎ

개발자가 현업에 무시당하는 이유 첫번째임

오 이거 또 재밌는데? ㅎㅎ 

여기 재밌는 동네네요... 

박가사탕님 글 읽다가  오오오 멋있다~~  했는데;; 표현이 지나친면이 있는 것 같네요

요즘은 디자인패턴 이런말 안쓰지않나요 근데?  한 십년전에 쓰던말같은데.. 

암튼 저도 막상 짜봐 하면 못하는데 말만 번지르르한 분들 많이봐서

야 개발자가 말로하냐 코드가져와 라는 스타일인데 

정작이러면 개발자들이 싫어함 -_-  거참 ㅋㅋ 

개발자가 코드로 말하는 것은 올바른 방향이라고 생각해요. 

(그리고 남의 소스 복붙해서 해도 사실 별로 문제없다고 보는데..  사실 남의 소스 복붙하려면 그거 다 알아야하잖아요 ㅋㅋ

모르고 복붙하면 귓방망이 맞아야하는 거니까 논외고 )

그런데 저는 패턴이니 방법론이니 하는 것이  상당히 의미가 있다고봐요.

글쓴님은 주로 컴퓨터 측면에서만 보시는것 같은데;

뭐 혼자 할만한 양의 기능이면 상관없습니다만;  프로그램이 여러 서버에서 돌면서 함께 뭔가 의미있는 서비스를 하고싶다면? 

예를들어 넷플릭스 같은 서비스를 만들고싶다 라고 한다면 좀 배워야하죠

아주 극단적으로 야 난 내꺼아니면 안믿어 하면

웹을 통한 이용하는 restful api 서비스는 사용하시겠습니까?   

그냥 약속만 믿고 던지고 받는것인데? 

구글의 어낼리틱스 api 한번 씹고뜯고맛보고 만들생각이십니까?  라는 질문을 하고싶네요 ㅎ

패턴이니 개발방법론이니 하는것은 사실 컴퓨터 보다 사람을 위한것입니다.  정확히 하자면 팀이죠. 

개발하다보면 코드도 중요한데 그것 못지않게 팀이 중요하고 협업이 중요해요.  생산성이 사실 코드에서 나오기가 한계가 있거든요.  사람마다 품질 다다르고... 이걸 패턴 강제하면 생산성 하락하고,  냅두자니 그냥 개판오분전되고;;

사실 서비스가 조금만 커져서 코드베이스가 커지면 맞닥뜨리는 문제들이고 

그러다보면 컴퓨터 코드와 상관없어 보이는 이래라저래랴 류의 뭔가 다만 있어보이는 컨설팅이니 코치니 등등 숟가락 얹어보려고 하는 시도처럼 느껴지는 분들이 있긴한데;

그래도 필요한 분야이고 진짜 세상을 바꾸고 싶은 큰꿈을 그리는 분이면 패턴이든 방법론이든 협업을 위한 용어나 해결방식들을 잘 알고 이야기 해줄수 있고 코드로 보여줄 수 있어야한다고 생각해요.

혼자가면 빨리가는데 멀리가려면 함께 가야한다고 하잖아요.

빨리가는것과 멀리가는 것의 관심사가 다르기 때문에 벌어지는 상황 같습니다. 

르상티망...

오키에는 뛰어나신 분들이 참 많군요.

깜짝 놀라고 있습니다.

펜더님도 저랑 의견이 좀 다를 뿐이지 뛰어나신 것 같습니다.

볼피드님도 이성적으로 상황정리 잘하시는 것 같아요^^

블럭놀이하는 수준으로는 경쟁력없다

이렇게 생각하면 되겠죠

뭐지도 모르면서 돌아가기만 하면 된다라

댓글읽어봤는데 저런 사람이 저렇게 옹호를 받다니

평생 si에서 자바블록놀이나 하시길

오키수준이군요 이게

박가사탕님이 깊게 생각해볼만한 의견을 낸건데 이렇게 까임을 받아야되는 이유를 모르겠습니다

댓글중 볼피드님 글보니 속이 좀 시원하네요

박가사탕님.. 이세돌과 비슷한 느낌을 받네요

한국기원에서 오지게 미움을 받던 이세돌..

유일하게 알파고에게 1승을 거두어 구글과 세계를 놀라게했었죠~~

자주오세요 박가사탕님

글이 저에게는 매우 유익합니다