서론
1주차 미션은 7개의 코딩테스트 문제를 푸는 것이다.
필자가 느끼기에 1~5번 문제는 프로그래머스 기준 레벨1, 6~7번 문제는 2~3정도 라고 생각된다.
여기서 중요한 것은 진행 방식이다.
프로그래머스 진행 방식
- 미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다.
- 세 개의 요구 사항을 만족하기 위해 노력한다. 특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다.
- 기능 요구 사항에 기재되지 않은 내용은 스스로 판단하여 구현한다.
여기서 프로그래밍 요구 사항과, 과제 진행 요구 사항은 설명을 따라하면 되기에 넘어가고 기능 요구 사항이 메인 문제이다.
특히 기능을 구현하기 전에 기능 목록을 만들고, 기능 단위로 커밋 하는 방식으로 진행한다. 이 문장이 이번 주차 회고의 핵심이다.
기능 목록
기능 목록은 무엇을 기준으로 나눠야 할까라는 생각을 많이 했다. 필자는 기본적으로 코딩 문제를 풀때 기능 목록을 나눠서 풀어본 적이 없는 것 같다. 프로젝트를 할 경우에도 크게 크게 나누고 거기서 extract method로 메소드로 분류를 했었다.
문제 1번을 예시로 기능 목록을 초기에 나눴을 때
이런 식으로 기능 목록을 나눴는데 두 가지 의문이 들었다.
- compareNum메소드는 if else를 통해 값을 비교하는 것인데 메소드로 빼는게 맞는가
- getMaxNum메소드 안에서 각 자리를
더하거나,곱하거나라는 기능이 있는데 이 부분도 메소드로 빼서 구해야 하는가
의문을 해결하기 위해 필자는 선배님께 질문을 하게 되었고 얻은 해답은 아래와 같다.
코드는 작업을 조정하는 코드와 작업을 수행하는 코드 두 가지로 나눠볼 수 있는데 작업을 수행하는 것을 보통 알고리즘이라고 할 수 있고, 작업을 조정하는 코드는 위 사진에선 solution이라 할 수 있다.
필자는 작업을 수행하는 코드를 메서드로 빼는 것을 목적으로 기능 목록을 구현하였고
위 문제 1번의 완성 코드는
같이 완성되었다.
기능 단위 커밋
이 부분이 아직 너무나도 익숙하지 않고 문제 특히 7번은 기능 단위 커밋을 완벽하게 지키지 못한 것 같다.
필자의 커밋을 기준은 기능 목록 구현 -> 기능1 구현 -> 기능2 구현 -> 조정 기능 구현 형식으로 커밋을 찍었다.
기능 단위의 커밋을 하고 단위 테스트를 진행하며 코딩을 이어 갔다. 항상 큰 단위의 기능을 테스트만 해보았는데 분리된 기능을 테스트하면서 Junit의 편리성을 알았다. 기능 구현에는 문제가 없었지만 마지막 기능들의 조정하는 코드를 구현하는 도중 이전에 구현한 기능의 수정이 필요한 경우가 있었는데
- 반환타입이 원하는 값이 아닌 경우
- 기능의 로직의 수정
이러한 경우 현재는 조정하는 기능 코드를 지우고 구현한 코드를 수정 후 Refactor 커밋을 찍고 다시 조정하는 코드를 이어갔다... 이 방법에 대해서는 어떻게 해야할지 개선이 필요해보인다. 현재 생각나는 것은 브랜치를 분리해 작업하는 것인데 결국 충돌을 잡아주는 작업이 필요하기에 다른 방법이 더 좋아보인다.
결론
- 기능 목록을 나누는 기준(수행 코드, 조정 코드)을 알 수 있는 시간이었습니다.
- 기능 목록을 만들 당시에 더 신중하게 고민하여 수정이 없도록 설계해야겠다고 생각했습니다.
- 기능 단위 구현을 통해 코드의 가독성과 명확성을 느낄수 있었고 단위 테스트의 편리성을 알 수 있는 시간이었습니다.
질문할 것들
- 문제들의 답안이라고 생각하는 코드와 커밋을 볼 수 있는가.
- 단위 테스트 케이스를 짜는 팁이 있는가.
- 기능 단위로 로직을 구현할 경우 만일 이전에 구현한 기능의 수정이 필요한 경우에는 어떻게 해야하는가(중요).
