Effortless - 上善若水 - 상선약수
물처럼 자유롭게 세상을 흐르자.

IT-소프트웨어 (48)

목록열기
자바(Java)라... 그 역겨움이란... | IT-소프트웨어 2007.12.12 23:36 上善若水

'IT-소프트웨어' 카테고리의 다른 글

모라는겨? 프레임�이 모하는건지는 아나? 자기가 무식한걸 탓해야지 남까지 그런줄 알지는 말아야지.
에효.. 21세기를 살면서 아직까지도 프로그래머들은 다 이모냥이냐.. ㅉㅉㅉ
프레임웍이 사람잡는 것이 아니어야 한다는 것 정도는 알고 있는 사람입니다.
c_guru님 먼저 제대로 읽어보고나 말씀하시져?-_- 이런 사람들 왜 이리 많은지 모르겠네. 프로그래머 아니면서 아는척하는듯한. 답답~
'내가 알고 남이 모르니까 모르는 바보들이 잘못..'이란
'기술적 우월성에 대한 잘못된 자부심'도 크게 한몫을 하고 있겠죠..

어쨌든 리더들의 다양성을 인정하지 않는 편향성과
'기술적 엘레강스함만을 유일한 답'이라는 생각을 버리지 않는 한 반복될 문제겠죠.
스트러츠 하나갖고 어렵다 툴툴대니 실력을 알겠군요... 스프링_Ejb 프로젝트라도 하면 아주 살인나겠습니다..
'그래, 니네들의 실력이 그 정도 밖에 안되냐?'라는 태도는 자바 진영에서 흔히 볼 수 있는 태도입니다.
공감!!! 매우 공감합니다...문제해결보다는 해결하는 폼에 편향되어있다고 생각합니다..
지금 이글을 웹에만 한정시킨다면 단순한 비즈니스로직의 간단한 웹에서는 맞는 말일지는 모르나, 일반 애플리케이션, 임베디드시스템, 단순 스크립팅 모듈, 복잡하고 큰 웹기반 시스템등등에 같은 논리로 얘기를 한다면 아주 편협한 생각이 아닌가 합니다. 간단하고 작은 프로그램은 어떤 것을 말하는 건가요? 효율성을 속도에 맞춘 건가요? 용량에 맞춘 건가요? 아님 유지보수에 맞춘 건가요? 프로그래머 아닌 누구나 다 할 수 있는 건가요? 이 넷 다인가요? 모든 언어에는 장단점이 있고, 그로부터 파생된 프레임웍 역시 장단점이 있습니다. 문제는 그것을 적절한 프로젝트에 활용하지 못하는 상위 단계의 의사 결정권자의 판단에서 비롯된 것입니다. 그리고 게으르려고 하는 프로그래머의 그 고집. 실상 프로그래머들은 복잡하고 시간걸리고 어려운 것들을 쉽고 편하게 만들기 위해 프로그램을 만드는 것인데 무엇이 여기에 더 효율적일까를 생각하기 보다는 이건 나에게 맞지 않기 때문에 혹은 내가 여기에 더 익숙하기 때문에 이게 정말 쉬운거지라는 독단에 빠진 사람이 더 많습니다. 수천명의 개발자들과 일하는 제가 본 개발자들은 새로운 것을 도입하고 활용하는 방법을 찾기보단 기존의 자신이 해오던 것을 고집하는 경향이 더 많습니다. 그 이유가 배우기 싫어서입니다. 프레임웍을 도입하던 도입하지 않던 작은 프로그램 누구나 이해하기 쉽고, 쉽게 만들 수 있는 프로그램이라는 것은 코드 한줄 코드 글자수 몇개 줄이는데서 나오는 것이 아닙니다. 개발자의 오랜 경험과 철학 넓게 볼 줄 아는 안목에서 큰 그림안에서 틀을 갖추는 것이죠.


--------------
배우기 쉽고, 간단하다의 정의는... 코딩에 필요한 타이핑 타수가 줄어드는 것을 의미하는 것이여. 그 이상도 그 이하도 아니여. 알겄냐?
-------------

왜 이제 막 이 분야에 발을 내딛는 후배들에게 이런식의 흑백 논리로 떠밀어 넣어야 하는지 이해할수가 없네요. 이 말인 즉슨 그냥 코딩을 위해서 사용하는 언어의 모든 철학을 무시하고 간단하고 짧게만해라라는 겁니다. 쉽게만 만든다고 해서 그 프로그램이 효율적이고 좋은 프로그램일까요? 만약 쉽게 만들긴 했으나 천라인당 오류가 3개 오류가 발생할 확률이 있는 프로그램하고 백라인당 10개의 오류가 발생할 확률이 있는 프로그램이라면 어느 것이 더 좋은 건가요? 같은 로직을 만들때 더 간단하고 쉽게 만드는 것의 비교는 쉬울지 모르나 큰 시스템의 틀을 놓고 보면 비교할 부분이 아닙니다.

