개발일기/설계와디자인10 매커니즘과 정책을 분리하라 2008.08.31: "Art of Unix Programming"을 보면 Unix의 철학을 언급하면서 "매커니즘과 정책을 분리하라(인터페이스와 엔진을 분리하라)" 는 말이 나온다. 이 원칙을 가장 잘 설명해 줄 수 있는 예가 "X Windows system"인데, X프로토콜을 이용한 서버 클라이언트 방식으로 X서버는 일반 그래픽 연산이나 입출력 만을 수행하고, 어플리케이션은 Xlib을 포장한 GTK나 QT 등의 X툴킷에 따라 달라질 수 있다. 매커니즘과 정책을 분리하는 큰 이유는 매커니즘은 오래 지속되지만 정책은 훨씬 빨리 변하기 때문이다. (그래픽 연산의 동작은 오래 지속되지만 툴킷의 유행은 빠르게 변한다.) 이 원칙을 적용한 최소한의 예를 보자. 다음 코드는 어떤 프로젝트에서 시스템 에러상황을 파악.. 2008. 9. 1. 내 자신에게 충고하는 설계지침 2008.08.24: 내 자신에게 충고하는 설계지침. 1. 설계 없이 코딩부터 하는 습관은 이제 그만할때도 되었다. : 머리속에 떠오른 아이디어를 바로 코드로 풀어내고 싶은 마음 안다. 하지만 이젠 노트와 팬을 잡자. 2. 처음부터 전체적인 flow를 다 고려하여 설계하자. : 구현 스케줄의 맨 처음은 첫번째로 구현해야 할 기능이 아니라 "전체 구조 설계" 이어야 할 것이다. 지역적인 기능만 보고 구현했다가 앞 뒤 flow와 연결이 쉽지않아 갈아엎은 기억을 잊지말자. 3. 처음부터 완벽한 설계를 하려 들지 마라. : customer의 요구사항은 언제나 변할 수 있고, 내가 spec.을 한번에 완벽분석 한다는 기적은 없다. 언제나 기능이 추가되고 확장될 수 있는 구조로 설계를 하라. Donald Knuth.. 2008. 8. 25. 이전 1 2 3 다음
