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

우아한 테크코스 3주차 후기

마지막에 제출했던 코드는 

https://github.com/be-student/java-lotto/tree/be-student

에 있습니다

 

이번 주차도 총 3번에 걸쳐서 코드를 만들었습니다

2주차도 3번 같은 코드를 만들고, 내다 보니 시간은 물론 많이 들지만, 많은 것들을 배웠습니다
3주차도 같은 코드를 3번 짜다보니 당연하게도 많은 것들을 배울 수 있었습니다

1번째 만드는 과정

정말 잘 짠것 같아보였던 분의 코드에 있는 기능들을 가져가보자 라는 생각으로 시작하게 되었습니다
1. @ValueSource
2. @ParameterizedTest
3. enum으로 싱글톤을 보장하는 view 객체들
4. view의 책임을 어디까지 볼 것인가
5. 커스텀 에러
6. MessageFormat
이렇게 6개를 사용해보자 라는 생각으로 목요일 저녁 전까지 만들게 되었습니다
여기서 커스텀 에러는 언제 사용해야될 지가 잘 떠오르지 않아서 스킵하긴 했지만, 나머지 부분에 있어서는 확실히 발전된 코드를 얻을 수 있었던 것 같습니다

2번째 만드는 과정

알게 된 부분
1. 출력, 입력 객체는 가장 나중에 만들어야 한다
2. 진짜 전역으로 관리 될 상수가 아니라면 클래스별로 그냥 사용처에 정의하는 것이 좋다
3. 정적 팩토리로 바꾸는 과정은 나중으로 미뤄두자
4. 그냥 만들어주는 생성기 느낌은 테스트를 거의 안 해도 문제 없을 거 같아보인다
5. 정 getter를 만들 거면 Collections.unmodifiableLIst로 바꿔서 보낸다
6. 생성 변수와 테스트 코드와 분리하는 쪽이 가독성이 좋아보인다
7. 예외 처리는 입출력과 바로 맞다아 있는 부분만 하면 된다
8. 객체의 어떤 부분까지 노출할 것인가? 진짜 getter를 두는 것은 최악의 선택
9. 캡슐화를 깨지 않고, 비교하는 방법은 그 객체에다가 밀어 넣는 방법 뿐이다
10. 바깥에서는 %d같은 printf로 출력하고, 안쪽에서는 {0}같은 messageFormat을 사용하는 쪽이 관리가 편할 것이다

단위 테스트가 빠졌는데도 생각보다 시간이 훨씬 많이 들어갔던 것 같습니다
시간이 그렇게 들어간 이유는 enum같은 것도 써야 하고, 이것도 써야하고 저것도 써야하고 하는 고민들과 프로세스 적립을 하는 과정이 가장 컸던 것 같습니다
시간은 확실히 많이 들어갔지만 정리가 된 부분은 가장 많이 있었던 경험이었습니다

3번째 만들 때는 기능 목록의 순서를 핵심 도메인 -> 입출력 순서로 추상화 된 순서를 따라가려고 했습니다
public으로 열어둘 메서드를 미리 조금 정해두고 가는 것도 커다란 도움이 될 수 있겠다는 생각을 하게 되었습니다
이 메서드들을 호출하면 모든 기능이 끝난다는 것을 미리 정의하고 들어가면 훨씬 깔끔하게 코드가 나올 것 같았습니다
처음부터 커다란 흐름을 미리 생각해두고, 그 흐름대로 따라가는 방식으로 정리할 수 있었을 거 같았습니다

3번째 만드는 과정

가장 많은 시간이 들어갔고, 이 정도면 괜찮다라는 생각이 처음 드는 코드였습니다
이 과정을 만들면서 기존 목표를 전부 버리게 되었습니다

진행했던 내용

1. 테스트 라인 커버리지 100%
2. 외부에서 접근 가능한 부분과 접근 불가능한 부분의 구분
3. 예외 처리를 어디까지 해야 하는지에 대한 기준 세워보기
4. 코드를 까보지 않고 알 수 있도록 만들어보자

코드상으로 메서드 형태와, 이름, 반환 타입만을 보고 완벽하게 동작을 추측할 수 있지 않으면 잘못된 코드다 라는 생각을 가지고 시작했습니다
이를 기준으로 코드를 고치고 나니 정말 많은 부분을 배울 수 있었습니다

전체적으로 알게 된 점

1. 메서드명과 변수명을 잘 짓는 과정이 얼마나 중요한지를 다시 한 번 느낄 수 있었습니다
2. 케이스가 몇 가지 없는 경우 enum을 사용했을 때 상태 관리가 얼마나 편해지는지를 느낄 수 있었습니다
이 부분이 없었다면 기능이 하나가 추가될 때마다 for문을 추가하거나, 최대값을 증가시키는 작업을 했어야 할 것 같을 때 enum.values를 통해 접근하게 된다면 너무 쉽게 되는 것을 볼 수 있었습니다
3. 테스트 커버리지 100%가 중요한 게 아니다
100%라는 숫자를 달성하기 위해서 코드를 만들 경우 추후 변경을 더 어렵게 만드는 경우가 있었습니다
필요 없는 곳까지 테스트가 작성되어 있어서 무조건 테스트코드도 함께 수정해야 되는 과정이 발생했었습니다
또한 처음 설계가 충분하지 않은 경우에는 100%만으로는 아무것도 알 수 없다는 점이었습니다
line 커버리지는 테스트 코드 도중에 실행되었던 라인을 보기에, 출력 메시지같은 것들은 검증할 수 없었던 부분 역시 있었습니다
이를 통해 다음 번에는 수치에 집중하는 것보다 어떤 부분에 예외가 들어가야 하는지를 조금 더 고민하는 시간을 갖도록 할 예정입니다

목표를 세우고, 그 목표를 달성하기 위해서 또 노력하고, 그 과정에서 얻은 피드백을 통해서 다시 성장할 수 있는 시간이었습니다
처음 코드와 비교했을 때는 정말 말도 안될 정도로 커다란 차이가 생겼습니다 남은 4주차도 더 열심히 해보도록 하겠습니다

 

느낀 점

초심으로 돌아가야 된다는 느낌이 든 시간이었습니다

왜 이 아키텍처를 여기다가 적용해야 되지? 진짜 필요한 내용이 맞나? 라는 생각을 계속해서 할 수밖에 없는 시간이었습니다

다른 코드를 봤을 때 Repository, Service, Controller, Domain, View 같은 다양한 구조로 파일을 나누고, 관리하는 것을 보았습니다

이때 무작정 저 코드가 뭔가 있어보이니까 따라가야지 라는 생각을 버릴 수 있었습니다

어떤 설계든 장점이 있고, 단점이 있기에, 복잡성과 유연성의 사이에서 고민해볼 수 있는 시간이었습니다

어떤 설계를 택하든, 그 설계에 대해 완벽하게 알고 시작하지 않으면, 오히려 애매한 결과가 나올 수 있다는 것을 확인할 수 있는 시간이었습니다