알파디벨로퍼 한, 두명 데리고 garage startup을 세우고 소셜네트워크같은 웹 서비스 만들어서 2, 3년내에 회사 팔고 튈 생각인 경우 Ruby같은 dynamic type language를 쓰겠다.
안정된 회사에서 평균 수준 장삼이사 디벨로퍼들 두자리수 이상 데리고 5년 이상 사용할 엔터프라이즈 시스템 개발 유지보수 조직 책임져야되는 자리로 가는 경우는 무조건 Java같은 static type language쓰겠다.
안정된 회사에서 평균 수준 장삼이사 디벨로퍼들 두자리수 이상 데리고 5년 이상 사용할 엔터프라이즈 시스템 개발 유지보수 조직 책임져야되는 자리로 가는 경우는 무조건 Java같은 static type language쓰겠다.
'잡소리' 카테고리의 다른 글
| 알파디벨로퍼 (0) | 2008/04/02 |
|---|---|
| Open Source 참여와 Localization (9) | 2008/04/02 |
| static type language vs. dynamic type language (8) | 2008/03/31 |
| 마이크로소프트를 믿어보잔다... (4) | 2008/03/29 |
| The story of Google China (0) | 2008/03/26 |
| 똥이냐 된장이냐 (6) | 2008/03/20 |
댓글을 달아 주세요
왜 그렇게 생각하세요 ?
다음과 같은 조건이 만족되는 경우 ruby나 python같은 dynamic language가 static language보다 개발생산성이 더 높은 경향이 있는것 같기 때문입니다.
1) 개발자가 소수의 알파디벨로퍼일때
2) scratch부터 새로 다 만들때
3) 개발자들이 전체 소스코드를 빠삭하게 알고 있고, 다른 사람이 개발한 코드를 분석해야 될 일이 거의 없을때
dynamic language로 만든 시스템의 경우, 개발자가 바뀌는 경우 static language시스템에 비해 문제가 발생하는 경우가 많은데, 처음 시스템을 개발한 개발자하고 나눠먹고 exit하는 시나리오에서는 이게 별로 문제가 안되죠.
두번째 시나리오는 이 조건이 충족되기가 힘드니 java같은 language로 가는게 만수무강에 지장이 없는 편입니다.
핵심을 찌르는 글이네요.
본문과 덧글 내용에 동의합니다. 루비 등의 언어는 개발자를 너무 타더군요. 어차피 절대적으로 모든 상황에서 좋은 언어란 없으니.
개발의 난이도, 생산성, 인수인계 등을 고려하여 프로젝트의 규모와 유형에 맞는 적절한 언어를 선택해야겠죠. ^^
혹시 개발자를 탄다라는 게 개발자의 능력을 의미하시는 건가요 ? 아니면 개발 언어가 가지고 있는 규칙들에 개발자들이 익숙해 지기가 힘들다는 건가요 ? 아니면 언어에 익숙해지려면 상당히 시간이 걸린다는 건가요 ?
script 언어는 일반적으로 소규모의 software 를 작성하는 용으로 많이 사용되었는데... 요즘은 대규모 software 를 작성하는 용도로도 사용되고 있는 것인 요즘 현실인 것 같습니다. 워낙 생산성이 좋다고 알려져 있으니...
요즘 하도 script 언어가 많이 사용되길래 script 언어도 언어적 측면에서 많이 향상되었나 보다 했는데... 여전히 그게 아니었나 보네요. 저는 tcl 외에는 script 언어를 써 본적이 없어서 ruby와 python은 판단하기가 힘드네요. tcl 은 문법 자체가 없는 언어라서 유지보수가 하기가 무척 힘들었던 언어였죠. debugging 하기도 힘들고
nokarma님의 덧글에 답이 있잖아요. 실전에서는 해당 조건들이 충족되지 않는 경우가 많기 때문이죠.
교과서적인 생산성은 의미가 없어요.
그 생산성이라는 것이 당연히 사람과 상황에 따라 다 다르니까요.
김윤수/ runtime에 late binding이 이루어지는 dynamic language의 특성상 전체 시스템의 runtime binding이 어떻게 돌아가는지 머리속에 있지 않으면 소스를 고칠때 버그를 만들기 쉽고, 버그를 만들고도 인식하지 못하게 되는 경우가 자주 발생합니다.
따라서 남이 짠 소스나 자기가 짰더라도 자기 기억 용량에 비해 시스템이 너무 큰 경우에 버그없이 고치기가 힘들고, 유지보수 생산성이 떨어지죠.
static language system의 경우 compiler가 잡아줄 수 있는 부분까지 unit test코드를 만들어서 거기에 의존하는 일이 발생합니다.
평균 수준 프로그래머들 손을 여럿 거치다 보면, unit test code를 철저하게 유지하기도 어렵고, 오버헤드도 만만치 않습니다.
따라서 평균 수준의 개발자들이 들락날락하고, life cycle이 긴 일정 규모 이상의 여러 모듈로 이루어진 시스템을 책임지고 있는 경우 static language로 가는게 안전합니다.
알파 디벨로퍼가 정확하게 어떤 개발자를 가리키나요?
프로그래밍 속도 및 정확성면에서 평균 수준의 프로그래머들보다 기십배의 생산성을 보이는 에이스 프로그래머들을 말합니다.
평균 수준 프로그래머들과 비교할때 생각, 코딩, 툴사용 속도 및 정확성이 일반인과 프로게이머 차이정도 나는것 같더군요.
어떻게 기회가 되서 돌아다녀본 이 동네 회사마다 적어도 한명씩은 본것 같습니다.
어떤 육십대에 가까워보이는 알파프로그래머는 자기는 유닛테스팅같은거 필요없다고 안하더군요.