[FE][Team23] 첫 번째 PR - 요구사항 분석 & 컴포넌트 설계

[jaypedia]

안녕하세요 Daisy! Millie & Oliver 입니다.
첫 PR을 보냅니다.
3주 동안 잘 부탁드립니다!

1. 구현 내역

• 그라운드 룰 & Readme 작성
• Issue Template & PR Template, Issue label 세팅
• 기능 요구사항 분석
• 컴포넌트 설계 (진행 중)

2. 고민 & 질문

기능 요구사항을 분석하고 컴포넌트 단위로 설계하면서 궁금한 점이 있습니다.

1. 기능 요구사항 분석에 관한 질문

• 프로젝트 기획서를 보고 기능 요구사항 분석을 진행했습니다.
• 분석을 할 때 어느 정도 세부적으로 분석할지에 대한 기준은 어떻게 정하는 것이 좋을까요? 바로 코드를 짤 수 있을 정도로 세부적으로 분석하여 명시하는 것이 좋을지, 혹은 팀원과 합의해서 적당히 추상적으로(?) 분석하는 것이 좋을지 고민이 되었습니다.
  • 세부적으로 분석하게 되면 설계하는 데 그만큼 시간은 많이 걸리겠지만 코드를 작성할 때의 시간은 비교적 줄어들어 그 점이 좋을 것 같습니다.

2. 컴포넌트 이름에 관한 질문

• 컴포넌트의 이름을 구체적으로 명명하면 재사용성이 떨어지고, 추상적으로 명명하면 역할에 대한 분명한 의미가 약해져서, 컴포넌트의 이름을 지을 때 어느정도로 구체적으로 지어야 할지를 모르겠습니다.

  • 예컨대, 예약창과 관련된 모달 컴포넌트를 만들 때 컴포넌트의 이름을 Modal로 지으면 향후 모달이 필요한 다른 곳에서도 쓰일 수는 있지만, 예약창 모달이라는 의미는 약해지고, 그렇다고 ReservationModal로 지으면 정확한 의미 전달은 되지만, 향후 모달이 필요한 다른 곳에서는 쓰일 수 없습니다.
  • Modal과 ReservationModal 둘 다 만드는게 맞을까요? 아니면 둘 중 하나를 만드는게 좋다면 어떤 방식을 추천하시는지 궁금합니다.

3. 컴포넌트 설계에 관한 질문

• 재사용될 수 있는 컴포넌트와 컴포넌트가 결합된 컴포넌트(한 번밖에 안 쓰이는)가 현재 같은 폴더 내에 있어서 헷갈리는데, 이들을 구분할 수 있는 convention(폴더구조 관련..?) 같은게 있을까요?

- components
    ㄴSearchbar
    ㄴPriceRangeSlider    // 1
    ㄴGuestSelector       // 2
    ㄴDateSelector        // 3

• 위와 같이 4개의 컴포넌트를 설계했을 경우 Searchbar 컴포넌트는 1, 2, 3 컴포넌트가 조립되어 만들어집니다.
• 이 경우 1, 2, 3 컴포넌트를 Searchbar 폴더에 넣어도 되는 걸까요? 이렇게 했을 때 컴포넌트끼리의 의존성이 강해지는 것은 아닐까 궁금합니다.

3. 이후 계획

• 리뷰 반영하여 컴포넌트 설계 수정
• 컴포넌트 설계 마무리 후 Issue 발급
• React-TypeScript 환경설정

[damilog]

ISSUE, PR template 좋네요ㅎㅎ

[damilog]

Ground Rule 구체적이네요. 좋습니다.

[damilog]

안녕하세요 Millie, Oliver~ 리뷰를 맡은 Daisy입니다.

개발에 앞서 Ground Rules, Component 설계 등을 진행하셨군요! 리드미 잘 봤습니다.
프로젝트 협업에 있어 많은 도움이 될 것 같네요. 앞으로가 기대가 됩니다!😄

질문에 답변을 드리자면,

1. 기능 요구사항 분석에 관한 질문
   프로젝트 기획서를 보고 기능 요구사항 분석을 진행했습니다.
   분석을 할 때 어느 정도 세부적으로 분석할지에 대한 기준은 어떻게 정하는 것이 좋을까요? 바로 코드를 짤 수 있을 정도로 세부적으로 분석하여 명시하는 것이 좋을지, 혹은 팀원과 합의해서 적당히 추상적으로(?) 분석하는 것이 좋을지 고민이 되었습니다.
   세부적으로 분석하게 되면 설계하는 데 그만큼 시간은 많이 걸리겠지만 코드를 작성할 때의 시간은 비교적 줄어들어 그 점이 좋을 것 같습니다.

