WIL 4F 회고 - 주특기(spring) 3주차

Weekly I Learned
4F 방법론 Fact, Feeling, Finding, Future

Fact

이번 주는 수욜까지는 lv3과제, 목요일은 테스트, 금요일부턴 일주일 백/프론트 프로젝트 시작이 있었다.

 

lv3과제에서는 Post entity와 Comment entity의 연관 관계를 고려하며 Comment CRUD를 맡아서 작성했고 테스트는 RDB와 EC2로 간단한 배포를 진행했다. 일주일 프로젝트는 아이디어 회의 -> 피그마 -> ERD -> API -> 업무분할 순으로 진행하였고 ERD와 API를 최대한 설계/명세하고 업무를 분담했다.

Feeling

이번주 테스트에서는 entity가 하나라 연관관계가 없었고 코드는 저번주보다 쉬웠다. 대신 배포가 필수였고 RDB로 mysql을 생성하고 application.properties를 생성된 RDB에 맞춘 후 로컬에서 jar 파일을 build하고 EC2에 jar파일만 옮기고 실행하였다. RDB는 블로그 글들에서 프리티어라 하는 조건으로 생성해도 생성할 때마다 예상 금액이 잡혀있어서 시험 결과만 보고 바로 내리고 있다.

 

백3 프론트2 구성의 일주일 프로젝트를 시작하였고 아이디어 회의 -> 피그마 -> ERD -> API -> 업무분할 순으로 진행하였다. ERD와 API를 회의하는 시점에서 최대한 명세하려 하니 코드 작성보다 더 힘들었다. 일주일 짧은 시간이기에 일단 브런치 전략은 따로 안쓰고 PR만 확실히 하기로 했다. 1명이 코드를 추가하려면 최소한 남은 (백엔드) 2명 중 한 명의 코드 리뷰와 approve가 필요하다.

처음 회의에는 swagger와 test code를 기본으로 작성하고자 했는데 금요일 부터 이틀이 지난 지금 생각보다 기능 구현만으로도 시간이 빠듯해보인다. swagger와 testcode는 나중에 공부하고 작성할 것 같다.

 

최근 주특기 과제, 매주 시험, 일주일 프로젝트 등을 진행하면서 코드의 설계/명세 단계의 중요성을 많이 느낀다.

과제나 시험은 요구사항대로 코드를 작성하며 주로 spring에 대해 생각했고, 프로젝트에선 기획에 맞는 요구 사항을 설계하고 있는가 그리고 그 요구 사항을 만족하는 ERD 설계와 api명세를 작성했는가 를 생각하고 있다.

Finding

사실 요구사항대로 코드를 작성하는 건 비교적 시원시원하다. 물론 기술적으로 막힐 때도 있겠지만 입출력이 확실한게 문제를 명확히 바라보게 된다. 그런 의미에서 ERD와  API를 먼저  설계/명세하는 것은 매우 힘들지만 매우 좋다. 가장 좋은 건 처음 명세에 수정이 안생기는 것이지만 entity가 여러개 생기다보면 관계 논리를 이상하게 생각하고 api도 이상해졌다.

그래서 명세가 끝나고 업무를 분할하여 코드를 작성하면서 잘못생각한 부분들을 발견하고 수정이 있었다.

ERD 설계

API 명세( 현재 21개 )

 

일주일 프로젝트라면 코드를 작성하기 전 처음 ERD와 API설계에 얼마정도의 시간을 쓰는게 적절할까?

현재 프로젝트에선 아이디어 회의 -> 피그마 -> ERD -> API -> 업무분할 에 하루를 사용했다.

 

Future

프로젝트의 기획이 명확하면 요구 사항의 목적이 확실하고 목적이 확실하면 API 명세는 잘 나오는 듯 하다.

기획에 모호한 부분이 있다면 파고들어서 목표하는 것을 확실히 정하자!

 

ERD는 일단 모든 entity에 관계를 설정하려고 하지 않아도 좋을 것 같다.

필수적인 관계만 연결해두고 코드를 작성하며 놓쳤던 부분들에 관계를 추가하자!

단, 테이블 정의와 관련된 부분은 최대한 명확히 설계하자. (테이블명, 필요한 Colum과 Colum명)