[우아한테크코스] 최종 코딩테스트 후기

최종 코딩테스트 연습

최종 코딩테스트를 앞두고 우테코 디스코드의 동물원 채널에서 친해진 분들과 함께 스터디를 진행했다. 최종 코딩테스트 3주 전부터 매주 2번, 5시간씩 실전과 동일한 환경에서 문제를 풀었고, 문제를 푼 후에는 대화형 코드리뷰를 통해 서로의 부족한 점을 채우고 피드백을 주고받으며 실력을 향상시켰다.

github repository : https://github.com/wooteco7th-study/wooteco7th/pulls

GitHub - wooteco7th-study/wooteco7th

 

또한 skillswap 스터디에서 매주 한번 페어 프로그래밍을 진행하며 미션을 함께 풀며 시야를 확장시켰다.

 

최종 코딩테스트를 준비하며 스스로 보완했던 점

1. 요구사항 분석 방식 개선

이전에는 성공과 실패 케이스를 모두 고려하지 못해 요구사항에서 명시적으로 작성하지 않거나, 누락된 부분이 실제 버그로 이어지는 경우가 많았다. 이를 보완하기 위해 요구사항을 도메인 별로 세분화해서 정리하고, 구현 후 확인할 수 있는 체크박스를 작성했다. 또한 요구사항 템플릿을 만들어서 검증 과정을 체계화했다.

2. 도메인 설계 방식 개선

이전에는 요구사항 작성 후에 바로 기능별 구현에 들어갔는데, 이렇게 진행하면 구현하면서 설계를 진행하기 때문에 시간이 오래 걸리고, 설계를 변경하는 경우가 많아지는 문제가 있었다. 그래서 스터디원의 조언을 받아들여 요구사항 분석 직후 도메인 설계를 진행하는 방식으로 변경했다. 도메인 설계 과정에서 객체의 필드와 기능을 정리함으로써 결과적으로 구현 시간이 단축되고 객체지향적으로 책임 분리를 할 수 있었다.

3. View 계층을 우선적으로 정의

복잡한 출력 요구사항을 처리할 때 여러 객체를 조합하는 것이 생각보다 시간이 오래 걸린다는 점을 깨달았다. 스터디 원 중 한분이 View를 먼저 정의하고 DTO로 출력 메세지 형식을 미리 결정하는 방식을 공유해주셔서, 이 방식을 적용하면서 출력 로직이 상대적으로 복잡한 경우(ex) 다리 건너기)에서 초기부터 출력 테스트를 진행할 수 있었고, dto를 고려하여 객체를 설계하며 전반적으로 문제 접근 방법이 수월해졌다.

4. 테스트와 리팩토링 전략 수정

프리코스에서는 TDD나 구현 후 바로 테스트를 작성하는 방식으로 수행했지만, 5시간이라는 제한 시간 내에서는 우선 완전한 요구사항 구현이 더 중요하다는 것을 깨달았다. 따라서 구현을 먼저 완료한 후 테스트를 작성하는 방식으로 변경했다.
또한 리팩토링은 바로 수행할 수 있는 간단한 부분만 구현 과정에서 진행하고, 메서드 순서 조정이나 인터페이스 도입같은 큰 변경은 구현 완료 후로 미루어서 구현시간을 단축할 수 있었다.

 

최종 코딩테스트 당일

일찍 도착했는데 자리가 정해져있어서 자리표를 보고 앉으면 되었다. 귀여운 피규어와 노트, 선물등을 주셨고 간식이 많았다.

와이파이

지정한 와이파이만 써야하는데 (인터넷 기록 확인을 위함) 일반 웹사이트에 들어갔을 때 "안전하지 않음" 창이 뜨며 접속이 안되는 문제가 있었다.

화면 가운데를 클릭하고 thisisunsafe를 치니 접속이 되었다.

https://blog.naver.com/sooni_/222438571322

환경 설정

intellj에서 ai 관련 플러그인을 끄도록 안내하였는데, 설정을 하다 code completion의 option+enter와 파라미터 팝업까지 꺼버려서 파라미터와 메서드 명이 전혀 안보이고 템플릿도 이용하지 못하는 문제가 발생했다. 이 문제로 인해 거의 3-40분간을 집중을 제대로 하지 못했다.

시간 부족

