ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [프로그래머] API설계의 황금 비율
    97가지 시리즈/프로그래머 2018.11.02 18:07

    #프로그래머가_알아야_할_97가지 vol.34

    API설계의 황금 비율 by. Michael Feathers


    API의 설계는 간단하지 않습니다. 규모가 크면 클수록 더 어렵습니다. 몇백, 몇천의 사용자가 동시에 사용하는 경우에는 앞으로 API에 더해질 변경까지 고려해야 합니다. 변경했을 때 그 영향으로 API를 이용하는 클라이언트 코드가 돌아가지 않게 된다면 정말 곤란하기 때문입니다. 반대로 사용자가 API에 끼치는 영향도 고려해야 합니다. 예를 들어 API를 구성하는 클래스 내부에서 메소드를 호출할 때 사용자가 그 클래스를 상속하는 서브 클래스를 만들어 메소드를 오버라이드하려고 하는 것도 고려해야 합니다. API의 개발자는 이제 그 메소드를 수정할 수 없습니다. 사용자가 독자적으로 그 메소드에 원래와는 다른 의미를 부여해 버렸기 때문입니다. 이처럼 사용자의 사용법에 따라 향후 개발 방식에 제약이 생길 수도 있습니다.


    이런 종류의 문제가 일어나지 않도록 하는 방법이 몇 가지가 있습니다. 가장 간단한 방법은 API를 잠그는 방법입니다. Java라면 클래스나 메소드의 대부분을 final 로 선언해 버리면 됩니다. C#이라면 클래스나 메소드를 sealed로 선언합니다. 언어를 불문하고 어쨌든 API를 싱글톤 혹은 스태틱 팩토리 메소드로만 구성하고, 사용자가 그 동작을 오버라이드 할 수 없게 해 버릴 수도 있습니다. 그러면 사용자의 사용법에 따라서 개발 방향이 제한되는 사태는 막을 수 있습니다. 이렇게 일단 문제는 해결되겠지만, 이걸로 정말 문제가 해결되었다고 말할 수 있을까요?


    개발 작업에서 유닛 테스트의 중요성은 과거 10년 사이에 두드러지고 있습니다. 하지만 아직도 인식이 충분히 퍼졌다고 할 수 없습니다. 그 증거는 여기저기에서 발견됩니다. 시험 삼아 서드 파티 중에 API를 이용하면서 테스트가 끝나지 않은 클래스가 있다면 그 클래스에 맞춰 유닛 테스트를 작성해보면 알 수 있습니다. 십중팔구 문제가 생길 겁니다. 문제가 일어나는 부분은 아마 API를 이용하는 부분이겠지요. 풀이 뭍은 종이가 아무 곳에나 달라붙는 것처럼, 대부분 API를 이용하는 곳에서 문제가 발생할 겁니다. API 클래스에 메소드인 하는 테스트용 메소드가 없어서 자신의 코드가 API와 어떤 정보를 주고받는지를 검출하지 못하고 또 테스트에 필요한 API의 반환 값도 처리할 수가 없습니다.


    이러한 상황도 언젠가는 개선될지도 모르겠습니다. 그러기 위해서는 모두가 API의 설계를 할 때, 테스트를 UseCase 중 하나로 상정해야 합니다. 사실 안타깝게도 자신이 쓴 코드를 테스트하는 것보다 훨씬 어려울 겁니다. API를 제공할 때는 API 자체 테스트뿐 아니라, 반드시 그 API를 이용하는 코드에 대한 유닛 테스트도 쓰도록 API의 설계자는 이 황금비율을 지켜주었으면 합니다. 이 황금비율을 지키면 API를 이용하는 사람이 유닛 테스트를 할 때 어떠한 문제에 직면할지를 사전에 감지할 수 있게 됩니다.


    API를 개발할 때 이 부분을 고려해주면, API 사용자는 간단히 유닛 테스트를 할 수 있게 됩니다. 간단히 static, final, sealed 로 선언하는 방법도 때에 따라서는 유효하기도 합니다. 그러나 정말 중요한 것은 먼저 API를 개발하는 사람이 API를 이용한 코드의 유닛 테스트는 어렵다는 걸 인식하는 것이 필요합니다. 그러기 위해서는 그 어려움을 직접 체험해보는 것이 최선입니다. 한번 겪어보면 테스트의 어려움을 설계상의 과제 중 하나로 인식하고 다른 과제와 동급으로 고려하게 될 것입니다.


    저자: Michael Feathers

    Object Mentor International 의 컨설턴트.

    JUnit의 C++이식판인 CppUnit, Fit통합 테스트 프레임워크의 C++이식판인 FitCpp을 개발.

    'Working Effectively with Legacy Code(레거시 코드 개선 가이드)'의 저자.


    [프로그래머] API설계의 황금 비율


    [출처] プログラマが知るべき97のこと (O'Reilly Japan)

    이 글은 [CC-by-3.0-US]에 의해 라이센스 되었습니다.




    댓글 0

Designed by Tistory.