[우테코 레벨 1]: 3주차 회고 (유연성 강화, 사다리 게임, 생일, 클라이밍)

레디의 회고 작심삼주 성공!🥳

 

🎢 오프닝

이번주 시작을 여는 월요일 데일리 미팅은 석촌호수에서 진행하였다. 테바가 사주는 커피도 마시며 한 40분동안 산책하였다. 오랜만에 산책을 했었는데 꽤 재미있었다. 롯데월드에 가서 놀고 싶은 마음도,,,

 

 

 

🙌 유연성 강화

 

소프트 스킬 교육 시간에 유연성 강화를 위한 활동으로 나에게 부족한 점 찾고 해결 방안을 찾는 시간을 가졌다.

 

소프트 스킬 강화를 열심히 해야 하는 이유는 여기서 확인할 수 있다. 

"기업들, 이력서상 S급 인재보다 태도 좋은 A급 인재 선호"

 

 

나의 문제점이 무엇인지 고민해볼 수 있는 기회였다. 나의 문제점은 자신과의 싸움을 통해 성장하고픈 욕심에 지나치게 스트레스를 받는다는 점이었다.

 

자동차 경주 미션과 사다리 타기 미션을 두고 보았을 때, 자동차 경주 미션보다 사다리 타기 미션이 더 뛰어난 애플리케이션이 되어야 한다는 생각에 더 멋진 방식으로 사다티 타기 미션을 구현하고자 하였다. 하지만 (지긋지긋한) 예외시 재입력기능을 두고 보았을 때,(계속 이 부분에 초점이 맞춰진 것 같지만) 결과적으로 자동차 경주 미션때보다 사다리 타기 미션이 뛰어나다고 볼 수는 없었다. 사다리 타기 미션에선 아예 해당 기능 구현을 하지 않았기 때문이다.

 

하지만 그렇다고 사다리 미션이 완전히 실패한 미션이었냐? 라고 본다면 아니다! 라고 답할 수 있다.

 

예외시 재입력 기능 구현을 포기하는 대신 다른 TDD와 리팩터링을 챙겼기 때문이다.

 

그래서 나의 유연성 강화 목표는 자신과의 싸움에서 져도 된다는 마음을 갖는 것이다.

최고심의 3월의 마음

 

 

번외로 스터디 도중 피드백 시간에 제제가 다른 사람과 비교해서 스트레스 받는데, 나는 나와 비교해서 스트레스를 받는구나라는 말을 남겼다. 전혀 깨닫지 못한 부분이었던 거 같다.

---

 

우테코에 들어와서 계속 깨닫고 있는 두가지가 있는데, 하나는

 

모든것은 트레이드 오프.

 

 

어떤 순간에도 선택을 해야하는데, 이때 기회비용을 커버할 수 있는 타당성을 증명해야 합리적인 선택이라고 말할 수 있을 거 같다.

 

그리고 또 한가지는

일의 우선순위를 정하기.

 

우리에게 주어진 시간은 한정되어 있고, 이 시간을 얼마다 효율적으로 쓰느냐가 중요한 거 같다. 선택과 집중을 통해서 일을 해결해야 한다는 것을 배우고 있다.

 

재입력에 관한 기능도 step2 때 구현을 하려 했지만 하다보니 클래스의 크기가 좀 너무 많이 커져서(커스텀 어노테이션과 리플렉션을 사용하여 구현) 리뷰어가 이 코드를 보느라 중요한 로직을 살펴볼 시간이 줄어들 것 같다는 생각이 들어 구현을 멈추었다.

그리고 이전 리뷰어 범블비에게 해당 기능 구현을 어떻게 하면 좋을지 dm을 남겨 조언을 구하였다. 돌아온 답변으로는 만약 내가 이 미션에 이미 익숙하다면 새로운 것을 도전해봐도 좋을테지만, 사다리 미션에서 얻어갈 수 있는 것들이 있고 이것에 집중하는 편이 좋을거라는 피드백을 남겨주셨다. 그리고 또 언젠간 프록시 패턴을 공부하게 될때 그때 공부해도 늦지 않다는 조언도 해주셨다. (범블비 최고👍)

 

 

🎮 사다리 게임 미션

 

사다리 게임 리뷰어는 아서였는데 2단계 피드백 중 기억에 남는 피드백은 model과 view를 철저하게 분리해보기와 일관성을 지키기였다.

 

Model과 View 분리

사람이름을 일정한 간격으로 출력하는 것부터 시작하여 사다리 모양을 맞춰 출력하는 것, 결과를 출력하는 것 등등 이번 미션에서 view 관련된 로직도 상당히 많았다. 이를 도메인 로직과 얼마나 어떻게 많이 분리하는 것이 관건이었다. 

 

좀 더 분리해보고 싶은 마음에 다시 한번 RC 요청을 해달라고 욕심을 부려보았다.

 

그렇다면 여기서 model이 view의 의존성을 끊어냈을 때 생기는 이점은 무엇일까? 다시말해 model 객체가 view와 controller 객체의 의존하지 않을 때의 장점은 무엇일까?

 

높은 응집도를 만들고 낮은 결합도를 만들 수 있다.

 

일관성 지키며 코딩하기

어찌보면 당연한 이야기인데 가끔 놓치거나 실수할 수 있는 부분이다.

step1에서 step2로 변경하면서 변경됐던 부분은 final과 record 사용이다. 

 

final

엥 님 final 키워드 이제앎??

필드에 붙이는 건 알고 쓰고 있었는데, 메서드 파라미터에도 final 붙이는 방법을 사용하기 시작하였다. 

 

