1주차
요일마다 해야 할 일을 주간 일정을 세워두고 진행해야 일정에 맞춰 과제를 해낼 수 있겠다.
2주차
더 중요한 것에 시간을 투자하자
2주차 수업은 아키텍처였으나 해결 과제는 선착순 신청개발과 통합테스트 작성이었다.
그리고 동일 유저가 여러 번 동일 강의를 여러 번 수강요청 하였을 경우 1번만 성공하는 것을 개발/검증하는 것을 하는 것이 과제였다. 그 과제를 처리하는 것이 주 임무였다.
월/화요일에 아키텍처 책을 사보면서 시간을 많이 잡아먹었는데, 아키텍처는 하루 아침에 알기도 어렵고 그냥 이렇구나 하면서 베스트프렉티스를 따라 패키지 구조를 잡고 나중에 이유를 공부하는 편이 좋았겠다.
요구사항 분석, TC작성이 1주차보다 나아졌다.
이 부분은 항해에서 공부할 때, 꾸준히 발전시켜서 빠르고 정확하게 하는 연습을 하자.
실무에서 가장 필요하다고 느꼈던 부분이다.
3주차
앞으로 할 프로젝트의 설계를 하는 주였다.
Fail 받았던 것의 아쉬움
- 좋았던 것은 내 설계를 기억하고 있었다. 그래서 더 아쉬웠는데,, 설계 문서를 통해 다른 사람에게 내 설계를 이해하게 했다면 하는 아쉬움이 있다. 이 부분은 멘토링 시간에도 ERD가 있냐고 요청 했었던 부분이다.
- 의사소통의 부분에서 아쉬움이 있었다. 코치가 개발팀장이라 생각하고 업무를 받았을 때의 관점으로 의사소통에 대한 부분이다. 의향에 대한 부분을 묻자.
즐겁게 해보자
이걸 하려고 결정할 때 즐겁게 해보자란 마음으로 시작했다.
즐겁게 란 것은 항해에서 자주 들은 표현으로 써보자면
파들파들하지 말고 '이 정도! 할 수 있지', 란 마인드로 하는 것과 같은 거다.
이번주 내가 했던 고민들은 대기열에 대한 고민에서 필요한 부분들이였다. 잘 생각해냈고, 필요한 것들을 잘 해냈다.
나 스스로 내가 생각한 부분들에 좋지 않은 의심을 한 부분들이 있었는데 처음 마인드를 잊지말자.
그리고 여러 의견과 생각을 많이 들어봐야겠다. 청강을 많이 활용해보자.
4주차
5주차가 끝나고 쓰려는 4주차는 기억이 잘 나질 않지만 4주차는 작업하면서 할 말이 많은 주차였다.
작성해야 할 코드와 해야 할 일들이 가장 많은 주차였다.
1. 일단 3주차 때 설계했던 내용을 보강
2. 모든 API가 기본 기능이 동작하도록 작성
3. 알맞은 단위테스트, 통합테스트 진행
4. 패키지를 아키텍쳐에 맞게 구성하기
일단 아키텍처 지식과 도메인기반 개발이 필요했고 그것을 검증하기 위한 테스트 코드를 짜야했다.
모두 기반 지식이 필요해야 돌아가는 일이였기에 할 것이 많고 주어진 시간내에 해내는 것이 어려웠다.
기반 지식 없이 도메인 TC부터 짜고 API 를 의존이 없는 것부터 거꾸로 개발해 나가려 하니 시작을 어떻게 해야할지 모르겠었다.
그래서 일단 개발을 완료하자는 마음으로 서비스에 모든 코드가 들어가 있는 레이어드 아키텍처로 작성했다.
아쉬운 마음은 있었지만 개발을 일정내에 완료하고 제출했다는 것에 성취감을 느낄 수 있었다.
5주차
따봉을 받았다.
5주차는 로깅 구현이 주제였는데 나는 클린아키텍쳐를 가미한 패키지 변경과 코드 리팩토링을 진행했다. 그러면서 거의 대부분의 테스트코드도 다시 짜야하는 상황이라 다시 4주차가 시작된 기분이였다.
이렇게까지 하라고는 하지 않았지만 4주차가 못내 아쉬웠기에 주말에 필요한 기반 지식 책을 읽었고 월요일부터 리팩토링에 들어갔다. 가장 먼저 포인트 충전/조회를 리팩토링하면서 레이어별 역할과 역할별로 어떤 테스트코드를 작성하고 어떤 방식으로 진행해야할 지 생각하고 찾아보고, 다른 사람의 코드를 들여다보면서 어떤 테스트코드를 왜 짰는지 파악해보았다. (때론 이 테스트코드는 왜 짰을까 궁금해서 직접 물어보고 싶었지만 일단 넣어뒀다)
그래서 그리 복잡하지 않은 로직이였지만 시간이 꽤 걸렸다. 월요일 하루면 완성 될것이라 생각했는데 화요일까지 포인트를 하고 있었다. 근데 그렇게 하면서 어느 정도 내 기준을 정했고 다른 api구현과 테스트코드를 짜면 되겠다고 생각했다.
하지만 책 한권의 기반 지식으로는 모든 것을 커버할 수 없기에 대기열 토큰 생성도 생각보다 오래 걸렸다. 수요일 하루를 다 사용했다. 목요일은 사실상 마무리를 지어야 하는 날인데 이제 todo list의 30%정도 한 상황이였다.
하지만 개발 방식을 바꾸다보니 고민 되는 부분은 다 고민하면서 완성해보고 싶었다. 수요일까지 그랬다.
그리고 목요일은 조금 빠르게 기존 코드를 파일 분리만 해서 api를 완성했다. 아직 기술부채로 남아있는 부분이다.
로깅은 http request/response는 기본 적재 내용이라 필터를 이용해 빠르게 구현했다. 로깅에 request, response 내용을 넣을 때 추가 항목에 대한 칭찬을 받았다.
결과가 나온 날엔 내용을 정확히 확인하지 못했었는데 다시 보니 노력에 대한 보상을 받은 것 같아 뿌듯했다.
아쉬운 점
테스트 코드에서 데이터 주기를 잘 파악하도록 사용법을 더 확실히 정리해둬야겠다.
테스트케이스가 실패하는 경우를 알고 PR을 보냈다. 지울수도 있었지만 필요한 TC였고 실패한다고 지우면 테스트코드의 의미가 없다고 생각했다. 근데 난 왜 fail이 나는지 원인을 못찾았었는데 다른 사람이 작성한 코드를 한 번에 실패 원인을 파악하시다니.....
아직도 질문이 많은 상태다.
작성한 코드가 아직도 DB에 의존적이지는 않은 지 고민된다.
예시로 대기순서를 계산할 수 있는 lastActiveOffset은 DB에 의존적이 될 수 있는 코드를 하나의 도메인으로 만든 케이스로 본다.
그래서 이 부분을 이렇게 시도해보길 잘했다고 생각했다.
나머지 대기열 통과 스케줄러 로직도 DB 의존적인 코드가 많다고 생각한다. 단순히 select, update로 로직을 표현할 수도 있지만, 개념을 도입해 변경하는 것이 도메인개발이 아닐까 혼자만에 생각을 해본다. 이 질문에 대한 답변은 중간 방학 때 해결해 보려고 한다.
밤샘은 더 이상 하지 말기.
S/F가 중요한 것은 아니지만 기한 내에 할 일을 마감하지 못하고 받는 Fail은 받고 싶지 않았다. 그래서 밤을 좀 샜는데... 인생의 우선순위를 잊지말고 할 일을 하자.
추가 할일
다른 사람의 리뷰를 보니 DDD관점과 객체지향 관점이 다르게 개발되는 것 같은데 해당 코드를 확인해보자
댓글