들어가며
Next Step에서 진행하는 TDD, 클린 코드 with Java 18기가 끝이났다!
네이버 부스트 캠프 마스터 클래스 시간에 Next step 이야기를 몇 번 해주셔서 기회가 되면 들어야지 하고 기억하고 있다가,
3월에 무슨 공부하지.. 고민하던 차에! 마침 수강신청이 올라와서 완전 럭키 하게도 좋은 타이밍에 듣게 되었다.
회사 교육비 지원의 1년치 몰빵해야하는 금액이라 부담이 되기도 했지만 (내돈도 아닌데 왜 부담이야)
단위 테스트 스터디 이후에 테스트 코드를 작성한 이후에 외부 의존성과 격리가 잘 되어 있어야 테스트 코드도 유지보수하기가 쉽다는걸 많이 느끼고 있었다.
뿐만 아니라, 입사 후 코드리뷰 문화가 점점 약해지는 것 같아, 배워서 또 전파하자는 마인드로 신청했다.
3월 초부터 시작해서 6주간 4개의 프로젝트를 수행한다.
아무튼 진짜 회고
무엇을 알게되었는가?
- 객체 지향 설계 연습
- 객체 분리 연습
- 일급 컬렉션
- 점진적인 리팩토링
구체적으로 쓰지는 않겠지만 과제와 강의는 위의 내용들을 중심으로 진행되었다.
그 중 일급 컬렉션은 진짜로 처음들어보는 단어였는데 향로님 블로그에 잘 정리되어있어, 강의 전에 과제에서 적용해보는데 많은 도움을 받았다.
뭐가 제일 좋았는가?
모짝미라고 해서 주말 오후에 오프라인으로 페어프로그래밍을 했던 것이 가장 기억에 남는다.
이전에도 페어프로그래밍을 몇 번 해봤었는데, 페어프로그래밍이 확실히 구현 속도 자체는 혼자 하는 것보다 느리지만, 그보다 코드 작성하는 방식에 있어서 배울 점이 분명히 있다고 생각한다.
TDD 자체에 대한 학습은 하지 못했기 때문에, 테스트를 먼저 작성해두고 코드를 작성하는 연습만 혼자 하고 있었다.
정말 럭키 하게도 같이 페어프로그래밍을 하게 된 분은 TDD 공부를 하고 계셔서, 페어 프로그래밍을 하면서 속성으로 많이 배웠다.
- 우선 테스트를 먼저 작성한다.
- 테스트할 실제 메소드(A라 칭함)의 형태만 작성하고 return은 테스트가 성공하도록 값을 강제로 넣어둔다.
- 테스트가 성공하는지 확인한다.
- A 실제 내부 구현을 한다.
- 구현 후에도 테스트가 성공하는지 확인한다.
- 수정 또는 리팩토링을 할 때 마다 테스트가 성공하는지 계속 확인한다.
TDD가 사실 혼자 하다보면 약간의 귀차니즘..때문에 자신과의 합리화를 하면서 아 일단 코드 먼저 작성해야지~ 할 수 있는데, 옆에서 "테스트 코드 먼저 작성하셔야죠 ㅇ_ ㅇ" 하고 빠안히 쳐다보고 있으면 반강제로라도 하게 된다. (나도 당하고, 나도 시전했음)
페어프로그래밍 뿐만 아니라 자바지기님께 현장에서 궁금한 점을 직접 여쭤볼 수도 있고 먼저 와서 더 생각해볼 수 있는 부분에 대해 질문을 던져주셔서, 주어진 요구사항 이상으로 더 생각해볼 수 있었다.
개인 사정으로 두 번의 모짝미 중, 첫 번째 모짝미는 참석하지 못했는데 두 번째 모짝미가 너무 좋았어서 첫 번째에 참여하지 못한 것이 아쉽다.
내가 부족한 점은
- 코드리뷰
- 구현하면서 이렇게할까, 저렇게할까 하는 고민들이 머릿 속에 많이 쌓여있었는데
그 고민들이 머리를 스칠 때 마다 적어두었다가 리뷰 요청 때 물어봤으면 좀 더 다양한 의견을 들을 수있지 않을까 하는 생각이 든다. - 막상 리뷰 요청을 하면서 Description을 쓰면 머리에서 생각보다 휘발이 많이 되어있어서, 기억나는 한 두개 정도만 여쭤보게 되더라..!
- 인터페이스 분리
- 코드 리뷰를 받으면서 인터페이스 분리와 관련하여 조언을 들었는데, 인터페이스를 먼저 설계하고 구체 클래스를 구현하는게 올바르다.
- 이전에 회사 코드 리팩토링을 진행하면서 구체 클래스를 먼저 생각해보고 이에 약간 끼워맞춘 인터페이스를 작성한 경험이 있어서 조금 부끄러웠다.
- 개념은 아는데 막상 잘 해내는 것이 쉽지않다는 것을 느꼈다.
그래서 코드가 변화했는가?
회사 내부 이슈로 거의 반년을 신규 개발 없이 유지보수만 하던 와중에,
3월 중순부터 신규 개발 건이 생기면서 일급 컬렉션을 적용할 수 있는 부분이 눈에 들어왔다. (럭키)
기존의 API에서 가격 관련 기능을 붙이게 되었는데, Repository 의존도 늘어나고 비지니스 로직이 많이 추가되다 보니 로직을 뜯어내야겠다고 생각했다.
Service에서 DB에 후보군인 가격들을 조회하고, 이 중에 어떤 것을 가져와 적용할건지 결정하는 로직을 일급 컬렉션으로 분리했다. (아래 다이어그램 참고)
public class PriceCandidates {
Map<PriceType, List<Price>> priceCandidates;
public PriceCandidates(List<Price> priceCandidateList) {
this.priceCandidateList = priceCandidateList.stream()
.collect(Collectors.groupingBy(Price::getType));
validatePriceCandidates();
}
public Optional<Price> determineFinalPrice() {
if (doesNotExistPrice()) {
return Optional.empty();
}
return combineTypes();
}
// List 중 한 개의 요소를 결정하는 비지니스 로직을 private method에서 수행
}이렇게 결정하는 로직을 일급 컬렉션이 있는 클래스에서 수행하도록 했더니, Repository와 분리되면서 로직만 딱 테스트할 수 있도록 되었다.
이 부분은 테스트를 더 쉽게 작성할 뿐만 아니라, 몇 주 뒤에 결정 조건을 요구사항 변경으로 인해 수정하면서 테스트 코드를 수정하는 작업이 이전에 비해 매우 빨라져서 매우 만족스러웠다.
일급 컬렉션을 사용하도록 유도된 과제를 넘어서,
실제 내 코드에서 필요한 지점을 찾아서 적용해보는 데에 의의를 가지고 뿌듯하게 생각한다.
앞으로는 뭘 할 것인가?
TDD와 Clean Code를 위한 준비 운동을 한 것 같다. (좋은 뜻)
책만 읽으면, 실제 내 코드에 어떻게 적용하지? 하는 고민들을 많이 느끼게 되는데, 과제를 하면서 실천의 시작을 하게되었다고 생각한다.
단순히 지식 전달의 강의가 아닌 실천까지 하는데 의의가 있었던 수업이였기 때문에, TDD와 Clean Code를 책을 읽으면 더 나은 코드를 작성할 수 있을 것이다.
마무리하며
처음에는 6주인데 미션이 4개면 한 주에 1개씩 하고도 남는데? 부캠 챌린지보다 덜 빡세겠네 하는 이런 아방한 생각으로 시작했는데 (실제로 지인에게 한 말), 코드 리뷰를 받고 개선하는 시간들도 있고 개인 적인 일도 겹치다 보니, 4개 미션을 기간 내에 끝내기 위해서는 진짜 시간을 쪼개서 이 과제만 하고있었다. ㅎㅎ 쉬고싶어
어쨋든 간에, 내 코드를 좀 더 객체 지향적으로 개선시켜보고자하는 의지가 있고, 퇴근 후에 과제를 한다는 것에 거부감이 없는 사람들에게 회사 교육비로 듣는 것을 추천한다!
