[후기] 우테코 2주차 회고

0. 이 글을 쓰게 된 이유

우아한 테크코스가 시작한지 2주가 되었다. 이쯤에서 다시 한번 돌아보는 회고를 가져보고자 이 글을 쓰게 되었다.

1. 우테코 생활

예상은 어느정도 했지만 우테코에서의 생활은 굉장히 자유롭다. 출석 체크도 크루끼리 알아서 하고 점심도 배고플 때 알아서 먹고오면 된다. 미션도 마감 기한 정도만 정해져 있고 나머지는 자기의 페이스에 맞춰서 하면된다. 그리고 무엇보다 가장 크게 느꼈던건 인싸들만 살아남을 수 있는 곳인것 같다. 개인적으로는 굉장히 재밌고 여러가지 스킬들을 배울 수 있는 것 같아 만족스럽다!

2. 답해보기

교육 및 피드백 시간에서 생각해볼만한 질문들이 있어 정리해보려고 한다.

2.1 TDD, 리펙토링

2.1.1 내가 TDD, 리팩토링을 하는 이유는 무엇인가?

솔직하게 평소에 TDD를 정석대로 적용하지 않았었다. 이전까지는 프로덕션 코드를 짜고 최대한 빨리 테스트 코드를 짜면 된다고 생각했다. 하지만 이번에 제대로 TDD를 적용하다보니 이전까지의 방식과는 다르게 다음과 같은 장점이 있는 것 같다.

1. 버그 발생 가능성이 줄어든다.
   프로덕션 코드를 먼저 짜고 테스트 코드를 짜게되면 내 코드에 딱 맞는 테스트를 짤 가능성이 높다. 그렇게되면 객관적이지 않은 시선으로 테스트 코드를 짜게되고 그만큼 서비스의 안정성이 낮아진다. 하지만 TDD를 적용하면 아직 프로덕션 코드를 짜기 전이기 때문에 비교적 객관적인 시선으로 테스트를 짤 수 있으므로 서비스의 안정이 높아지게된다.
2. 핵심 비지니스 로직에 집중할 수 있다.
   테스트를 미리 짜두면 프로덕션 코드에 조금 더 집중할 수 있다. 안정적인 테스트가 이미 있으니 빠르게 로직을 테스트 해볼 수 있고 그만큼 다양한 시도를 할 수 있게된다.

2.1.2 기존에 구현하는 방식과 TDD로 코드를 구현할 때 어떠한 차이를 느꼈는가?

일단 되게 불안했다. 없는 코드를 테스트하니 컴파일 에러가 굉장히 많이 보였고, 혹시나 놓치는 부분이 없을까 노심초사 했다. 하지만 역으로 생각해보면 조금 더 테스트 자체에 집중하게 됐던 것 같다.

2.1.3 미션을 진행하면서 리팩토링을 경험하며 어떠한 어려움을 겪었는가?

처음에 구현할 때 유지 보수하기 힘든 구조로 짜놓으면 리펙토링 하나 하는데에도 시간이 굉장히 오래 걸렸다. 최초에 오버 엔지니어링이라는 생각으로 가독성 좋게 짜놓았는데 너무 거기에 매몰되어 유지 보수하기 힘든 구조가 나온 적이 있다. 그 코드를 리펙토링 하는데에 시간이 굉장히 오래 걸렸다.

2.1.4 리팩토링 과정에서 어려움을 줄이기 위해 어떠한 시도를 해볼 수 있는가?

최초에 설계할때 리펙토링 및 유지보수에 신경을 조금 더 써도 될 것 같다. 그리고 다른 동료들의 피드백을 열린 마음으로 수용해서 일단 해보는 것도 좋은 시도인 것 같다.

2.2 자바에 대한 이해

2.2.1 본인이 생각하는 자바를 잘한다는 기준은 무엇인가?

내가 생각하기에 자바를 잘한다는 기준은 다른 사람의 코드를 볼 때 잘 이해하는 사람이다. 자바는 객체 지향 언어이고, 그러한 사고는 상당히 주관적이다. 자바를 잘하는 사람은 여러가지 사고를 경험 해봤기 때문에 누군가의 코드를 봐도 비교적 빠르게 이해할 수 있다.

2.2.2 자바를 잘하는 사람이 되기 위해 어떠한 시도를 할 것인가?

남의 코드를 많이 보고 피드백을 해본다. 그리고 남의 코드를 볼 때 내 코드를 보듯이 어떻게든 이해하려고 해본다.

2.2.3 미션을 진행하며 위 시도를 하였을 때 본인이 성장하고 있는지 어떻게 측정할 수 있는가?

남의 코드가 잘 읽히면 성장한다고 느낀다고 생각한다. 10명의 코드를 봤을 때를 기준으로 측정할 수 있을 것 같다.

2.3 예외 처리

2.3.1 Checked Exception을 사용하는 경우와 Unchecked Exception을 사용하는 자신만의 원칙은 무엇인가?

항상 복구할 수 있는 에외이면 Checked Exception을 던진다. 하지만 그런 경우는 흔치 않으므로 대부분 Unchecked Exception을 던진다. 솔직히 어플리케이션을 개발할 때 거의 100% Unchecked Exception 사용한다.

2.3.2 어떠한 상황에 예외를 복구하는 것이 좋다고 생각하는가? 왜 그렇게 생각하는가?

복구할 가능성이 있는 경우 -> 복구할 방법이 분명히 있는 경우 사용한다.

2.3.3 어떠한 상황에 예외를 회피하는 것이 좋다고 생각하는가? 왜 그렇게 생각하는가?

호출한 쪽에서 처리하는 것이 더 낫다는 확신이 있을 때 사용한다. 호출한 쪽에서 그 예외를 일괄 처리할 솔루션이 있는 경우 사용한다.

2.3.4 어떠한 상황에 예외를 무시하는 것이 좋다고 생각하는가? 왜 그렇게 생각하는가?

사용하는 API에서 잘못 설계되어 무조건 큰 상황이 아닌데 예외를 던지게 하는 부분이라던지, 무시해도 어플리케이션 전체나 비즈니스 로직 상 아무런 문제가 되지 않는다면 무시를 사용한다.

2.3.5 어떠한 상황에 예외를 전환하는 것이 좋다고 생각하는가? 왜 그렇게 생각하는가?

1. 내부에서 발생한 예외를 그대로 던지는 것이 그 예외 상황에 적절한 의미를 부여하지 못하는 경우, 그 예외의 의미를 분명하게 해주기 위해서
   ex) SQLException -> DuplicateUserIdException
2. 예외를 처리하기 쉽고 단순하게 만들기 위해 포장 -> 주로 예외처리를 강제하는 체크 예외를 언체크 예외인 런타임 예외로 바꾸는 경우 사용

3. 회고

약 3주 동안 경험해본 우테코의 가치는 함께 성장하기인 것 같다. 물론 혼자서 미션을 진행하고 피드백을 받으며 성장하는 것도 크지만, 똑같은 미션을 다른 사람이 어떻게 구현 했는지 이해하고 의견을 주고 받으며 성장하는 것이 핵심인 것 같다.