학습 부분

무엇을 배웠는가?(학습 중 아하 모먼트 위주)

1. 인터페이스 이름 짓기

• 섹션 7의 48강 리팩토링(3) - 관점의 차이로 달라지는 추상화에서 인터페이스 네이밍에 관해서 아래와 같은 기준이 있습니다.

- 어떤 데이터를 가져와야 하는가?

- 데이터를 어디에서부터 어떻게 가져올 것인가?

• 이 부분이 인상 깊었는데, 인상 깊었던 이유는 제가 인터페이스를 만들고 확장하려고 할 때 막혔던 부분과 똑같기 때문이었습니다.

• 제가 만들었던 인터페이스의 이름이 무엇을 반환할 지가 아니라 어떻게 반환할 지에 초점이 맞춰져 있었습니다.

• 회사 코드라 자세한 사항은 말할 수 없지만, 인터페이스를 이름 지을 때 어떤 데이터를 가지고 와야 하는지를 중점으로 생각하면 좋다는 인사이트를 얻었습니다.

2. 인터페이스의 추상메서드로 getter가 있어도 괜찮을까?

• Cell 인터페이스에서 Snapshot getSnapShot()이라는 메서드를 선언해서 구현을 했습니다.

• 저는 처음 이 추상 메서드를 봤을 때 객체의 필드를 반환하는 단순한 메서드라고 생각을 했습니다.

  • 이 단순한 메서드를 "인터페이스에 선언하여, 모든 구체에서 메서드를 구현해야하나?"라는 의문이 들었습니다.

• 그런데 생각해보니, 단순한 메서드가 아닐 수 있을 거라는 생각이 들었습니다.

  • 구현체가 Snapshot을 필드로 가지고 있다면 getSnapshot()메서드가 필드를 반환하는 단순한 메서드이다.

  • 구현체가 Snapshot을 필드로 가지고 있지 않다면 직접 SnapShot을 만들어 줘야 한다.

• 상속을 사용하여 부모의 필드를 getter로 내려주는 것보다, getter를 인터페이스의 추상 메서드로 만들어서 유연성이 높은 코드를 작성할 수 있겠다는 생각이 들었습니다.(상속이 나쁘다는 의미는 전혀 아닙니다.)

3. 예외는 비싼 객체이다.

• 중간 점검에서 우빈님께서 "예외는 비용이 큰 객체이므로 사용에 신중해야 한다"는 말을 하셨습니다.

• 예외 객체에는 예외가 발생한 위치와 경로를 담은 stack trace 정보가 포함되며, 이를 생성할 때 추가적인 연산이 필요합니다.

• 따라서 꼭 필요한 경우가 아니라면 예외를 던지는 것을 지양하는 것이 좋습니다.

4. 리팩토링을 단계별로 하는법

• 회사에서 결제 로직을 추상화, 통합하는 리팩토링을 진행했는데, 처음에 도메인 객체를 먼저 변경하는 바람에 전파 범위가 넓어지고 변경 부분이 파편화되는 어려움이 있었습니다.

• 우빈님의 강의를 보니, 전파 범위가 작은 부분부터 점진적으로 리팩토링하는 방식을 취하셨습니다.(메서드 추출 -> 인터페이스 선언 및 구현)

• 클래스 내부의 리팩토링을 마치고 나서 클래스 간의 리팩토링을 진행하니, 변경 범위를 보다 명확하게 파악할 수 있었고, 안정적으로 리팩토링을 진행할 수 있었습니다.

   

• 앞으로는 전파 범위를 고려해, 영향도가 적은 부분부터 점진적으로 리팩토링하는 게 좋다는 생각이 들었습니다.

5. Enum implements interface

• enum에서 인터페이스를 구현할 수 있다는 점이 신기했습니다.

   

• 다만 enum을 단순한 상수로 볼지, 하나의 상태를 가진 객체로 볼 지에 따라 인터페이스 구현의 필요성은 달라질 수 있다고 생각합니다.

어떻게 학습했나?

• 최대한 휴일(화요일 금요일)을 이용하려고 했습니다.

  • 화요일이 바빴는데, Readable Code 4강 중반 ~ 6강까지 들었습니다.

  • 미션 수행은 날짜게 맞춰서 수요일에 제출했습니다.

  • 목, 금, 토는 쉬었습니다.

  • 일요일에는 Readable Code 강의를 마무리 지었습니다.

• 메모장을 사용해 강의를 들으면서 좋았던 부분, 키워드를 메모하면서 아이디어가 날라가는 걸 방지했습니다.

좋았던 점

• 화요일에 결국 세웠던 목표(6강 마무리)를 달성했습니다.

• 미션도 제출하고 금요일에 중간 점검도 참석했습니다.

• 메모장을 사용해 강의에서 와닿았던 키워드를 적으니, 무엇을 배웠는지 정리하기가 수월했습니다.

아쉬운 점

• 화, 수요일에 많은 에너지를 써서 목, 금, 토는 손을 놓은 것 같습니다.

• 화요일에 새벽까지 강의를 듣다보니 머리 속에 코드 잔상이 남아 수면의 질이 떨어졌습니다.

개선할 점

• 10시 ~ 11시에 자고, 일찍 일어나서 강의를 들어서 밤새 강의를 듣는 걸 방지해보려고 합니다.

• 휴일이라고 해도, 강의를 몰아 듣는 건 지양해야 겠습니다.

미션 수행 부분

어떤 미션을 했는가?

• 이번 주는 코드 리팩토링 미션을 했습니다.

어떻게 접근 & 수행했는가?

• 화요일에 관련 강의를 다 듣고, 수요일에 미션을 수행했습니다.

• 화요일에 강의를 듣기 바빠서 리팩토링할 코드는 수요일 9시 반에 처음 봤고, 12시까지 리팩토링 미션을 진행했습니다.

• 빨리 끝내야겠다는 마음이 앞서다 보니 코드를 한번 훓고 바로 리팩토링을 수행했습니다.

• 핵심 로직부터 변경해야겠다는 생각이 들어서, 도메인(StudyCafePass) 변경부터 시작했습니다.

좋은 점은?

• 직접 강의에서 들었던 내용을 적용하다보니 코드가 깔끔해졌습니다.

아쉬운 점은?

• 시간의 압박을 느껴 전체적인 리팩토링 포인트를 잡지 않고 바로 코드를 수정했습니다.

• 어디를 어떻게 변경할지, 어떤 부분을 먼저 변경할지 전략을 짰으면 시간을 효율적으로 사용할 수 있을 것 같습니다.

• 전체적인 질도 만족스럽지 않습니다. 리팩토링할 부분이 보이는데 하지 않았습니다.

어떻게 개선하고 싶은가?

• 월요일에 테스트 코드 작성 미션이 있는데, 내일부터 미션을 분석하고 수행하는 방식으로 개선하고 싶습니다.