기동 2팀 중간 점검

[기동2팀] 중간점검 회고록

기동멘토

1. base component style 관련

관련하여 커피챗시간에 답변을 드린 내용이라 간단하게만 적어두겠습니다.

통일성을 위해 스타일은 고정해놓는것이좋습니다. props로 스타일을 너무 확장성있게 주면 안된다. 와이어프레임이 먼저 잘 그려져있어야, 어떠한 버튼리스트가 있는지 확정될 수 있고, 그에 따라서 컴포넌트를 구성하는데 도움이 됩니다.

• 버튼에 대한 종류별로 figma 를 정해준다.

처음부터 CSS에 하나하나 신경을 쓰면 머리가 아프다

CSS보다는 우선 기능에 중점을 두고 개발하고 이후에 디자인을 적용해도 늦지 않을것 같습니다.

저 같은 경우 어떤 식으로 동작을 하게 할 것이냐. handleChange, value 등의 props에만 집중해서 개발하고, 기능 개발이 어느 정도 진행되면 css작업을 합니다.

물론 사이즈가 어느 정도 정해져 있긴 해야된다.

"버튼을 만들건데.. 그려진건 없어요..."이러면 안된다.

base컴포넌트를 만들때 제일 조심해야되는 요소!

• 페이지마다의 요청사항이 다르다.

• 요청사항에 맞춰서 base컴포넌트를 만들면

• base컴포넌트의 초기 컨셉이 엉망이 된다.

• 따라서, base컴포넌트의 컨셉을 확실하게 정하고, page를 해당 컴포넌트에 맞추는 게 낫다. (바텀→탑)

2. API 로직 관련

페이지마다 axios에서 바로바로 받아서 API를 사용하는 방법은 추천하지 않는다.

1. baseUrl사용
1. 이 경우 400대 , 500대 에러 등에 대해서 공통적인 에러사항들에 대해서 공통적인 코드가 들어가게되겠죠?

2. API 파일을 별도로 만들어서, 로직을 별도로 빼서 사용 (API.js)

.env(baseUrl) 이 무조건 있어야 한다! 별도의 파일을 빼서 api를 만드는것이 좋습니다. 처음부터 완벽한 props가 존재하는 컴포넌트는 존재하지 않아요. 그렇지만 page를 만들면서 공통적으로 발생되는 사항을 컴포넌트로 만들어서 -> 재사용하고, 공통 이슈가 발생하면 컴포넌트로 만들면서 점차 완성도를 높이는 것. 처음부터 설계, 기획단계에서 완벽한 컴포넌트는 없다. 비슷한 컴포넌트라도, 프로젝트의 성격에 따라 달라질 수 있다.

3. 개발 속도가 다른 팀원과의 협업 시

지금 여러분들 수준에서 동료의 개발속도를 가늠하는게 쉽지 않다.

하지만, 협업에서는 기능을 언제까지 개발할 수 있는지 대략적으로 파악하는 능력을 배양하는게 중요하다. 그래야 개발일정을 산출해 낼 수 있는 것이기 때문. 그리고 그 결과에 따라서, 현재의 개발속도가 어느 정도인지를 파악할 수 있고, 결과적으로 전반적인 개발계획을 유동적으로 수립해 나갈 수 있다.

업무의 분배 관련 :

공통컴포넌트(만 만드는 팀이 존재) / 페이지(만 만드는 팀이 존재)할 수 있다.

(여러가지 버튼, 라디오, 인풋) 등을 전담해서 개발하는 팀이 개발하고(프레임워크) 패키지화 할 수 있다.

리아 피드백

• 전반적으로 여유있는 발표가 듣는 사람도 편하게 만들어준 것 같아요. 굉장히 능숙하네요.

• 다만 노션 페이지를 살짝 확대해줬다면 어떨까라는 생각을 했어요. 듣는 사람을 고려하여 화면 확대 여부를 유동적으로 바꿔볼까요?

• 전체적인 내용이 텍스트로도 보여서 말씀하시는 내용에 대해 파악하기 쉬웠어요.

• 프로젝트 세부 내용에 대해서는 그림으로도 표현해보면 어떨까요? 텍스트로만 들으면 굉장히 복잡해보이네용.

• 타겟 설정 넘 좋네용.

• 기술 스택을 선택한 이유를 설명해 줘서 좋네용!
• 다만 리액트를 선택한 이유가 우리한테는 정말 공감되지만 다르게 표현해보면 어떨까요? 리액트리기 떄문에 리액트를 선택했다고 해도 좋지 않을까..!

• 피그마를 정말 알차게 사용하고 있다고 느꼈어요. 스토리라인도 볼 수 있어서 좋았습니다.

• 모달을 정말 귀엽게 잘 구현했군용.

• main에서 저장 버튼은 더 크게 만드실 예정이시죠?! 잘 안 보여서 날아갈까 무섭네용.