[꼼꼼한 개발자] 꼼코더

🐶 이전 이전 경기 결과가 10개가 잘 나왔다. 하지만 나는 스스로 만족하지 않았다. 나머지 [더 보기] 버튼 클릭 시 '비동기' 처리로 추가로 10개의 경기결과가 나오길 원했다. 그렇게 열심히 방법을 찾아보고 개발을 시작한다. 📝 개발 준비 우선 메서드가 하나가 더 필요하다! 왜냐하면 현재 조회기능을 내가 MVC형식으로 진행했기 때문이다..(추후 변경 예정!) 따라서 아래 두 가지를 만들어야 한다. MVC 형식 경기기록 조회 > 최초 요청, 화면 렌더링 때 Ajax 형식 경기기록 조회 > 재요청, [더 보기] 버튼 클릭 시 🧑🏻‍💻 서비스 코드 사실 이전 코드와 비교했을 때 반환 값만 다를 뿐 별 차이가 없어 보인다. 그리고 반환 값을 List 객체를 직접 반환하고 @ResponseBody 어노테이션을..

🐶 이전 자 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..

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

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

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