본문 바로가기

분류 전체보기

 (193)
23년 2월20일 팀프로젝트 프론트 페이지 개발2주차다. 다른데서 형식을 가져와서 만들면 금방 만들줄 알았는데 생각보다 작업이 오래 걸리는것 같다. Refresh토큰 추가를 했는데, Response에서 값은 들어오는데 로컬스토리지에 저장을 못해서 뭔가 했더니 cors 설정에서 exposeHeaders 설정을 추가로 해줘야 했던 것이었다. 이전에 맨날 헤더나 바디, 또는 쿠키로 토큰값을 쏴주면 프론트에서 어떻게 처리해야 하나 궁금했었는데, 로컬 스토리지에 저장하거나 해서 처리하는 것을 알게 되었다. 그리고 이전에 변경했던 email인증 방식에 문제가 있다는 것을 알게 되었다. 인증키를 response에 담아 반환하는데 문제는 이렇게 되면 인증키가 그대로 노출이 되어 콘솔만 열어도 인증키가 무엇인 줄 알 수 있게 된다. re..
25주차 개발일지 프로젝트 진행 2주차다. jpql로 써져있던 쿼리문을 쿼리 dsl을 사용하는 것으로 변경하고, 프론트 페이지를 만드는 등의 변경과 추가가 있었다. 이번주에는 프론트 페이지를 만드느라 정신이 없었던것 같은데, cors에 대한 개념과, 백엔드와 프론트 사이에 어떻게 값을 주고 받는지 더 자세히 알게 된 것 같다. 사실 오래되긴 했지만, 부트캠프 초기에 파이썬 flask와 js, 몽고db를 사용하여 간단한 웹페이지를 만든 적이 있는데, 프론트와 백엔드간의 흐름은 틀만 놓고 보자면 그때 했던것이랑 크게 다를 것은 없었던 것같다. 단지, 그때는 하라는대로 따라했고, 백엔드 개발자가 어떤 것을 해주어야 하는지 몰랐기 때문에, 감을 잘 잡지 못했다. 백엔드에 대한 지식이 조금 쌓인 지금에서야 그때 했던 것들이 왜 그..
23년 2월 19일 프론트 페이지에 api를 연결하는 작업을 계속 진행 중이다. 회원가입 페이지를 만들다 중복체크 api가 필요한걸 깨닫고 api를 새로 만들었다. 문제는 response로 받아온 값을 받아 분기별로 처리를 하게 하려 했는데 잘 되지 않았다. 알고보니 js가 비동기 언어라 그런 문제였다. 그렇게 처리를 하려면 async라는 것을 이용해서 처리해 주어야 한다고 그러는데, 거기까지 알아보기는 싫어서 그냥 함수를 다 나누었다. 이메일 인증 기능도 만들었는데, 기존의 이메일 인증 로직이 자꾸 같은 인증메일만 보내서 손을 좀 보고, 코드 인증 자체도 백엔드가 아닌 js서 처리하게 변경했다. 프론트 페이지를 만들면서 백엔드 개발자와 프론트 개발자간의 협력이 원활하게 되려면 어떻게 해야할까 라는 생각을 자주 하는것같다.
23년 02월 16일 프론트 페이지 개발을 계속 하고 있다. 프론트 페이지를 만들다 api를 좀 더 세분화해서 만들 필요가 있다고 느꼈다. 예를 들어, 회원가입 api안에 중복체크가 포함되어 있었는데, 이런 중복체크를 하나 하나 따로 나누어 버튼에 가져다가 붙이는게 좋다는 생각이 들었다. 포스트맨으로 api가 잘 작동하는지 확인만 했을때는 몰랐는데 직접 프론트를 만들면서 api를 연결하니까 앞으로 어떻게 api를 설계해야 할지 약간 감이 잡혔다. 그리고 어제 한 CORS설정 때문에 빌드 자체는 되지만, 컨트롤러 테스트 코드가 작동하지 않았다. 원인은 잘 모르겠지만 시큐리티 설정 클래스에 webMvcConfugurer를 implements했는데 컨트롤러 테스트 코드 구동시, 빈이 달리지 않아 자꾸 테스트가 실패했다. 당연히 C..
23년 02월 15일 기본적인 프론트 페이지 개발에 들어갔다. 리액트를 사용해 본격적으로 만드는 것은 아니고, 기본적인 자바스크립트와 html, css를 이용해 만들기로 했다. 직접 하나 하나 만들 자신은 없고, 만들어진 템플릿을 가져다가 api와 연결하는데 문제가 생겼다. 검색해보니 인터넷 연결 문제, 크롬 설정의 문제, vscode설정의 문제 등이 나왔는데 모두 아니었다. 로그인 페이지 자체가 가져다 쓴거라 신경 쓰지 않았는데, 회원가입 버튼이 submit으로 되어있었다. 이를 button으로 바꾸니 잘 동작이 되었다. 그리고 그다음 예상했던 문제가 나왔다. 사실 타입리프로 구현을 하지 않고 vscode로 따로 프론트를 구현 해 본 이유가 여기에 있는데 cors처리를 한번 해 보고 싶었다. cors는 Cross-Origi..
23년 02월 14일 쿼리 dsl수정을 마저 했다. 나는 Tuple이 아닌 Dto의 형태로 쿼리를 받아오고 싶은데 그게 되지않아 구글링을 해보니 Projections라는것으로 처리를 할 수 있다고 하여 Projections을 사용해 처리 해 주었다. 그래서 어제의 쿼리에서 다음과 같이 바뀌게 되었다. 찝찝했던 강제 형변환을 하지 않고 애초에 ReviewResponseDto로 받아오게 하였다. 그리고 전체적으로 추가 리팩토링을 한 후 빌드 오류가 나는 것을 수정했다. 내일은 프론트 페이지 구현을 시도 해 볼 예정이다.
23년 02월 13일 오늘은 지금까지 쓴 프로젝트 코드들에 대해서 리팩토링을 하고 가기로 했다. 리팩토링 기준은 반복되는 코드정리와, 쓸데없이 길어지는 코드 간결화 정도로 잡았고, 팀원 모두 코드를 보면서 어떻게 바꿔야 할지 짚어 주었다. 사실 내가 이에 대해서 어떻게 하는게 좋은것 같아요 라고 하기보다는 이렇게 하는게 어떨까요? 라는 진행방식이 더 바람직 해 보이지만 생각보다 잘 되지 않았다. 그리고 이전에 jpql로 가져왔던 값을 쿼리dsl과 쿼리팩토리를 사용해 한번 정리해 보았다. 올바르게 작성한지는 잘 모르겠다. 일단 jpql을 사용했을 때 보다는 쿼리 dsl을 사용했을때 어떤 값을 가져오는지는 더 보기 편한 것 같다. 게다가 컴파일 단계에서 검사를 해 주니 실행시켜 보기 전까지는 어디에서 오류가 있는지 알 수 없는 ..
24주차 개발일지 이번주는 새로운 팀 프로젝트를 시작했다. 팀원 개개인의 수준이 다르기 때문에 어떻게 진행을 해야 할지 고민했는데, 일단 애자일 방법론의 스크럼 방식과 비슷하게 진행하기로 했다. 작업을 논의하며 우선순위를 정해 구현을 시작했고, 프로젝트의 처음부터 끝까지 모두 설계하지 않고 우선순위로 논의한 항목에 대해서만 설계해 작업을 시작했기때문에 일단 작업은 빠르게 진행되고있다. 이에 대해서 피드백 페이지에 질문을 했으나 아직 답변을 받지 못했다.. 이번에 협업을 어떻게 해야할지 고민하면서 깃허브 이슈로 작업을 관리하는 법과 pr템플릿이란것을 알게 되었다. 증간에 풀리퀘스트를 잘못 날려 깃허브를 한번 초기화하는 문제도 있었다. 정신없이 작업하다 실수를 했었는데 pr을 할때 신경을 좀 더 써야겠다는 생각이 들었다. 기..
23년 02월 12일 팀 프로젝트의 리뷰 기능을 완성했다. 연관관계를 맺은 user에서 값을 탐색해와야하는데 user에 lazy를 걸어놨기때문에 N+1문제가 발생이 될걸 우려하여 일단 jpql로 쿼리를 써서 값을 가져오게 했다. 다음주에 쿼리 dsl을 전체적으로 적용해 볼 생각인데 쿼리 dsl과 쿼리팩토리를 사용해서 좀 더 가독성 좋게 코드를 쓸 생각이다. 그리고 리뷰기능의 서비스에 대한 단위 테스트를 썼다. 테스트를 쓰다가 캡슐화한 메서드에 대해 테스트를 어떻게 할까 고민했다. 일반적으로 private선언을 한 메서드는 테스트를 못하고, 테스트를 하는 방법이 있지만 private메서드를 테스트를 해야 하는 상황이면 설계가 잘못된건지 고민을 해야한다고 했었는데, 딱히 설계를 잘못한 것 같지는 않았다. 생각을 해 보았는데 캡슐..
23년 02월 09일 팀프로젝트를 진행한지 4일차다. 일단 목표로한 기능들을 모두 구현해서 1차 목표 구현에 들어갔다. 내일 튜터님이 기술 멘토링을 해 주신다고 하여, 지금 하고 있는 방법론이 맞는지 간단하게 설명과 함께 질문을 적어보았다. 저희 팀의 개발 방식은 워터폴 방법론보다는 애자일 방법론의 스크럼 방식에 가깝다고 생각합니다. 저희는 다음과 같은 방식으로 프로젝트를 진행했습니다. 구상한 프로젝트에서 요구하는 기술과 우선순위를 정합니다. 정한 프로젝트 구현 목표의 우선순위에서 어디까지 작업을 할지 팀과 조율합니다. 조율해서 선정된 구현 목표를 이번 분기의 목표로 분업을 하고 구현을 합니다. 분기는 구현 목표의 난이도에 따라 달라질 수 있는데, 하루가 될 수도, 일주일이 될 수 도 있습니다. 분기 진행중에 매일 정해진 시..

티스토리툴바