개요

누군가 지금까지의 프리코스 기간 중 가장 힘들었던 기간을 묻는다면 고개를 들어 3주차를 보게하라...
고통과 혼란 그리고 극복으로 들어찬 아주 흥미진진...한🥲 3주차였다. 무슨 일이 있었는가..!

PR 링크

[로또] 이현지 미션 제출합니다. #879

이번주 목표 달성 확인

• ✅ READ.ME 요구사항, ApplicationTest 코드 정독하고 시작하기
• ✅ 요구사항 관련 기초적인 실수 하지 말기
• ✅ 상수화 빠뜨린 것 없는지 점검
• ✅ CLI 방식으로 add -p 습관 들이고, commit 해보기
• ✅ 기능별 분리 commit 및 직관적인 commit 메시지 작성
• ✅ public 메소드 중복없는 선에서 모두 테스트해보기
• ✅ 컨트롤러 없이 메인 로직 다짜보기: 철저히 중개 역할만 하기
• ✅ 테스트 코드 가독성 높이기
• ✅ 상수 모음 객체로 분리해보기
• ✅ 불변 속성 (필요한 경우를 따져서!) 적용해보기
• ✅ 공통 피드백의 내용대로 네이밍에 타입 넣지 않고, 직관적으로 작성하기

공부한 것

미션을 하면서의 구체적인 고민 과정은 여기를 봐주시길!

• [우테코 6기 프리코스] 2주차 피드백 정리
• [우테코 6기 프리코스] 3주차 고민 해결 과정
  
• [공부한 것] 나만의 커밋메시지 방식 정리!
  

😋 리뷰를 다 먹어치우는 커비

리뷰를 정리하는데 장장 4일이 걸렸다.
나에게 달린 리뷰 뿐만이 아니라,
다른 분들에게 리뷰를 달면서 배우게 된 것, 타 리뷰어 분들이 다른 분들에게 남긴 리뷰까지 싹 다.
조금이라도 괜찮은 게 보이면 일단 수집했던 것 같다.

거기에 바로 적용하지 않고, 개념을 찾아보며 적용하는 과정까지 하니
4일을 꼬박 투자하니 겨우 정리하고 리팩토링을 얼추 마칠 수 있었다!

그렇게 정리해본 100여개의 2주차 리뷰 https://velog.io/@dlguswl936/우테코-6기-프리코스-2주차-피드백-정리

🫠 그동안 적었던 불안이 차올랐던 한 주

하지만 그렇게 수많은 리뷰와 개선할 점을 정리한 후 또 다른 국면을 맞닥뜨리게 되었다.

리뷰를 받아본지 몇 주 되지 않았지만 리뷰를 대하는 그동안의 내 모습은,
어쨌든 당시의 내 능력으로 최선을 다한 코드였고,
그에 대한 피드백이라면 받아서 다 흡수하면 된다는 생각으로 비교적 긍정적이게 지내왔다고 할 수 있다.

하지만 이번주에는 저번주보다 코멘트의 양은 적어도 내가 아는 수준을 넘어서는, 또는 그동안 생각조차 못해본 부분, 그리고 대대적인 수정이 필요한 피드백을 많이 받았다.
새로 개선해야하는 부분으로 인식된 것이 와르르 쏟아지다보니,
리뷰를 모두 흡수하는 자칭 우테코 6기 프리코스 커비로서도 감당하기 어려운 양의 새로운 고려사항들이 생긴 것이다.

그렇게 넘쳐나는 피드백을 정리하고 반영하다보니 3주차 미션을 3일만에 해야하는 상황에 놓이게 되었었다.
그러면서 과연 내가 이걸 1주일 안에 습득해서 구현에 반영할 수 있을까하는 생각이 스물스물 들기 시작했던 것 같다.
거기에 추가된 수많은 고려사항이 머리속에 가득 들어차니 그동안 적었던 불안이 차오르고, 유난히 손이 안떼지는 3주차 미션이었던 것 같다.