한번 통계적으로 실험을 해보시기 바랍니다. php를 썼을때 defect를 검출하고 해결하는 것이 디자인 단계, 코딩단계, 컴파일단계에서 java 프레임웍을 사용했을때보다 얼마나 더 줄어드는지..
말씀하신 계산을 좀 해보긴 했는데, 정량적인 증거를 제시할 만큼의 자료는 확보하지 못하고 있습니다. 어쨌든 경험은, 자바를 둘러싼 개발자 그룹의 문화가 거의 모든 것을 과장되게 부풀려 표현하려는 속성이 있어 보인다는 것입니다. 아주 기본 적인 것도 복잡하게 하는데, 아주 복잡한 것은 더 할 나위 없게 복잡해지죠. 다른 프로그래밍 언어 진영에서는, 이미 과거에 더 단순한 모델이 만들어 졌음에도 불구하고... 라는 문구도 덧붙이고 싶네요.
음...
일단 흑백논리라는 점에서는 동감입니다.
PHP와 프레임워크간의 비교는 인정합니다... ㅎㅎ 시간이 좀 걸리기는 하죠...
근데... PHP를 어떻게 구현하는가에 따라서도 거의 동일한 결과가 나올때가 있읍니다.
얼마전 PHP와 Struts로 구현된 프로그렘을 비슷한 시기에 분석한 적이 있읍니다.
PHP는 분석하다가 짜증나서... 머리털을 뽑았죠.... 너무나 많은 include ㅎㅎㅎ
소스를 까보면 4줄밖에 없더군요... 전부 include.... 하나의 결과를 보기위해 5-7개 정도의 파일을 봐야만 되더군요...
근데... 그 소스자 좋은 소스랍니다...
Struts의 경우 struts-config.xml하나보고 전부 파악할 수 있었고, 바로 찾아서 수정이 가능했읍니다.
이런경우는 필자가 이야기 한 결과의 정반대 결과가 나오죠...
제가 하고싶은 이야기는 프레임워크니.... 자바니.... 하는 문제가 아니라... 누구나 보기쉽고, 이해하기 쉽도록... 주석 많이 남겨주고
코딩 표준 잘 지켜주는 개발자가 많이 없다는것... 그것이 문제가 아닌가 합니다.
뭐든지 학습하지 않으면 장점에 대해서 깊이있는 이해를 할수 없구요....
이해를 했다고 하더라도 경험이 적으면 지대로 쓸수없구요...
많은 개발자들과 대화하지 않으면 자신만의 또다른 아집을 만들어내게 된다는것....
이 말을 해드리고 싶네요...

상상플러스에서 매가폰같이 생긴걸로 머리때리면서 한마디 하더군요.... ### 공부하세요 ~~ ###
자바, 프레임워크가 문제가 아니죠. 그것을 둘러싼 사람들의 문화가 문제죠. 모든 것을 '과도하게 복잡하게' 하려는 문화...
님의 글을 보면서 열받는거 보면 저도 자바대가인가 봅니다. ㅋ

일부 내용에 반대 되어서 글을 남깁니다.

우선 모든 도메인에 님의 내용이 적용되듯이 일반화한것 같아 안타깝습니다.
엔터프라이즈 영역 경험해보셨나요? 1000명이 들어가는 프로젝트, 1~2년짜리 프로젝트.. 해보셨나요?
그런 프로젝트에 프레임워크 없이 진행하는 것을 해보셨나요? 차세대 은행 계정계를 프레임워크 없이 한다고 했을때 방법은 있으신가요? 전사 표준 프레임워크에 대해서 고민을 해보셨나요?
단순 웹개발이나 몇십명으로 진행하는 프로젝트가 다인양 얘기하지 마십시오.
그리고, SOA에 대해서 고민해보셨는지.. 그 사상에 대해서 고민해보셨는지..

개발자에게는 자바냐, C냐, 파이션이냐 이런 언어가 모든걸 해결해 주지 않습니다.

글을 쓰다보니.. 감정이 섞인것도 같습니다. 적당히 필터링해서 읽으세요.
요는 다른 영역도 큰 시야를 가지고 바라 보시라는 겁니다.
1000명 x 1년 프로젝트라면 저도 할 말이 없습니다. 십수년의 경험으로도 아직 그정도 과제는 해 본적이 없어서... 전사 표준 프레임웍에 대해서는 매일같이 머리가 지끈지끈하게 고민하고 있습니다만, 저희가 만드는 '나름대로의 프레임웍'은 일종의 '해체적 프레임웍'이라고 할까, 전통적인 유닉스가 가지는 미니멀리즘과 조립에 기초한 프레임웍입니다. SOA 가 가지는 기본 철학은 보면 볼 수록 미스테리입니다. 내 이해력이 많이 떨어졌나... 아무리 좋게 봐 준다 해도, SOA 는 마케팅 용어라는 생각밖에 안 들었습니다. 이건 공부가 부족할 지도 모른다는 생각을 하지만... 역시나 자바진영의 산물 답게, 쉽게 이해할 수 있는 대상은 아닙디다.

