레벨 1 - 출석 회고

레벨 1의 두번째 미션인 출석이 끝났다.
 
이번 미션은 1단계에서 페어랑 함께 TDD로 구현하고, 2단계에서 혼자 처음부터 다시 TDD로 구현하는 것이 요구사항이었다. 우선 1단계는 많이 힘들었다. 그 명성과 대략적인 프로세스만 들어봤지, TDD를 직접 해보기는 처음이었기 때문이다. 페어인 젠슨도 TDD가 처음이었어서 둘이서 상당히 헤맨 기억이 있다. 무엇보다 어디서부터 어떻게 시작해야할 지가 가장 막막했었다. 예를 들어 A 객체에 대한 실패하는 테스트를 만들고 구현하자니, B 객체가 필요했다. 그래서 B 객체에 대한 실패하는 테스트를 만들고 구현하고자 하니, 또 C 객체가 필요했다. 이런 것이 몇번 반복되다 보니 젠슨이랑 나는 당황스러운 감정을 감추지 못하고 같이 웃기 바빴다. 지금 돌아보니 젠슨이랑 많이 웃을 수 있었어서 좋기도 했고.. 아무튼 1단계는 대략 10% 정도의 TDD를 적용할 수 있었다. 우테코는 크루들이 어려워할 것을 알기에 2단계에서 혼자 처음부터 해보라고 했던 것 같다.
 
그래서 2단계에서는 제대로 TDD 사이클을 지켜가며 구현하고자 했다. 우선 1단계에 가장 큰 문제가 무엇인가 생각했을 때 설계를 하지 않고 큰 단위부터 TDD 사이클을 적용하려고 했던 것이라고 생각했다. 실제로 미리 책임과 역할을 생각하며 설계를 어느정도 잡아 놓고 가장 작은 단위부터 시작했던 다른 크루들은 제법 TDD 사이클을 지켜가며 개발했다고 했다. 이처럼 가장 아래서, 작은 것부터 프로그래밍하는 방식을 바텀-업이라고 한다. 반대로 나랑 젠슨이 했던 방식은 탑-다운 방식이다.

네오(코치)는 탑-다운과 바텀-업 어느 하나만을 고집하기 보다는 왔다 갔다한다고 한다. 바텀-업으로 하다가 막히거나 뭘 더 해야할 지 모를 때는 다시 탑-다운으로 하고. 또 탑-다운으로 하다가 어떠한 작은 기능이 필요할 때는 바텀-업으로 개발하고. 좋은 방식 같다.

아무튼 나는 탑-다운 방식으로 미리 설계를 하고, 바텀-업 방식으로 가장 작은 단위부터 TDD 사이클에 맞추어 구현했다. 예시로 아래처럼 애플리케이션의 흐름을 책임과 역할에 집중하여 쭉 작성하고(구현이 아닌). 그리고 가장 테스트하기 쉬운 기능부터 실패하는 테스트를 작성하고 구현, 리팩토링을 했다.
 

/*
application에서 출석 관리자 객체에게 크루 이름과, 오늘 날짜, 출석 시간을 넘겨주며 출석 확인을 요구
출석 관리자는 받은 날짜의 요일과 시간을 출석 정책에게 넘겨 출석 상태를 반환할 것을 요구.
출석 정책은 출석 날짜와 출석 시간을 기반으로 출석 상태를 반환. (테스트하기 쉬워 보인다)
출석 관리자는 출석 객체에게 출석 날짜, 출석 시간, 출석 상태를 넘겨주며 생성될 것을 요구.
출석 객체는 생성된 자신을 반환.
출석 관리자는 출석 기록들에게 생성된 출석 객체를 넘기며 저장할 것을 요구.
출석 기록들은 넘겨받은 출석을 저장하고 저장된 출석 객체를 반환. (테스트하기 쉬워 보인다)
출석 관리자는 반환 받은 출석 객체를 반환.
*/

 
잘한 것인지는 모르겠지만 1단계에서 애먹었던 것보다는 훨씬 수월했다. TDD의 이점도 보이기 시작했다. 우선 도메인 객체에 대한 테스트 커버리지가 높아질 수 밖에 없어 내 코드에 대한 믿음이 생긴다. 그리고 리팩터링을 했을 때 실수를 빠르게 확인할 수 있어 비교적 과감하게 리팩터링을 할 수 있다. 즉 TDD는 초반 비용이 들지만, 애플리케이션의 규모가 커질 수록 오히려 유지보수 비용을 아낄 수 있다. 마지막으로 작은 단위의 기능들을 개발해놓고 마지막에 끼워 맞추듯이 조합하는게 나름 재미가 쏠쏠하다.
 
