그러나 나의 경우에는 주로 기능 구현과 테스트를 분리해 커밋하고, 테스트와 관련된 사항들은 모두 test 타입을 사용하고 있었다.
이에 커뮤니티에 다른 동료들의 의견을 물어 보았다. 평소 같았다면 혼자 구글링하고 자료를 찾아보며 결정을 내렸겠지만, 이러한 프리코스라는 기회가 주어진 만큼 의견을 물을 수 있는 좋은 동료들이 있는 환경에서는 조금 더 용기내야겠다는 생각을 했다.
이에 세 분의 댓글이 달렸고, 정리해보자면 공통적으로 기능 구현이 정상 작동하는지 확인하는 것까지 하나의 흐름이기에 같이 커밋해야 한다는 의견이었다. 이 의견에 나 역시 동의하여 앞으로는 해당 부분을 참고해야겠다는 생각을 했다.
이렇게 확신이 서지 않는 부분에 대해 공유를 하고 나니, 목표를 이뤘다는 뿌듯함과 어떤 방식으로 다른 사람들의 의견을 참고하며 기준을 정립해 나가야 하는지에 대한 방향성이 생겼다.
📝 두번째 목표, 나만의 타당한 기준 정립하기
이 목표를 떠올리며 꾸준하게 임했던 태도가 있다. '왜' 라고 스스로에게 자꾸만 질문하는 것이었다.'이 메서드는 정적 메서드가 좋겠어' 하고 생각하며 나도 모르게 구현에 급급해 움직이던 손을 의식적으로 멈추고 왜 정적 메서드가 좋은지 알아보는 것부터 시작했다. 이 태도에 대해 뭐라고 정의내려야 할지 고민하다 보니, OT 에서 봤던 '메타인지'가 머릿 속에 스쳤다. 나도 모르게 이번 주에 메타인지를 사용해 사고하는 것을 실천했던 것 같다.
1. 객체지향에 대해
본격적인 기능 구현에 들어가기에 앞서 자꾸만 내 머릿 속에 떠오르는 키워드가 있었다. '객체지향' 이었다.
이가 중요한 패러다임이라는 것은 알고 있지만, '왜' 라는 질문에 대답할 수 없다는 것을 깨달았다.이에 객체지향적으로 설계해야지 라는 생각부터 지우고 왜 내가 객체지향을 해야 하는지부터 고민을 하기 시작했다.관련된 자료들을 찾아보다, 인프콘 2024에서 조용호 연사님이 강연해주신 '객체지향은 여전히 유용한가?' 라는 강의를 들어 보았다.이를 통해 언제 어떤 경우에 객체지향이 옳은지 알게 되었고, 무조건적으로 절차지향을 지양하고자 하는 태도는 옳지 않다는 것을 알게 됐다.강연 내용과 위의 자료를 바탕으로 과제를 풀어 나가다 보니, 절차지향적으로 설계를 하게 됐다.계산을 하기 위해서는 사용자의 입력값(데이터)이 노출이 되어야 변환, 검증 및 계산이 편리할 것이라고 생각했기 때문이다.처음에는 이러한 사고를 바탕으로 절차지향적으로 코드를 설계했다. 그러나 추후에 코드의 사이즈가 커질수록 객체지향에서 이야기하는 행동 중심의 기능들이 보이기 시작했다. 이에 현재 나의 코드에서 '행동'이라고 정의할 수 있는 것들을 나열하고 다른 객체로 분리되어야 할 만큼 책임이 흐름을 관장하는 Processor 와는 다른 것 같은 객체들을 분리하기 시작했다.
이에 Processor 하나의 클래스에서 Calculator, Validator, Splitter 라는 객체가 탄생하게 됐다.
2. 모델에 대해
코드를 살펴보며 문득 숫자 자체를 모델로 정의해야 할지에 대한 고민이 들기 시작했다.
이에 모델이 어떤 경우에 필요한지에 대해 먼저 공부를 해봤다.
모델은 1. 복잡한 비지니스 로직이 있거나 2. 데이터의 무결성이 것이라는 우려가 들 때 필요하다고 한다.
이후 숫자 자체가 모델로 정의해야 하나 라는 고민에 대해 나의 대답은 No 가 되었다.
1. 숫자 자체에는 복잡한 비지니스 로직이 없고 2. int, 즉 원시 타입으로 정의된 숫자는 데이터 무결성이 해쳐질 우려가 없다고 판단했기 때문이다. 또한, int 자체로 이미 숫자 모델과 비슷한 기능을 한다고 생각했기에 모델로 정의하지 않기로 결정했다.
그러나, 위와 같이 모델로 정의되어야 하는 경우를 보니 int 배열이 모델로 선언되어야 하는 게 아닐까 하는 생각이 들었다.
배열은 외부에서 요소를 변경할 수 있기에 무결성이 우려가 되었고 숫자들의 합을 반환하는 기능이 필요하기에 숫자 하나하나보다는 이 과제에서는 '숫자들' 이 더 의미를 갖는다는 생각을 했기 때문이다. 또한, 복잡한 계산 기능이 필요해져 계산 기능을 하는 객체를 분리한다고 했을 때도 int 배열 자체보다는 모델로 선언된 배열을 넘기게 되면 도중에 변경될 가능성도 없기에 조금 더 견고한 설계가 가능해질 것이라고 생각했다.이렇게 배열 자체를 모델로 선언하는 것에 대해 찾아보니 '일급 컬렉션'이라는 것을 알게 됐다. 이후 Numbers 라는 이름의 일급 컬렉션을 선언해 int 배열을 감쌌다.
public class Numbers {
private final int[] numbers;
public Numbers(int[] numbers) {
this.numbers = new int[numbers.length];
for (int i = 0; i < numbers.length; i++) {
validate(numbers[i]);
this.numbers[i] = numbers[i];
}
}
private void validate(int number) {
if (number < 0) {
throw new IllegalArgumentException("양수만 입력하실 수 있습니다.");
}
}
public int calculateSum() {
return Arrays.stream(numbers).sum();
}
}
// Numbers 추가 전
int[] numbers = Converter.toIntArray(splitInput);
Validator.isAllPositiveNumbers(numbers);
return Calculator.calculateSum(numbers);
// Numbers 추가 이후
numbers = new Numbers(Converter.toIntArray(splitInput));
return numbers.calculateSum();
이렇게 구현하니, Validator 에 있던 검증 로직을 내부로 가져와 음수인 숫자는 아예 배열에 추가될 수 없도록 막을 수 있었다.
또한, 외부로 굳이 숫자를 넘기지 않고도 내부에서 계산을 처리할 수 있게 되어 비교적 코드가 깔끔해질 수 있었다.
🥳 이번 주차의 소감
이번 주차를 통해 프리코스의 가치를 조금 맛봤다. 어떤 방식으로 이 기간에 집중하면 내가 더 성장할 수 있을지에 대해 어느 정도 말미를 잡은 것 같다. 이를 위해서는 계속해서 내가 결정하는 사소한 것들의 이유를 스스로에게 되물어보고 확신이 서지 않는 부분에 대해서는 타인의 고민 과정을 방해하지 않는 선에서 혹은 과제가 마무리 된 이후에 질문을 해야겠다.
이전까지는 다른 사람들의 의견에 조금 더 치우쳐진 코딩을 해왔던 것 같다. 다른 사람들이 좋다고 하는 방법론들을 무조건적으로 수용하고, 이를 코드에 반영하기 위해 노력해왔다. 그러나 이번 주차의 비교적 간단한 과제를 구현하면서도 다양한 방식으로 고민을 해보며 어떻게 내가 나의 기준을 정립해 나가고 공부해야 하는지에 대해 깨달았다. 첫번째 주차라고 열심히 임하는 것이 아니라 앞으로도 꾸준히 집중하고 몰입하는 시간으로 만들어 나가고 싶다.
💭 다음 주차의 목표
1. 의견을 공유하기
사실 이번 주차에 타인의 글에 댓글을 남겨 나의 의견을 공유하는 것 역시도 나의 목표였다. 그러나 나의 의견이 제대로 정립되지 않았다는 생각에 주저하게 됐고, 잘못된 정보를 전할까 두렵기도 했다. 이를 극복하고 싶었지만 이번 주차에는 적응해 나가느라 제대로 공부해 나의 의견을 피력할 시간이 부족했던 것 같다. 다음 주차에는 꼭 토론에서 나의 의견도 공유하기 위해 노력해보고 싶다.
2. java21 의 기능 적용해보기
이번 주차에 java21 에 새롭게 적용된 기능들에 대해서도 공부를 했다. 그러나 이에 대해 어떻게 적용해야 할지 아직은 감이 잘 오지 않아 사용하지 못했다. 다음 주차에는 한번 같이 고민해보고 적용할 수 있는 부분들에 대해 적용해 보아야겠다. 특히 리스트 부분에서 적용할 여지가 있을 것 같다.
3. 코드 리뷰 3개 이상 참여하고, 3개 이상 받기
'코드 리뷰 열심히 하기' 보다는 수치화하는 게 좋을 것 같아 3개로 정해 보았다.타인의 코드를 보는 눈도 키우고 내가 헷갈렸던 부분들에 대해서도 정립하기 위해 코드 리뷰를 3개 이상 받으려고 노력해야겠다.