아마도, 1천명x1년짜리 자바과제를 파이선 개발자들에게 주면, 아마도 100명x6개월 짜리로 다운사이징해 버릴 지도 모른다는 생각은 여전히 듭니다. 허거... 프로젝트 비용이 1/20으로 줄어버리네요? ... 이거 아무도 좋아하지 않을 테니... 절대로 파이선이 엔터프라이즈 언어가 될 수는 없겠죠?
上善若水 님

1000명 넘는 혹은 가까이 되는 프로젝트 3-4군데 3년이상 돌아본 사람입니다. 근데 님말에 더 더 더 더 동감이 가는 이유는..ㅋㅋ

저만 그런생각 하고 잇는줄 알았는데..님도 저랑 비슷한 생각이시군요.

자바 개발은 하지만 자바개발자들한테는 그런 이야기 하지 않습니다.ㅋㅋ

괜시리 해봐야 분위기만 이상해지더군요.

저도 개발은 님만큼은 아니지만 cgi-perl/c 부터 시작해서 php/c/pro*c/PLSQL   다 해봤던 경험으로도 님말에 동감이 가지않을수 없네요.

지금도 SOA쪽일을 하지만 역시 마음에는 들지 않습니다..

지금 하는 일 자체도 아키텍쳐에 구애없이(기존의 자바진영에서 절대적으로 신봉하는)..개발하라고 한다면.

솔직히 지금 인원이나 기간 1/5로도 가능할거 같군요... 개발자의 수와 기간이 문제가 아니라 개발자/아키텍쳐의 질의 문제가

되겠죠.

요즘은 그냥 마음 비우고 삽니다..ㅎㅎ
흠.. 정말 님이 1천명 * 1년짜리 프로젝트를 파이선 개발자들을 통해 100명 * 6개월 프로젝트로 해내는걸 증명해 보이시면. 전 세계적인 개발자의 영웅이 되실 겁니다.. 정말로..
그리고, 모 은행의 경우 자체적인 표준 프레임워크로 몇년간 정말 만족하면서 잘 사용하고 있습니다. 아키텍처 팀도 따로 구성해서 프레임워크 설정은 모두 그 팀에서만 구성하게 하고 있습니다. 프로젝트 팀에서는 프레임워크를 deep하게 몰라도 되게끔 되어 있는 구조구요.. 현재까지 해당 은행의 대부분의 J2EE 기반 시스템은 그 프레임워크 기반으로 가고 있습니다. 개발자가 프레임워크를 알아야 할거 같다구요? 아뇨.. 몰릅니다.. 개발자는 비즈니스 로직만 짜면 되게끔 되어 있습니다. 비즈니스 로직만이죠...
제가 하려는 얘기는 이겁니다.. 저도 프레임워크만으로 모든것이 된다고 말씀드리는건 아닙니다. 프레임워크의 learning curve 같은건 여전히 문제죠.. 중소기업에서 프레임워크를 도입했을때 생산성이 안나는 것도 대부분 learning curve 문제이구요..
하지만 조직적인 해결책, 프로세스적인 해결책과 전사 표준 프레임워크를 함께 했을때는 프레임워크의 효용은 말할수 없을 정도로 커집니다.
님의 말씀중에 동의하는 부분은.. 아직 웹MVC 프레임워크의 효용성은 저도 아직은 긴가민가입니다.. 님 말씀처럼 웹부분 생산성은 아무리 잘 모듈화 해도.. PHP를 따라갈 수 없겠더라구요.. 유지보수 생산성 부분 조차도..

님과는 나중에 deep 하게 얘기해 보는것도 재미있겠네요 ^^
그런데 말이죠. SOA를 들이밀고 나온건 자바쪽이 아니라 마이크로소프트쪽이랍니다. EJB, IIOP, RMI 같은것들 파토 놓으려구요. SOAP proposal 어디서 했나 알아보세요.
SOAP이 SOA때문에 나온 건가요.. 푸훗
글을 읽어보니 어떤 부분은 맞는 이야기도 있습니다만, 세상에 모든 일을 자신이 경험을 한 것은 아닙니다.
도메인 영역에 따라서 많이 달라질 수 있다는 이야기죠.
http://www.ologist.co.kr/813
우연히 보게되었습니다.
아직 경력이 5년차 미만이지만, 묘한 반감이 드는것은 어떤 이유인지 모르겠네요..
어느 프로젝트건 단순히 한두명선에서 진행하는거라면 불필요한 약속에 의해 오버해드가 생길수도 있겠지만
상이한 레벨의 다수의 개발자가 작업을 한다면 다소 필요성에 의문이 생기는 부분이 생긴다 하더라도 미리 규정된 약속을
하는게 당연하다라고 생각됩니다. 한마디로 진행과정에 일부를 시스템화시키는 것정도로 봐야겠죠.
프레임워크가 그 이상도 그 이하가 되지 않아야 하는게 맞지 않을까 하고 생각합니다.
그런 의견에서 글을 적으신 거라면 어느정도 수긍이 갑니다.

