SSongsing/code-startUp

code-startUp 1주

고민한 지점

1. 할인을 어떻게 구현할 것인가?
   • 놀랍게도 고민을 꽤나 깊게 한 지점이었다. 그치만 해답을 찾지 못하고 시간에 쫓겨 개발을 하여 돌아가기만 하는 코드를 만들고 말았다. 더 공부해서 무조건 리팩토링하고 싶은 지점이다.
   • 제대로 된 이해가 없이 회사에서 익숙한 대로 개발하려고 하다보니, db에 할인 정책을 저장해두고 꺼내두는 방식을 처음 구상했으나, 테이블 설계에 막히고 매 주문 db를 찌르면 비효율적이라는 점을 깨달아 코드에 할인율을 지정해두는 방식으로 틀게 되었다.
2. 테스트 코드는 어렵다.
   • 모든 코드를 구현한 후에 보여주기 식으로 작성한 코드를 테스트 코드라 부를 수 있을까
   • api 개발은 맨날하고 있으니 평소에 하지 못한 부분에 집중했어야 했는데 테스트 코드를 또 뒷전으로 둔 점이 가장 아쉽다.
   • 2주차 과제는 단위 테스트에 대한 학습 이후에 시작해야겠다.
3. 설계를 하려면 공부해야한다.
   • 야심차게 좋은 구조를 고민하여 프로젝트를 만들고 싶었으나 아는 게 없으니 결국 이해 없이 익숙한 코드를 베껴서 모든 구조를 만들게 되었다.

후기

• 문제 해결 전략, 분석한 내용, 실행한 방법을 적어달라고 하셨으나 구현에 급급한 코드 작성으로 그 무엇도 하지 못했다. 2주차는 좀 더 시간의 여유를 두고 해야겠다.
• 업무에 사용하는 언어와 프레임워크에 이해가 부족한 것을 느끼고 남에게 보여주기 부끄럽다는 생각을 했다. 부끄럽지 않기 위해서는 공부해야한다..

2주차

공부

• Stream
  • 쓴 이유: 변수명 헷갈릴 것 같아서 변수 선언 없이 가고 싶어서 사용했다.
  • 알고 있던 것: 함수형 프로그래밍.
  • 장점: 코드가 이해하기 쉬워진다. 다양한 데이터소스를 표준화된 방법으로 다룰 수 있게 된다.
• 왜 서비스에서 DTO를 바로 반환하지 않고 view를 쓰는가
  • 다른 팀원에게 물어보니 컨트롤러 - 서비스를 분리하기 위해서라는 답을 얻었다
• 제어할 수 없는 테스트 코드
  • 문제: 오늘 날짜와 같이 내가 제어할 수 없는 부분(이전 구조에서는 금요일에 할인 되는지 화요일에 확인할 수가 없었다.)이 존재했다.
  • 찾아낸 해결 방법: 제어할 수 없는 부분은 최대한 밖으로 뺀다. 혹은 의존성 주입해야한다.
  • 개선해야할 지점: discountPolicy 에서 오늘 날짜를 계산하지 않을 뿐이지

고민한 지점

1. 할인 정책 캐싱
   • TODO 였으나 구현하지 못한 첫번째 문제.
   • 캐시를 사용하라고 해서 처음에는 memoryRepository처럼 자체 구현해야하나 고민했었지만, 어노테이션 사용하는 방법으로 틀었다.
   • 이후 discount 리포지토리에 캐시를 어케 적용할지 좀 고민하다가 오래 걸릴 것 같아서 뒤로 미뤄뒀다가 결국 시간이 부족해서 못했다.
   • 생각한 구조는 discount도 생성, 변경할 수 있는 코드를 만들어서 생성, 업데이트 시 캐시를 갱신하도록 하기.
     • 할인 정책이 자주 변하지는 않을테니 유효시간은 하루로 생각했다.
   • 더 고민해야할 지점
     • discount 엔티티. 할인을 나눌 코드(금요일, 카테고리 할인인지 가져올 수 있도록)를 id로 정할 것인가?
     • 버전을 넣은 방법은 코드로도 비즈니스적으로도 고민하게 되었다. 주문 직전에 날짜가 변경되었는지 또 확인을 해야하나?
   • 더하여 isdiscountable 2개의 인자를 받도록 구성했는데 맘에 들지 않음. 변경방법을 고민해야겠다.
