stackoverflow 전 세계 개발자들의 (거의 모든) 언어에 대한 Q&A 사이트
Apr 02
Programming Developer, Development, Q&A 사이트, stackoverflow, 개발, 개발 사이트 2 Comments
stackoverflow는 거의 모든 언어에 대한 전 세계 개발자들이 Q&A를 하는 사이트죠?
아시는 분들도 많으시겠지만….
가끔 구글링을 하면 심심치 않게 검색되지요.
디자인 패턴 (Design Pattern) Quick Reference 입니다.
Jun 20
Programming Design Pattern, Quick Reference, 디자인 패턴 2 Comments
Jason McDonald 의 블로그에 자신이 만든 멋진 Design Pattern Quick Reference가 있어서 포스팅합니다.
각 Design Pattern의 Class Diagram과 목적을 간략히 기술한 것으로 아래는 스샷입니다.
PDF로 받을 수 있습니다. 
Generalization의 오용 – 역사에 남을 인물이 아니면 강제하지 않는건 어떤가요?
Dec 24
Programming Design, Generalization, SE, Software Engineering, 디자인, 소프트웨어 공학 8 Comments
무례한 제목입니다.
하지만 “Generalization”으로 이한 지난 몇 년간의 피해가 있어 몇 글자 적어 봅니다.
아래 그림은 “Design”이라는 이름하에 꿈과 희망을 주는 그림입니다.
승객용 열차 (Passenger) 클래스와 화물 열차 (Goods) 클래스에서 공통된 부분을 뽑아서 기타 (Train) 클래스를 만들고 상속 관계를 아래 그림처럼 구성한 “Generalization”을 하라는 것이겠죠?
하지만, 현실에서는 애석한 일이 발생합니다. 특히 “허공 답보”와 “사상누각”을 일삼는 무리에 의해서.
무지한 저에게 저 그림이 말하는 것은
“화물열차”와 “승객열차”를 별개로 개발하지 말고 공통적인 속성을 뽑아서 “기차”를 만든 후 상위 클래스의 속성 (attribute)이나 행동 (method)을 하위 클래스에서 그대로 이용하든지 응용해서 (overriding) 만들어보자
를 의미하지,
“화물열차”도 “기차”이고 “승객열차”도 “기차”이니 둘 다를 포함할 수 있는 “슈퍼 기차”를 만들어서 조금만 변경하면 개개의 열차가 될 수 있게 만들어보자
는 아닙니다.
“누가 두 번째와 같은 생각을 하냐구요?”
의외로 그런 것을 강요하는 사람들을 주변에도 많았고 이런 문제는 Effective STL과 같은 책에서도 다룰 만큼 전 세계적으로도 많은 것 같습니다.
이러한 현상은 자신의 총명함을 – 어느 정도 총명한 – 믿고 한눈에 상황을 보고 기민하게 판단하는 사람일수록 쉽게 빠질 수 있는 오류인 것 같습니다.
특히 다른 사람 – 총명함을 떠나 열심히 분석하고 생각한 – 을 존중하고 배려하지 못할수록 더 심각합니다.
또는 작업을 최종 마무리를 위해 구석구석 까지 해보진 않았거나 글자로만 모든 것을 익힌 사람일수록 쉽게 빠지는 것 같습니다.
“Generalization”을 부모 클래스가 아닌 슈퍼 클래스로 보는 문제는 비단 클래스 문제에만 국한되지는 않는 것 같습니다. 제품 (product) 자체에까지 마수가 펼쳐지는 경우가 많습니다.
제 짧은 경험에 비추어 몇 가지 사례를 이야기해보겠습니다.
Worst cases
■ 만능 테스트 도구
제가 주로하는 일이 테스트 도구를 만드는 것이라 첫 번째 사례로 꼽아 봤습니다.
“No Silver Bullet” 이 말은 소프트웨어 공학과 여러 도메인에서 자주 거론되는 말일 것입니다. 말 그대로 모든 것을 잠재워줄 한 가지 해결책은 없다는 것이겠죠.
테스트 분야에서도 마찬가지일 것입니다. 테스트 레벨 (unit, integration, system)이 틀리고 검정하려는 목적이 틀린 데 (positive/negativae, functionality/non-functionality, static/dynamic, etc), 단지 “테스트 도구”라는 큰 타이틀을 앞세워 만능 테스트 도구를 찾거나 만들 것을 요구하는 경우가 종종 있는 것 같습니다.
특히, 수백 수천에 달하는 상용 도구를 대하거나 1년 이상 많은 사람이 투입된 도구 제작 프로젝트를 대할 때 높은 사람들의 입에서는 너무나도 거리낌 없이 General 한 만능 도구를 거론합니다.
■ 이 세상 모든 것에 Generic한 컨테이너 (container)
Effective STL의 항목 2이에서 아주 자세히 다루고 있어서 간단히 이야기하면, 머리에 먹물이 들었다는 사람일수록 여러 종류의 “시퀀스 컨테이너”와 “연관 컨테이너”를 일반화 시킬 수 있는 Generic 한 슈퍼 컨테이너를 만들려고 시도합니다.
이 시도는 아주 프로그램적으로 다가가 다양한 STL 컨테이너의 멤버 함수들을 포기해야 하는 문제도 발생하며 더욱이 상황에 맞게 잘 설계된 컨테이너의 특성들을 포기하는 “아무 쓸모도 없는” 컨테이너를 만들 수 밖에 없다는 결론에 도달합니다.
검색을 고려한 map이나 multimap이 vector나 list와 합쳐지면 무슨 이득 (부귀영화)이 있겠습니까?
※ 고객 데이터를 위한 클래스를 만들고 “고객 추가”를 위해 AddClient()를 만들고 그 내부에 실제 컨테이너의 기능을 넣는 “컨테이너 은닉화”를 이야기하자는 것은 아닙니다.
■ 너무나 많은 것을 고려해서 쓸모없어진 프로그램
주제가 비약되는 느낌도 들지만, 같은 문제 범위에서 다루어도 큰 문제는 없을 것 같습니다. 슈퍼 기차의 문제로 볼 수 있다고 생각합니다.
누구나 아는 “Simple is beautiful”이라는 만고불변의 진리도 이 사례 설명을 도와줄 것입니다.
명확한 요구 사항을 가지고도 팀을 이끌어서 소프트웨어를 만들기도 힘든 상황에서 미래의 기능이나 미래의 확장 또는 다른 도구임이 분명한 도구의 기능까지 고려한 프로그램을 만들려는 시도는 정말 쓸모없는 괴물을 만드는 일일 것입니다.
“그들은” 왜 간절히 “소박한 기능”을 원하는 고객을 생각하지 않을까요? 고객이 누구인지는 알까요?
■ 애플리케이션 (Application)을 라이브러리 (Library)처럼 사용하려는 그릇된 시도
삼겹살집으로 건축한 건물을 목욕탕으로 재 사용하기는 너무 막막한 일입니다.
요구사항이 바뀌면 애플리케이션이라는 것은 많은 수정을 요하고 때로는 새로 만드는 것이 좋을 것입니다.
하지만 이렇게 지극히 상식적인 것을 – 모르진 않을 것이지만 – 망각하고 애플리케이션을 재사용 또는 커스터마이징 (customizing)이라는 말을 오용해 마치 라이브러리 처럼 사용하려고 합니다.
이러한 강요는 순수하고 순진한 개발자들에게서 간결함과 최적화를 뺏어가는 것 같습니다.
제가 “역사에 남을 인물” 운운한 것은 최근 영화인 “어거스트 러쉬 (August Rush)”에 나오는 음악 천재 소년처럼 저의 이 모든 다소 주관적인 불평을 잠재워줄 만큼 천재적인 디자이너나 개발자도 있을 수 있기 때문입니다.
하지만, 과연 그런 사람이 얼마나 될까요?
오히려 천재에 가까운 사람들은 – 정말로 – 복잡하고 불필요한 많은 것을 고려하기보다는 간단하고 최적화된 것을 선택하는 것 같습니다.
VC++을 개발한 개발자들과 만나보세요. 오늘 저녁 6시30분
Oct 12
Programming ms, VC++, VC++ 개발자, 세미나 4 Comments
아래와 같이 VC++ 개발자가 한국에와서 세미나를 하는 군요..
어제 저희 회사에서도 했었는데 다른 회의가 있어서 못가서 아쉬워하고 있었는데,
역시 VC++ Team blog에도 소개가 되었네요.ㅜ.ㅜ 아 가고 싶어.
오늘 오후에하는데 멀어서 제 시간에 가지도 못할 거 같고…
시간 되시는 분들은 가면 좋을 것 같습니다.
Hello from Korea
아래 정보는 여기에서 자세히 볼 수 있습니다.
 |
 |