하지만 개발속도와 유지보수성에 대해서 말씀하셨는데 개발속도 == 품질이라면 몰라도 아시다시피 아닌 경우도 충분히 발생하죠.
유지보수역시 속도로 말씀하셨는데 이 역시 유지보수속도 == 품질이라고 할 수는 없습니다.
물론 프레임워크 == 품질도 절대 될 수는 없는 것이 사실입니다.
애초부터 이들간에는 상관관계를 정의하기가 곤란한 부분이 아닌가 싶습니다.
어느 환경에서건, 단순 인라인 코드가 됐건, 심각하게, 또는 불필요하게 고도화된 코드가 됐건, 능력이 좋은 개발자들은 잘 따라가기 마련이 아닌가 생각합니다. 품질역시 환경적인 부분보다는 개개인의 능력에 기인되겠죠.

좋은 글 잘 읽었습니다. 말씀하신대로 일부 몰지각한 자바를 모르고 프레임워크를 아는 개발자들은 사라져줬으면 하는데에 찬성입니다. ^^
다만 그런 부류의 사람들은 자바에 국한된 부분이 아닌 이바닥, 어느 언어를 다루는 사람이라도 있기 마련이 아닌가 하는 생각이 듭니다.
그로 인해 그 책임이 자바라는 언어로 간다면 좀 곤란하지 않을까요? ^^
언어의 문제가 아니고, 프로그래머의 문제라는 생각이 드는데... 한국인이 영어하면 미국인됩니까?
C++경력자/신입자바프로그래머 자바로 잘짭니다.(copy&paste,지식인으로) 그런데, try catch절대 안씁니다. 죄다 함수지향적이죠. return return return... 어떻게든 라인수늘립니다.

단순한 ec싸이트라면 php, 간단한 윈도어플은 VB로 작성하는 것이 낫습니다. 묻고 싶은 것이 있는데... 자바로하면 동기화,객체직렬화,메모리리크등등 기본적으로 신경써야할 부분들도 있는데, 왜 자바를 사용합니까?

프레임워크 사용하면 생산성 좋아집니다. 제대로만 쓰고 제대로 소스체크/감시한다면...

제가 생각하는 원인 1.단가낮추려고 급제조된 자바프로그래머 사용 2.프로젝트 리더가 안건에 맞는 아키텍쳐나 기술자체를 모른다. 3.문서화/테스트/소스체크하지않는다.강한의존성으로 테스트불가능하게 작성한다.(junit,findbug) 4.소스 곳곳에서 Copy&Paste한다. 5.자동화하지않는다.(CVS,BTS,CI)
님께서 제기한 문제점은 충분히 이해합니다. 저도 무식한 그들이 싫습니다. 하지만 저도 그 무식한 사람들중에 하나였고 지금도 아마 삶의 어느부분에서는 아직도 무식한 짓을 하고 있을지도 모릅니다.ㅠㅠ 그렇다고 자바에 대한 역겨운 생각을 만드는 사람들에게 휘둘리시면 안되죠? 오히려 창조적 가치를 창출하여 역겨운 생각을 나게 만들은 분들을 좋은 방향으로 이끌 수 있는 역량이 더 필요한 것이 아닐까요? 그러기 위해서는 비판보다는 비전을 제시하는 것이 더 효과적인 것 같습니다.
비판보다는 비전... 제 가슴을 가장 아프게 하는 지적입니다. 아직 비전을 제시하기에는 제 역량과 내공이 태부족이네요. 원색적인 표현을 동원해야만 하는 것도 사실 공력부족을 자인하는 것이나 마찬가지이긴 합니다만...
프레임웍, 개발결과물의 우선순위가 바뀐 경우가 많이 있습니다. 프레임웍 자체가 의미 업는 것은 아닌것 같고 써야 할때와 우선순위를 헛갈린 프로젝트들이 많이 발생한다고 봅니다. 규모와 목적에 맞는 플랫폼(언어, 프레임웍)을 선택해야 한다고 생각합니다.
vb도 윈도우 환경안에서는 python만큼 편하다고 생각합니다.
제 생각에는 자바의 문제가 아닌 프레임워크를 조그만 홈페이지 만드는데 쓰려는 무자비한 개발자들이 문제죠.
자바든 php든 각자의 능력을 십분 활용할 수 있는데서 사용하게 된다면 그 효용성이 타의 추종을 불허할 만큼 좋은 것이죠.

