바틈업과 탑다운이 상위 1/3지점쯤에서-_-? 만나는 게 좋겠죵. 근데 보통 PT로 박스만 그리던 분들께서 탑다운 프렛셔~를;; 하는 경향이 있지 않나여 ㅋㅋ

그 적임자중에 끼고 싶은데, 잘 안되네용~

dawnsea 님 : 그죠? 현실에 맞지도 않는 블랙 박스를 가지고 와서 쓰라고 하니... 소내기 : 일단 업무에 집중하다보면 영감이 떠오를 때가 있을거여.

프레임워크라는게 보통 같은일을 세번정도 할 노력이 드는일이라 세번 넘게 할일이 아니면 투자대 효용가치가 없더군요.

그와는 별도로 프레임워크가 커버하는 영역을 잘 이해하고 있으려면 세번정도 같으나 다른일들을 삽질해본 사람이 아니면, 제대로된 프레임워크가 안나온다능..

반복되는 일은 다른 사람을 시키세요. (일자리 창출)

그래서 Django가 좋은 듯합니다;; 실제로 웹사이트 개발하다가 짜던 것을 그대로 프레임웍화한 경우라고 하니...

아침놀 : 오호 그렇군요. ORM 쪽만 잠깐 살펴 보았었는데... 애석하게도 Python을 사용할 기회가 없군요.

첫 댓글에 무례가 될런지 모르겠습니디만, 이 토론을 제가 작성하는 PPT 자료에 인용해도 될까요? 자료는 웹 공개용입니다만... ^^;

이 글 지금 고민하고 있는 주제에 대한 뚜렷한 해답. 그리고 토론~ 인용해도 될런지 문의 중…

framework의 다른측면 재사용성 이외의 project policy(exception, coding rule.etc) 적인 부분에 대해선 어떻게 생각하시나요?

아시모프 님 : 아마 framework이라는 단어에 대한 이해가 저랑 약간 다른 듯 합니다. 저는 말씀하신 것들을 framework이 아닌 개발 표준으로 분류해서 다룹니다.

써니 님 : 아이고 뭘 문의까지... 공개된 것이니 마음 껏... ^^

제가 알고 있는 framework 의 이해입니다. 예를들어 struts를 보더라도 validation의 대한 exception처리라든지 action간의 이동들은 framework의 규약에 종속되어 있습니다.(물론 커스텀도 가능하지만 말이죠..)

아참 위의 처음덧글에서 말하는 coding rule은 제블로그 글(덧글포함)에서 말하는 코드를 강제한다는 의미로서 말한것입니다.

(필요 이상으로) 논란이 되었던 글의 답글이군요. ^^ 개인적으로 프레임워크에서 재사용을 다루어야 하는 것인지는 의문입니다. 예를 들어 스트럿츠는 action의 재사용성을 고려하고 만들었습니다. 하지만 action의 재사용성이 프레임워크에서 지원해야 할 문제일까요? 저는 언어 차원에서 OOP적인 기법으로 충분히 재사용을 할 수 있다고 봅니다.

저는 framework의 재사용성이라고 하면 컴포넌트 코드의 재사용이 아닌 workflow의 재사용이라고 생각합니다. 흔히 말하듯 template method pattern의 확장된 형태가 framework이라는 거죠.

참고로 제가 가지고 있는 프레임워크에 대한 생각은 이 글 을 참고해주시고요. 이 글을 쓴 취지가 좋은 프레임워크는 실무를 반영해야 한다는 것이므로 토비님의 이 글 이 제가 말하고 싶은 내용이라고 보시면 될 듯 합니다.

결국 실무를 하는 사람들이 객체지향 기술을 더욱 익혀 프레임워크로 발전시키는 것이 좋은 프레임워크를 만드는 바른 방향이라는 생각, 즉 강조점은 '객체지향 원리'에 있었던 ... ㅎㅎ

^^; 링크하신 글에 대해 별다른 이견은 없고요. 재사용성에 관해서는 조금 이견이 있습니다. 논점을 나눠야할듯한데, 1.서서히 만들어지는 것이 더 낫다 2. 실무자가 만드는것이좋다. 에서 제가 애초 말하고자 했던 부분은 1에 관한 이야기였습니다. framework의 정책은 개발중 수시로 변경될수 있는 부분이 아니기 때문에, top down의 접근도 필요하다는 생각입니다.

맞습니다. 모든 것은 종합적이어야 하겠죠. 다만 수시로 변경되는 것과 성장하는 것은 구별이 되어야 한다고 생각합니다.