Ayman Shoukry(아이만 슈크리) Visual C++ 라이브러리 프로그램 매니저 팀장. VC++ 라이브러리 팀 운영 및 VC++ 비전 및 계획 |
|
|
|
 |
Ulzii Luvsanbat (율지 루브산바트) IDE에서 QA팀을 리드하면서 VC++ IDE QA를 지휘. |
대세는 이클립스 (Eclipse) 이냐!?? 그리고 맹목적이어야 하느냐?
Aug 31
Programming Eclipse, Java, mfc, RCP, win32, 개발 IDE, 이클립스 40 Comments
저는 작년 어느 즈음부터 이클립스 (Eclipse) 기반 vs MFC와의 갈등을 경험하게 되었습니다.
어찌 어찌 하다 개발 프로젝트의 언어 및 전체적인 방향을 결정에 큰 영향을 줄 위치에 있게되었습니다. 아무튼..
저는 주로 C/C++과 MFC에 익숙했고 (그래서 평범하겠죠?) 이클립스도 1년여 동안 IDE로 사용을 해본 경험도 있긴했습니다. 이클립스를 1년 정도 쓰다 다시 Visual Studio 환경으로 오니 황무지에 낙타 한마리와 동행하는 느낌이 들긴했지만 어느 새 적응이 되었습니다.
(그래도 STL와 code guru, code project, devpia가 있는데 왜 Rich한 Java가 부럽냐라고 반론을 제기하는 사람이었습니다)
어찌되었던 작년 가을 정도와 올해 초 그리고 지금 (세 번이군요) 이클립스 기반이냐 MFC와 Win32기반이냐로 의견이 분분하고 신중한 결정을 내려야 하는 계절이 있었고 지금도 그러고 있습니다.
이클립스 편 – Eclipse
단적으로 이클립스로 가야한다는 쪽의 주장을 들어보고 분석해보면 아래와 같습니다.
■ 막강한 Plugin Model과 RCP
손쉽게 Eclipse Plugin으로 component 기반 개발 (CBD)를 할 수 있음
(이 것은 단순히 DLL을 이용해서 잘 만든 윈도우즈 기반 프로그램을 훨 씬 뛰어넘는 수준이겠죠)
그리고 3.2부터인가 나온 RCP (Rich Client Platform)는 IBM의 같은 프로젝트인 OSGi Framework 위에서 환상적인 많은 것들을 제공하고 있습니다.
■ Rich Environment
수 많은 Powerful한 Plugin (TPTP나 여러 가지…)을 비록한 유용한 지원 도구를 사용할 수 있음
■ OS Indenpendent (including GUI throught JVM, SWT, JFace)
무엇보다도 OS Independent할 수 있음
(저희 과제는 다양한 OS환경을 고려해야 했습니다. 다양한 OS에 올라가야 하는 것은 아니었지만)
특히 SWT와 JFace의 Look and feel은 swing과는 비교도 할 수 없을 것입니다.
그리고 Eclipse의 배포 정책에는 여러 다양한 환경 (OS를 포함한)을 지원하고 있습니다.
의 이유로 주창을 했고
Win32 및 MFC
C/C++로 GUI가 있는 호스트 부분은 MFC와 Win32로 가야한다는 쪽의 주장과 분석을 들어보면 아래와 같습니다.
■ JVM이 필요 없음
최소한 윈도우만 고려한다면 JVM을 위해 JRE를 설치하지 않아도 된다
(이상한 나라의 엘리스 처럼 들릴 수도 있고 민감한 부분으로 인식할 수도 있는 문제인 것 같습니다)
※ 물론 VC6.0 이상은 .net framework을 설치해야하겠죠?
■ 빠르다
(Eclipse가 속도가 개선되었다고 하지만 JVM으로 여러 OS를 고려해야 하고 Windows 경우는 JNI를 통해서 system control을 해야 하며 Eclispe 및 Eclipse RCP (Rich Client Platform) 자체가 lazy binding이라 Win32와 MFC를 따라 올 수는 없습니다.
■ Eclipse로 간다면, JNI를 사용해야 하는 경우가 있다.
가끔 Win32 api를 이용해야 하는 경우 JNI를 이용해야 하는데, 이 것은 한 프로그램이 이질 언어도 작성됨으로써 디버깅이 힘들게 되고 Eclipse의 OS Independency를 잡는 경우도 있습니다.
(물론 linux로 간다면 JNI DLL의 내용을 porting하면 되겠죠)
■ 많은 것들을 핸들링할 수 있다.
흔히들 (GUI이든 engine이든) MFC와 Win32를 이용해서 (돌아가든, 바로가든) 불가능 한 것은 거의 없다 라고 합니다.
※ 하지만 이 것은 잘 생각해봐야할 문제인 것 같습니다. OS Independent하니 Eclipse 기반으로 가는 것은 어느 정도 한계를 가질 수 있습니다. 하지만, 정말 그렇게 인터페이스나 기능을 고쳐야하는게 맞는지 잘 생각해봐야 할 것입니다.
■ 유지 보수할 인력들이 더 많다.
저희 회사의 경우는 Eclipse 기반 개발자 보다는 아닌 개발자가 더 많았습니다.
※ 이 문제는 단순히 Java를 할 수 있는 인력이 아니겠죠? C++을 잘한다해도 MFC를 배워야겠지만 Eclipse는 더 많은 것을 (RCP 등을 제대로 사용하려면) 이해해야할 것입니다.
※ 위에서 거론한 것 보다 더 많은 장.단 점이 있을 것이고 거론 한 것들도 잘 못 될 수도 있을 것입니다.
그리고 위의 문제는 많은 논쟁점을 가지고 있고 어떤 프로젝트냐에 따라 장점이 단점으로 단점이 장점으로 변경될 것입니다.
중요한 것은 프로젝트 (개발한 소프트웨어?)에 무엇이 맞는지 (버릴 것과 얻을 것을 생각해서) 심사숙고해서 검토해야 할 것입니다.
단순히 많은 세계적인 소프트웨어 (JBuilder, OSGi, ClearQuest, 기존 C/C++을 위한 도구들도)들이 Eclipse 기반의 플러그인이나 RCP 모델로 간다고 해서 무작정 따라가는 것은 맞지 않을 것입니다.
![[iPhone][Tutorial #5] Http Request결과를 JSON으로 쉽게 파싱 해보기](http://alones.kr/wp-content/plugins/wordpress-popular-posts/no_thumb.jpg){kind=small}