프리코스 2주차가 끝났다! 이번 미션에서 강조된 것은 함수 분리
와 함수별 테스트 작성
이었다.
이번 후기는 이 두 가지 강조점을 중심으로 작성해보았다.
1. 확실히 함수를 분리할 수록 테스트, 수정, 재사용면에서 이점이 생기는 것이 느껴졌다.
유저의 입력을 String 형태로 받아 고유한 3자리 숫자인지 판단하고 Int 형으로 다시 변환해야하는 기능을 예로 들어보자.
이를 한 함수에 전부 몰아놓을 경우 테스트에서 오류가 발생했을 시, String으로 입력을 받는 것 자체에서 오류가 났는지, 3자리 숫자인지 판단하는 과정에서 오류가 났는지, 각 자리수의 수가 고유한 수인지 판단하는 과정에서 오류가 났는지 그것도 아니라면 Int 형으로 변환하는 과정에서 오류가 났는지 판단하기가 귀찮아 질 수 있다.
만약 코드를 수정해야 할 경우, 어떤 부분이 내가 수정해야할 부분인지 파악하는데도 오래 걸릴 것이다.(혼자 코드를 짜는 것이 아니라 여러명이서 협업을 하는 경우라면 더더욱)
또, 저 안에서 한 가지 기능 ( ex. 고유한 3자리 숫자인지 판단하는 기능) 만을 재사용하고 싶어도 분리가 되어있지 않다면 처음부터 함수를 새로 작성해야한다는 불편함도 있다.
함수를 작은 기능별로 분리하게 되면 위 문제들이 전부 해결된다.
굳~
2. 함수 분리를 잘 하기 위해서는 먼저 기능 정의가 잘 되어 있어야 하는 것 같다.
한 가지 큰 기능에 대해 필요한 작은 기능들이 무엇인지 정리해놓고 시작하니, 코드를 작성할 때도 자연스레 작은 기능들로 함수를 분리하며 작성할 수 있었다.
다만, 기능을 처음부터 완벽하게 분할해놓고 코딩을 시작하려고 했더니 기능 정의에 걸리는 시간이 너무 오래 걸렸다. 이에 대한 타협점을 확실히 정하는 것이 필요할 것 같다.
1. 디버깅 시간이 눈에 띄게 줄었다.
놀랄 정도로 평소에 비해 디버깅 시간이 적었다.
이번 미션에선 함수의 인자, 반환형을 결정한 다음 바로 테스트 코드를 작성한 후 구현을 완료하는 방식으로 코딩을 진행했다.
사실 처음엔 테스트 코드 작성시간 때문에 코딩 시간이 너무 길어질 것 같아 걱정했었는데, 오히려 그 반대였다. 편리한 JUnit과 Assertj 라이브러리덕에 코드 작성 시간자체도 상상이상으로 짧았다.
만약 작성한 테스트 코드를 통과하지 못하는 함수가 있어도 수정 → 테스트 하며 빠르게 디버깅 해 나갈 수 있어 프로그램 전체를 실행시켜가며 테스트를 하는 방법보다 확실히 시간을 아낄 수 있었다.
2. 근데 나 테스트코드 작성 경험이 너무 없네…
private 함수는 어떻게 테스트하지?
사용자 입력을 받는 함수는 테스트할때마다 입력을 넣어줘야하나?
등등… 테스트 코드 작성 도중 생각지도 못한 벽에 막힌 경우도 많았다. 말 그대로 테스트 코드에 대한 경험이 전무한 것이 원인이라고 생각한다.
결국 근본적으로 FIRST 원칙에 어긋나지 않는 코드를 작성하는 것이 가장 효율적인 것 같다고 생각하여 이를 지키는 방향으로 코드를 작성했다.
이번 주 미션도 끝나자마자 커뮤니티에서 몇몇분들의 코드를 확인했는데, 역시 배울점이 많았다.
이번 미션은 특히 패키지구조나 클래스 분리를 잘 하신분들이 많은 것 같다.
나도 나름 이를 신경쓰기 위해 객체지향 5대 원칙을 다시 공부하고 코딩을 하긴 했지만, 지금보니 정면에서 원칙에 어긋나는 코드도 있었다…
아직 갈 길이 정말 멀다~~ 남은 2주도 성장하는 시간이 됐으면 좋겠다