좀 더 넓은 곳을 보지 못하고 비판적인 생각을 먼저 갖으신것 같아 조금 씁쓸하네요. 그리고 약간의 자만심도... 기분 나쁘시다면 죄송.
자바의 문제가 아닌 것은 확실합니다. 당연하게 프레임웍 자체만의 문제도 아닙니다. 자바를 둘러싼 사람들의 문화가 문제라고 생각합니다. 특히 자바계 리더들의 문화가 문제라고 생각합니다.
초중급 개발자들은 리더들이 주장하는 바를 큰 비판없이 수용하니까요. 자바계의 리더들이 문화적으로 손쉬움과 단순함을 추구하는 면이 부족하다는 얘기를 하고 싶은 것이었습니다.
원색적인 표현을 동원한 것에 대해서는 좀 과하지 않았나 생각이 듭니다.
이뭐병. 프로젝트에 스트럿츠가 맞는지 안 맞는지 판단안해보고 무작정 스트럿츠 쓰니까 당연히 불편하고 어려워 보이는거지. 스트럿츠는 예일 뿐이고 요건정의 할 때부터 어느 언어가 적합한지부터 생각해야되고 그 후에 프레임웍이 필요한지 어떤지 정해야 되는데 이유없이 그냥 스트럿츠로 하니까 그런 상황이 발생하는거야. 프레임웍의 장단점, 활용도 제대로 못하면서 좋네 나쁘네 말할 자격 없다고 본다. 한마디로 본문 정말 쓰레기글이다. 이제 배우는 사람이 이런 글 읽고 편협적인 사고방식 가질까 무섭다.
스트럿츠가 맞는 프로젝트가 존재하기나 하나요? 그게 질문입니다. 그것은 제 답보다는 영문으로 된 페이지에 가셔서 스트럿츠 만들었다 이제는 죽이려 드는 사람들이 하는 얘기를 직접 보시고 판단하시길...
자바계 리더들의 문제로 돌리는 건 오버인 것 같은데요.

훌륭한 엔지니어들의 얘기를 자세히 들어보면 열린 마음으로 여러가지 해결책을 객관적으로 비교하고 가장 나은 것을 고르는 태도가 체화되어있는 것을 알 수 있습니다. 설령 자바 리더들이 Struts를 강요했다고 하더라도 맹목적으로 Struts를 쓰는 건 그 엔지니어의 문제죠.

PHP로 잘할 수 있는 것은 PHP로 하세요. 코드가 커지다보면 Smarty도 써야되겠죠. 대형 서비스가 되면 memcached도 써야하고, 데이터베이스 접근을 일반화하고 싶을겁니다. 나중엔 Java로 migration하게될 수도 있겠죠.

