겐 도 사마 의 재림 : : 주석 은 쓸모없 는 것 2 
 주석 은 쓸모없 는 것 2 
 Posted 2006 / 07 / 24 11 : 25 
 " 주석 은 쓸모 없 는 것 " http : / / process . kaist . ac . kr / ~ gendoh / blog / 18 이란 글 을 작년 에 썼 는데 http : / / kaistizen . net / EE / index . php / weblog / benefits _ of _ documatation _ tools / 글 을 또 발견 하 게 되 서 좀 더 보충 . 
 OOPL ( Object - Oriented Programming Language ) 들 이 Method 혹은 포괄 적 인 의미 의 Property ( 최근 언어 들 은 Member function 과 Member variable 의 구분 이 점점 사라져 간다 ) 에 대한 Polymorphism 을 지원 하 는 과정 들 을 볼 때 나름 대로 내린 결론 . 
 운영 체제 를 만들 거나 새로운 언어 를 만드 는 케이스 가 아니 라면 주석 따윈 필요 없 도록 디자인 할 것 . 
 코드 가 바로 주석 인 정도 가 아니 라 아예 그런 것 조 차 도 필요 없 도록 Abstraction 을 잘 해야 한다는 것 이 지론 이 다 . 
 MFC ( Microsoft Faoundation Class ) 의 훌륭 한 점 중 하나 로 전반 적 인 사용 의 통일성 과 부모 가 동일 한 클래스 는 대충 집 어 던지 면 잘 동작 한다는 것 을 들 수 있 다 . 통일성 이 라고 한다면 객체 는 모두 " 생성 - 초기 화 - 사용 - 파괴 " 의 구조 를 지키 고 있 기 때문 에 새로운 클래스 를 가져와 쓸 때 도 특별 한 케이스 를 제외 하 곤 기존 의 쓰 던 가락 대로 코드 를 생성 할 수 있 다 . 특히 파괴 부분 은 AutoDestroy 를 지원 하 기 때문 에 집 어 넣 고 나 면 신경 쓰 지 않 아도 되 는 케이스 가 많 다 . ( 물론 조금 만 잘못 디자인 해도 AD 를 쓰 지 못하 고 수동 파괴 를 해 줘야 하 는 케이스 가 생기 긴 하 지만 . . 뭐 양쪽 다 문제 ) 더불 어 Abstraction 의 도움 으로 부모 클래스 의 virtual function 을 이용 , 비슷 한 놈 들 은 쉽 게 집 어 던질 수 있 고 그 틀 만 벗어나 지 않 으면 새로운 클래스 도 그대로 들어간다는 점 이 다 . 이 는 최근 의 언어 들 로 와서 는 구지 부모 가 같 을 필요 도 없 고 몇 개 의 조건 만 만족 시키 면 쉽 게 된다 . ( iteration 을 비교 해 보 면 느낄 수 있 다 . Ruby 정도 되 면 매니악 하 다 ㄱ -) 
 사용자 에 대한 User Interface 를 디자인 할 때 일관 성 도 중요 하 여 메뉴 하나 를 사용 하 는 학습 을 하 게 되 면 그 가락 으로 나머지 기능 도 비슷 하 게 사용 할 수 있 도록 하 는 것 이 좋 다고 한다 . 이 는 프로그래머 에 대한 인터페이스 에 대해서 도 동일 할 것 이 다 . 함수 마다 일일이 설명 이 있 는 것 이 아니 라 A 4 한장정 도 되 는 문서 에 라이브러리 사용 하 는 방법 과 전반 적 인 구동 메커니즘 만 설명 하 면 각 함수 들 을 예상 되 는 대로 사용 가능 토록 디자인 되 도록 하 는 것 이 좋 을 것 이 다 . 
 어떤 객체 이 든 " 생성 - 초기 화 - 동작 - 파괴 " 의 일관 된 사용 과정 을 가지 고 다른 객체 를 받 아 들여야 하 는 경우 그것 이 무엇 이 든 알 아서 구겨 넣 어 들어가 게 디자인 하 는 것 이 다 . 가령 ChangeCustomerName 이 란 함수 를 제공 하 는 케이스 라면 Customer 객체 를 Assign 하 는 것 으로 이 를 대체 할 수 있 고 근본 적 으로 새로운 Customer 의 생 성 이나 각 프로 퍼티 의 변경 을 Assign 으로 단일 화 할 수 있 다 . Data 를 직접 들 고 있 는 객체 입장 에선 받아들인 Customer 객체 를 어떻게 핸들 링 해야 하 는지 Determin 할 수 있 기 때문 이 다 ( 할 수 있 게 디자인 해야 한다 가 정확 할 듯 ) . Assign Operator 혹은 Function 에서 Polymorphism 을 이용 하 거나 데이터 에 대한 추상화 를 통해 나누 어 진 여러 기능 을 쉽 게 하나 의 방법 으로 구현 가능 할 것 이 다 . Add 와 Update 가 다른 것 처럼 보여도 개념 에 따라서 는 동일 하 게 볼 수 도 있 다 . 디자인 의 차이 다 . 
 처음 에 API 에 대해선 예외 를 적용 했 는데 그 이유 는 당연 하 다 . 그런 것 은 낮 은 레벨 이 기 때문 이 다 . GendohSQL DBMS 를 만들 고 이것 을 접근 하 는 Low API 를 제공 하 려면 당연히 메뉴 얼 을 두껍 게 만들 어야 할 것 이 다 . Exception 설명 에 만 도 Appendix 를 따로 할애 해야 할지 도 모른다 . 허나 ADO 혹은 더 높 은 수준 의 모델 을 제공 한다면 당연히 간단 한 샘플 로 끝낼 수 있 어야 한다 . 이 는 인터페이스 의 일관 성 은 물론 이 고 예외 상황 이 발생 하 여 프로그래머 를 괴롭히 는 것 이 아니 라 알 아서 그것 이 처리 되 어야 하 고 ( 밖 으로 는 차이 가 없 어야 한다 ) 사용법 이 단순 해야 한다는 점 등등 을 요구 할 것 이 다 . 
 전자 렌지 의 경우 사용 설명서 없이 도 많 은 사람 들 이 잘 쓴다 . 30 초 를 돌리 든 5 분 을 돌리 든 사용 방법 이 동일 하 기 때문 이 다 . 그리고 그 방법 이 직관 적 이 다 . 가장 중요 한 점 은 , 음식물 이 핫 바든 햄버거 든 사용 방법 이 달라지 지 는 않 는다 . 한 병사 의 죽음 으로 개발 된 , 매우 어려운 물리 적 현상 으로 개발 된 전자 렌지 가 가정 마다 보급 된 이유라 할 수 있 다 . 
 2006 / 07 / 24 11 : 25 2006 / 07 / 24 11 : 25 
 Tag 주석 
 https : / / www . gendoh . net / atom / trackback / 187 
 DRY 법칙 - 주석 을 아껴라 
 2006 / 07 / 24 15 : 57