1. 주어 + 목적어 + 술어 단위로 스토리 뽑기 (user flow 단위 하나가 스토리가 되면 될 듯. )

ex ) 관리자는 초대 기능을 만들 수 있다. → api 구성, 협업 단위 구성 특히나 주어를 제대로 명시해야 기능의 주체를 정확히 할 수 있음.

2. 유저 입장 기능 중점으로 story 짜기

   1. API 중점이 아니라 기능 단위로 생각해야 함.
      백, 프론트, 디자이너 모두가 공감할 수 있는 unit이 story다 되어야 함.
   2. Story 내용은 Jira ticket 제목으로 관리, story 를 달성하기 위한 task 들을 할당

3. 챌린지적인 요소들은 후에 점진적으로 추가

   1차 구현이 끝나고 challenge 스러운 것들을 시도해 보면 좋을 것 같음. 웹뷰 데모데이에 시현 ⇒ 완성에 초점 ⇒ challenge 요소 추가

   a. admin을 2명 이상으로 가정

   b. 일반 유저의 admin롸

   c. 실시간성 기능 구현 ex ) 채팅

   d. 회계 내역 처리 → trasaction 으로 처리해 보기 (locking 처리)

   → 실제 돈 연동이 아니라 mock(csv) 데이터를 이용해도 괜찮음.

   e. 멤버 수 제한 신청하자 마자 바로 실시간으로 알려주는 방식. locking 이라는 건, 시간이 지연이 되기 때문에, 한정된 시간 내에 어떻게 해결할 것인가를 생각해보기

4. Story는 어디까지 확장시킬건지 확인하기 ( MVP에 포커싱을 먼저 하고 타협 지점 )

a. 확장을 어디까지 고려해야할 것인가 일단 고려하지 않아도 충분히 수정 가능한 경우가 대부분이고, 경험에서 얻는 방법 밖에 없기 때문에 확장성을 미리 고려할 필요는 없을 것 같음.

b. side effect 최소화 하기. 그래도 고려하면 좋은 것은,객체간의 의존성을 최대한 낮추는 것.인터페이스를 최대한 이용하는 것이 좋음.그래야 작은 수정으로 인해 대규모 수정이 발생하지 않음 (객체지향 프로그래밍, 함수형 프로그래밍).

1. 애자일한 설계가 무엇인가?

처음부터 완벽한 설계는 없다. 확장성이라는 것은 경험론적으로 해봐야 아는 것임. ⇒ story 확장성 정도만 잡고 가면 될 듯

백) erd 설계를 확정했다면 빠르게 구현해보는 것이 좋음. => software라는 특성상 정책 등이 쉽게 변화할 수 있기 떄문에 설계 집착하지 말 것 (erd, 정책, 기능은 언제든 바뀔 수 있음. (Backlog))

ㅂerd 설계를 확정했다면 빠르게 구현해보는 것이 좋음. => software라는 특성상 정책 등이 쉽게 변화할 수 있기 떄문에 설계 집착하지 말 것 (erd, 정책, 기능은 언제든 바뀔 수 있음. (Backlog))

2. 협업 및 역할 분담.
   1. 백의 경우에는 일단 관련 없는 도메인을 기준으로 역할 분담하는게 좋음 실상 개발중에는 여러 도메인에 접근하게 되긴 하지만 일단은?
   2. 프론트가 api 가 완벽하게 나오기 까지 기다리지 말고 백이 mock 데이터 정해주면 그거 일단 넣고 쓰기
   3. story 정의 하고 블락되지 않을 것 같은거 먼저 시행하기

백엔드 질문

1. 백 개발환경 셋팅

   1. Gradle vs Maven ⇒ Gradle (maven )
   2. properties vs yml ⇒ yml _ properties에 중복된게 많아짐.
   3. Java version 20에 Spring boot는 3점대로 쓰는게 좋음.

2. Entity 와 DAO

   엔티티 : 비즈니스 로직에서 메인으로 사용

   그러나 엔티티(비즈니스 로직)와 table(Data base)을 일치시키는게 좋은게 아님 왜냐면 의존성을 줄이는 방향으로 가는게 가장 좋기 때문

   도메인이랑 db 일치시켜서 문제에 닥쳐보는 것도 도움이 될듯

3. 현업에서의 JPA 사용 여부 마이크로 서비스화 되어갈 수록(외부 api 사용), 도메인이 복잡해 질수록 JPA 사용이 어려워짐. 그러나 우리 수준에서는 전혀 문제 없음

4. api

   • result 값을 쿼리 파라미터로 넣는 것 보다는 string 으로 approve / resect 로 확실히 구분하는게 좋을듯. 차라리 body로 넘겨라.
   • api 설계시에 내부적으로 convention을 확정 짓고 그에 따라 진행하는 것이 좋음. (좋은 api 방식이라는 것은 없다…!)

5. table 인덱스를 VARCHAR(45)를 쓰는 것에 관하여.. 알다시피 DMS에서 우리가 원하는 what을 찾을 때 인덱스를 이용함. (보통 B-tree) 근데 인덱스를 (ex) username) 을 인덱스로 사용하게 되면 정수 bit로 빠르게 처리할 것을 8bit를 사용하는 꼴이 되는 것임. ⇒ 결론적으로 ..? 인덱스는 무조건 정수