[TIL] 221227 - 백엔드의 프로젝트 준비사항

 

백엔드가 이정도는 

 

 

 

강의를 듣고 프로젝트를 진행할때(진행하기전) 참고할만한 체크리스트가 있으면 좋을 것 같아 간단하게 만들어봤다. 자세한 내용은 아래 블로그 참고하기!

백엔드가 이정도는 해줘야함 - planB

시리즈 | 백엔드가 이정도는 해줘야 함 - city7310.log

 

 

1. 프로젝트 기획서(요구사항 분석)

프로젝트에 대해 정리하기

• 프로젝트를 5문장/3문장/1문장으로 정의하기
• 비슷한 서비스가 무엇이 있고 어떤 차별점이, 무엇을 배울수 있는지
• 가장 중요한 기능(메인기능)은 무엇인지
• 기능 화면 스케치 해보기

 

피드백하기

• 가성비가 낮은 기능이 있는지 확인하기 (중요도에 비해 오래걸리고 구현이 어려운 기능) -> 기능을 유지하거나 변경
• linear하게 늘어나는 데이터가 있는지 확인하기 -> 무한정 늘어나지 않도록, 최악의 상항을 예측 가능해야한다.
• validation rule이 상세한지 확인하기 ->  당연해 보이는 것도 언급하고 넘어가기, max 값 지정, 중복 발생 케이스 고려, ...

 

2. 프로젝트 준비하기

GitHub Organization 설정

: 개인 레포로 만들어도 되지만 organization 추천. 

 

 

작업 프로세스 결정

• 작업 관리 도구 (Issue Tracker)
  • SaaS(Trello, Asana, Monday, JIRA), GitHub Projrcts + Issues, Notion, ..
• 작업 방식
  • branch protection / forking workflow
• 기술적 의사결정
  • API 제공 방식 : REST
  • 데이터 직렬화 : JSON
  • 기술 스택 : 언어/프레임워크 , 서버 인프라, 컴퓨팅 엔진, DB, DB 서버

 

 

3. 프로젝트 진행시 고려사항

DataBase tips

• Schema 디자인에서 유의점
  • 타입 선택을 잘하자 : 데이터에 가장 잘 맞는 타입을 선택하고, size는 가능한 표준에 근거하여 사용하자.
  • Key 설정 : 자연key로 할만한 데이터가 없는 경우(유니크한 값이 없을 경우) 대체key를 사용한다.
• alter table이나 update 쿼리 등 파괴적인 행동에서 유의점
  • soft delete : hard delete로 삭제된 것은 쉽게 복구하는 것이 어렵기 때문에 사용한다. 하지만 select 쿼리를 사용할때 항상 where절을 걸어줘야하는 불편함이 있기때문에 그에따른 논쟁이 있다.
  • DROP TABLE 보다 ALTER TABLE RENAME TO : 테이블을 DROP시키면 복구가 어렵기 때문에 이름을 바꾼 후 문제가 없는지 며칠 지켜본후 그때 DROP을 진행한다. 
• DB Lock에 관해
  • ALTER TABLE을 경우 테이블 전체에 lock을 발생시키기 때문에 조심해야한다. -> Online DDL을 통해 문제를 해결할수있다.
  • backfill 작업과 같이 많은 데이터를 한번에 변경시 트랜잭션이 끝나기 전까지 모든 row가 lock에 걸릴 수 있어 lock의 범위와 지속시간을 줄이기 위해 수십~수백개 정도씩 나눠서 작은 update를 여러번 발생시키는 것이 좋다.
• DB index에 관해
  • PK, UQ, FK 는 자동으로 index가 걸린다.
  • where 절에 자주 쓸거같은 컬럼, 많은 양의 데이터에 비싼 쿼리를 수행할 거 같은 컬럼에 추기적으로 인덱스를 건다. 처음부터 해당 컬럼을 알기는 쉽지않고 쿼리가 느려지면 추가하도록 한다.(query plan)

 

 

API tips

• API Design - Request
  • Method
  • URL : 기본적으로 리소스에 따라 URL을 분류한다.
  • Header
• API Design - Response
  • Status Code
    • 상태코드 종류는 4~5개 정도로 적게 유지하는게 좋다. 
    • 권한이 없는 사용자의 리소스에 접근시에는 403(Forbidden) 대신 404(Not Found) 사용을 고려한다.
  • Error Message
  • Body
  • Header : POST 메소드의 경우 상태코드 201(Created) + location 헤더 추가를 기본으로 한다.
• API 문서화
  • 코드와 문서가 강결합하여 자동 생성되는 API Docs 사용하는 것이 좋다. -> 미스매치를 줄이고, 자동 업데이트 할 수 있다.
  • UI 수준의 문서화 방식으로 README.COM을 꽤 많이 사용한다.