개발 일기

프로젝트를 진행하고 약 3주의 시간이 지났다. 3주동안 프로젝트 설계와 mvc 개발을 진행했고 오류의 범위를 좁히고자 최대한 명확한 코드를 작성하기로 했었다. 예를 들어 중복검사와 같은 기능이 필요하다면 jpa를 사용한 find가 아닌 exist를 사용해 boolean 값으로 반환시켜 해당 코드를 작성하지 않은 팀원도 알기 쉽게 하였다. 그리고 변수명과 함수명을 지으며 많은 고민을 했던 것 같다. 약 3주의 시간이 이렇게 지나고 멘토님과 중간 발표 시간이 있었고 사전 질문으로 아래와 같은 질문을 받았다. --- 질문 --- Redis는 메모리 DB라서 서버가 리부팅되면 모든 데이터가 삭제됩니다. 이런 관점에서 서버를 리부팅해야 할 일이 발생했을 때 인기 검색어가 노출되지 않을 수 있을 것 같은데요. 어떻..

팀 프로젝트에서 테스트 코드를 작성해볼 기회가 있었다. 테스트 코드를 작성하기 위해 본 코드의 클래스에서 ctrl + shift + t 를 눌러 클래스 내부의 메서드 중 테스트 코드를 작성하고자 하는 메서드를 선택해주었다. 위의 방법대로 테스트 클래스를 만들고 막막함이 컸다. 테스트 코드를 작성해본 적도 없고 어떻게 작성해야 하는지 방향을 잡기도 어려웠다. 그러나 테스트 코드를 작성하기 위해 가짜 Mock 객체를 만든다는 것을 알고있었고 여기서 말하는 Mock 객체란 내가 테스트하길 원하는 필요한 기능만으로 만들어둔 객체이다. 그리고 테스트 코드를 작성하며 권장되는 구조가 있는데 바로 given - when - then 구조이다. 이 구조는 테스트의 목적을 명확하게 표현해낼 수 있으며 봤을 때 이해하기도..

3월 31일 부터 6주간 팀 프로젝트를 진행하게 되었다. 팀원과 프로젝트를 진행하며 첫 1주간은 가장 기본적인 CRUD의 구현을 목표하였고 회원가입과 로그인을 그동안 구현해본 적 없었기에 직접 코드를 작성 해보고 싶었다. 회원가입과 로그인 기능을 구현하며 로그인을 할 때 JWT 토큰 헤더와 쿠키에 담아서 보내는 두 가지 방법중 쿠키에 담아서 클라이언트로 보내는 방법을 선택했다. 헤더로 전송한다면 토큰 사용에 대한 제어 및 유연성이 올라가고, CSRF 공격과 같은 보안 위험을 피할 수 있다. CSRF는 사이트 간 요청 위조(Cross-Site Request Forgery)로 불린다. 브라우저에서 웹사이트의 신뢰를 악용하는 공격 유형이며 이 공격은 악의적인 웹 사이트 또는 사용자가 알지 못하거나 동의 없이 ..

프론트의 도움 없이 카카오톡 로그인 기능을 혼자서 구현해 봤는데 이게 맞는 기능인지 궁금했었다. 기능이 작동하는지 포스트맨을 사용해 확인해 보겠다. 카카오 개발자 사이트 가입 및 로그인: 카카오 디벨로퍼 시작 -> 애플리케이션 추가하기 -> 애플리케이션 들어가서 REST API키 복사해두기 -> REST API키를 저장해두고 포스트맨에서 테스트를 위해 Redirect URI를 추가해놔야 한다. 아래 두 가지 URI를 추가하자 https://getpostman.com/oauth2/callback 로그인 이후 반환 URI 보안에서 Client Secret 코드를 생성해 복사해두기 GET메서드, 아래의 URI를 입력한다. https://kapi.kakao.com/v2/user/me Authorization 클..

단위 테스트를 작성해야 하는 이유는 많다. 그 중에서 몇 가지만 살펴보고 넘어가자면 아래와 같다. 단위 테스트의 중요성 코드를 작성하고 수정 또는 추가할 때 오류가 어떤 곳에서 발생하는지 빠르게 찾아낼 수 있다. 오류를 빠르게 찾아낼 수도 있지만 다른 코드를 수정할 때 안정성을 갖고 진행할 수 있다. 코드 작성과 수정 그리고 유지, 종합적인 것을 생각했을 때 결과적으로 시간과 비용을 절감할 수 있다. 시간과 비용을 절약할 수 있다는데 어떤 부분에서인지 와닿지 않을 수 있다. 단위 테스트 코드를 작성하지 않았다면 개발이 끝난 후 통합 테스트를 진행하기 위해 애플리케이션을 실행해 수동으로 통합 테스트를 진행해야 한다. 통합 테스트는 캐시, 데이터베이스 등 다른 컴포넌트들과 연결하거나 추가적인 시간이 필요하게..

