조엘을 읽다보니,, 넷츠케이프가 코드를 새로 작성하는 바람에 90%->7% 로 떨어졌다는 부분에서

freesm5의 이미지

조엘을 읽다보니,, 넷츠케이프가 코드를 새로 작성하는 바람에 다음버전 출시가 3년이 걸려서

점유율이 90%->7% 로 떨어졌다는 부분에서

올바르지 못한 선택이었다는 것은 동의가 가지만,,,

그 당시 코드가 관리 불가능하게 짜여있다는 점에서

개발자로서 얼마나 새로 짜고 싶었을까 하는 마음에는 공감이 가네요.

그래도 요즘 파폭 쓰다 보면,

중간에 새로 짜서 이렇게 좋은게 나왔나 싶은 생각도 들고.

이대로면 점유율도 다시 회복하지 않을까 하는 생각도 드네요

코드를 새로 짜지 않았더라면

지저분한 코드 때문에 어차피 버전업에 시간도 오래 걸리고, 버그가 난무하는 상황으로 가서 점유율은 떨어지지 않았을까 싶네요.

이 때도 결국엔 대책 없이 다시 짜야하는 상황이 되었을테고...

깨진 유리창은 그냥 두지 마라는 실용주의 프로그래머의 원칙을 생각해봤을 때,

조엘과 달리 제 생각엔 넷츠케이프가 코드를 다 뒤엎고 새로 짰다는 것은 올바른 선택이었다고 생각되는데,,,

여러분은 어떻게 생각하시나요?

zelon의 이미지

세부적인 내용은 당사자들만 알겠지만, 코드를 새로 짜더라도, 완전히 엎지 않고, 부분적인 리팩토링을 해서 개선해야하지 않나 생각해봅니다.

예를 들자면, 해당 책에 나온것처럼 렌더링 엔진에 심각한 구조적 문제가 있다면, 해당 렌더링 엔진을 새로 짜는게 아니라, 새로운 렌더링 엔진을 만들면서, 기존 엔진을 같이 가져가고, 새로운 렌더링 엔진이 어느정도 안정화되었을 때 기존의 엔진을 교체한다던지등의 방법을 써도 되었을 겁니다. 현재 Internet explorer 도 일단 이런 식으로 가고 있는것 같습니다.

마찬가지로 잘돌아가던 소스를 새로 짤 때 '교체' 가 아니라 '동시 사용하며 검증' 이라던지, '점진적 개선' 이 어땠을까 생각해봅니다.

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

-----------------------------------------------------------------------
GPL 오픈소스 윈도우용 이미지 뷰어 ZViewer - http://zviewer.wimy.com
블로그 : http://blog.wimy.com

CromShield의 이미지

임베디드 소프트웨어를 하고 있습니다만 여태껏 코드를 뒤엎는 것은 본적이 없습니다.
시장은 기다려주지 않습니다. 아무리 좋아도 Time to Market이 되지 않는 이상 사라지고 말죠.

깨진 유리창을 그냥 두진 않아야겠지만, 새 유리창을 사오기전까진 종이라도 붙여놔야
바람이라도 안들어오겠죠.

jj의 이미지

종이를 붙여논곳이 어딘지 기억하는것도 중요합니다. ;-)

--
Life is short. damn short...

--
Life is short. damn short...

neocoin의 이미지

조엘의 분석은 정확하다고 생각합니다. Firefox 는 아예 다른 제품군이죠.

Netscape 가 IE 5.0에 급격하게 밀려갈때 자금력과, 인력 양쪽다 문제에 직면하면서, 더 이상 코드 관리를 못하던 netscape 가 오픈하고, 무모하다 싶은 리팩토링 때문에 차기 버전이 밀리면서, 시장 점유율 감소가 가속화 되었습니다.

그리고...

IE가 시장을 독점하면서, MS의 IE팀의 중요 인력들이 다시 오피스 군으로 옮겨 갔고, 독점 이후 MS는 IE 개선을 멈추어 버렸습니다. mozilla의 실수(?)를 고스란히 반복하죠.
IE 6와 IE7의 출시일은 무려 5년이라는 시간 벽이 존재합니다. 웹을 정복했다고 착각했던 모양입니다.
See Also http://en.wikipedia.org/wiki/Internet_Explorer#Internet_Explorer_6