하지만, 미션을 다 못하는 한이 있더라도 이번주차에 나에게 주어진 성장을 해내는 것이 중요하다는 생각을 하려고 했다. 미션 수행과, 프리코스 만큼 이 과정을 통한 성장이 무엇보다 중요한 것이니까!
그렇게, 불안감이 밀려들었지만 최대한 2주차의 피드백을 충실히 반영하면서 미션을 진행하려고했던 한 주였다!

✌️ 두번 실수는 없다! 하루가 걸려도 잡고 넘어가기

2주차를 돌아보며 가장 아쉬웠던 점 중 하나를 꼽아보자면 커밋 메시지가 있겠다.
이유는, 분명 1주차 목표 때도 썼던 내용인데 개선이 없었다는 게 너무나 아쉬웠다.

그래서 사소한 부분이라고 할 수도 있지만 장기적인 개발 습관을 위해 반나절 시간을 잡고,
6~7명의 리뷰어들의 커밋 메시지를 수집하고 그걸 종합해 나만의 커밋 메시지 틀을 만들었다!

실제로 적용해보기 위해 2주차 커밋 메시지를 만든 틀로 모조리 다시 작성해보기까지하니
커밋 메시지를 어떻게 써야하는지 감이 오는 것 같았다!

정리해본 포스팅: [공부한 것] 나만의 커밋메시지 방식 정리!

그런 뒤, 3주차 커밋을 대하는 내 태도가 달라진 것을 느낄 수 있었다.

자연스레 커밋 단위에 신경을 쓰게 되었고,
계속해서 기능별로 구현을, 커밋을 하고 있는지 점검하고,
커밋 메시지를 공들여 적어보며 각 기능이 책임에서 벗어난 일을 하지 않았는지 점검하게되는,

단순히는 커밋을 대하는 자세의 변화지만, 결론적으로 개발하는 자세 전반에 변화가 일어나는 것 같다는 뿌듯함을 느꼈던 것 같다!

📝 하루종일 의존성을 고민하고 나온 구상

2주차 미션 때, 의존성이 강하게 생기는 클래스들이 서로 생기다보니 리팩토링하면서 그 의존성을 끊어주는 것이 상당히 까다로웠다.
따라서, 이번주에는 구상 단계에서부터 의존 관계를 최소화하려고 노력했다.

하지만, 객체 간의 의존성을 파악하는 것부터가 어려웠다.
짜고 나니 너무 의존성이 강한 것은 알겠는데, 그래서 어떻게 구상해야 필요한 값을 사용하면서도 객체간의 의존성을 낮출 수 있는 건지 고민이 들었다.

그러면서
190620 우아한테크세미나 - 우아한 객체지향 by 우아한형제들 개발실장 조영호님 영상도 찾아보며 의존관계, 연관관계에 대한 개념을 잡고
그림으로 의존관계, 연관관계를 그려보면서 계속해서 점검하려고 했다!

그렇게 객체 하나에 다른 객체를 필드로 넣기로 결정할 때, 의존관계를 그려보고 생길 수 있는 이런 문제, 저런 문제를 다 고려해보면서
이렇게도 객체들을 만들어보고, 싹 엎고 저렇게도 객체들을 만들어보고.
그렇게 하루를 꼬박 구상에 투자하고 몇 번을 갈아엎으니 기적적으로 가장 괜찮아 보이는 객체들간의 연결 방향이 보이는 듯 했다.

그렇게 의존관계를 충분히 따져보고 한 구상을 바탕으로 프로그램을 만들다보니 지난주보다 컨트롤러의 역할도 경량화되고 객체를 연결할 때에도 훨씬 순조롭게 되는 것을 느끼게 되었다!

의존 관계, 처음에는 어떤 개념인지 어렵게만 다가왔는데 적용해보니 프로그램을 가볍게 만들어주는 녀석이라는 느낌이 강하게 온다! 다음주에도 가져가면서 더욱 발전시켜서 적용해봐야겠다!

