우아한테크코스 프리코스 4주차 후기

실제 제출했던 코드는 여기 있습니다

제출했던 소감문을 바탕으로 적었습니다

이번주 목표

1번만 완벽하게 만들자

1~3주차 까지는 그냥 코드를 많이 짜봐야 될 것 같다는 불안감이 있었기에 많이 짜려고만 했던 것 같습니다

실제로 2, 3주차는 다시 만들어보자는 생각을 가지고 총 3번씩 같은 코드를 작성했기에 여러 요구사항들 중 놓쳤던 부분이 있던 점이 아쉬웠습니다

꼭 프리코스만이 아니더라도 조금 안 좋은 코드임에도 요구사항을 완벽하게 지켜주는 쪽이 더 좋은 개발자라는 생각이 코수타를 통해서 들게 되었습니다

지금까지의 방식과는 거의 반대되는 느낌이라서 이 부분을 내려놓는 과정을 거쳤습니다

같은 문제를 여러번 푸는 것도 많이 배울 수 있었지만, 생각이 굳어버리는 과정이 있었습니다

그래서 하지 않았던 한 번의 코드를 꾸준히 리팩토링 하는 과정을 거쳐보기로 했습니다

 

처음부터 모든 피드백을 다 훑어보고, 지금까지 썼던 회고를 되돌아보니 놓치고 있던 4가지 부분들을 배울 수 있었습니다

배우게 되었던 4가지 항목

1. 기능 목록 작성

지금까지는 할 수 있는 것은 다 적는다는 생각을 가지고 있었습니다

너무 자세한 것을 정하고 시작하려다보니 기능 목록을 수정하는 경우도 많아져서 오히려 방해가 되었습니다

너무 구체적인 것들에 집중하면 큰 그림을 잃어버리게 된다는 것을 배우게 되었고, 큰 흐름 위주로 만들 수 있도록 생각했습니다

그렇기에 기능 목록에 들어갈 내용은 3가지로 정리했습니다

1. 구현 특이사항

문제에서 나오는 특이한 제약 사항들을 모두 적고 있습니다

예를 들면 어떤 부분은 코드를 변경하면 안되고, 시그니처를 변경하면 안되는 것같은 부분입니다

2. 작동 순서

시퀀스 다이어그램 수준의 정교함을 요구하는 것이 아닌, 커다란 단위로 끊을 수 있도록 고민했습니다

어떤 메시지를 출력한다, 어떤 입력을 받는다, 결과를 출력한다

같은 커다란 덩어리로 작업의 순서만을 보장하려고 했습니다

3. 구현 핵심 클래스

구현 특이사항과 연결되는 클래스거나, 전체 흐름에서 진짜 중요하다고 생각하는 클래스만 적었습니다

 

이렇게 3가지를 만들고, 이와 구현 특이사항을 비교해서 확인하며 조건을 이해하는데 들어가는 시간을 줄일 수 있었습니다

 

2. 의미없는 주석은 달지 않는다

어떤 주차에서는 바깥에서 접근 가능한 public 메서드마다 모두 주석을 다는 과정도 있었습니다

무조건 달아야 하니 다는 것보다는, 이름으로 설명하기 힘든 부분이나, 예외같은 부분에 주석을 달게 되었습니다

주석을 안 달려고 하니 오히려 메서드 명이나, 변수명에 신경을 쓰게 되었습니다

특히 주의했던 부분은 2가지 입니다

1. is가 들어갔을 경우에는 무조건 boolean 을 return 하도록 한다

is 내부에서 throw 에러를 해버리는 경우가 있었는데, 이 부분은 is라는 명칭과 어울리지 않는다는 생각을 갖게 되었습니다

2. 평범한 get이라는 내용은 거의 도움이 안 된다고 생각해서 get 이라는 이름을 거의 제거한다

get 을 없애려다보니, 입력같은 경우 receive, 계산은 calculate같은 여러 방식을 적용할 수 있어서 좋았습니다

이렇게 2가지를 신경썼을 때, 지금까지 get만 써왔던 부분에 대한 명칭을 의도적으로 생각할 수 있는 기회를 갖게 되어서 변수명을 짓는 순간이 되게 좋게 작용했던 것 같습니다

 

3. 테스트를 왜 작성해야 되는지를 경험적으로 되돌아보아야 한다는 점

테스트 커버리지 100%라는 그냥 단순히 테스트만을 위한 테스트를 작성했던 경우도 있었습니다

제 생각에 테스트의 장점은 메서드의 목적만 유지되면, 내부 구현을 바꿔도 작동하는지를 검증하기 쉽다는 점이었습니다

이 관점에서 생각했을 때, 단순히 테스트 커버리지 100%를 위한 테스트를 만드는 것은 리팩터링 과정에 도움을 거의 주지 못했습니다