자기 손에 맞지 않는 도구를 골라놓고 도구를 만드는 데 수고한 분들을 공격하는 것은 옳지않은 것 같습니다.
그렇게 하는 지혜가 필요하겠죠.
프레임워크 다시말해 MVC 모델을 코딩에 도입했으면 일도 MVC 에 따라 나누어야죠. 버티컬하게 나누어 작업해야 효율과 생산성이 높아진다는 말입니다. 한사람이 수평적으로 html, javascript, java, sql 을 넘나들며 이파일 열었다가 저파일 열었다가 하니까 생산성이 안나고 짜증만 나는 것입니다. 한사람이 딱 하나씩만 잡고, 분업해야죠. 산업혁명이 뭡니까. 프레임워크는 코딩을 아트에서 대량생산으로 끌어내려주신 거룩한 것입니다.
일을 재조정 해야 하는 것은 맞는 말씀입니다. 그런 정도의 재조정은 MVC/프레임웍 없을 때에도 해주면 생산성 높아집니다. 그리고 유지보수로 넘어갈 경우에는 개발 때와 다르게 인력 투입이 현저하게 줄어들기 때문에 일을 분업하는 것 자체가 쉽지 않구요. 근데 고민은... 그런 업무 재조정 작업을 정성스럽게 했다고 생각하는데도, 원하는 만큼의 성과가 나오지 않더라는 것입니다. 팀원들의 실력 탓할 일도 아니고, 경험 탓할 일도 아니라는 것도 확실해 보이구요. 자바쪽의 개발관행이나 스타일 외에는 뚜렷한 답을 아직 못 찾았습니다. 이거 자바를 쓰는 사람들은 심각하게 고민해 봐야할 일입니다. 진짜로...
고민스러운 분야죠..@@
자바 쓰레기들의 자기만족을 위한 프레임웍이 자바 찌질이들을 제물로 삼는다는 말이군요
엘레강스한 이면에는 구역질나는 쓰레기, 오물들이 가득하죠
사이비교주와 다를 바 없는 반인륜적 범죄가 암세포처럼 퍼지다가 결국엔 죽음뿐이죠
저는 예전에 회사에서 asp.net으로 개발하다가 지금은 연구실에서 jsp로 가끔씩 프로그래밍하는 학생입니다.
원래 친 MS적이라서 그런지 님의 말에 공감되는 부분이 너무 많군요. MS의 프레임워크를 쓰면 편한것도 많고 코드도 깔끔해져서 '이래서 프레임워크가 좋구나."라고 생각을 했었어요. 하지만 자바의 스트러츠 같은 시스템은 개발의 편리함과는 거리가 멀다고 해서 개발시 고려하지도 않고 있습니다. 사실 자바진영의 뻘짓 때문에 닷넷이 많이 성장했다는 의견도 있죠. -이거 자바 개발자 분들이 대다수 일텐데 너무 플레임성 아닌가 싶기도 하네요.- 하여튼 자바도 좋아지겠죠. 언어쪽은 새버전이 나올 때마다 점점 좋아지고 있다는 생각이 듭니다.
여러가지를 뒤섞어서 써 본 사람은 공통적으로 자바의 문제점을 이해할 겁니다. 특히 웹 부분에서는 죽음이죠. 당최... 일이 끝이 안 나니... 그러고도 자랑스럽게, 그렇게 해야 나중에 관리하기 편해요... 하면 어쩔 수 없이 또 속아야죠. 다음에 유지보수 해야 할 일이 생기면, 또 세월아 네월아 코드 붙들고 있는 자바 개발자들을 보면... 좀 측은하고 불쌍하기까지 하죠.
c,c#   쓰다가 java 로 개발한지 3개월 되는 저로서는 상당히 도움이 되는 글인 듯 합니다.
퍼가도 될까요? ^^
그러시죠.
저도 님이 얘기하는 사람중에 한명인 듯합니다.. 얼굴이 화끈거리네요.. ^^
그 이유는 아마도 자바만큼 다른 언어에 대해 깊이 알지 못하기 때문인 것 같네요..

그래도 자바의 프레임웍에 대한 지나친 평가절하가 아닌가 싶어 몇글자 적습니다.
적어도 자바로 제대로된 결과물을 작성하기 원하는 초보 개발자들이 읽고
가감없이 동조하지는 않았으면 하는 바램으로요..

자바진영에서는 조금씩 더 많이 알아갈수록, 개발하는 시스템이 커질수록 프레임웍을 빼고는 말이 안되는 게 맞는 거 같습니다..
저도 처음부터 프레임웍을 쓰지는 않았죠..
프로그램 테스트를 위해 System.out을 사용하고 지우기를 반복하다가, log4j를 사용하게 되었고,
jsp파일의 html tag사이에 복잡하게 포함된 java code들(공통method등)을, class로 분리해 가다가
taglib이나 jstl을 사용하고 EL을 사용하다 보니, MVC 패턴으로 자연스레 변경된 것 같습니다.
또 enterprise system을 개발하다 보면 고민하게 되는 많은 것들(다국어 지원이나 theme, transaction등)이
프레임웍에서 편하게 사용할 수 있다고 하면 확 땡기는 건 어쩔수 없지요..

물론, 단순한(class5~6개로 구성된) 프로그램을 작성할 일이 있을때에도 괜스리 log4j 등을 사용하기도 하고,
단순한 홈페이지를 개발하면서도 MVC 패턴을 적용하고 있는 나를 보면 좀 웃긴 일이긴 하지만...
알고보니 더 쉽기 때문이거나 나중의 확장성을 괜히 고민해서 그런게 아닐까 하는 생각도 하게 되네요..

많은 분들이 상황에 맞는.. 이라는 말씀도 많이 하시네요.. 정말 고수다운 말씀이 아닐 수 없습니다..

