리팩토링 스터디 #8 - API 구조 개선하기

8주차 리팩토링에서는 방법과 API의 구조를 개선하는 방법에 대한 내용을 진행했습니다. 책에 실려있던 내용은 리팩토링 스터디 #7.5 - 내용 미리보기를 참고해주세요.

 

 

실제로도 자주 쓰이는 기법?

10.5절의 특이 케이스 진행하기의 경우엔 이전에 진행된 객체지향 스터디에서 널 객체 패턴(null object pattern)이라는 이름으로 언급된 적이 있었다고 합니다. 현재 스터디를 리팩토링 2판으로 진행중인데, 1판의 본문에서는 실제로 이런 이름으로 쓰여져 있었다고 하네요. 사례를 기반으로 지어진 기존의 이름과 달리 지금은 특징을 기반으로 한 직관적인 이름으로 바뀐 모습입니다. 이 기법이 잘 이해되지 않으면 객체지향의 개념 쪽을 다시 한 번 살펴보는게 좋을 것 같습니다.

 

마침 스터디를 함께 진행하시던 분 중 최근에 코드리뷰를 하시며 이 리팩토링을 적용시킨 사례가 있었습니다. 그만큼 실제로도 많이 쓰인다고 보아도 되겠네요. 저도 앞으로 수 많은 코드들을 보게될텐데, 코드를 리뷰하는 입장이라면 언제든 이 기법은 머리속에 염두하고 있어야겠습니다.

 

 

어서션(assertion)에 대한 이야기도 있었습니다. 보통 코드를 설명하기 위해선 주석을 많이 사용하는데, 본문에서 설명하는 어서션을 이용한 방법은 다소 생소해보였기에 실제로도 쓰이는지 궁금했습니다.

 

Q. 어서션을 코드를 설명하는 용도로 실제로 쓰이는지?

A1. 책에서 설명하는 것처럼 코드 본문에 assertion을 넣어서 사용하는 것은 아직까지는 못 본 것 같고, spring security 쪽에서는 본 것 같다. 테스트 코드에서는 사용해 본 적이있다.

A2. 아직까진 본 적이 없다. 테스트 코드 느낌으로 사용하는 경우라면 throw { ... } err { ... } 형식의 guard형을 사용하였다.

A1. 어서션은 절대 일어날 수 없는, 로직상의 치명적인 오류의 여부를 검출할 수 있는 코드이다. 혹시 모를 실패에 대비하는 guard형과는 다른 경우인데 둘의 사용처에 대한 차이를 알아두면 좋다.

분명히 어서션은 표현력을 높여주기 위한 개발자를 위한 도구라는 점에서 매력있는 방법 중 하나임이 틀림 없지만, 흔하게 사용되는 방식은 분명히 아닙니다. 사용하기 전 팀원들과 충분히 논의를 한 후 코드 컨벤션을 정립하고 나서 사용하는 것이 좋겠습니다.

 

 

코딩 스타일이 다를 때 

 
본문에서 언급되던 제어 플래그를 통한 함수 컨트롤은 사람의 실수 (human fault) 를 만들 위험이 있습니다. 예를 들어 제대로 안 닫은 플래그 때문에 이곳 저곳에서 들어온 요청을 처리하다 그대로 뻗어버리는 동시성 문제가 발생할수도 있죠. 당장의 동시성 문제뿐만 아니라 나중에 시간과 노력을 더 많이 들여야하는 큰 버그로 이어질 가능성이 높으니 최대한 사용을 지양하는 것이 좋다는 것이 공통된 의견이었습니다.

이 챕터에서 한 가지 재미있던 건 return 문에 대한 이야기였는데, 스터디원들 모두 책에서 권장하는대로 return 문을 통한 함수 제어에 긍정적인 반응을 보였지만 책에서 언급했던 '함수 안에 여러개의 return이 보이는걸 싫어하는 사람' 과 함께 프로그래밍을 해야 한다면 어떨까요? 팀의 코드 컨벤션은 통일해야하지만, 함수 제어의 방법은 개인 취향인만큼 장단점이 분명히 존재할텐데 리팩토링을 하겠답시고 이러한 구조를 싹 바꿔버린다면 혼란이 올 수 있겠죠. 의사소통을 통해 적당한 합의점을 찾아 개발해야 할 것 같은데, 전 아직까지 코드 스타일이 크게 차이나는 사람을 만나본 적이 없어 이런 문제를 경험해 본 적은 없네요. 어찌되었든, 결국 소통을 통한 해결이 베스트인 것 같습니다.

 

 