처음으로 백엔드와 프론트를 나누어 팀 프로젝트를 진행하게 되었다. 기간은 3.17(금) ~ 3월 23(목) 약 1주일 이었고 재밌으면서도 힘들었던 기억이다. 프로젝트의 주제를 정하기 앞서 처음으로 백엔드와 프론트의 협업이 이뤄지는 이번 프로젝트에서 무엇을 경험해보고 배우는것이 무엇일지 생각해 보았다. 많은 기능과 보기 좋은 웹 사이트를 만드는 것 분명 좋은 일이다. 하지만 지금까지 배웠던 기본적인 CRUD를 사용해 리펙토링을 거쳐, 프론트와 통신하며 발생하는 오류 등을 경험해보고 싶은 마음이 더 있던것 같다. 다행히 다른 팀원들도 이 부분에 동의하는 분위기였고 팀 프로젝트에서 게시글의 생성, 조회, 수정, 삭제를 담당하여 구현하게 되었다. 전체 데이터를 조회하는 과정에서 반복문을 사용하고 한개 이상의 리..

클론 코딩을 시작하기에 앞서 오늘의집을 주제로 선정했다. 오늘의 집 https://ohou.se/store?utm_source=rt_brand_google&utm_medium=inorganic&utm_campaign=uc_web-all-all-google_se 그리고 무슨 기능이 있는지 위 사이트를 들어가 이것저것 눌러보며 짧게나마 정리했다. 다른 회원의 집들이 게시글의 스크랩 버튼을 누르면 스크랩이 가능하다. 스크랩 된 게시글은 마이페이지에서 모아서 확인 가능하다. 스크랩 버튼을 누르면 바로 스크랩 북으로 이동 할 것인지 의사를 묻는다. 집들이 게시글 목록에서 제목,글쓴이, 스크랩 수, 조회 수를 보여준다. 집들이 게시글에서 오른쪽 댓글 토글을 누르면 게시글 영역 중 댓글 영역으로 스크롤이 자동 이동한..

CI (Continuous Intergration) - 지속적 통합 설정 브랜치로 머지하면 자동으로 build, jar파일 생성 여러명이 하나의 코드에 대해 수정을 해도 지속적인 통합 관리가 가능함. 고객의 요구사항에 빠르게 대응하기 위해 나온 XP의 실천방안 CD (Continuous Deployment) - 지속적 배포 설정 브랜치로 git push > 생성된 jar파일 AWS에 업로드, 배포 빌드의 결과물을 프로덕션으로 자동, 지속 배포. CI의 연장선 개념 아래는 ci(지속적 통합)를 위한 간단한 yml파일 준비 예시 # 브랜치는 main(최종 dev 배포만을 위한 브랜치) - dev(각 개발 브랜치 합치는 브랜치{빌드 및 테스트 검사}) - feature/1-어쩌구(각 개발 브랜치) name: ..

public List getAllPost(User user) { // 모든 게시글 작성일별 내림차순 리스트 List posts = postRepository.findAllByOrderByCreatedAtDesc(); List postList = new ArrayList(); for (Post post : posts) { postList.add(new PostResponseDto(post, isLike)); } return postList; }예를 들어 위와 같은 전체 게시글을 조회하는 기능이 있다 가정하고 Stream을 사용해보자. postRepository.findAllByOrderByCreatedAtDesc().stream().map(post -> new PostResponseDto(post)).co..

프로젝트 배포하기 위해 먼저 거쳐야 하는 것은 프론트와 백의 소스를 합치는 일이다. 이러한 과정에서 발생하는 대표적인 문제는 CORS에러이다. CORS는 Cross-Origin Resource Sharing 이라는 단어로 이루어 져 있고. 문장을 직역하면 "교차 출처 리소스 공유 정책"이라고 해석할 수 있다. 교차 출처란 엇갈린 다른 출처를 의미하는 것으로 보면 된다. 분명 따로 개발하고 기능을 돌려봤을 때 문제는 없었지만 발생한 CORS를 해결하기 위해 WebSecurityConfig 클래스에 코드를 추가했다. 원래 코드는 아래와 같다. package com.sparta.studybook.config; import com.sparta.studybook.jwt.JwtAuthFilter; import co..