추신) 이 글이 논란에 휩싸이는(?) 이유는 글의 내용보다 제목의 포스가 강하기 때문인 듯^^.. 하네요..
이 글을 읽고 있다면 당신도 저와 같은 바닥에서 먹고사는 개발자이겠죠??
이런 고민하는 줄 관리자들는 알까 몰라~?
자바개발자들은 각별히 '단순함'에 대해서 고민해야 합니다. 자바계에는 언제나 불필요한 복잡도가 만연해 있기 때문입니다. 더 단순하게 만들 방법은 없을까? 다른 언어에서는 얼마나 단순하게 똑같은 일을 하고 있나...? 이런 것들을 항상 보면서 지나치다 싶을 정도로 단순함을 추구할 필요가 있습니다. 자바개발자들은 특히나...
음. 이미 개발의 복잡성은 사람의 두뇌를 초월했죠. 쉬운건 모르겠지만, MS워드나 엑셀 혹은 이클립스 같은걸 파일수를 줄여서 만들 수 있다고 생각하는건 말도 안되죠. 시스템언어까지 말씀하시는분이니 걍 로컬어플까지 예로 들겠습니다만..
이쁘게 객체간의 관계를 잘 정리하고 소통로를 만들어 서로간의 필요한 내용만 공개하는 수많은 클래스가 없이 개발이 가능한건 저같은 중소에이전시가 받아오는 조그만 홈피정도겠죠.
전 C++조차도 에이스프레임웍없이 네트웍개발하기 싫고, 플렉스도 페이퍼비전없이 3D개발하기 싫고, php도 사실 pear패키지 안깔고 개발하기 짜증나는데 아닌가요..=.=;
프레임웍이 복잡하면 또 래핑하면 되지 멀 그런걸...이란 생각입니다.
참고로 글로 쓰신 내용 중에 공감하는 부분은 많이있습니다. 그 예로 JSP공사를 안받거든요 ^^; 단가가 안맞기 때문에.ㅎㅎ
그리고 그것도 언제나 의문입니다 왜 게시판 만드는데 jsp로 하면 며칠씩이나 잡아먹어야하는가..그렇게나 래핑클래스를 많이 만들어서 들어가는데도..고객의 요구변화가 오면 항상 에이전시에겐 손해가 오죠. php는 요구가 사실 마구마구 와도 대략 일정안이지만 ㅎㅎ;
하지만 그 모든것도 다 위에 말씀드린대로 규모가 작을때나 머릿속에 쑤셔넣고 줄여보고 그러는거라 생각합니다.
스타크래프트 한번 파일세개에 삼백줄로 짤 수 있다고나 하는거나 마찬가지 주장인지라 현대 개발복잡성을 초월하는 개발자분같지는 않은데 ^^;
뭔가 포트폴리오에 최신 c++컴파일러, 윈도우Z같은걸 클래스 10개로 만드신건가요 *.*?
"개발의 복잡성은 사람의 두뇌를 초월했다"는 맞습니다. 그래서 더욱 단순함을 지향해야 하구요. 자바의 경우, 불필요한 복잡성이 만연해 있다는 것을 지적한 겁니다. MS워드나 엑셀 또는 이클립스 같은 것을 10개 또는 100개의 파일로 만들 수는 없지요. 하지만 평균적인 자바 개발개발자들이 만들어내는 파일의 수나 코드의 길이가, 평균적인 PHP/C/Python 개발자들의 그것보다 더 많으면 분명 문제는 문제죠. 그것도 그냥 많은 게 아니고 훨씬 많은 것이라면...   지적하는 포인트는 자바의 불필요한 번잡함입니다. 근데 이상하긴 하죠? 왜 JSP 개발이 항상 PHP개발보다 공수가 더 들어가는지... 꼭 그래야만 하는 이유가 뭔지 생가해 보셨어요? 그냥 한두번도 아니고 항상 그럴 때에는 이유가 있는 거잖아요. 그게 바로 "자바계 리더들이 그래야만 한다"고 생각하기 때문 아닐까요?
현재 나이 만26 이고 월 실수령액이 370 만원(정규직)인 초짜 프로그래머 입니다.

현재 저는 C++ 하고 있으며 엔진정도 만드는 허접한일을 하고있습니다.

근대 웹은 JSP 보다 PHP 6만배 정도 좋다고 생각듭니다.
(유지보수+개발기간 포함)

JSP 쓰래기 언어는 개나 줘버리고 쓰랄때 써야 됩니다.

프렘웍도 쓸때 쓰면 좋죠. 위에 잠시 봤는데 1천 명의 개발자가 동시에 스타트로 끊고 바로 개발할시에.

근대 JAVA 붕신들은 그걸 남용한다 이거죠..

항상 남용이 문제야....

그냥 긁적 대다 갑니다.
스트럿츠1의 문제점은 동감합니다만....
자바진영의 프레임워크를 싸잡아 매도하시는건 본인이 자바를 덜 경험하셨다는 반증이 아닐까 싶네요.

자바에 있어서 '선택'은 단점이지만 장점이 될 수도 있습니다.

이미 자바진영에서도 복잡하고 느린 EJB나 스트럿츠등을 없애고 단순함을 추구하는 spring이나 EJB3.0등으로 일종의 '회귀'를 하고 있다는건 알고 계시죠?

