개발일기/설계와디자인11 데이터 중심 프로그래밍 2008.06.28: 데이터 로직의 복잡함과 자료구조의 복잡함. 이 두가지 중 하나를 선택해야 한다면 무었을 선택해야 하나? Eric S. Raymond는 1%의 망설임도 없이 자료구조라고 말한다. 이것의 가장 간단한 예는 복잡한 변환 테이블과 복잡한 스위치 문이 될 수 있다. 자료 구조의 복잡함을 선택해야 하는 이유는 무었인가? 사람의 사고 자체가 제어 흐름을 처리하는 능력보다 데이터 구조를 머리속으로 그려내는 능력이 뛰어나다고 한다. 또한, 데이터에 대한 무결성을 검증하는 작업보다 아무리 간단한 로직이라도 완벽함을 검증해 내는 작업이 더 어렵다. 이는 또한 문제의 수준을 상위로 끌어 올리는 역할도 한다. 프로그래머는 되도록 작은 일을 하고 컴퓨터 에게 많은 작업을 시키도록 한다. 패치 작업 시 코드에.. 2008. 9. 29. 매커니즘과 정책을 분리하라 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 다음
