[네이버 부스트캠프] 멤버십 1 ~ 4주차 회고록

개요

부스트캠프에는 베이직 → 챌린지 → 멤버십, 총 3가지 단계가 있다.

지난 글에서 2단계 과정인 챌린지를 수료한 내용에 대해 담았는데,

현재 나는 챌린지를 수료하고, 멤버십 입과에 성공하여 최종 3단계를 진행하고 있다.

 

오늘은 네이버 커넥트재단의 부스트캠프 멤버십 과정을 시작한 지 벌써 4주차가 끝나는 금요일 밤이다.

지난 1 ~ 4주차 간의 과정을 담아보겠다.

 

---

학습 내용

확장성을 생각하며 프로그래밍하기

미션은 챌린지와 달리 하루 단위가 아닌, 2주 단위이다.

깃허브를 통해 1일 1PR을 보내고 팀원들의 PR을 보며 피드백을 하는 시간을 가진다.

 

매주 월요일마다 1주일에 대한 미션을 공개하기 때문에

미션을 시작하는 첫 주에는 다음 주에 어떤 미션이 나올지 모르므로 확장성을 염두에 두고 코드 작성을 해야한다.

 

첫 1~2주는 스토리보드 작업이었고 UI와 관련한 부분이 많아서 모델을 대충대충 작성했다.

미션의 규모가 작아서 모델을 간단하게 해도 미션을 구현함에는 어려움이 없었다.

그러나, 마스터클래스 수업을 듣고 코드를 잘 작성하는 팀원들의 모델간의 의존성을 보니 나의 코드는 강한 결합도와 높은 의존성을 갖고 있었다.

 

상위 계층은 추상적으로 작성을 하고, 하위 계층은 구체적으로 작성을 한다.

또한, 상위에서 일하는 것이 아닌, 하위 계층이 일을 하는 구조로 만들어 피라미드 형태가 되어야 한다.

 

이 내용을 듣고 내 코드를 다시보니

나는 아무 생각없이 코드를 작성해서 상위 계층인 클래스에서 데이터를 처리하고, 하위 계층에 알려주고 있었다.

조영호 - 객체지향의 사실과 오해 에서 언급하는 “엘리스 원더랜드”에서도 엘리스가 일을 하고, 하위 계층에 보고하면 안되는데 딱 내가 그런 상황이었다.

 

---

추상화의 힘

3-4주차에서는 지난 번의 미션과 같이 멍청한 행동을 하지 않기로 했다.

코드를 작성할 때 모델들의 구조를 잘 생각해서 느슨한 결합을 통해 의존성을 줄이고, 응집도는 높이려 했다.

 

그 과정에서 객체지향 설계 원칙 - SOLID를 온전히 생각하며 코드 작성을 할 수 있게 되었다.

나의 머리속에 떠오르는 모델간의 여러 구조들..

이들의 결합도를 낮추려면 어떻게 모델간의 계층을 나누어야 할까? 를 많이 고민할 수 있었다.

 

먼저 OCP 이야기이다.

미션 첫째 날에는 사각형 버튼 하나를 만들고, 그 버튼을 누르면 사각형 뷰를 그리는 것이다.

둘째 날에는 사진 버튼을 추가하고, 그 버튼을 누르면 이미지 뷰를 그리는 것이다.

 

이때 생각했다. “이거 Shape가 점점 더 생기겠는데..?” 라며

그때부터 Rectangle 클래스와 Photo 클래스를 추상화하여 Shapable 이라는 프로토콜을 만들었다.

나의 첫 추상화 시도였다.

 

미션의 요구사항 중에 Factory Pattern 을 적용하여 도형들을 만들어내는 팩토리가 필요했다.

 

ShapeFactory 를 만들어서 열거형에 따라 Shapable을 반환하는 하나의 팩토리를 만들까 ?

각각의 Factory 를 만들어서 ShapeCreatable 프로토콜을 채택하고 associatedtype 을 통해 열거형 없이 만들까 ?

 

이 두 개가 너무 고민됐다.

그래서 열심히 나만의 방법으로 장단점을 분석하여 멘토에게 질문했고,

그 과정에서 결정을 하여 ADR을 작성했다.

https://kyxxn.tistory.com/121

[ADR] 내 프로젝트에서 겪은 OCP 원칙에 대한 생각 정리

 

---

추상화에 첫 발을 뗀 지금,

Shapable 을 통해 “사각형, 사진, 텍스트, 펜 그리기”에 대한 처리를 해줄 수 있었다.

새로운 Shape가 추가될 때면, 열거형에 case만 추가해주고 다른 Shape를 처리하는 코드만 복사하면 금방 확장이 되었다.

나는 확장성을 위한 코드를 작성할 수 있었고, 처음 느껴보는 감정이었다.

“오 설계를 잘 하면 이렇게 쉽게쉽게 확장할 수 있구나” 라며.

 

그러나 팀원에게 새로운 지적을 받았다.

“효준님의 Shapable 을 새 도형마다 넣어주면

필요없는 프로퍼티/메소드 까지 가지게 되는 상황이 나오는데 그런 경우는 어떻게 하실 건가요 ?”

 

나는 여태 이런 질문을 받아볼 수가 없었다.

프로토콜을 통해 OCP를 지키는 코드를 작성해본 적이 없기 때문이다.

그래서 팀원의 위 지적은 날카롭게 다가왔다.

 

‘이미지의 경우, 실제 사진을 가져오니까 BackgroundColor는 필요가 없는데,

이미지가 Shapable 을 채택하면 쓰지도 않는 프로퍼티를 가져오게 되네?’ 라고 생각했다.

 

이 부분에 대한 고민을 하고 멘토님께 질문했더니 inherit 와 composition 에 대해 알려주셨다.

상속은 늘 하던거니까 넘어가면, composition은 처음 들어봤다.

프로토콜을 잘게 쪼개서 필요한 클래스&구조체에서 조합해서 쓰는 방법이었다.

 

 

나는 아직 배우고 있는 중이다.

배운 것을 내 코드에 적용해볼 줄 알고, 그 과정에서 뭐가 맞는지 고민하며 조심스레 판단을 해보고 있다.

남은 10주간 내가 배우고 있는 이 내용을 조금 더 적용해볼 예정이다.