적극적인 의사소통을 통해 슬기롭게 헤쳐 나가봅시다.

 

 

○○○가 무엇인가요?

스터디가 진행되던 도중, API가 무엇일까? 라는 질문이 던져졌습니다. 스터디원들 대부분이 어디서건 API라는 말을 들어보고, 직접 사용해왔던 사람들이었지만 저를 포함한 상대적으로 경험이 적은 학부생들은 막상 API에 대해 물어보았을때 명확하게 답변하기가 어려워하는 모습이었습니다. 머릿속의 키워드들을 조합하여 70~80점의 답변은 내놓을 수 있었지만 100점이라고 하기엔 살짝 모자란 감이 있었네요.

 

Q. API가 뭘까요?
A1. 통신할때 쓰는 명세 같은거...
A2. 서버와의 통신.. 을 할때 서로 주고받는 통신의 규약? 아닐까요.

Q. 그럼 서버랑 통신할때만 API를 사용할까요? window API 같은것도 있는데.

 

나중에 면접등을 대비해서라도 이런식의 용어들을 묻는 질문에 자신있게 답할 수 있으려면 본인의 언어로 설명할 수 있도록 연습을 해두는 것이 좋다고 합니다. 나만의 개발 용어 사전을 만들어서 스쳐가는 용어들을 정의해보고, 꺼내서 설명해보는 과정들을 거쳐야 내가 사용할 수 있는 지식이 될 수 있겠죠?

"API는 프로그램을 어떻게 사용할지 나타낸 명세이다" 정도로 설명하면 개념들을 포함할 수 있겠네요. 아니면 책에서 설명하는 방식대로 이야기 하는 것도 훌륭한 방법입니다.

 

모듈과 함수는 소프트웨어를 구성하는 빌딩 블록이고, API는 이 블록들을 어떻게 끼워맞출지 결정하는 연결부이다.

 

 

 

관계설정의 책임

매개변수를 질의 함수로 바꾸기 ↔ 질의 함수를 매개변수로 바꾸기의 기법들을 적용하는 근거는 '책임을 누구에게 줄 것 인가'입니다. 상태를 변경하고 관리하는 주체를 설정해주는 것을 관계설정의 책임을 부여한다고 합니다. 의존성을 가볍고 단순하게 가져가며, 외부의 변화에 유연하게 대처할 수 있도록 하기 위해 '누구에게 책임을 주고 해당 기능을 관리할 것인지 정해주는 것' 으로 java 프레임워크인 spring이 수행하는 가장 큰 기능 중 하나이기도 합니다.

 

안타깝게도 자바스크립트는 해당 기능을 수행해주는 프레임워크가 따로 없기 때문에, 프로그래머가 직접 이를 설정해줘야합니다. 그 결과로 서로 의존성도 생기게 되고, 누구에게 무엇을 줄 것인지에 대한 근거 또한 사실상 프로그래머의 경험에 의존해야 하기 때문에 상당히 어려운 부분입니다.

 

이 부분은 어떤 상황에서 어떤 방법을 사용하는 것이 좋을지 딱 떠오르는 예시나 감이 거의 없었습니다. 프로젝트 경험이 더 쌓이고 나서야 조금씩 보일 것 같네요. 

 

 

 

 

리팩토링 기법들을 모두 공부한 뒤에는, 저번에 언급했던 Axis 라이브러리 중 한 파일을 직접 리팩토링 해보는 시간이 있었습니다. 공부한 기법들을 직접 사용해 볼 수 있었고, 개발자들이 어떤 의도로 코드를 작성했는지 엿볼 수 있었던 어느때보다도 알찬 스터디 시간이었습니다. 다음 스터디에서도 직접 리팩토링을 진행해 볼 계획입니다.

 

#8.5에서 계속됩니다.