[Clean Code 정리] 경계

Clean Code - 경계

 

1. 개요

- 우리는 가끔 서드 파티 패키지나 오픈 소스를 사용해야될 상황 또는 회사 내부 팀이 만든 컴포넌트를 사용해야할 상황에 마주한다.

- 우리는 이러한 코드를 우리가 개발하고 있는 내부 코드와 안전하게 통합시켜야 한다.

- 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교가 중요하다.

 

 

 

2. 외부 코드 사용하기

- 인터페이스를 제공하는 입장과 사용하는 입장 사이에는 필연적인 긴장감이 존재한다.

- 제공하는 입장에서는 좀 더 다양한 환경에서 좀 더 많은 사용자가 사용할 수 있도록 다양한 사용성을 지향한다.

- 사용하는 입장에서는 그들의 사용성에 맞는 Specific한 인터페이스를 원한다.

- 이것을 '경계에서의 긴장'이라고 부른다.

 

 

 

1) Bad Case

class EUVEquipment():
    ...

class Client():
    ...
    def some_function(self):
        euvs = dict()
        
        euvs["euv_1"] = EUVEquipment()
        euvs["euv_2"] = EUVEquipment()
        
        # 실수로 삭제
        del(euvs["euv_1"])

- 비즈니스 로직상 한번 등록된 EUV 설비는 삭제될 수 없다는 조건이 있다고 가정하자.

- 하지만 사용하는 클래스(dictionary)는 삭제라는 메서드를 제공하고, 개발자가 실수로 삭제라는 기능을 사용할 수 있다.

 

 

 

2) Good Case

class EUVEquipment():
    ...

class EUVEquipments():
    def __init__(self):
        self.__euvs = dict()

    def add(self, equipment_id):
        self.__euvs[equipment_id] = EUVEquipment()

    ...

class Client():
    ...
    def some_function(self):
        euvs = EUVEquipments()
        euvs.add("euv_1")
        euvs.add("euv_2")
        
        # 삭제 기능은 사용할 수 없음

 

 

 

3. 학습 테스트(Learning Test)는 값어치를 한다.

- 학습 테스트에 드는 비용은 없다.

- 필요한 지식만 확보하는 손쉬운 방법이다.

- 학습 테스트는 코드 이해도를 높여주는 정확한 실험이다.

- 메인 로직에 영향을 주지 않으면서 서드 파티 코드를 이해할 수 있다.

- 서드 파티 코드가 바뀔 경우 Learning Test를 돌려 우리가 제공하는 기능이 정상적으로 동작하는지 확인할 수 있다.

- Learning Test 여부와 관계 없이, 경계 테스트는 새 버전으로의 이전에 도움을 준다.

 

 

 

4. Clean한 경계

- 좋은 소프트웨어 디자인은 변경이 생길 경우 많은 재작업 없이 변경을 반영할 수 있는 디자인이다.

- 우리 내부 코드가 서드 파티 코드를 많이 알지 못하도록 막아야 한다.

- 우리가 컨트롤할 수 있는 것에 의지하는게 그렇지 않는 것(서드 파티 코드)에 의지하는 것보다 낫다.

- 래핑, 어댑터 패턴 등을 사용해 경계 인터페이스를 일관되게 유지해야 써드 파티 개발자 입장에서도 변경에 유연하게 대응할 수 있다.

 

 

 

5. Adapter 디자인 패턴

- 이미 제공되어 있는 것과 필요한 것의 차이를 없애주는 디자인 패턴이다.

- 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환한다.

- 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 사용할 수 있다.

- Wrapping 패턴이라고 부르기도 한다.