첫 TDD니 이정도의 경험을 해본 것만으로도 내가 생각한 목표는 달성했다고 생각한다. 앞으로 있을 미션에서도 TDD로 개발하다 보면 더 확고한 나의 방식과 기준이 생기지 않을까 생각한다. 물론 왜 TDD를 적용해야할까?라는 질문에 나만의 확고한 답변을 찾는게 우선이다.
 
또한 이번 미션을 하며 고민을 몸소 겪어보고 학습하는 경험을 할 수 있었다. 문득 과연 내가 습관적으로 예외를 던지고 있던 상황이 정말 예외 상황일까 생각들었다. 예를 들어 크루 이름과 날짜를 형식에 맞추어 잘 입력했지만, 이미 출석을 한 기록이 있어 중복 출석을 허용하지않을 때를 생각해볼 수 있다. 평소였으면 출석을 하는 로직 내부에 중복을 체크하고 예외를 던졌을 것이다. 하지만 중복 출석 불가라는 비즈니스 로직에 반한다는 이유만으로 예외를 던져도 되는 것일까? 진짜 예외 상황인가? 예외를 던지지 않아도 처리할 수 있지 않을까?하는 생각이 들었다. 출석 로직을 호출하기 이전에 출석을 관리하는 객체에게 해당 크루가 이미 출석한 적 있는 지 여부를 확인한다면 분명 boolean으로 다음 로직을 수행하지 않도록 구현할 수 있다고 생각했다. 이에 관해 여러 크루들과 얘기해보았고 대부분 그냥 예외를 던지라고 말했지만 나를 납득시킬만한 이유가 없었는지 막 와닿지는 않았다.
 
그래서 일단 해보면 장/단점이 확실히 보일 것이라고 생각하고 예외를 던지지 않는 방향으로 구현을 했다. 그렇게 구현을 완료하니 상상만 했을 때는 보이지 않았던 단점들이 명확하게 보였다. 우선 비즈니스 로직에 따른 분기를 처리하는 지점이 너무 많다. 이는 곧 유지보수가 힘든 코드가 된다. 만약 예외 메세지와 함께 예외를 던졌다면 공통으로 처리할 수 있었을 것이다. 그리고 미래의 나 혹은 제 3자가 검증 로직을 거치지않고 도메인 핵심 로직을 호출한다면 개발자가 의도하지 않은 예외가 발생할 수도 있다. 이에 대해 리뷰어인 제이는 호출부보다 도메인 핵심부의 검증이 우선시 되어야 한다고 조언을 주셨다. 눈에 보이는 단점들과 제이의 조언에 따라 고민했던 상황들의 핵심부에서 예외를 던지고 외부에서 공통으로 처리하게끔 수정했다. 수정 전 후의 코드를 같이 보니 내 질문에 대한 명확한 답변을 얻을 수 있었다.

