프로젝트를 통해 이루고 싶은 개인적인 목표들을 정리 및 작성하여 원하는 포인트에 집중해서 프로젝트를 진행하기 위해 작성하려고 합니다. 각자 1차 프로젝트를 진행한 이후이기 때문에 이전 프로젝트에서 미흡했던 부분이나 개선하고 싶었던 점을 고려해서 작성해도 좋을 것 같습니다!
샘플
프로젝트 개인 목표 샘플 (Readonly)권내영
기술적 측면
- SSR에 대한 이해 및 적용(Next.js)
- 채택된 라이브러리에 대해 공부하며 사용하기
- react-query, recoil, jotai 등을 사용한다면 라이브러리에 대한 이해도를 높인 채 사용하기
경험적 측면
- 백엔드 개발자들과의 협업 방식 습득하기
- 프로젝트 회의 문서화, 기록 작업
- 회의나 각자 한 일, 할 일 등을 일정 주기로 기록해 서로의 상황을 확인하고, 추후 활용 가능하도록 기록 작업
- 템플릿을 만들어놓고 정리하는 시간 갖기
- 프로젝트 시작 전 또는 초기 단계에 컨벤션 등을 정하고 문서화해 프로젝트 시 통일된 코드 또는 문서 작성
이지원
- 애자일 방법론의 적용
- 각 팀원들이 현재 작업 진행상황을 보다 자세히 공유할 수 있도록 git Project 활용
- 주마다 혹은 더 짧게 스프린트를 정하고 스프린트의 반복으로 프로젝트 진행
- 4주 전체 프로젝트를 분업하기에는 너무 단위가 크다
- 4번으로 자른다고 가정하고 일을 분배를 하면 Git Project 일의 단위가 작아질것
- 매일 정해진 시간에 짧게 프로젝트 진행 상황을 스크럼을 통해 공유
- 매 스크럼 혹은 회의가 있을 때 마다 노션을 통해 간단한 회의록 작성 (돌아가면서)
- 개발에 집중할 수 있는 환경을 미리 세팅
- PR 템플릿
- Commit Convention
- Code Convention
- 디렉토리 구조
- 공통 컴포넌트에 대해서..
- 프로젝트를 마무리하고 전체 프로젝트 흐름에 대한 이해가 남아있도록 작업
코드 컨벤션 예시
1. Components 이름은 Pascal case를 사용합니다.
- Good :
function Button = ...
- Bad :
function button = ...
2. Component 확장자는 JSX를 사용합니다.
- Good:
Button.jsx
- Bad:
Button.js
3. Component는 함수 표현식 + 화살표 함수로 작성합니다.
- Good:
const Button = () => {}
- Bad:
functon Button(),const Button = function(){}
4. props는 각 태그의 고유 기능을 잃지 않게 항상 할당해 줍니다.
- Good:
5. styled component에 인라인 스타일을 넣는 것은 최대한 지양합니다.
- Bad :
<StyledButton style={{...}}>
6. prop에 명시하는 이벤트는 on~, 핸들러 함수를 정의할 때 는 handle 접두사를 사용하고 이벤트의 이름을 사용합니다.
- Good:
<StyledButton onClick={handleClick} />
- Bad:
<StyledButton onClick={somethingElse} />
7. 동일한 이벤트를 다루는 핸들러가 여러개 존재 할 경우 정확히 어떤 컴포넌트에 할당되는 이벤트인지 명시해서 구분합니다. (handle + 컴포넌트 + 이벤트)
PR Template 예시
조계진
- 초기 기획을 기한 내에 모두 이루기(현실적인 시각이 필요할 것) + 트러블 슈팅
- 제한적인 비용 안에서 기획을 이루기 위해선 생산성이 높은 도구를 활용하는 것이 좋을 것 같음(Next.js, Typescript, React-query)
- 태스크를 인원별로 분배 후 예상 작업 기간을 기록하기
- 디자인 툴 익히기(전에는 Figma 안에서 Chakra-ui의 kit을 이용)
- 후에 리팩토링 할 일이 적어지게 컨벤션을 확실히 정하고 팀원이 서로 이해했는지 확실히 확인하기
- ESLint나 Prettier로 커버가 안되는 부분(컴포넌트 내에서 함수나 변수 간의 띄어쓰기), TS를 사용한다면
interfaceortype - import ⇒ interface ⇒ component ⇒ style
- 서로의 작업 상황 확인
- PR에 대해서 리뷰를 달 상황이 안되더라도 approve 남기기
하신영
경험적 측면
- 프론트 개발자로서 백엔드 개발자와 협업하는 방법 배우기
- 어떻게 하면 팀원들과 효율적으로 소통할 수 있는지 연구
- 협업툴 선택과 활용( Notion, Github: issues, projects, Slack, Discord )
- 업무 분담을 어떻게 하면 효율적으로, 합리적으로 할 수 있을지
- 좋은 코드 리뷰를 하려면?
예시
issue 사용( 여기에 pr단위의 테크 스펙 적기) ⇒ propjects 보드에서 각 팀원의 업무 파악 (sprint단위)
pr 예시
기존 템플릿에 마감일이 없어서 추가가 필요하다고 생각
- 맨데이 파악하기
- 디버깅, 및 시행착오 그날 바로 문서화
기술적 측면
- NextJS, TypeScript를 적용
- 컴포넌트 다이어그램 적용
- 아토믹 디자인 시스템 적용해서 재사용성, 확장성이 강한 컴포넌트 만들기
시간이 된다면 하고 싶은 것
- 스토리북 적용: Atom, Molecule, Organism 까지 완성을 해보고 싶다. 또한 데이터가 많이 들어온 경우 테스트도 해보면 좋을 듯.
번외
스쿼시머지합시다!!