[Clean code] chapter 8. 경계

Overview

우리는 온전히 우리가 만든 코드를 통해서 어떤 프로그램을 만들지 않는다. 만약 외부에서 가져온 코드를 사용하게 되는 경우는 우리는 어떻게 대처해야될까요?

외부 코드 사용하기

외부 코드를 사용하게 되면 어쩔 수 없는 문제는 우리가 사용하지도 않을 기능들, 코드들을 나의 코드 내부로 들어오게 된다.

간단하게 Map을 보게 되더라도 keySet(), contain() 이런 메소드들은 우리가 사용하지 않는다는게 명확하더라도 우리는 그 코드 모두를 가지고 와야한다.

그것말고 사용하는데 있어서 좋은 팁으로는 Map을 예시로 했을 경우 get를 했을 경우 지속적으로 많은 변경이 요구하는 경우가 많아 그것을 막기 위해서 클래스 내부에서 변환하는 코드를 사용하면 (래핑)을 했을 때 나중에 수정에 큰 장점이 있다.

경계 살피고 익히기

우리는 많은 경우 우리가 작성하지 않은 외부 코드를 통해서 개발을 진행한다. 그것을 통해서 더 빠른 결과물을 만들 수 있기 때문이다.

외부 패키지 테스트에 대해서는 우리가 책임을 가지고 있지 않다. 하지만 우리 자신을 위해 우리가 사용할 코드를 테스트하는 편이 바람직하다.

해당 라이브러리를 공부하고 적용했을 때 우리 코드 문제인지 라이브러리 문제인지 찾아내느리 굉장히 힘들 수 있다.

그것에 대한 방법으로 학습 테스트라는 것을 해보자. 외부 코드를 익히고 통합하기는 어려우니 바로 우리 코드에 외부 코드를 적용시키는 것이 아닌 간단한 테스트 코드를 통해서 외부 코드를 익히는 방법이다.

실제 책에는 log4j를 활용해서 설명했다. 튜토리얼을 따라하다가 안되면 이유를 찾고 지속적으로 사용해보고 테스트해보고 공부하는 방식으로 진행한다. 그 과정의 마무리는 해당 라이브러리를 테스트하는 코드를 작성하는 것이다.

학습 테스트는 공짜 이상이다.

어차피 우리는 해당 API를 배워야 한다. 오히려 필요한 지식만을 빠르게 얻을 수 있는 방법이다.

학습 테스트는 공짜 이상인 것은 투자하는 것에 비해 노력이 적고 심지어 패키지에 새로운 버전이 나온다고 해도 학습 테스트를 톨려 차이가 있는지 확인할 수 있다.

새 버전으로 업데이트하는 것은 위험이 있는 행동이다. 바뀐 패키지(버전)이 이전 메소드를 지원하지 않을 수도, 혹은 다르게 동작하게 만들 수도 있다. 그러기 때문에 이런 학습 테스트는 우리가 사용하는 라이브러리에 대한 보증을 해준다.

아직 존재하지 않는 코드를 사용하기

같이 협업을 진행하는 과정에서 내가 해야되는 코드와 다른 사람이 해야되는 코드를 분리하고 그것을 통해서 테스트를 진행할 수 있다.

그 뿐만 아니라 Adapter 패턴을 이용해서 변경이 있을 때를 대비하도록 하면 추후 리팩토링 과정에서 큰 어려움이 없다.

깨끗한 경계

경계에서는 흥미로운 일이 많이 벌어진다. 변경이 대표적인 예다.

좋은 설계로 만들어진 소프트웨어는 변경에 있어서 엄청난 시간과 노력이 필요하지 않다. 통제하지 못하는 코드를 사용할 때는 경계를 확실히 하는 것이 좋다. 또한 기대치를 정의하는 테스트 케이스를 작성한다.

만약 외부 코드를 통제하지 못하는 경우는 사용하지 않는 것이 오히려 더 좋을 수 있다. 그것을 통한 주기적인 변경이 소프트웨어에 더욱 안좋은 영향을 줄 것이다.

외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자. 새로운 클래스로 경계를 감싸거나 Adapter 패턴을 이용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자.

key point

• 외부 코드를 사용할 때는 경계를 명확하게 해야한다.
• 변경에 대해서 항상 조심하고 경계해야 한다.

궁금한 점

마무리

외부 코드를 사용하지 않을 것이라는 생각을 해본 적이 없다. 항상 외부 코드를 사용을 기반으로 생각했다.

하지만 중간에 해당 부분을 바꿔야 한다면 분명히 큰 변경이 있어야 된다. 그런 부분에 대해서 좋은 방법을 배운 것 같다.

그리고 라이브러리에 대한 테스트는 정말 좋은 방법인 것 같다.