view쪽 처리를 하다가 중간에 포비님이 오셔서 전체 시험보시는 분들에게 먼저 기능별로 구현을 하라는 팁을 주셔서 view에 더이상 시간을 쏟지 않고 먼저 기능을 구현하기 시작했다. 기능을 구현하다보니 1~4번까지의 각 기능에서 요구하는 부분(검증, 구현)이 많아 시간 내에 구현하는 것이 쉽지 않을 것이라는 생각이 들었다.

 

정렬 외 모든 기능을 구현한 후 출력을 확인해보았을 때 출석 기록에서 빈 부분을 처리해주어야하는 것을 깨달았다. 원래 기능 구현 전 후에 작성한 기능 목록을 한번 더 훑어보는데, 이번 구현에서는 시간 부족 문제로 기능목록을 제대로 보지 못해서 그러한 문제가 발생했다. 수정하다보니 1시간이 남아있었다.

 

1시간이 남았을 때 우선 테스트 작성보다도 버그를 수정하고 ApplicationTest를 모두 통과하는 것을 목표로 하자라고 생각하고 코드를 수정했고, 많은 버그를 발견했다. 하나씩 수정하면서 시간이 다 되어 소감문과 함께 제출했다. (끝내 모든 버그들을 수정할 수 없었다...)

 

최종 제출 상태 : 3/5

페어 매칭이나 온콜 문제를 시간재고 풀면서 이정도로 못풀었던 적이 없어서 더 아쉬웠다.
편의점을 5시간 내에 풀 수 있었다면 해당 문제를 풀어낼 수 있었을 것이라는 생각이 들었다. 또한 LocalDate를 잘 다루고, 환경 설정이 제대로 잘 되어있었다면 더 잘 풀 수 있었을텐데 라는 생각이 들었다. 내가 그러한 대비를 하지 않은 것이 이번에 잘 테스트를 통과하지 않은 문제라는 생각이 들었다.

 

제출 후 코드 틀린 이유 분석하기

틀린 테스트 분석하기

하나는 출력문 모두를 포함하지 못했다는 예외가 있었고, 하나는 No line found 예외가 발생했다.

1. 출석 확인 테스트

outputView의 출력 메서드를 호출하지 않아서 틀렸다.
실전에서는 출력 메서드를 호출하지 않았을 것이라는 생각을 하지 못하고(지금까지 그런적이 없었기에)DateTimes.now() 부분에서 문제가 있나 하고 그 부분만 확인했었다. 만약 테스트 결과를 꼼꼼히 보고 출력이 찍히지 않은 것을 알아채어 outputView 문제가 아닌가하는 생각을 하면 바로 고칠 수 있었을 것이다.

 

지금까지는 시간이 부족한 상태에서 view를 처리한적이 없었기 때문에 해당 문제를 생각하지 못했다. 또한 출력 양이 많아 출력 메서드를 굉장히 쪼갠 상태로 구현하였기 때문에 시간 부족 상황에서 어떤 메서드를 호출했는지 미처 파악하지 못했다.

2. 주말 또는 공휴일 예외 테스트

No line found 예외가 발생했다. 해당 예외가 발생했을 때 디버깅을 하다 살짝 패닉이 와서 다른 부분부터 먼저 고쳐야겠다고 방향을 틀었다.
종료 전 문제를 발견했는데, 출석 확인 기능을 선택하면 바로 예외가 떠야하는데, 모든 입력을 받고 예외가 발생하여 해당 에러가 발생했다. 마지막에 발견하여 끝내 수정할 수 없었다.
제출이 끝나고 날짜 검증하는 메서드를 먼저 호출했더니 통과했다.

 

최종 제출 후 테스트를 수정하면서 느낀 점

구현을 하면서 내가 작성한 로직이 완전하다는 착각에 빠져 테스트를 제출 1시간 전에 돌려본 것이 가장 큰 문제이다. (출력 정렬까지 구현 하지 않고 그나마 1시간 전이라도 테스트를 돌려본 것이..)

포비님 말씀처럼 한단계씩 구현을 완전히 완성해나갔다면 테스트는 다 통과했을 것이다. 왜냐하면 테스트가 대부분 기능 1 구현에 맞추어져있기 때문이다. 모두 다 구현하려고 했던 욕심과, 테스트가 기능 1 구현이 아닌 전체적인 기능 구현에 초점이 맞추어져있다고 짐작하여 콘솔로만 테스트한 것이 이번 테스트를 통과하지 못한 원인이다.

 

끝나고 본 나의 코드

날짜, 시간 계산 책임 분리 필요

