프로젝트 관련 Q&A

Q1. 진행한 프로젝트를 핵심만 담아 간략하게 설명해주세요. (30초 이내-5문장?)

• CheQuiz는 ‘개발지식 점검 서비스’ 입니다. 개발관련 퀴즈세트를 자유롭게 풀어보고, 나아가 문제를 출제할 수 있는 서비스입니다. 코딩테스트 이외의 개발지식을 정량적으로 측정할 수 있는 서비스가 없다는 문제를 해결하고자 하였고, 특정 주제에 대해 퀴즈를 맞추며 해당 지식에 대한 이해도를 정량적으로 측정할 수 있습니다. 공부의 재미를 주기 위하여, 2d 캐릭터와 경험치 제도를 통해 문제를 맞출 수록 성장하는 게임요소를 도입한 것도 하나의 특징입니다.
• 코딩테스트 이외의 개발 지식, 게임적 특성 → 프로젝트 point
• 제일 앞 부분 + 기간이랑 사람 수를 넣어주면 좋을 것 같다. (어땠어요? 호 불호?)
• 뒷 부분: 주요기능은 ~고, 저는 ~것을 담당했습니다.
• 면접관이 다음 질문을 편하게 할 수 있어서 흐름상 좋다고 생각

• CHEQUIZ는 퀴즈를 통해 개발 지식을 측정할 수 있는 서비스입니다. 개발 관련 퀴즈들을 해결하고, 문제를 직접 만들면서 해당 지식을 알고 있는지 체크를 할 수 있도록 하였습니다. 또 게임적인 특징들을 서비스에 반영하여 퀴즈를 풀면서 재미를 느낄 수 있고, 개발자가 성장도를 정량적으로 확인할 수 있도록 하였습니다. + 내가 담당한 부분 (퀴즈 풀기, 퀴즈 해결 후 결과 페이지)
• 확실히 아는 서비스인데, 강약?이 없다보니 확 포인트 캐치가 안되는 느낌?
• 레벨 시스템 + 경험치를 도입했다는 내용이 들어가면 좋을 듯

• <러북>은 여러 책의 인상깊은 문구를 보고 취향에 맞는 책을 고를 수 있는 독서 공유 서비스입니다. 어떤 내용의 책을 읽고는 싶지만 특정한 책을 고르기 힘들때, 문구를 먼저 보고 자신이 끌리는 책을 고를 수 있습니다. 많은 사이트에서 책을 검색할 때 책 제목을 검색해서 들어가야만 문구를 확인해야하는데 그런 번거로움을 줄일 수 있다는 장점이 있습니다.. 평소 책에 관심은 있지만 어떤 책을 읽으면 좋을지 모르던 사람, 또 서로 흥미있는 분야에 대해 의미있는 대화를 나누어보고 싶은 사람들 모두에게 도움을 줄 수 있습니다.
• 약간 ppt 발표 느낌
• ~~를 목적으로 만들었다.

• <러북>은 책을 좋아하는 사람들이 모여 자신이 읽은 책을 서로 공유하는 독서 커뮤니티 플랫폼이에요. 유저들은 본인이 읽은 책을 ‘문구’를 통해 공유하고 게시물 안에서 댓글을 통해 해당 책에 관해 서로 소통할 수 있어요. 단순히 책에 대한 정보를 공유하는 것보다 책을 읽고 자신이 느낀 점, 인상깊은 구절을 공유하면서 그 책을 모르던 유저도 책을 읽고 싶게끔 만들어서 책에 대한 접근성을 향상 시킬 수 있는 플랫폼이 될 수 있어요.
• 깔끔
• 개발관련 1줄이 들어가면 좋을 듯.

• 해당 질문은 더 가볍게 던질 가능성이 높다.
• 짧고 간결한 1~2줄이 더 좋을 것 같다는 생각도 든다.

Q2. 해당 스택은 왜 사용하게 되었나요?

• CheQuiz
• typescript, React, ContextAPI, emotion, webpack
• Slack, github(Zenhub)

• Luvook
• 개발: React, ContextAPI, emotion, storybook
• 커뮤니케이션: Notion, Discord, Slack
 

• React
• 커뮤니티가 많아 자료를 찾기 쉬운 장점이 있습니다.
• 요것만 말하면 위험하다.
• vue와 달리 view만 담당하다보니 다른 라이브러리와 결합이 유연하다.
• 다른 라이브러리를 많이 사용했다는 건데? 그럼 뭘 썼냐? 그거 vue에서는 안되나
• 위험해!!!! → deprecated
• 프로젝트 기간이 2주였고 팀원들 대부분이 react에 익숙해서 빠른 생산성이 요구되었습니다.
• React, Vue 중 고민 →

