[클린 코드] 8장 - 경계

 

제목에서 무슨 내용인지 유추하기 가장 힘들었던 챕터였어요. 개발을 하며 때로는 패키지를 구매하고, 또 오픈 소스를 이용하는 경우가 많아요. 사내 다른 팀이 제공하는 컴포넌트를 사용하기도 해요. 이 챕터는 소프트웨어 경계를 깔끔하게 처리하는 기법과 기교를 살펴봐요.

 

1. 외부 코드 사용하기

패키지나 프레임워크 제공자는 적용성을 최대한 넓히려 애써요. 더 많은 환경에서 돌아가야 더 많은 고객이 구매하기 때문이에요. 반면에 사용자는 자신의 요구에 집중하는 인터페이스를 바라요. 이 차이 때문에 문제가 생길 소지가 많아요.

 

2. 경계 살피고 익히기

외부에서 가져온 패키지를 사용하고 싶다면 어디서 어떻게 시작해야 좋을까요? 

곧바로 우리 쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히면 어떨까요?

이것을 Jim Newkirk는 학습 테스트라고 명명했어요. 

학습 테스트는 프로그램에서 사용하려는 방식대로 외부 API를 호출해요. 통제된 환경에서 API를 제대로 이해하는지를 확인해요.

 

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

학습 테스트에 드는 비용은 없어요. API를 학습하기 위한 시간은 어차피 필요하기 때문이에요. 오히려 필요한 지식만 확보하는 손쉬운 방법이에요. 투자하려는 노력보다 얻는 성과가 더 커요.

 

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

경계와 관련해 또 다른 유형은 아는 코드와 모르는 코드를 분리하는 경계예요. 때로는 우리 지식이 경계를 너머 미치지 못하는 코드 영역도 있어요. 이런 경우 더 이상 내다보지 않기로 결정하는 경우가 있어요.

 

나의 생각: 현업에서 DifferenceKit이 적용된 코드를 DeepDiff로 변경하는 마이그레이션 작업을 수행한 적이 있어요. 두 라이브러리 모두 어떤 자료의 변경점을 비교해서 찾아내는 역할을 해요. 그런데 그 내부 로직은 Wagner-Fisher의 수학적 알고리즘이 들어가 있었어요. 하지만 작업의 포인트가 이 알고리즘을 완전히 이해하는 게 아니라 어떻게 작동하는지, 또 어떻게 구현하는지였기 때문에 알고리즘을 파고들어 이해하지는 않았어요. 이런 경우가 더 이상 내다보지 않기로 결정하는 경우라고 이해했어요.

 

5. 깨끗한 경계

소프트웨어 설계가 우수하다면 변경하는데 많은 투자와 재작업이 필요하지 않아요. 엄청난 시간과 노력과 재작업을 요구하지 않아요.

 

나의 생각

이번 챕터는 크게 와닿지는 않았어요. 예시로 나온 Java 코드의 상황이 제가 했던 경험에서 비슷한 경우는 없다고 느꼈어요. 그래서 이 부분은 우리 팀이 직접 구현하는 부분 vs 외부에서 가져온 코드를 연결하는 그 경계를 깔끔하게 만드는 법으로 이해하는 정도로 마무리했어요.

그래도 와닿았던 부분은 외부에서 가져오는 코드를 학습할 때 단순히 학습하기보다 학습 테스트를 먼저 하는 것이 좋다는 부분이에요. 특히 현업에서 처음 보는 라이브러리를 활용해야 할 경우가 많았는데 이제 학습 테스트를 통해 외부 코드를 습득하면 좋을 것 같아요.

 

 

클린코드(Clean Code) by Robert.C.Martin