날짜, 시간 계산이 많았기 때문에, 2024년 12월 한 달에 대한 날짜 계산을 수행하는 클래스 하나를 만들어서 책임을 분리했다면 중복되는 코드가 없고 더 쉽게 코드를 작성할 수 있었을 것이다.

• ex) 2024년 12월에 날짜만 받아 생성하는 정적 팩토리 메서드를 만들어 사용했다면 훨씬 코드가 깔끔할 것이다.
• ex) 매번 LocalDateTime의 getDayOfWeek(), getDayOfMonth()를 호출하기 보다 해당 날짜 객체의 메서드를 만들어 재사용했다면 훨씬 코드가 깔끔했을 것이다.

 

중복 코드가 많고 코드가 길다

원래라면 중간중간 조금씩 리팩토링을 하면서 구현하는데, 처음 요구사항을 보고 이걸 시간 내에 구현하려면 최대한 빠르게 구현해야겠다는 생각을 가지고 구현하였다. 그러다보니 리팩토링을 전제로 구현하여 15줄을 넘은 코드들이 있고 중복 코드가 많다. (시간 부족으로 인해 리팩토링은 하지 못했다.)

 

시간 부족을 만든 상황 : 복잡한 요구사항 연습 부족

사실 지금까지 페어매칭과 온콜을 4시간 안에 풀고 테스트도 작성하였기 때문에 충분히 연습이 되었다고 생각했다. 그런데 이번 미션에서는 5시간 내에 모든 기능을 구현하지 못했다.

 

연습에서 편의점을 시간 재고 구현했을 때 8시간 정도가 걸렸는데, 이걸 한번 더 풀어서 5시간-6시간 내로 구현을 마무리하기 위해 노력했다면 결과는 달라졌을 것이다. 편의점 문제만큼 최종 코딩테스트에서는 나오지 않겠지라는 마인드 때문에 충분히 더 연습하지 못한 것이 가장 큰 문제이다.

중간에 설계를 수정하지 않음

원래 연습때라면 설계가 요구사항에 들어맞지 않을 경우 바로 수정하고 전반적인 코드를 그에 맞춰 수정했다. 그런데 이번 미션에서는 구현양이 많았기 때문에 최대한 기존 설계를 수정하지 않고 구현하려다보니 중복 코드도 많고 굉장히 코드가 더러워졌다. 이 문제도 위와 같이 복잡한 요구사항을 충분히 연습하지 않았기 때문이다.

 

실전에서 예측하지 못한 상황을 대비하지 못함

5시간 시간을 재고 연습하면서 순수 미션 구현 시간만 재고 연습했다. 그런데 생각해보면 Collaborator도 추가해야하고, 실전에서 예측가능하지 못한 문제들도 있어서 30분 정도를 날릴 수 있다고 생각하고 준비했어야했다. 실전이 연습과 크게 다르지 않을 것이라는 약간의 자만심이 내가 좋은 결과를 얻지 못한 원인인 것 같다.

 

마치면서..

잠실에서 시험을 보면서 코치분들도 보고 디코에서 친해진 분들과 밥도 먹고 이야기도 할 수 있어서 좋았다.

 

가장 아쉬운 것은 미션 제출 결과와 내 코드인데, 다시한번 내 부족함을 느끼고 더 성장해야겠다는 생각이 든 하루였다. 압박감이 존재하는 환경에서 주어진 시간 내에 최소한의 좋은 품질을 유지하는 소프트웨어를 만들기 위해서는 나의 체력과 멘탈을 키워야겠다는 생각을 했다. 그리고 예측하지 못한 상황에서도 시간 내에 좋은 결과를 얻기 위해서 더 연습하고 정진해야겠다는 생각을 했다.

 

결과는 아쉽지만 더 성장해야겠다는 생각이 많이 드는 하루였고, 앞으로의 개발자로서의 삶에서 잊지 못할 하루가 될 것 같아 감사하다.

다시 나의 코드를 살펴보는 것이 굉장히 고통스러웠지만 그래도 그 시간동안 최선을 다했기 때문에 더 좋은 코드로 꼭 리팩토링을 하고 싶다.

 

다들 정말 고생많으셨습니다!

 

다시 풀어본 최종 미션

https://github.com/Starlight258/java-attendance-7/pull/1

[출석 시스템] 다시 풀기 by Starlight258 · Pull Request #1 · Starlight258/java-attendance-7