프론트엔드 메인 구성 및 기초 프로젝트 구조 구성 마스터 배포
→ 개인 기능 구현 부분마다 Branch 생성 시작 및 CRUD, Viewpage 작업 시작
업무 분담의 미스
앗, 하지만 개인 기능 구현 부분?을 어제 업무 분담을 정확하게 구분하지 못했었던것이 컸다.
그리고 생각보다 프론트엔드와 백엔드를 동시에 담당하고자 했지만 제한된 시간은 프론트엔드에 소모되는 시간이 생각보다 컸다.
아침부터 나는 우선 순위로 되어있던 양식에 맞게 기획 단계를 마무리하며 제출해야 할 양식에 대해 신경쓰고 있었지만, 다른 팀원은 이미 백엔드작업이 시작되었고,
하필 내가 맡던 부분이 전반적으로 영향을 끼칠 수 있는 로그인 부분이 포함된 상태라 기초 테스트 부분의 지연이 발생하게 되었다.
업무 분담을 명확하게 하지 못했던 점이 삐그덕 거릴뻔 한 것이다.
이번 커뮤니케이션 미스는 첫날 아이디어 회의 이후 본격 개발 첫날이다보니 서로가 이해하고있는 로드맵이 달랐다.
하지만 모두가 빠르게 회의를 통해서 업무를 재분배하고 우선순위를 재정렬하기 시작했다.
우선 하던 부트스트랩 테마를 활용한 반응형 css(@media)가 적용된 메인 테마 작업까지는 간결하게 마무리짓고, 각 기능별 추가 될 페이지 양식들은 참고 할 수 있도록 와이어프레임의 기본 형태들을 구성해두었다.
혼자 모든 프론트엔드와 백엔드까지 부담하려던 계획에서 팀원모두 전체적으로 상세페이지 관련 프론트엔드를 커버 해야 하는 형태로 팀 전체가 프론트의 이해도를 높이도록 업무를 분담을 변경했다.
회원가입 및 로그인(CRUD) - 샘플 임포트 및 수정 시작
→ 초기 프론트엔드 메인 페이지를 SpringBoot 환경에 맞추어 가이드라인을 제공하기 위해
기존 실습 프로젝트의 내용을 활용하여 샘플 임포트 및 테스트
→기획 및 DB 설계에 맞추어 수정 필요
해찬님에게 기초 프론트엔드 테스트를 위해 임포트 되었던 로그인 및 회원가입 코드 리팩토링 인수인계
와이어프레임 기초 설계 마무리 및 index.html 초기 테스트
→ 기초 와이어프레임 계획 완료
→ 기획 및 DB 설계에 맞추어 추가 페이지들 마다 추후 추가 필요
→ 기초 S.A 완성 및 제출 이후 백엔드 개발 합류
리뷰 CRUD
→ 리뷰(Comment) API CRUD 구현 및 테스트
/**
* 리뷰 관련 HTTP 요청 처리를 담당하는 컨트롤러
*/
//@Controller
@RestController
@RequiredArgsConstructor
@Slf4j
@RequestMapping("/api")
public class ReviewController {
private final ReviewService reviewService;
// 리뷰 작성 API
@PostMapping("/reviews")
public ReviewResponseDto createReview(
@RequestBody ReviewRequestDto requestDto,
@AuthenticationPrincipal UserDetailsImpl userDetails
)
{
return reviewService.createReview(requestDto, userDetails.getUser());
}
// 리뷰 모두 조회 API
@GetMapping("/reviews")
public List<ReviewResponseDto> getAllReviews(
@AuthenticationPrincipal UserDetailsImpl userDetails
)
{
return reviewService.getAllReviews(userDetails.getUser());
}
// 리뷰 선택 조회 API
@GetMapping("/reviews/{id}")
public ReviewResponseDto getReview(
@PathVariable Long id,
@AuthenticationPrincipal UserDetailsImpl userDetails
) {
return reviewService.getReview(id, userDetails.getUser());
}
// 리뷰 수정 API
@PutMapping("/reviews/{id}")
public ReviewResponseDto updateReview(
@PathVariable Long id,
@RequestBody ReviewRequestDto requestDto,
@AuthenticationPrincipal UserDetailsImpl userDetails
//@AuthenticationPrincipal StoreDetailsImpl storeDetails
) {
return reviewService.updateReview(id, requestDto, userDetails.getUser());
}
// 리뷰 삭제 API by Id
@DeleteMapping("/reviews/{id}")
public ResponseEntity<String> deleteReview(
@PathVariable Long id,
@AuthenticationPrincipal UserDetailsImpl userDetails
) {
return reviewService.deleteReview(id, userDetails.getUser());
}
}
Java
복사
→ API 명명규칙에 따라 Comment → Review로 리팩토링
커뮤니케이션
변경되는 부분들에 대한 보고를 진행했다. 특히 클래스명과 같이 전반적으로 많은 부분이 수정되는 부분이다보니 영향을 미칠 수 있기 때문에, 또한 API명세서, ERD에서도 변경되는데 만약 프론트와 협업된다면 오해가 발생 할 수도 있다. 이런 리팩토링 부분은 빠르게 보고하고 설명하는 버릇을 들였다.
