[우테코 Level 1] 미션3. 블랙잭 - Clean Code

별의개발자커비·2024년 3월 24일
0

우테코 6기

목록 보기
4/22
참고: 4F 회고

Fact : 무슨 일이 있었는지, 어떤 일을 했는지
Feeling : 어떤 감정을 느꼈는지
Finding : 어떤 지식과 인사이트를 얻게 됐는지
Future Action : 앞으로 무엇을 할 계획인지

Fact

: 무슨 일이 있었는지, 어떤 일을 했는지

테코톡 - 가비지 컬렉션

그렇다. 우테코 크루라면 누구나 한 번씩 해야하는 테코톡이 다가왔다!
귀가 얇은 나는 주위에서 같이 신청해보자는 말에그럴까?하고 덜컥 신청해버렸다.
주제도 GC 언젠가 한 번 공부해봐야겠다 했는데, 이걸로 할까?라는 매우 단순한 생각으로 덜컥 가비지 컬렉션으로 정했다.

그런데 문제는 여기부터였다.
주위는 다들 평소에 관심있던 주제 또는 어느정도 알고있던 주제로 테코톡을 준비하는 편이었는데,
나는 무작정 아예 모르는 주제로 준비하려다보니 아예 처음부터 공부를 했어야했던 것이다.

하나 더, 준비하다보니 알게된 것인데,
GC를 설명하려면 기반이 되는 JVM도 어느정도 함께 다뤄야되더라!
...와우!
그렇다. 나는 JVM도 공부해본 적이 없다.

그렇게 스스로 불러온 GC + JVM, 그런데 이틀정도의 시간만을 곁들인 독학을 시작했, 과정은 호락호락하지 않았다.
JVM의 기본 동작 원리부터 파려니 꼬박 이틀이 걸려, 정작 GC는 하루만에 공부하고 발표 피피티는 전날 만들기 시작했다던지,
'static 변수의 관리 영역이 heap영역이다'에 대해 블로그 별로 말이 달라서 책을 뒤지고, 오라클 공식 문서를 뒤지고 하는 데에 한참을 쏟는다던지 말이다.
그 과정에서왜 처음보는 주제로 한다고 한 거지? 가비지 컬렉션 대상은 커비 너 아닐까...?하는 생각이 들었던 것도 사실이다ㅎ

하지만, 발표 특화형 인간 이커비.
하기 전에는 무척이나 떨렸는데, 막상 테코톡 발표 시간이 되니 너무 재밌었다.
내가 깊이 공부한 지식을 누군가에게 설명한다는 것, 그리고 그 청중들이 나를 통해 뭔가를 알아간다는 것이 신났다.

더불어 마음의 짐처럼 있었던 JVM, GC를 제대로 파볼 수 있어서,
최소한 이 내용에 대해 이야기가 나오면 어느정도 아는 척은 할 수 있게되어서 그 점도 만족스럽다!


영어, 코드 리뷰 스터디 시작!

5기 선배와의 수다타임에 5기 에코가 와서 해외 취업에 대한 이야기를 해주었다.
원래도 해외 취업에 관심이 있었는데 에코의 이야기를 듣다보니 더욱 생각이 커졌다.
이때다 싶어, 해외 취업에 마음이 맞는 몇몇 크루들과 영어 스터디 ✌️잉글잉글✌️을 시작했다.

더불어 코드 리뷰 스터디 코코클도 시작했다.
(*코코클: 코미디 코딩 클럽의 약자로 우테코 내 비공식 개그 동아리이다.)
코코클은 코드 리뷰에 초점을 맞추기 보다는 다양한 코드를 읽어보자는 의도로 가볍게 시작해본 스터디이다!

우테코 생활에 스터디가 더해지니 좀 더 바빠졌기 해도 재미있는 일이 더해진 기분이다!


브라운과의 개인 면담

레벨별로 한 번씩 있는 브라운과의 개인 면담!
정리해보면 세가지가 궁금했었다.

  1. 코드를 서로 볼 때나 토론할 때 내가 부족한 점에 대해서 아직도 드러내는 것이 어렵다.

    내가 부족하다는 감각에 익숙하지 않은것은 계속 노출시켜보면 된다.
    모르는 것 드러내고, 부족한 코드 보여내지고 이런 경험들 늘려볼 것.

  2. 습득에 대한 욕심이 너무 많은 것 같다. 내려놓기가 쉽지 않다.

    욕심이 많은 것 나쁜 것 아니다. 저번 페어가 의존성부분을 잘해서 부러웠는데 이번 리뷰어가 의존성 RC를 많이하네? 좀 무리해서 자주 RC로 소통해야겠다. 가 나쁜 것이 아닌 것 처럼!

  1. 내가 맞는 방향으로 잘 학습하고 있는지 모르겠다.

    누군가 하나(예: 객체지향)를 엄청 잘해서 뽑히는 게 아니다.
    객체지향 조금, 소프트스킬 조금 ... 이렇게 잘하는 게 내 조합이 되어서 내 강점이 되는 것!
    다른 크루들과 비교해서도 나도 충분히 강점이 있다. 개성도 있고, 욕심도 중요한데 욕심도 많고!

몇 년동안 수많은 크루들을 보아왔던 브라운의 말이라 그런지 면담을 하고나니 마음이 훨씬 가벼워졌다!

Feeling

: 어떤 감정을 느꼈는지

크루에게 메타인지 도움받기