다른내용은 다 이해하는데 성급한 일반화의 오류는 범하지 마셨으면 합니다.
그나마 단순화 했다고 하는 spring마저도 다른 언어계열의 프레임웍에 비하면 여전히 복잡합니다. 자바는 아직 멀었습니다.
루비, 파이썬, PHP 로 바꾼다고 프로젝트의 개발 기간이 정말 단축될까요?
Java 의 수 많은 프레임웍들은 정말 단순히 기술력을 과시하기 위해서 만든 것들일까요?
중소형 프로젝트에서 PHP 같은 스크립트 언어의 생산성은 엄청난 수준입니다만
Java 로 그렇게 짤 수 없는 것도 아닙니다. 오히려 더 심플하게 작성할 수도 있죠
(아파치란 보물창고에는 참 많은 것이 들어 있으니까요)
jsp 에 beans 만 적절하게 사용하면 프레임웍 안 써도 ui 와 비지니스 로직을 분리하는 것도 심플하게 끝납니다.
소스 알아보기도 쉽고 스크립트 언어에서 버그가 되버릴지도 모르는 부분도 컴파일러가 약간 잡아줍니다.
그럼에도 불구하고 사람들은 프래임웍을 연구하고 계속 발전시켜왔습니다.
(물론 EJB를 모든 분야에 적용하겠다고 설쳤던 대규모 삽질도 있었습니다만...)
왜일까요?
그런 고민없이 프레임웍을 사용하시고 자바를 역하게 느끼신다면 좀 실망입니다.
웹 프로그래머들 몸값 올리려고 저런 개념이 나온듯.

저걸 소위 '윗선'에 보고하기 위한 프로그래밍이라 하오..

embedded, opengl 끄적거리고 php asp쪽 만지다
이번에 SE ㅈ도 모르는 윗선의 지시로 spring 다루게 되었는데
개발을 위한 코딩인지 관리를 위한 코딩인지 모르겠소

php하고 자꾸 비교들 하시는데 제대로 된 4년제 학사 나오고
어느정도 경험 쌓으면 php로도 멋진 (그러면서 생산성도 뛰어난)
웹app 나온다오


꼭 그걸 스프링이나 스트럿츠 프레임웤을 써야 관리가 된다는게
아니라는거지


그나저나 본토에서 갖다버리려고 하는 저걸 왜 한국 돌팔이들은
고집할까나..? 참 미스테리라오
필요한 곳에 필요한 것을 가져다 쓰는 것이 방법이겠죠

프로그래머가 프로그래밍 언어를 가지고 놀아야지
그반대로 되는 것 - XXX
잘 읽고 갑니다. ㅡㅠ
  • 조인상
  • 2009.04.14 18:20
  • |
  • 답글
기존의 방식에서 벗어난 효율적인 자바 프레임워크를 소개해 드리고 싶습니다.

www.aimaxsoft.co.kr
흠 공감합니다. 저는 자바진영과 MS 진영, 웹진영과 윈도우진영 양쪽을 오가는 양다리 프로그래머입니다. 그래서 사실 둘을 얻기보단 둘을 잃고 있는 사람인데요. 공감되는 부분이 많네요. 제가 느끼기에 MS 진영은 쓰기는 편한데 개념이 약한듯 했고 JAVA는 개념은 강한데 쓰기에 불편한듯 한 느낌이 많았거든요.   사실 요즘 JAVA플젝 하기 겁납니다. 무슨 말들이 그리 많은지 저도 JAVA를 2001년 부터 했는데 요즘 1년만 신경 안쓰면 별의별 말들이 많습니다.
예전에 EJB 플젝을 할 때가 생각나는군요. 그많은 객체들이라니..... 그때 하던 말들이 재 사용성이었습니다.   글쎄요. 솔직합시다. 지금까지 10년째 이바닥 있지만 레거시의 재사용성을 고려해 차기 플젝이 설계되는걸 본적은 없습니다. 왜? 그러면 장사 안되니까.
최근에 스트럿츠를 쓴 플젝을 했는데 사실 알고보니 그리 어렵지는 않았습니다. 이미 알고 있는 개념이라. 그런데 문제는 초급 개발자들이죠. 그들은 응용에 어려움이 많습니다. 낯선것에 대한 두려움으로 고통받더군요. 근데 많은 JAVA 리더들이 그들 앞에 쉬운 답을 주기보다는 복잡한 오만가지 이야기를 끌어냅니다. 그럴려면 프레임웍이 왜 필요할까요? 제 생각으론 프레임웍이란 많은 기능보다 더 중요한것은 아무 생각없이 쓸 수 있어야하는 단순함이 있어야 한다고 생각합니다.
서로의 영역이 달라져야 할 듯 합니다. 프레임웍 개발하고 싶은 사람은 지지고 볶던 맘대로 하고, 그 대신 사용자는 망치처럼 그저 갖다 쓸 수 있으면 그만이라는 거죠. 망치 만드는 사람과 목수가 같은 고민을 할 필요는 없어야 합니다.
이전12


텍스티콘 텍스티콘
등록