애매한 테스트보다는 확실한 테스트 2가지 종류로 분류해 작성하게 되었습니다

1. 진짜 필요한 단위로 단위 테스트를 하는 경우

전체 어플리케이션 단위가 아닌 진짜 작은 단위로 도메인 로직을 테스트 하는 경우입니다

2. 어찌되었든 결과만 잘 나오면 된다는 통합테스트 결과 

전체 어플리케이션에 해당하는 그런 커다란 단위를 테스트 하는 경우입니다

이렇게 2가지 방식으로 나누면서 리팩터링에 도움을 받기 위한 목적으로 고민하게 되었습니다

효과로는 커다란 단위에서 봐야 의미가 있는 함수들을 테스트하는 쓸데없는 테스트 작성 시간이 없어졌습니다

또한 사소하고 테스트될 필요 없는 부분에 대한 변경까지 테스트에 엮여있지 않기에, 오히려 리팩터링 과정이 편했던 거 같습니다

 

4. 테스트 코드도 코드기에 리팩터링의 대상이 되어야 한다는 점

테스트코드에서 중복을 제거하기 위해서 @ParameterizedTest 를 적극적으로 활용하려는 와중 고민이 생겼습니다

모든 것들을 다 묶어 넣었을 때, 너무 많은 부분들을 한꺼번에 테스트하기에 하나의 역할을 한다는 책임에서 벗어난다는 점이었습니다

그래서 적당한 부분에서는 @ParameterizedTest를, 아닌 부분에서는 @Test를 여러개 사용했습니다

추가로 테스트 코드를 리팩터링하는 과정에서 신경썼던 부분은 여러 작업들을 한  번에 해주는 함수들을 사용하는 것이었습니다

이 과정에서 assertTrue, assertThatIllegalArgumentException() 같은 여러 함수들을 이용하게 되었습니다

테스트 코드 자체의 길이도 짧아지고, 조금 직관적인 테스트코드가 나올 수 있었기에 좋았다고 생각합니다

 

이 4가지의 항목에 대해서 커다란 변화를 느끼게 되었습니다

 

길다면 길고, 짧다면 짧은 1개월동안의 프리코스가 모두 마무리가 되었습니다

이 시간 자체만으로도 정말 커다란 의미를 얻을 수 있었습니다

 

이 코스를 진행하기 전과 후를 비교하게 된다면 정말 큰 차이가 생겼습니다

가장 크게 변화했던 점은 총 5가지로 볼 수 있습니다

1. static의 사용을 줄일 수 있었습니다

1주차에서 처음 짰던 코드를 다시 살펴보면 모든 메서드가 다 static으로 되어있고, Inner Class까지 사용해서 테스트하기도 불가능했고, 가독성도 안좋았습니다

2. for문을 사용하지 않게 되었습니다

정말 필요한 경우에는 while을 사용하고, 거의 대부분의 코드는 stream 을 활용해서 작성하게 되었습니다

주변에 부수효과를 내지 않는 방식으로 코딩하게 되었던 부분이 가독성도 좋고, 이해하기도 좋아서 정말 좋았던 것 같습니다

3. indent를 1로 맞추는 것이 익숙해졌습니다

예전에는 억지로 reduce를 통해서 합치려고 했던 코드가 있었습니다. filter와, count api를 적극적으로 활용하면서 훨씬 깔끔한 코드가 나왔던 것 같습니다

이렇게 억지로 indent를 1로 만드려고 하니, 생각보다 훨씬 가독성이 좋았던 것 같습니다

4. 1메서드에 10줄까지를 생각해보는 것도 좋았습니다

 한 메서드에 10줄 이하로 들어가야된다는 생각을 하고 나니 거의 모든 중복되는 부분을 다 메서드로 분리할 수가 있었습니다

5. 다른 사람의 코드를 보는 것에 효과를 정말 확실하게 느낄 수 있었습니다

처음 봤을 때 와 진짜 저렇게 짤 수 있으면 좋겠다 싶었던 분의 코드에 직접 리뷰를 해보기도 했습니다

직접 생각을 물어보기도 하고, 직접 그 분에게 리뷰를 받기도 하면서 같이 성장할 수 있던 부분이 되게 좋았습니다

 

이런 경험 하나하나가 정말 뜻깊고 좋았던 시간이었습니다

1개월만에 이렇게 많은 부분이 바뀔 수 있다는 것만으로도 정말 놀라운 시간이었습니다

이런 코스를 10개월동안 같이 할 수 있다면 정말 그것만으로도 행복할 것 같은 진짜 힘들었지만 즐거웠던 순간이었습니다

긴 글 읽어주셔서 감사합니다