• Context API
• 인: 다른 상태관리 라이브러리의 도입을 고민했지만, 가장 row한 방식의 ContextAPI를 사용하면서, 해당 상태관리 라이브러리에서 처리하지 못하는 문제를 발견했을 때, 이를 해결할 수 있는 라이브러리의 도입을 고민해보자고 생각했다.
• Redux와 고민해보았지만, 생각보다 전역으로 관리하는 데이터가 많지 않았다. 그에 비해 사전에 작성해야 하는 코드 양이 많기 때문에 현재 도입하는 것이 너무 과하다고 생각했다. 해당 부분은 추후 Redux로 대체하는 것이 쉽기 때문에 일단은 ContextAPI를 사용하기로 결정했다.
• redux와 contextAPI 중 고민했지만 Redux가 context API 기반으로 만들어 졌고 데브코스 기간 중 context api로 실습을 배웠기 때문에 2주안에 프로젝트를 완성시키기 위해 사용 (+ redux 공부 시간 줄이기, + 프로젝트 규모가 별로 크지 않음)
• 동영say : 기술스택은 얼만큼 깊이 있게 이해하고 사용했는가 point 따라서 ContextAPI가 주로 마주치게 되는 성능문제를 파악했는지, 어떻게 해결할 수 있는지 까지 언급해주는 것이 best
• 구체적으로 프로바이더가 감싸고 있는 컴포넌트들이 내부적으로 몇 번 렌더링 되는지, 찍어봤는지 물어볼 수도 있다.
• Context 분리 하였는지 (context의 성능을 향상시키기 위한 한가지패턴- 링크🔗)
• state / dispatch → context 2가지 분리
• 하나의 AuthProvider → 상태제공 Context와 상태조작하는 Context로 구분
• 상태관리 최적화 관점에서 reactive programming (rx)
• Q. reactive programming이 react나 vue에 활용되는 예제를 말씀해주세요.

• emotion
Q. 스타일드컴포넌트 왜 사용하셨나요? 사용했을 때 느낀 장점이나 문제가 있었나요?
• className 안써도 되서 → 이거 고민하는 것도 시간적 비용이 큼
• 가독성 측면에서 더 장점이 있다고 생각
• S라는 별도의 네임스페이스를 주어, 함수컴포넌트와 스타일드컴포넌트와 구분했다.
• S.Container
• 해당 컴포넌트에서만 스타일을 정의하여 사이드 이펙트 확률이 적어지고 className이 자동으로 부여되기 때문에 스타일이 겹치지 않고 props 등에 따라 스타일 지정 가능
• 여러가지 컴포넌트가 필요한 상황에서 간단한 컴포넌트들을 빠르게 만들어 낼 수 있다. 여러 곳에서 사용되는 컴포넌트를 가장 기본적인 형태로 만들어놓고 재사용하면서 팀적으로 공통된 컴포넌트 스타일링을 정할 수 있었다.
• emotion 사용시 좋았던 점(장점)
• props 전달 → 다이나믹 스타일 적용 가능
• 따로 파일 안찾고 태그보고서 바로 스타일 확인 가능 했던 부분
• emotion 단점
• babel config를 따로 설정해주어야 하는 단점이 있다
• styled-components랑 비교해서 문법상 불편한 점이 있었다.
code사례 (해결완료-emotion도 가능)

import { Input } from ...

const LoginInput = styled(Input)`
  input.className {
		
	}
`

const Component = styled.div`
	${Input} {
		display: flex;
		...
	}

styled-components 과 emotion, 도대체 차이가 뭔가? (velog.io)
• 동영say
• 제어의 역전 (Inversion of Control) U know? 추가로 찾아서 달아주삼 → 저희팀원에게

동영쓰 답변

Q3. 해당 프로젝트에서 본인이 맡은 역할과 수행한 부분에 대해서 말씀해주세요.

• 2

• 3

• 4

Q4. 진행하면서 가장 어려웠던 점과 어떻게 극복하려고 했는지 설명해주세요.

• 두 가지 개념을 구분해서 처리

• 충전기좀 가져오겠음다

• 3

• 4

Q5. 프로젝트의 부족한 점이 있다면? (시간이 주어진다면 어떻게 리팩토링 하고 싶은지)

• 1

• 2

• 3

• 4