[꼼꼼한 개발자] 꼼코더

🐶 이전 기능 이전에 '유저의 매치 기록' 기능 결과는 '매치 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번째 제외 모두 '고유 식별자'로 조회를 한다... 너무 자주 사용기 때문에 무언가 변화가 필요하다!) 아래 글 참고

🤷🏻 스택 트레이스(Stack Trace)란? - 프로그램의 실행 과정에서 호출된 메서드들의 순서와 위치 정보를 나타내는 것. 스택 트레이스는 일반적으로 예외가 발생했을 때 예외가 발생한 지점부터 호출 스택의 상위 메서드들까지의 정보를 담고 있다. 👍🏻 장점 - 스택 트레이스는 예외가 발생한 원인을 추적하고 디버깅하는 데 매우 유용하다. 예외가 발생한 위치와 호출된 메소드들의 순서를 통해 프로그램의 실행 흐름을 파악할 수 있고 이를 통해 문제의 원인을 분석하고 해결할 수 있다. ✌🏻 사용방법 (2가지) try-catch 구문 사용함 스택 트레이스는 보통 예외 객체의 printStackTrace() 메서드를 호출하여 출력할 수 있다. ex) e.printStackTrace(); try-catch 구문 사용..

🧑🏻‍💻 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..

🙆🏻‍♂️ 많아진 기능 이전 기능들을 보면 알겠지만 대부분의 Open API 기능들이 '유저 고유 식별자(accessId)'를 필수적으로 요구하고 있다. 나는 이전에 개발 시 "우선 한 화면에 모든 메서드 기능을 출력하고 나중에 나눠야지!"라는 생각을 가지고 'accessId'를 한 메서드 안에서 계속 저장하여 돌려쓰는 방법을 선택했었다. 그렇게 계속 개발하던 도중 "매번 페이지 넘어갈때마다 닉네임 호출 -> '고유 식별자 획득' 작업을 반복할 수 없는데.." 그렇게 수정이 필요하다는 걸 직감했다.. 🤷🏻 어떻게 수정할까? 찾아보니 리액트에서는 UseState를 사용하지만 백엔드에서는 상태 저장을 3가지 중(세션, 쿠키, 토큰)에서 선택해야 했다. 🚀 상태 저장 선택(세션(Session), 쿠키(Cook..

👀 RequestEntity란? RequestEntity는 HTTP 요청을 나타내는 객체이다. 요청 헤더, HTTP 메서드, URI 등의 정보를 포함한다. 👨‍👧 RequestEntity의 종류 RequestEntity는 크게 2가지 종류로 나누어진다. 요청 본문이 없는 경우 RequestEntity requestEntity = new RequestEntity (헤더, 메서드, 요청 URI); ex) RequestEntity requestEntity = new RequestEntity (headers, HttpMethod.GET, uri); 요청 본문이 있는 경우 RequestEntity requestEntity = new RequestEntity (본문 데이터, 헤더, 메서드, URI); ex) Req..

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

🧹 간단 정리 카멜케이스, 파스칼케이스 모두 프로그래밍에서 주로 사용하는 명명 규칙. 카멜케이스는 첫 글자 소문자 이후, 각 단어의 첫 글자를 대문자로 표시. ex) myVariableName) 주로 변수나 함수의 이름을 지을 때 사용. 파스칼케이스는 첫 단어의 첫 글자도 대문자로 표시. ex) MyClass 파스칼케이스 : 주로 클래스나 타입의 이름을 지을 때 사용된다. 🤷🏻 카멜케이스(Camel Case)와 파스칼케이스(Pascal Case)란? 프로그래밍에서 주로 사용되는 대표적인 두 가지 명명 규칙이다. 이 두 가지 명명 규칙은 변수, 함수, 클래스 등의 식별자를 작성할 때 사용된다. 잘 이해하고 올바르게 사용한다면 코드의 가독성을 높이는 데에 큰 도움이 된다. 🐪 카멜케이스 (Camel Case..