Search Results for 'API'

2 POSTS

  1. 2007.09.18 디자인 시 고려할 점. (4)
  2. 2007.08.30 프레임워크와 개발자의 상상력 (10)

디자인 시 고려할 점.

Posted 2007.09.18 04:27

모듈이 할 수 있는 일을 클라이언트가 하게 하지 말아야 한다.

사용자가 단순 반복되는 코드(boilerplate code)를 작성하지 않도록 해야 한다. 반복되는 코드는 주로 잘라 붙이기(cut-and-paste)를 통해 구현되며, 이렇게 작성된 코드는 실수를 범하기가 쉽다. 따라서 API를 사용해 여러 유스 케이스를 구현해보고, 동일한 코드가 반복된다면 해당 코드를 API 안으로 집어넣어서 사용자가 쉽게 사용할 수 있어야 한다.

사용자가 놀라게 하지 말아야 한다(The Principle of Least Astonishment).

API는 사용자가 예상치 못했던 행동을 해서 놀라게 하는 일이 없어야 한다. 대표적인 예가 Thread 클래스에서 interrupted() 메서드를 불렀을 때 인터럽트 되었는지 여부를 리턴할 뿐만 아니라, 인터럽트 플래그를 클리어시키는 것이다. interrupted() 메서드 이름만 봤을 때는 이진 플래그를 리턴하는 간단한 질의 메서드를 떠올리게 되는데, 사용자가 예상치 못하게 플래그를 클리어하는 부작용이 있다. 이 메서드가 하는 중요한 역할은 인터럽트 플래그를 리턴하는 것이 아니라 인터럽트 플러그를 클리어하는 데 있으므로, clearInterrupt()라고 명명하는 것이 나았을 것이다.

빨리 실패해야 한다.

문제가 있으면 최대한 빨리 발견되는 것이 좋다. 타입 검사를 통해 컴파일 타임에 발견되면 제일 좋고, 런타임의 경우 잘못된 메서드가 호출되었을 때 즉시 이상이 있음을 알리는 것이 좋다. 문제가 중첩되고 있는데, 나중에서야 알려주면 문제가 시작된 지점이 언제인지 찾기가 어려워진다. 결국 디버깅이 불가능해진다.


역시 마소 원고 쓰다가 남은 부분입니다. 전체 리스트는 아니고 고려해야할 사항 중에 일부입니다.

신고
요즘은 프레임워크 없는 개발은 상상하기 힘든 세상이 되어 버렸습니다. 예를 들어 웹 개발을 한다고 하면 프로젝트의 성격에 따라 J2EE 급의 프레임워크를 쓸 것인지 Django나 Ruby on Rails처럼 간단한 프레임워크를 사용할 것인지 결정하는 일이 제일 중요합니다. 그리고 이렇게 결정된 프레임워크를 습득하고 사용하는 일이 프로젝트의 대부분을 차지하고 있습니다.

오늘 Artima.com을 보니 Overstock.com의 Chris Maki와의 인터뷰가 Do Frameworks and APIs Limit Developers' Imagination? 라는 제목으로 올라왔던데, 결론은 제목 그대로입니다. 프레임워크가 생산성을 비약적으로 발전시켜 주기는 했지만, 프로그래머의 상상력을 제한하는 부정적인 측면도 있다는 것이죠. 복잡한 것 생각할 필요 없이 프레임워크가 다 해주니깐 편하긴 한데, 프레임워크에 익숙해질수록 내가 하는 일이 없다는 생각이 드는 게 문제입니다.

신고

티스토리 툴바