👏

프로젝트 중간 점검

현재 개발에 대한 공부를 꾸준히 하고 있는 여러분들의 입장에서 가장 절실할 수 있는 서비스로의 설계를 잘 선택한것 같습니다.

다만, 사용자들에게 이미 널리 알려진 여러 유형의 알고리즘 테스트 이외에 퀴즈로써 문제의 질을 어떻게 올릴 것인가하는 과제가 남겨져 있는 것 같습니다.

하지만, 지금 여러분들이 수행하는 프로젝트가 출시를 통한 수익실현이나 사용자의 유입 증대가 목표가 아닌 이상 어느정도 타협할 수 있는 부분인것으로 보여, 크게 문제라고 할 수 있는 부분은 아닌것같습니다만,

최종제출때에는 이러한 부분에서 어떠한 포인트로 퀴즈의 질을 높일 수 있을 것인가에 대한 해답이나 풀어나갈 포인트를 제시해 주신다면 더 좋을 것으로 생각합니다.

영상을 보면서…

1. 게임의 요소를 적절히 배치


자칫하면 지루해질 수 있는 퀴즈의 서비스 요소에 게임이라는 요소를 추가하여,
사용자가 게임하듯이 풀 수 있게 하는 아이디어가 너무 좋았습니다.

2. 퀴즈 수정이 있던데…


이미 퀴즈를 푼 다수의 사용자가 존재하는 경우에 대해서
퀴즈의 수정이 이루어져서 문제자체가 정반대로 바꾸거나 하게된다면,
이거는 문제의 소지가 발생할 수 있을 것 같은데,
이부분에 대해서도 고려가 되었던 걸까요??

그리고 퀴즈 삭제를 한다면, 이전에 퀴즈를 풀었던 사용자들은 어떻게 되나요??
삭제전이나 수정전에 풀었던 퀴즈라면 이전의 내용으로 표시가 되거나 해야할 것으로 보이는데,
그걸 볼 수 있는 view같은게 설계되어 있는걸까요?

3. 세트화관련


퀴즈를 세트화한다는것이 특정 유저가 여러개의 퀴즈를 세트로 묶어서 한번에 제출하겠다라는 의미같은데,
임의의 퀴즈를 풀 경우에는 세트화 여부가 어떠한 영향을 미치는 건가요?
세트화에 대한 구체적인 설명이 툴팁으로 있어야 유저에게 친절한 설명이 될 수 있을것으로 생각합니다.

회고록을 보면서…

개발 진행 관련

Keep

미해님이 디자인에 투자한 시간에 대한 감사와 respect

개발환경 세팅들 솔선수범하여 미리 해주신것에 대한 감사

인터페이스 미리 구현해준 것에 감사

깔끔한 코드를 보고 많이 배울 수 있어 감사

Problem

개발 진행속도는 느리다고 생각해용

이유는 기획 단계가 부실해서..

2주에 맞는 기획을 생각해야 했으나 adv를 고려하면서 복잡도가 높아졌다 (4주 정도의 욕심)
adv 고려하면서 basic의 구체적 기획이 부족했다


2주에 맞는 서비스 기획이라는 부분은 사실 몇년이나 현직에 근무한 현직자들에게도 무척이나 
어려운 부분입니다. 기획단계에 있는 모든 부분을 다 만들생각보다는, 중요도를 구분지어서
꼭 구현되어야 할 기능들을 우선 개발하여 오픈 후, 나머지는 추가 개발을 하거나 하는
방법으로 하셔도 될 것 같습니다 :)

[ Try ]

데드라인에 맞는 기획을 하자

팀 개발이 익숙하지 않아서 팀 RULE 익히는게 오래 걸렸음

동의 동의2


이번 프로젝트를 통해 여러분들이 배웠으면 하는 부분입니다.
아직은 어려운 부분도있고, 어색한 부분도 있을것으로 생각합니다.
이러한 부분을 미리미리 체험해보면서 앞으로 팀단위 개발에 대한 이해도를 끌어올리실 수 있기를 기원합니다.

2주에서는 도전을 하면 안될 듯? → 인간은 도전하는 동물이에요!! (re:ㅋㅋㅋㅋㅋ)

공통 기술 스택 관련
새로운 개발 스택 적응에 오래 걸렸음

[ Try ]

학습과 프로젝트를 구분하자
가장 잘하는 걸로 하자
오류는 채팅으로 빠르게 물어보자

