TIL 35 [ Spring 기초 프로젝트 ( Day 2 ) - 구현 (게시판 페이징 작업, 정렬), 깃 기능별 병합 ]

16:00 ~ 17:00 미니 실습과제 해설 ( 영속성 컨텍스트 ) 스탠다드반 ( 박성규 튜터님 )

 

어제 하였던 게시물 기능에서 CRUD와 연관관계만 작성하고 하루를 마쳤었다.

이제 여기서 조건에 맞게 조회 할때 1페이지에 10개 데이터가 조회되게 하는 형식으로 구현 하였고, 기본 적인 정렬은 생성자 일 기준으로 내림차순으로 구현하였다.

Controller

Service

전체 조회 기능이 되는 부분이 CRUD 상으로 List형태로 반환 받게 되어 있었는데 이제 List가 아닌 Page클래스를 활용해서 구현을 하였다.

처음에 컨트롤러에서 @PageableDefault 라는 것을 활용해서 request 값을 보냈으며 여기서는 기본값이 size가 10이고, page가 0으로 설정 되어 있다. 여기서 이제 direction 이라는 속성을 이용해 Sort.Direction.DESC 로 해주면 내림차순을 한다는 의미가 되며, sort = " {컬럼명 (카멜 케이스)} "  방식으로 선언 한다.

이렇게 하면 createdAt 컬럼 기준으로 내림차순을 하겠다라는 의미가 된다 ( 생성일 기준 내림차순 )

✅ userName이라 하지않고 username, signup 등 한 단어로 보고 있다. 

 

파라미터 부분은 Pageable 객체를 활용해서 pageable로 매개변수 형식으로 선언해주었다.

이 객체는 Spring Data JPA가 페이징 처리를 쉽게하기 위해 제공하는 객체이다.

 

다음, 서비스에서 Page로 반환을 받고 있기 때문에 반환값도 Page로 선언해주어야 한다. 그래서 pageable로 통해 전체 조회를 위한 findAll(pageable)로 받고, map을 통해 responseDto::toDto 만해주면 끝난다. 리스트 형태로 반환할 것이 아니기 때문에 toList()가 사라진다.

 

팀원들과 다 같이 튜터님 한테 찾아가서, 각자 한 기능별 대로 dev에 병합하는 시간을 가졌다.

내가 화면 공유를 하고, 이제 하나하나 씩 병합하는 과정을 거쳤는데 하는 과정에서 충돌이 일어나도, 굉장히 간단하였다. 코드 두개를 비교하면 왼쪽 오른쪽 코드를 비교하면서 해당되는 곳을 ✅, 수정하지 않고 삭제해도 되는 곳을  ❌ 할 수 있었다. 그렇지만 불편하던 것이 깃에서 띄어쓰기만 한것도 짚어주는게 가장 큰 단점 이었다.

 

그 결과 아주 깔끔한 구조가 나왔다.

dev에 병합된후 깔금해진 구조

 

병합 이후로도 아직 DDD구조(도메인 형식 구조)로 통일하지 않으신 분들이 계셔서 시간이 좀 소요 되었지만, 내가 팀의 프로젝트를 운명을 걸고 있었으니까 부담이 되기도 하였다. ( 처음부터 이렇게 잘 알고 있었다면 미리 작업 해둘 것 이라는 아쉬움이 남았다. )

그리고 해당 작업 이후 클래스 가 겹쳐지는 부분이 있어서 해당 담당하는 팀원 분 께서 작업을 마무리하고 나서야 이제 우리가 다시 pull 을하여 다시 새로운 브런치로 만들어서 작성을 할 수 있게 되었다. 

 

마지막으로 각자 미리 역할을 분담 하였는데 트러블 슈팅, 대본, 트러블슈팅 ,영상 찍기 , ppt 형식으로 각자 역할 분담을 맡고 하루를 마무리 하게 되었다.