이번주를 한마디로 정리하자면 과부하였다.

  1. 처음보는 주제로 테코톡 준비
  2. 질문을 던지는 스타일인 리뷰어, 그래서 더 많이 rc 진행하고 싶은 욕심
  3. 근데 네오 강의에서 나는 아직 수익 계산도 못했는데 진도는 나가고, abstract 능숙하게 쓰시는데 나는 '왜 저기서 abastract를 써야하지'하고 생각하는 수준의 자괴감.

어쨌든 미션은 계속해서 진행됐고 불안감은 점점 커졌다.
그러다 유연성 강화 스터디날에 마침 이 얘기를 조원들에게 털어놓았다.

제 3자가 보는 나는 이랬었나보다. 요지는 욕심과 priority queue이고 둘다 인정한다.
하지만 솔직하게 욕심 버리기는 당장 어떻게 해야하는지 모르겠고,
우선순위를 정해서 그걸 따르면서 불안감을 느끼지 않는 것이 그나마 당장 할 수 있는 일 같은데, 어떻게 우선순위를 정해야할지 잘 모르겠었다.
내 상황을 메타인지적으로 보고 정리하는 것말이다.

이걸 조원들이 해줬다.
내 엉켜있는 계획들을 늘어놓고 어디서부터 손을 대는 것이 좋을지,
또 불안한 마음에 대해서는 내려놔도 된다고 몇 번이고 확신을 줬다.
왜 그런 순간 있지않나.
이 고민이 내 머릿속에서 사라지고 다른 일에 집중하고 싶은데, 찌꺼기처럼 계속 마음에 남아 마음이 무거운 순간들. 그런 감정들이 나를 덮쳐오는 때가 꽤나 많았는데 이번에는 조원들에게 말하면서 그 감정들이 빠르게 날아갔다.

이렇게 도움을 받다보면 언젠간 나 혼자서도 과업이 과중한 상황이더라도 부담감과 불안감을 정리하고 능숙하게 다룰 수 있게되지 않을까?


Finding

: 어떤 지식과 인사이트를 얻게 됐는지

원칙을 따르는 것? 실리를 취하는 것? 난 뭘 좋아하지?

블랙잭 카드를 출력하면서 클로버, 다이아몬드.. 등 한글로 카드 문양을 출력해야했다.

public enum CardShape {
    CLOVER("클로버"),
    DIA("다이아몬드"),
    SPADE("스페이드"),
    HEART("하트");
}

이 때, 이 한글 문양 이름을 도메인의 CardShape에서 관리하는 것은 view의 영역을 도메인이 관리하는, 즉 도메인이 view에 의존한다고 생각하여 model용 카드문양 enum과 1대1 대응하는 view용 카드문양 enum을 만들어서 관리하였다.

하지만 이렇게 하다보니 단점이 꽤나 존재했다.

  1. formatter 클래스에 name()에 의한 중복코드가 존재한다는 점
  2. signal과 비교하여 가져오는 조회 로직이 outputView에 추가되어야한다는 점
  3. sinal이 변경될 경우 두 곳에서 변경이 일어나야한다는 점

결국, 도메인이 view에 의존하면 안돼!라고 생각했지만 이것 역시 트레이드 오프로 감수할 수 있는 점이었다는 걸 깨달았다. 그리고 이에 대해 리뷰어의 의견도 들을 수 있었다.

이런 부분에서 내가 원칙을 따르는 것을 좋아하는가, 조금 더 실리를 취하는 것을 좋아하는가 등등 본인의 전반적인 취향을 유추해볼 수도 있답니다!

물론 어떠한 장/단점을 고르는 기준은 왠만하면 비슷비슷한게 좋아요. 일관성이 있어야 다른 개발자들과 협업을 할 때도 그들도 이해할 수 있기 때문이죠 😃

해당 미션이 커비의 선호도와 지향성을 알 수 있게 해주는 첫 걸음이면 좋겠네요 😉

리뷰어의 이야기를 듣고보니 나는 현재로써는 실리를 취하는 걸 좋아하는 것 같다고 느꼈다. 왜냐면 뷰가 수정될 경우를 미리 가정해서 도메인이 view에 의존하는걸 지양하자는 가정이 현재에는 크게 문제점으로 느껴지지 않기때문이다.
결국 도메인에 한글 문양 이름을 다시 넣는 것으로 코드 상으로는 처음으로 돌아온 게 되었다. 하지만,

  1. 결국 모든 건 트레이드 오프이기에 내 취향을 가지는 것이 중요함
  2. 다만 그 기준이 비슷하게 일관성이 있어야한다는 것을 새로 알게되었기에,

코드는 같아도 나는 달라졌달까!


매서드 시그니처로 행위를 짐작할 수 있는가?

이번 미션의 목표는 클린코드다. 클린코드란 무엇인가에 대한 기준은 다양할 것이다.
나의 경우 가장 먼저 떠오르는 건 가독성이었다. 신문을 읽듯이 위에서 아래로, 밖에서 안으로 술술 읽히는지.
그리고 그렇게 잘 읽히기 위한 여러 기준들 중 이번 미션을 진행하면서 새롭게 정립한 기준은 바로,
매서드 시그니처로 행위를 짐작할 수 있는가?이다.

즉, '클래스명.메서드명()을 했을 때, 어떠한 동작을 할지 기대할 수 있고 기대한 응답을 제대로 내려준다면 그게 바로 읽기 좋은 코드다'라는 기준이 생긴 것이다!

메서드명과 파라미터의 갯수, 타입, 순서까지 이 요소들이 모두 합쳐져 의미있는 컨텍스트를 만들어내는 것! 기억하자!

0개의 댓글