FF를 FB시절인 0.95 부터 써왔는데, Mozilla의 아예 다른 제품군이었죠. 그때 부터 사용자 요구사항을 적극 수용하면서 편리한 브라우징에 집중하고, 꾸준히 업그레이드 해왔습니다. 탭브라우징 부터 테마까지 IE가 거의 업그레이드를 손놓고 있을 동안 급격하게 발전해왔습니다. 2004년에 1.0이 등장하네요. 그리고 사용자에게 좀 더 적극적인 마켓팅이 시작된게 2.0이구요.
See Also http://en.wikipedia.org/wiki/Mozilla_Firefox#Version_2.0

정말 승승장구하던 세상의 왕 IE가 점차 점유율이 줄어드는 경향을 보면 아직도 신기합니다.

ps. 하지만, 요즘 저의 주 브라우저는 이미 크롬이 차지하고 있습니다.
플러그인 설치후 재시작이 필요없는 구조와, 프로세스 방식으로 이루어져 문제있는 탭만 죽는 안정된 동작이 매우 마음에 듭니다. 일단 키면 끌 필요가 없어지죠.
그래서 chrome os 의 등장이 기대됩니다. :)

moonhyunjin의 이미지

FF도 3.6부터는 '플러그인 설치후 재시작이 필요없는 구조'로 바뀌었습니다. 클릭 몇번으로 플래시 플러그인 깔고 바로 되더군요.

<- 이거면 안 되는 게 없어~
정품 소프트웨어 사용 캠패인

<- 이거면 안 되는 게 없어~
정품 소프트웨어 사용 캠패인

neocoin의 이미지

Firefox 의 NSAPI 호환 플러그인은 예전부터 최초 설치후 재시작이 필요없는건 지원했습니다. 물론 업그레이드 이후에 재시작은 아직 필요할겁니다. (정확치 않네요)

제가 언급한건 extension이었습니다.

3.6 부터는 extension이 둘로 나뉘어서 재시작할 필요가 있는 것과 그렇지 않은 것으로 나뉩니다. 아직 문서는 자세히 보지 않았는데, XPCOM(혹은 그에 준하는 프로그래밍 모델)의 사용 유무에 따라서 결정되겠네요.

ironiris의 이미지

IE6 는 몇년동안 후속이 없었는대도 점유율 별로 안떨어지던데요....

preisner의 이미지

이 부분은 논란이 많은 내용 입니다만,
당시의 재개발 결정이 넷스케이프 시장 점유률이 내려간 원인이라고 하는데는 동의 하지 않습니다.
기술적으로 넷스케이프의 문제는 방대하고 모듈화 되어 있지 못한 코드의 문제였지
재개발로 인한 개발지연 문제와 시장 점유 하락은 나타난 현상과 문제 중 일부 였습니다.

오히려 당시의 재개발 결정으로 Geoko 엔진의 개발에 탄력을 더 받게 되었고 오늘날 Firefox 와 Thunderbird 등이 탄생 할 수 있는 기반이 만들어 질 수 있게 되었습니다.
http://en.wikipedia.org/wiki/Gecko_(layout_engine)

조엘이 하고자 하는 말이 무엇인지는 이해 합니다만, 예로 든 내용은 적절하지 않은 것 같습니다.
원인과 현상을 혼동 하는 거죠.
마치 그지같은 SQL 쿼리로 인한 DB 의 높은 부하를 해결하는 해결책으로 하드웨어 교체를 고려하는 것과 같은 이야기 입니다.

조엘이 책을 쓸 당시에는 IE 가 최고 상한가를 치고 있을때 입니다. 그 당시에는 저런 말이 나올만도 했습니다.
Firefox 와 Thunderbird 가 이정도로 성장할 수 있었던 데는 Gecko 엔진의 역활이 절대적 이었습니다.

vulpes의 이미지

사실 어느쪽이냐고 한다면 진작 재개발을 안 했기 때문에 상대적으로 개선사항 없이 제자리걸음 하는걸로 보였었죠.

--
"It's too bad that stupidity isn't painful" - Anton LaVey

밤여우 Tech: http://foxtech.tistory.com
트롤은 말려 죽입시다 - http://kldp.org/files/trollfreeKLDP.user_.js__0.txt

--
"It's too bad that stupidity isn't painful" - Anton LaVey

밤여우 Tech: http://foxtech.tistory.com
트롤은 말려 죽입시다 - http://kldp.org/files/trollfreeKLDP.user_.js__0.txt