🧐 개발 할 때 나만의 기준이 있었나?

1. '출력 메시지를 모두 상수화해야할까? 상수화를 하는 나만의 기준은 뭐지?'
2. '모든 메소드를 테스트해야할까? 나는 어떤 기준으로 테스트를 하는 걸까?'
3. 'final이나 unmodifiableList를 왜 모든 곳에 붙여줬지? 나만의 불변성 적용 기준은 뭐였을까?'

이번주가 유독 이러한 개발 할 때 나만의 기준이 있었나?라는 질문을 자주 던진 한 주 였던 것 같다. 그리고,

1. '그래, 상수화는 가독성과 재사용성을 기준으로 판단해야겠어'
2. '설계 변화로 에러를 발생시킬 가능성이 없는곳, dto와 같은 곳에 우선 적용해야겠어'

이런 식으로 그 질문에 대해 고민하고, 대답을 찾아가면서 자연스레 개발을 할 때의 '나만의 기준'에 대해 하나 하나 정립하게 되었던 것 같다.

1주차와 비교했을 때, 좋은 방법을 따라하는 것이 아니라
나만의 기준이 점점 생기고 그 기준을 적용해 개발을 해나가고 있다는 느낌이
눈에 띄는 성취는 아니지만 개발에 있어서의 자신감을 조용히 올려주고 있는 것 같다!

🚮 그동안의 방식 과감히 버리기

이번주의 코드에서의 큰 변화 중에 하나는 validate 방식을 Validator Factory 방식으로 갈아끼운 것이라고 할 수 있다.
몇 주동안 유효성 검사는 객체 안에서 하는 방식으로 고정해왔는데 저번주 리뷰를 하면서 발견한 이 방식이 기존의 방식에 갖고있떠던 고민을 해결해 줄 수 있는 방법이라고 생각했고 시도해보게 되었다!

물론 그 과정에서 해당 방식에 대해서도 찾아보고 공부하는 시간이 필요했기도 했고, 그동안 계속 해오고 정교화했던 방식을 버리고 새로운 방식을 시도하는 것이기때문에 완성도가 더 떨어질 수도 있다는 생각은 한다.

하지만 단순히 계속 쓰던 방식이니까, 익숙한 방식이고 큰 문제 없으니까. 하고 사용하고 싶지 않았다.
여러 점을 감수하더라도 이제는 사용의 근거를 댈 수 있는, 스스로 대답할 수 있는 방식의 사용을 하고 싶었기에 새로운 방식을 시도해보게되었다.

사실 어떤 피드백이 올지 불안한 마음도 있지만, 그렇게 피드백을 받아가며 부족한 부분을 발견해가며 개선 될 수 있다고 생각한다! 와라 피드백!!

🧐 과도한 사용 경계하기

지난주 내가 했던 아래의 것들에 대해 경계가 필요할 것 같다는 생각을 했다.

1. 모든 예외 메시지의 상수화나 객체화, 출력메시지의 상수화를 한 점.
2. 생각 없이 모든 getter 리스트 리턴에 unmodifiable 적용이나, final 키워드 적용등

-> 개발의 유연성이나 설계 변화로 인한 에러를 불러올 수 있다.
전체 설계를 생각하고 또 생각해서 몇 번 생각해서 넣기

📌 4주차에는?

이번주에는 1~2주차 때 보통 쓰던 방식을 버리고 새로운 방식을 대거 시도해본 코드라고 할 수 있다.
따라서, 어떤 리뷰들이 달리고 어떤 토론이 이루어질지, 그 과정에서 또 어떤 많은 배움이 있을지 기대된다. 어서 12시가 되어서 내 코드에 달릴 리뷰들을 만나고 싶다!!

그 리뷰들을 모두 먹어치워서 4주차에는 진화한 현지가 되리💪💪💪

참고: 3주차 고민 해결 과정 포스팅 : https://velog.io/@dlguswl936/우테코-6기-프리코스-3주차-고민-해결-과정