2. 불변 객체
   • money 객체를 추가했으나, 이걸 book의 데이터 타입으로 써야하는지 고민했다. 내린 결론은 쓴다인데 그러면 여기저기 꺼내쓰기에 이상해지는 느낌. 개선이 필요하다.
   • 불변 객체를 적용하게 되면서, 코드를 전반적으로 다 고치게 되었다. 오더 서비스 테스트 코드를 무사 통과하길래 잘 된다고 착가했는데 응답으로 내려주는 형식 자체가 바뀌어서 차주에 수정해야할 것 같다.
   • discountpolicy 테스트 코드에서 현재 소수점 단위가 다르다고 실패가 뜬다. 단위를 적용하여, 단위에 따라서 소수점을 다르게 설정하도록 해야하나 고민중.
3. 테스트 코드
   • 이번 주에 가장 헤매었던 지점: 테스트 코드에 discountpolicies 를 적용하겠다고 시간을 가장 많이 썼다. 해결법은 찾았지만...
4. 우선순위에서 밀린 검증
   • todo 였으나 구현하지 못한 두번째 지점.
   • 검증 공부하면서 그저 당연하게 에러 찍히는 지점들이 당연하지 않았꼬 이미 프로젝트 공통적으로 예외 처리해줬기 때문이라고 깨달앗다.
   • 어노테이션 말고 다른 방법들을 좀 더 공부해야겠다.

후기

• 주말에 시간 많으면서 안하고 또 주중에 바쁘게 공부한 걸 반성합니다..
• 사실 저번 주에 todo 적어줄만 할 때만 해도 할만하겠는데 생각했는데, 구글링으로 찾고 공부한 내용을 난 바로 소화할 수도 없고, 내 코드와 다른 부분들이 있으니 응용이 필요하며 응용은 하나의 포스팅 봤다고 할 수 있는 지점이 아니었다. 구현만 생각할 것이 아니라 공부 시간을 더 넉넉하게 잡아야하는 것을 나를 과신했다.
• 그래도 오랜만에 자율성을 보장받으며 개발하니 재밌었다.
• 직접 api 테스트해보니까 당연하다고 로깅의 소중함을 깨달았다. 어차피 로컬에서 돌릴 땐 디버깅으로 확인하면 되지만 로그 찍을 만한 일이 있다면 좀 더 신중하게 고민해봐야겠따.

3주차

TODO

1. 검증
   • 전 계층을 통틀어서 하나의 검증 객체에서 검증을 해야하는데 시작부터 막혔다. 검증 객체는 어디에 위치해야하는가? utils 로 빼야하나
     • 하나의 객체를 쓰더라도, 값이 들어올 때 검증하고 할인이 적용된 값에 대한 검증도 있고 객체만 하나로 두고 각 계층에서 다르메서드를 호출하여 검증해야하나..?
     • 검증을 해야하는 할인 부분이 제대로 구현되지 않은 상태라 일단 controller로 들어오는 값에 대한 검증만 해보기로 결정.
   • dto 검증에서도 결제수단에 따른 결제금액 검증에서 어디에 검증을 위치시켜야할지 고민함
   • 할인률 검증은 어떤 방식으로 해야할지 고민만 함(구현 X)
     • 비즈니스 로직 상 일반적으로 사용자는 장바구니에서 미리 가격을 보게 되니까, 장바구니에서 가져온 정보와 지금 할인이 일치하는지 검증?
     • cache에 저장해둔 값이 유효한지 검증인가
2. service 분리
   • discount, pay 모두 service 로 분리
   • payMethod도 다형성을 적용하도록 변경
   • payService에서 discountService를 부르도록 변경할까 고민도 했었음.
   • 일단 할인이 결제할 때만 보이는 것도 아니며 코드가 보기 안 좋아져서 포기
3. 왜 resultMessage를 두는가
   • 즐거운 휴가로 물어보지 못함.
   • 앱에서는 무조건 status code로 200을 내려주게 되어있어서 구별하기 위한 방법인 듯하다. (resultMessage 뿐만 아니라 resultCode도 있음)

후기

• 3주동안 힘들지만 즐거웠다.
• 이것저것 바꾸니까 테스트 코드도 바뀌게 되가지구 너무 번거로웠다. 근데 또 내가 제대로 변경했는지에 대한 확인은 테스크코드가 맘 편하다. 테스트 코드에 대해 더 많이 고민해봐야겠다.