이처럼 당연하다고 생각했던 것들을 일단 없이 해보고 필요하다고 생각되는 시점에 사용해보니. 근거 없이 혹은 어디서 근거를 주워 들어 사용했을 때 보다 더 깊은 이해와 학습을 할 수 있었다. 우아한테크코스에 있는 동안 이처럼 계속 의심하고 근거를 물어가며 나만의 이유를 찾아가는 학습 방법을 연습해보아야겠다. (현재는 컨트롤러를 따로 분리하여 사용해야 할 이유를 찾지 못했기 때문에 만나는 페어들을 설득해가며 Appliction 클래스를 일종의 컨트롤러로써 사용하고 있다.)

이번 페어 프로그래밍에서의 나를 되돌아보았을 때 스스로 지적할 만한 문제가 하나 있다. 어느 오후에 페어인 젠슨이 체력적으로 힘들어 집중을 못하던 때가 있었는데, 나는 미션을 빨리 해결해야한다는 생각에 페이스를 줄이지 않고 빠르게 나갔다. 그로 인해 젠슨은 어느 순간부터 길을 잃었고 결국 집에 가서 코드를 다시 이해하고 와야만했다. 물론 내가 젠슨의 의사를 묻지 않고 진행한건 아니지만, 어느정도 결론이 나지 않으면 일단 해볼까요?하며 진행했던 것이 문제였다. 지난 회고에서 내 스스로 페어가 소프트 스킬을 늘리는 과정이라고 생각했던만큼 젠슨의 페이스에 맞춰줬어야 됐다. 미션 앞으로 죽어라 할 건데, 좀 완성도가 떨어지면 뭐 어떤가.. 그래도 젠슨이 노력해서 다시 페이스를 따라와준 덕분에 미션은 무사히 잘 마무리할 수 있었다. 젠슨은 계속 나보고 미안하다고 하지만, 오히려 내가 너무 미안하다.

지금 회고를 하는 시점에 페어를 3번째 진행 중인데, 통계적으로 보았을 때 내 페이스가 남들에 비해 조금 빠른 편인것 같다.(단축키 활용 등 여러 방면에서) 그래서 최대한 페어의 속도에 맞춰야겠다. 아 밥 먹는 속도도 조원들보다 월등히 빨라서 같은 맥락에서 조금 천천히 먹어야한다.

다음은 나에 대한 젠슨의 피드백이다.

젠슨이 좋은 말을 떠나서 없는 말들까지 적어놓았지만 여기서도 내 단점을 하나 더 파악할 수 있었다. 나는 사람이 말할 때 종종 끝까지 듣지 않고 말을 끊으며 확인하는 나쁜 습관이 있다. 예를 들면 이런 거다.

/*
젠슨 : 근데 이렇게 되면 이중 for문을...
나 : 아 이중 for문을 두번 돌아서 성능이 안좋다?
젠슨 : ㅇㅇㅇ
*/

젠슨은 찰떡 같이 알아듣는다고 좋게? 받아들인 것 같지만, 이건 명백히 나의 단점 중 하나이다. 내 단점을 메타인지한 지금은 말하기 전에 한번 더 생각하고, 상대방을 기다렸다가 확실한 발언권을 얻었을 때 말하기를 노력 중이다. 물론 한번에 고치기가 쉽지 않다. 아무튼 피드백만 보면 젠슨은 오바가 좀 심한듯하다. 그래도 10개월간 함께 할 좋은 친구가 되었다.
 
리뷰어인 제이의 이번 미션에 대한 총 피드백이다.

음.. 그렇다.
요즘 크루들 사이에 본인과 잘맞는 리뷰어에 대한 얘기가 나오고 있는데 나는 제이의 리뷰 스타일과 잘 맞지 않는 거 같다. 내 방식을 존중해주셔서 좋았지만 리뷰어로써는 조금 더 세부적으로 간섭을 해주셔도 좋지 않았을까 싶다.
 
이제 블랙잭과 체스까지 마무리하면 레벨 1 종료다.
조금만 더 힘내서 방학 때 놀러가자~
 
https://github.com/kjyyjk/java-attendance

GitHub - kjyyjk/java-attendance: 우아한테크코스 BE | 레벨1 | 자바로 구현하는 출석