[꼼꼼한 개발자] 꼼코더

🚨 문제 발생 [피파 프로젝트] 개발 도중 이상한 현상이 일어났었다 분명 엔드 매핑 주소(첫 요청 시작 주소)가 'users'로 설정하였는데 'user'로 첫 요청을 하여도 정상적으로 동작한다는 것이었다.. (aaa, bbb, adfdagb로 해도 전부 동일하다) 따라서 코드를 확인해 보았다. 😁 코드 확인(원인 발견) 이상한 점을 눈치챘는가..!?!? 그렇다.. '{}'를 붙여 놓은 것이었다.. 이렇게 되면 '변수'로 인식하여 아무런 단어가 들어와도 처리가 돼버린다.ㅠ 🧑🏻‍💻 해결 수정하였다.(매우 부끄러워지는 상황 하핳..)

🐶 이전 자 DTO객체를 통하여 경기 상세 기록을 모두 가져오게 되었다. 잠깐 다른 이야기하자면 내가 백엔드 개발자를 희망한다. 그럼 내가 백엔드 개발자라고 가정하고 생각한다면 다음과 같이 생각할 것이다. 그렇다면 '이 데이터 들중에서 어느 데이터들을 어떻게 만져야 할까?' 그럼 답이 슬슬 그려진다! 아래에 정리해 보자! 경기시간 승/패 (승, 무, 패) 닉네임 득점 수 (0, 2, 1, 등) 경기종료(몰수패, 정상종료 등) 이렇게 5가지 정도 뽑아볼 수 있다. 사실 나는 컨트롤러(패드, 키보드)도 뽑고 싶었지만. 추후 프런트 개발을 깔끔하게 다듬고 아이콘, 색상등으로 표현하는 게 좋아 보여 지금은 뺐다. 그럼 이제 저 데이터를 컨트롤러로 받아오고 화면에 출력까지 해보자! 🧑🏻‍💻 컨트롤러와 화면 컨트롤..

🐶 이전 기능 이전에 '유저의 매치 기록' 기능 결과는 '매치 ID'가 리스트업 됐었다. 그럼 이제 '매치 ID'가 무엇을 의미하는지 알아보자 🕵🏻‍♀️ 공식 문서 확인 '매치 ID'를 가지고 아래 URL로 요청하면 '매치 상세 정보'를 조회할 수 있다고 확인된다. https://api.nexon.co.kr/fifaonline4/v1.0/matches/{matchid} 그럼 '매치 ID' 1개로 테스트 후 결과를 확인해 보자. ..?? 보이는가?? 상세정보.. 일부만 봤음에도 정말 엄청난 양의 데이터 종류이다..(정말로 상세하다..넥슨 👏🏻) 따라서 나는 "너무 막막하다.."라는 생각을 5초 동안 하다 정신차리고 바로 스크롤을 내려봤다. DTO..?? 그렇다 이렇게 넥슨에서 친절하게 총 '9 가지'의 D..

👉🏻 개발할 기능 오픈 API를 모두 구현하고 싶은 마음을 가지고 시작했기에 3번째 까지 완료한 나는 4번째 ('유저 고유 식별자로 유저의 매치 기록 조회') 기능을 구현하려고 한다. 요청 정보는 accessid, matchType, offset, limit가 필요하다는 걸 확인할 수 있고 반환 값은 여러 개의 '매치코드'로 이루어진 걸 확인할 수 있다. 기존처럼 저 매치코드를 글자로 변환하고 그 안에 데이터를 확인하고 한꺼번에 처리하려고 했었지만 하나씩 차근차근 개발해 나아가는 방법으로 변경하려고 한다. 우선 저 코드를 출력하게 처리해 보도록 하자! (그나저나 개발할 기능들을 보면 1번째 제외 모두 '고유 식별자'로 조회를 한다... 너무 자주 사용기 때문에 무언가 변화가 필요하다!) 아래 글 참고

🧑🏻‍💻 accessId 넘겨주고 받아서 저장하기 컨트롤러에서 'HttpServletRequest request'를 매개변수 객체로 선언하여 서비스에 전달 @GetMapping("/{nickname}") public ModelAndView getUserByNickname(@PathVariable("nickname") String nickname, HttpServletRequest request, Model model) { FifaUser nickNameUser = fifaUserServiceImpl.findUserByNickname(nickname); // 닉네임으로 유저 정보 가져오기 String accessId = nickNameUser.getAccessId(); // 가져온 유저정보에서 access..

😅 고민 다음 글에서 적어보겠지만 새로 개발 중인 기능이 너무나 복잡한 구성으로 되어있어 도저히 테스트 코드 작성 고민을 피할수가 없게 되었다. 이전 [역대 최고 티어 조회] 기능 개발에 1주일가량 쏟았다. 길지 않을 수 있지만 나는 개발기간을 더 단축하고 싶은 생각에 고민을 하였다. 개발기간이 늘어났던 요인은 메소드 성공 여부 확인, 에러 잡기가 있었다. 이후 개발 후반에 log, 디버깅 등을 사용해서 문제해결에 매우 좋은 경험을 하여 블로그 글 작성 중 문득 '근데 테스트 코드 작성하면 개발시간이 더 빨리 지지 않을까?' 싶었다. 물론 개발시간이 빨라진다는 것은 어불성설일 수 있다. (코드 량이 늘어나니) 하지만 직전 개발 경험을 토대로 말 하자면 우선 메서드 하나씩 테스트하고 결과를 찍어내고 기억하..

🚀 서비스 분류 먼저 서비스 분류다. 맨 처음에 UserSerivce 한 곳에만 개발을 했어도 별 문제가 없었다. 하지만 이제 메타 데이터, 데이터 매칭 등 여러 가지 성격을 가진 기능들이 나타나니 나의 코드는 혼잡해졌었다. 보이는가? 닉네임으로 유저 정보 조회 고유 식별자로 유저 정보 조회 유저의 데이터 매칭 전 경기별 최고 티어 정보 리스트 조회 유저 데이터와 피파 데이터 매칭(경기 종류, 티어) 유저의 데이터 매칭 후 경기별 최고 티어의 데이터 정보 조회 위 모든 기능이 UserSerivce 한 곳에 작성했었다. 메서드만 7개니 구현체 코드는 안 보여줘도 얼마나 복잡한지 알 거라 믿는다. 👀 어떻게 분류할 거야? 아무튼 이러한 복잡한 코드 구성은 [개발, 수정, 리뷰]등을 하기에 최악이었다. 그렇게..

📑 개발할 기능 순서(이전 글 내용 요약) 유저 고유 식별자로 역대 최고 등급 조회 피파의 메타 데이터 조회 (매치 종류, 등급 식별자) 유저의 matchType(경기 종류), division(최고 티어)의 식별 번호들을 피파 메타 데이터와 매칭시켜 값을 추출 추출한 데이터를 경기당 1개의 객체(DTO)로 변환 후 리스트로(감독, 공식) 모아서 화면에 표현 💻 기능 개발 전 DTO 작성 먼저 보면 API 결과 값이 보인다. 이 뜻은 곧 내가 만들어야 할 DTO의 인터페이스라고 할 수 있다. DTO의 필요성은 간단하게 설명하자면(추후 개별 글 작성) DTO 객체를 사용함으로써 클라이언트에게 필요한 정보만 전송할 수 있다. 3가지의 DTO를 작성해 보자. (DivisionDTO, MatchTypeDTO, U..