다른 사람이 경험했을 확률 높다

코드리뷰를 어느 정도로 해야 하는지 고민이었고, 리뷰하는데 보다 많은 시간 소요

[ Try ]

첫 페이지를 구현한 다음에는 PR단위를 줄이자 + 가독성 좋은 PR 메시지를 쓰자

개인 < 프로젝트 < 서비스단 에서의 우리 코드 기준은 어디인가

[ Try ]

“basic First, advance Later Due to TimeLimit“
“Do First, Refactor Later” 12345 vs 13579

어렵지 않다고 느끼는데, 빠르다고 느끼진 않음 → 쉬운데 오래걸림 .. → 저도 동감

container 폴더의 역할? 의미?

소통문제도 있는 것으로 → 일단은 ㄱㄱ

[ Try ]

각자 리뷰 올린 후 폴더구조 결정

api 처리하느라 시간이 많이 소요되었다

백엔드와의 소통과정 체험이랄까

선협님이 짜놓은 컴포넌트, hooks 그냥 가져다 사용할 수 있는 부분들 있는데, 바람직한가?

기타 (어려운점 , … )

Keep

음..

Problem

zenHub 도입 의미 있었나?

에픽 단위로 이슈를 관리한다는 측면에서 어느 정도 장점은 확실히 있다고 생각
지금은 하나의 에픽을 한 사람이 관리해서 + github 자체 칸반이 있어서 효용성이 적다

[ Try ]

issue + PR 연결, epic등록만 같이 잘해주기


이슈 단위의 개발방법은 차후에도 계속해서 쓰이게 될 겁니다 :)

라이브러리 도입(formik)

익히는데 하루 꼬박 걸림


다양한 라이브러리를 가져다 쓰는것도 좋은 프로젝트를 구성할 수 있는 방법이죠!

페이지 구현 기본 로직들이 바로바로 생각나지 않아 시간을 많이 썼다

시간에 쪼들린다고 생각해서 생각날 것도 잘 안난다
로직 분리에 대한 고민들을 했는데 생각만큼 잘 되진 않아서 일단 어거지로 쓰는 중


나중에 이 코드를 다시 보고 리펙토링을 해보시는것을 추천드립니다 :)
이 과정만 잘 수행된다면 면접단계에서 좋은 인상을 받을 수 있습니다.

hook과 분리된 완전한 로직을 작성(클래스 형식으로)하고 싶었는데, 해당 부분이 쉽지 않다


결코 쉬운 과정은 아니죠 ㅎㅎ
그래서 회사가 커질수록 프론트에서도 직군이 세분화가 됩니다.

제어/비제어 컴포넌트 선택과, 비제어 컴포넌트로 할 수 있는 구조를 짜다가 포기하고 되돌아 온 것

로직을 분리하는 것에 있어 어느 정도로 분리할지 / 어떤 폴더에 넣어야 할지 고민이 많았다

구현 시 확장성에 대한 고민을 하다 많은 시간을 보냈다


우선 구현 후 확장성을 고민할수도 있을 것 같네요 :)
hooks라는부분이 사실 그러한 방법으로 만들어졌다고 해도 과언이 아니니까요

[ Try ]

확장성 관련은 PR과 develop에 올린 것만 참고하자!

코드를 보면서…

아래 코드는…음…해당 방법이 최선이었을까요??

notion image

Form 컴포넌트 관련

현재 만들어진건 Form 안에서 사용되는 Field 하나에 대한 부분인 것 같습니다.
FormContainer, Label, Layout 등으로 구성을 나누어서 전체적인 하나의 폼 컴포넌트를 만드는것이 이상적인 폼 컴포넌트 입니다.

create 폴더명은 무엇이죠?

혼자만 폴더의 네이밍규칙이 깨져있어요. 어떤 의미가 있나요??
규칙을 준수하면 좋을 것 같습니다.

colors 의 type 정의 부분

colors에 대한 리스트가 이미 정의된걸로 알고있습니다. string이 아니라 해당 리스트의 타입으로 변경해서 정의된 컬러만 들어갈 수 있도록 해주세요.


type propsType = {
  colors: string;
  text: string;
};

color 명칭이…숫자??

컬러 이름이 숫자…인건가요??

notion image

각 폴더마다 존재하는 README.md

꼭 필요한 파일인건가요??