가능한 세부적으로 분석하는게 좋다고 생각합니다. 같은 요구사항을 보고도 서로 다른 방향으로 이해를 할 수도 있는 것이고, 기능을 세부적으로 분석하는 과정 자체가 설계의 한 부분이기 때문입니다. 남겨주신 위키 확인해보니, 지금 작성해주신 요구 사항 분석 리스트 정도도 충분해 보입니다~ 하지만 Millie와 Oliver 놓친 feature 들이 있을 수 있으니, 데일리 스크럼 / 페어 프로그래밍 시간 등을 활용해서 자신이 맡은 기능이 의도에 맞게 구현되고 있는지 함께 점검해보는 시간을 가져보면 좋을 것 같네요~🙂

2. 컴포넌트 이름에 관한 질문
   컴포넌트의 이름을 구체적으로 명명하면 재사용성이 떨어지고, 추상적으로 명명하면 역할에 대한 분명한 의미가 약해져서, 컴포넌트의 이름을 지을 때 어느정도로 구체적으로 지어야 할지를 모르겠습니다.
   예컨대, 예약창과 관련된 모달 컴포넌트를 만들 때 컴포넌트의 이름을 Modal로 지으면 향후 모달이 필요한 다른 곳에서도 쓰일 수는 있지만, 예약창 모달이라는 의미는 약해지고, 그렇다고 ReservationModal로 지으면 정확한 의미 전달은 되지만, 향후 모달이 필요한 다른 곳에서는 쓰일 수 없습니다.
   Modal과 ReservationModal 둘 다 만드는게 맞을까요? 아니면 둘 중 하나를 만드는게 좋다면 어떤 방식을 추천하시는지 궁금합니다.

재사용 컴포넌트를 설계할 때 자주 하게 되는 고민이네요~ㅎㅎ 컴포넌트 이름은 컴포넌트의 역할과 책임이 잘 드러나게 짓는게 좋은데, 이건 두 분이 Modal 컴포넌트를 어느 정도로 추상화할 건지에 달려있습니다. 이 Modal 컴포넌트가 가진 역할은 무엇인가요? 단순히 toggle 기능인가요? 그럼 toggle 기능을 갖춘 Modal 컴포넌트를 만들어서 ReservationModal을 별도로 구현하는데 활용할 수 있겠네요.

ReservationModal로 지으면 정확한 의미 전달은 되지만, 향후 모달이 필요한 다른 곳에서는 쓰일 수 없다고 말씀 주셨는데, ReservationModal이 아래 모달 말씀하시는 것 맞나요?🤔 그럼 이번 프로젝트에서는 ReservationModal이 다른 곳에 쓰이는 경우는 없을 것 같은데요~ 추후 기능 추가를 염두해주시고 질문해주신걸까요??😃

재사용 컴포넌트를 설계하는 것에는 정답은 없고, 또 처음부터 재사용 컴포넌트를 완벽하게 만드는 건 누구에게나 어려운 일이라고 생각합니다. Modal을 만들어보시면 각 Modal 중복되는 부분이 분명 존재할 거예요. 그럼 그때 기존에 추상화했었던 Modal 컴포넌트를 리팩터링 해나가는 것도 좋다고 생각합니다. 컴포넌트 설계 관련 자료 전달 드리니 참고해보시면 좋을 것 같아요!

• 변경에 유연한 컴포넌트
• [A3] 컴포넌트, 다시 생각하기

3. 컴포넌트 설계에 관한 질문
   재사용될 수 있는 컴포넌트와 컴포넌트가 결합된 컴포넌트(한 번밖에 안 쓰이는)가 현재 같은 폴더 내에 있어서 헷갈리는데, 이들을 구분할 수 있는 convention(폴더구조 관련..?) 같은게 있을까요?

• components
  ㄴSearchbar
  ㄴPriceRangeSlider // 1
  ㄴGuestSelector // 2
  ㄴDateSelector // 3
  위와 같이 4개의 컴포넌트를 설계했을 경우 Searchbar 컴포넌트는 1, 2, 3 컴포넌트가 조립되어 만들어집니다.
  이 경우 1, 2, 3 컴포넌트를 Searchbar 폴더에 넣어도 되는 걸까요? 이렇게 했을 때 컴포넌트끼리의 의존성이 강해지는 것은 아닐까 궁금합니다.