파라미터에 final을 붙여 사용하는 것은 프리코스 때 코드리뷰하면서 처음 봤었었다. 그때는 그냥 이런 방법도 있구나~하고 넘어갔는데, 백호랑 페어미션을 진행할 때에는 백호의 인텔리제이 설정이 디폴트로 되어 있어서 그냥 사용했다가 네오의 피드백에서 계속 사용하는 것을 보고 그래서 final 붙이면 뭐가 좋은거야? 뭐가 좋은지는 알고 써야지! 하고 장단점을 찾아보았다.

 

가장 와닿았던 점을 설명해보자면,,, 우선 내가 작성한 코드는 시간이 지나면 결국 다른 사람이 보게된다. 지금 작성한 코드를 몇년 후의 내가 보는 것도 다른 사람이 보는 것이라고 볼 수 있다.  그렇다면 내가 작성하는 코드에서 나의 의도를 들어내야 한다. final 키워드를 사용하면 이 파라미터는 건들이지마! 라는 의도를 전달할 수 있다는 장점이 있다. 

 

자바가 이런 의미/의도를 전달하기 위해 특화된 언어인 거 같다. 자바 독스를 살펴보아도 각 기능마다 만든이의 주관이 들어가있는 경우가 많다. 

 

파라미터에는 final을 붙였지만 메서드 안에서 등장하는 변수에 대해서는 final을 붙이지 않아 일관성이 깨졌던 거 같다. 하지만 이 부분에 대해서는 아직 고민이 있다.

 

final LadderStatus ladderStatus = LadderStatus.from(blahBlah);
 
LadderStatus ladderStatus = LadderStatus.from(blahBlah);
 
final var ladderStatus = LadderStatus.from(blahBlah);

 

변수에 final 붙여 사용하게 된다면 = 의 왼쪽 녀석들의 길이가 상당히 길어진다. 그래서 var 라는 친구를 사용해보았었는데, 괜찮은 녀석인지는 아직 잘 모르겠다.

 

record

record는 JDK 14에 등장하였고 JDK 16에 정식 기능으로 자리잡았다.

인텔리제이에서 코딩을 하다보면 클래스로 되어 있는 VO들을 레코드로 변경하라고 추천하는 문구가 뜬다. 

정확히 어떤 경우에 이런 추천 문구가 뜨는지 궁금해서 마침 record로 테코톡을 준비하는 타칸에게 미리 질문을 하였다😊

(위 내용은 테코톡을 참고하도록 하자!)

 

논점은 내가 어떤 VO는 클래스로 두고 어떤 VO는 레코드로 만들어 일관성 없이 작성한 것이다. 일관성이 없으면 둘을 차별화한 이유는 무엇인지 사람들은 궁금해한다. 레코드에 대해 잘 모른채로 인텔리한 인텔리제이의 추천을 따랐다가 말았다가 한 결과이다. 

 

그래서 레코드의 이점도 한번 짚고 넘어가보기로 하였다.  

 

가장 와닿았던 점을 정리해보자면,,, 우선 getter, equals, hashcode 등의 코드를 직접 작성하지 않아도 되기에 코드의 양이 단축되고, 해당 객체는 VO라는 의미를 명확하게 전달할 수 있다. 코드의 양이 단축되면 읽는 시간도 단축되고, 중요한 곳에 시간을 투자할 수 있는 여유가 생긴다(너무 오바인가😅)

 

점점 이유를 가지고 코딩을 하는 방법을 배우고 있다.

 

🎂 번외1 생일

수요일이 귀빠진 날이었다. 

저녁먹으러 새로 생겼지만 크루 사이에서 맛있다고 소문난 짐승덮밥에 가서 생일축하 노래도 부르고 생일 선물로 까까랑 사탕을 챙겨주셨다. 

 

짐승덮밥 : 네이버

 

다시 돌아오는 길에 리건과 혈당좌 러쉬가 몰래 케익을 사고, 커비와 안나의 감쪽같은 연기로 서프라이즈 생파를 챙겨주었다. 🥳

 

색다른 생일이었다.

 

🍻번외2 동동 클라이밍

토요일에는 클라이밍 동아리에 참여해보았다. 6기 백엔드에선 리니, 아루, 망쵸가 왔고, 프엔에선 포메가 왔고 안드는 없었다😥 선배 크루분들이 잘 챙겨주셔서 처음 하는 클라이밍이었는데도 재밌게 즐길 수 있었다. 

 

루트 파인딩 하는 방법도 배웠는데 꼭 길찾기 알고리즘 풀었던 경험과 클래시 오브 클랜(모바일 전략 게임)했던 때가 생각났다. 

 

클라이밍 마무리하고 회식하러 가서는 리뷰어의 비하인드 스토리, 현업자의 비하인드 스토리를 들을 수 있던 재미난 시간이었다.

 

기억에 남았던 말은 객체지향의 목적은 읽기 좋은 코드와 유지보수하기 쉬운 구조를 만들기위한 수단일 뿐, 만약 절차지향적이 더 읽기 쉽고, 유지보수하기 쉬워진다면 어떻게 하는 것이 좋을까?란 질문과 읽기 좋은 코드를 추구할 것인가 안정적인 서비스를 추구할 것인가에 대한 질문이었다. 후자의 예시로는 로또미션에서 돈과 관련된 데이터를 다루는 것이었는데,

부동소수점 오류를 최소화하기 위해 BigDecimal을 사용해야하냐 아니면 좀 더 읽기 쉽게 Double로 할 것이냐라는 질문이였다. 

 

아직까진 어떠한 판단을 내리기엔 데이터가 부족하다.🤔