이건 팀 컨벤션 정하기 나름인 것 같은데, 저는 재사용 컴포넌트는 주로
components > common 하위에 넣습니다. (common이 많아지면 거기서 또 그룹핑 할 수도 있겠죠?ㅎㅎ)

SearchBar구성하는 자식컴포넌트가 있다면 SearchBar directory에 해당 컴포넌트 폴더/파일들을 놓고 , entry point가 되는 Index 파일에 SearchBar를 구현해서 SearchBar가 entry point가 되는 상위 컴포넌트라는 걸 명시할 것 같아요. 어찌 됐든 directory로 컴포넌트를 계층을 표현하는 건 Millie와 Oliver 방식과 같네요. 컴포넌트끼리 의존성이 강해진다는 의미가 제가 이해한 의존성을 의미하는 것이 맞다면, 이것은 디렉터리 구조라기 보다는 props로 어떤 값까지 내려받는지, state 위치 등을 살펴봐야 할 것 같은데요! 이런 부분에서 의존성을 느슨하게 하는 방법을 고민해보면 좋을 것 같습니다.😄

[jthw1005]

ReservationModal로 지으면 정확한 의미 전달은 되지만, 향후 모달이 필요한 다른 곳에서는 쓰일 수 없다고 말씀 주셨는데, ReservationModal이 아래 모달 말씀하시는 것 맞나요?🤔 그럼 이번 프로젝트에서는 ReservationModal이 다른 곳에 쓰이는 경우는 없을 것 같은데요~ 추후 기능 추가를 염두해주시고 질문해주신걸까요??😃

저희가 구상한 Modal 컴포넌트의 역할은 아래와 같습니다.

1. 팝업창 역할
2. 모달창 이외의 영역을 클릭했을 시 해당 모달창 닫기

이러한 역할을 하는 component의 이름을 단순히 Modal로 정하면 어떤 모달창인지 너무 추상적일 것 같아서 ReservationModal로 정해야할지 고민했습니다.

조언주신 대로 위와 같은 역할만 담당하는 Modal 컴포넌트를 만들고, Modal 컴포넌트를 이용하는 구체적인 컴포넌트인 ReservationModal을 만드는 방향으로 컴포넌트를 설계해보려 합니다.

[jaypedia]

이건 팀 컨벤션 정하기 나름인 것 같은데, 저는 재사용 컴포넌트는 주로 components > common 하위에 넣습니다. (common이 많아지면 거기서 또 그룹핑 할 수도 있겠죠?ㅎㅎ)

SearchBar구성하는 자식컴포넌트가 있다면 SearchBar directory에 해당 컴포넌트 폴더/파일들을 놓고 , entry point가 되는 Index 파일에 SearchBar를 구현해서 SearchBar가 entry point가 되는 상위 컴포넌트라는 걸 명시할 것 같아요. 어찌 됐든 directory로 컴포넌트를 계층을 표현하는 건 Millie와 Oliver 방식과 같네요. 컴포넌트끼리 의존성이 강해진다는 의미가 제가 이해한 의존성을 의미하는 것이 맞다면, 이것은 디렉터리 구조라기 보다는 props로 어떤 값까지 내려받는지, state 위치 등을 살펴봐야 할 것 같은데요! 이런 부분에서 의존성을 느슨하게 하는 방법을 고민해보면 좋을 것 같습니다.😄

📁component
    ㄴ📁common
        ㄴ📁GuestSelector
            ㄴindex.jsx
            ㄴstyle.js
        ㄴ📁Calendar
            ㄴindex.jsx
            ㄴstyle.js
        ㄴ📁Modal
            ㄴindex.jsx
            ㄴstyle.js
        
    ㄴ📁SearchBar
        ㄴindex.jsx
        ㄴstyle.js
        ㄴ📁SearchBar_GuestSelector
            ㄴindex.jsx
            ㄴstyle.js
        ㄴ📁SearchBar_Calendar
            ㄴindex.jsx
            ㄴstyle.js
    
    ㄴ📁ReservationModal
        ㄴindex.jsx
        ㄴstyle.js
        ㄴ📁ReservationModal_Calendar
            ㄴindex.jsx
            ㄴstyle.js

• 데이지가 하신 말씀을 위와 같은 디렉토리 구조로 이해했습니다.
• common 폴더에는 재사용이 가능한 컴포넌트들을 위치시킵니다.
• SearchBar와 같이 다른 컴포넌트를 필요로 하는 컴포넌트일 경우, 다른 컴포넌트들을 SearchBar_GuestSelector와 같이 명명해서 위치시킵니다.
• 이런 설계 방식을 말씀하신 게 맞나요?