Portfolio

프로젝트 리드 임명

리드의 역할: 총 책임자

개발 일정 및 진행상황 관리
컴포넌트, 페이지 세분화
세분화한 페이지, 컴포넌트별 업무 배분 (일정 산정이 들어가야함)

이 로그인 페이지는 대략적으로 몇일 걸리겠군.
주문페이지는 양이 많고 로직이 복잡함

컴포넌트별, 기능별로 나누기

Task 보드 생성
너무 개발범위가 터무니없이 많거나 일정이 타이트하면 징징대기
Repository 메인 관리 (Git)

팀원의 역할 : 맡은 임무 소화

문제가 있거나 변동사항 있을 경우 바로 보고
매일 중간상황보고
끊임없이 대화 필요

개발 시작 전에

개발 방향 및 스택 결정

팀원들간의 의견을 최대한 조율하되 하루이상 넘기지 않도록
메인 프레임워크 및 라이브러리들 결정

React vs Vue
Typescript
Nextjs ? Nuxtjs?
Redux? contextAPI? zustand?
material UI, Bootstrap? tailwind
css in js 라이브러리 (styled, emotion)

정적배포 vs 서버리스 배포

개발 시작

프로젝트 리드

메인 리포지토리 생성
기본 global css, webpack, config,
eslint, prettier, husky 작업
기본 레이아웃, breakpoint media query

위 작업들은 최대한 빨리 이루어져야 함 지금 하는 프로젝트에서는 하루이내에는 끝을 내기

위 작업이 이루어지게 되면 팀원들에게 고지

프로젝트 팀원

기본 틀 잡힌 develop 브랜치 clone
페이지 및 컴포넌트 개발
코드리뷰 적극참여

Git 프로젝트 관리

메인 리드가 만든 리포지토리를 clone (깃허브의 경우 fork)

각 팀원들은 로컬 저장소에서 작업 후 원격저장소로 push

메인 리포지토리에 pull request 생성 후 팀원들에게 고지

팀원들은 생성된 PR을 보고 문제있는 부분이나 궁금한게 있으면 코멘트

문제가 없으면 merge하기

생겨날 수 있는 문제사항

❗

main, develop 브랜치에 직접 푸쉬금지 항상 PR을 받을 것

원격저장소에 올리고 PR을 올리기 전에

컴파일 오류가 없음을 보장
최신 develop 브랜치의 소스 위에서 수정이 진행되었는지 점검. 그러지 않았다면 최신 develop 소스를 풀 받고, 컨플릭트가 났을 경우 해결해서 PR
develop을 직접 수정하면 안 됩니다. develop 브랜치 위에 커밋 X. 반드시 feature 브랜치를 만들어 그 위에 작업해야합니다.
불필요한 주석과 console.log가 없는지 확인합니다.
PR을 작성할 때는 커밋 내역을 내용으로 첨부하고, 이외에 팀원들에게 자신의 소스 수정에 대해 알릴 사항, 혹은 작업 내역을 보여줄 수 있는 이미지를 첨부합니다.

충돌이 이루어날 경우 PR 올린사람이 해결

코드리뷰 체크리스트

돌아 가는가 : 물론 PR을 올리는 개발자는 돌아가지 않는 코드를 PR해서는 안 됩니다. 하지만 컴파일 오류가 날 수 있는 치명적이고 명백한 코드가 수정된 소스안에 남아 있다면 코멘트를 남깁시다.

컨벤션 : 팀의 코드 컨벤션을 어기는 부분은 없는지 점검합니다. 변수명이나 함수명, 이벤트명등이 직관적으로 이해되지 않는다면 코멘트를 남깁니다.

디렉토리 : 새로운 파일이 생성되었다면 생성된 파일이 적합하고 가시성있는 위치에 컨벤션을 준수하여 저장되어 있는지 확인합니다.

컴넌 구조 : 컴포넌트의 네스팅 깊이가 너무 깊어 특정 코드에 접근하기 어렵거나 너무 얕아 코드의 재사용성이 떨어지고 특정 파일이 특히 길어진다던지 하는 컴포넌트 구조와 배치를 확인합니다. 수정된 컴포넌트의 구조가 확장에 용이한지 살핍니다.

최적화 : 코드가 불필요한 http 요청을 굳이 하지는 않는지, 렌더링 과정에서의 부하나 불필요한 컴포넌트의 재랜더링이 이루어지고 있지는 않나 확인합니다.

중복 : 컴포넌트들 사이에서 같은 로직과 코드를 하드코딩해서 사용하고 있지는 않나 확인합니다. 그런 로직이 있다면 util로 분리하는게 좋습니다.

UI : 코드를 보고 구현된 실제 뷰가 요구사항에 맞게 잘 렌더링 되지 않을 수도 있겠다는 우려가 생길 수 있습니다. 그런 경우 직접 브랜치를 내려받아 돌려보시고, 무슨 문제인지 눈으로 직접 보고 판단하는게 좋습니다. 귀찮은 일일지도 모르겠습니다만, 더 나은 팀을 위해서는 적극적으로 서로의 실수를 검증하는 깐깐한 자세가 필요하다고 생각합니다.

.eslintrc.json, prettierrc (현 nextjs 세팅 파일 그대로이므로 rule 부분 위주로 참고부탁드립니다. 그대로 사용하면 오류가 날 수 있으므로 주의)


{
  "env": {
    "browser": true,
    "es2021": true
  },
 "extends": [
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended",
    "plugin:react-hooks/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaFeatures": {
      "jsx": true
    },
    "ecmaVersion": 2020,
    "sourceType": "module"
  },
"plugins": ["react", "@typescript-eslint"],
"rules": {
    "react/jsx-filename-extension": [
      2,
      {
        "extensions": [".js", ".jsx", ".ts", ".tsx"]
      }
    ],
    "prefer-const": [
      "error",
      {
        "destructuring": "any",
        "ignoreReadBeforeAssign": true
      }
    ],
    "no-var": "error",
    "prefer-arrow-callback": "error",
    "func-style": ["error", "expression"],
    "prefer-rest-params": "error",
    "import/first": "off",
    "new-cap": "error",
    "lines-between-class-members": [
      "warn",
      "always",
      {
        "exceptAfterSingleLine": true
      }
    ],
    "filenames/no-index": "off",
    "react/jsx-uses-react": 2,
    "react/jsx-uses-vars": 2,
    "react/react-in-jsx-scope": 2,
    "react/boolean-prop-naming": "warn",
    "react/no-array-index-key": "warn",
    "react/no-children-prop": "warn",
    "react/no-danger": "warn",
    "react/no-deprecated": "error",
    "react/no-did-mount-set-state": "warn",
    "react/no-did-update-set-state": "warn",
    "react/no-direct-mutation-state": "error",
    "react/no-find-dom-node": "warn",
    "react/no-is-mounted": "error",
    "react/forbid-dom-props": "off",
    "react/no-redundant-should-component-update": "error",
    "react/no-render-return-value": "error",
    "react/no-set-state": "error",
    "react/no-typos": "error",
    "react/no-string-refs": "error",
    "react/no-this-in-sfc": "error",
    "react/prefer-read-only-props": "error",
    "react/require-render-return": "error",
    "react/jsx-boolean-value": "error",
    "react/no-unescaped-entities": [
      "error",
      {
        "forbid": [">", "}", "<"]
      }
    ],
    "react/no-unknown-property": "error",
    "react/no-will-update-set-state": "error",
    "react/prefer-es6-class": "error",
    "react/void-dom-elements-no-children": "error",
    "react/jsx-no-target-blank": "error",
    "react/jsx-pascal-case": "error",
    "react/destructuring-assignment": [
      "error",
      "always",
      { "ignoreClassFields": true }
    ],
    "react-hooks/rules-of-hooks": "error",
    "react-hooks/exhaustive-deps": "error",
    "react/forbid-prop-types": "error",
    "react/style-prop-object": "error",
    "no-mixed-spaces-and-tabs": "off",
    "no-useless-escape": "off",
    "no-unsafe-finally": "off",
    "@typescript-eslint/no-unused-vars": "error",
    "@typescript-eslint/explicit-module-boundary-types": "error",
    "@typescript-eslint/no-empty-function": "off",
    "prettier/prettier":["error",{
      "endOfLine":"auto"
    }]
  },
}


// prettier
{
  "semi": false,
  "trailingComma": "es5",
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false
}

// vscode settings.json eslint 부분
"editor.formatOnSave": false,
    "editor.codeActionsOnSave": [
        "source.formatDocument",
        "source.fixAll.eslint",
        "source.fixAll.stylelint"
    ],

스타일 컨벤션

BEM 방법론 을 따르는 것을 원칙으로 합니다.

네스팅시 타이핑을 줄이기 위해 &를 사용합니다.

단일 파일 컴포넌트 구현을 위해 해당 컴포넌트에만 매핑되는 스타일시트를 작성하는 것을 권장합니다. 따라서 하위 컴포넌트나 컴포넌트 범위 바깥에 영향력을 끼칠 수 있는 CSS 프로퍼티 작성을 지양합니다.

공통적으로 사용하는 스타일 요소들은 프로젝트 상위 디렉토리에 존재하는 global.scss에 작성하고 임포트해서 사용하세요.

!important는 쓰지 않습니다. 대부분의 경우 스타일의 nesting 구조를 바꾸는 것으로 해결이 가능합니다.

단일 파일 컴포넌트의 스타일 시트에서는 선택자 사용을 지양해야 합니다. 공통 스타일은 최상위 클래스 요소에 작성하세요. 최상위 요소는 항상 클래스여야 합니다.

다만 vuetify같은 UI 라이브러리의 스타일을 수정할때는 예외적으로 !important나 ::v-deep으로 상위 컴포넌트에서 하위 컴포넌트에 영향을 미치는 스타일 요소를 작성할 수 있습니다.

내포된 요소의 class 이름이 너무 길어질 경우 컴포넌트를 분리해야합니다. 내포관계를 표현하는 __를 세 개 이상 사용하지 않는 것을 권장합니다.

Git 컨벤션

master(main) : 최근 애져에서는 main으로 바뀐 브랜치인데, 릴리즈가 아니면 푸시를 하지 않습니다. develop에서만 머지합니다. hotfix가 아닌 경우 직접적으로 건들면 안 됩니다.

develop : feature 브랜치를 파생시킬 수 있는 일반적인 작업 브랜치입니다. feature 브랜치의 PR은 무조건 develop으로 날립니다. develop에서 각 개발자들의 작업 내역을 합쳐서 릴리즈시 master로 머지합니다.

feature : PR의 단위입니다. develop에서 파생시켜 각자 맡은 내역을 작업한 후 develop에 PR을 날립니다. 브랜치를 생성할때 개발자이름/피처-브랜치-이름 형식을 따릅니다.

hotfix : 급하게 수정해야하는 버그를 수정하고 master에 직접 합치는 브랜치입니다. hotfix를 머지한 이후에도 release를 브랜치를 새로 만들어 태깅하고, develop을 최신 상태로 바꿔놓아야 합니다.

release : master에 develop을 합친 후 버저닝을 위해 생성하는 브랜치입니다. release/n.n.n과 같은 형식을 따릅니다.

commit rule

커밋 그래프는 왠만하면 단순하게 유지하는게 좋습니다.

develop을 바로 수정하는건 아니됩니다. 수정을 하실때 develop위인지 feature 브랜치 위인지 잘 확인해주세요!

커밋 접두어:수정내역와 같은 형식을 따릅니다.

커밋 내역만 보더라도 무슨 내용이 수정되었는지 바로 알 수 있는 커밋을 남기셔야 합니다.

commit prefix

feat: - 프로덕트에 없던 새로운 기능을 Implement하고 커밋할때 사용하는 접두어입니다.

fix: - 버그 혹은 프로덕트의 잘못된 부분을 수정하고 커밋할때 사용하는 접두어입니다.

refactor: - 기존에 잘 작동하던 기능을 리팩토링한 수정내역을 커밋할때 사용하는 접두어입니다.

chore: - 콘솔로그 제거나 주석 제거, 인덴테이션 수정과 같은 그닥 중요하지 않은 수정을 진행하고 커밋할때 사용하는 접두어입니다.

style: - 스타일(만) 수정할때 사용하는 커밋 접두어입니다.

Pull Request

PR에도 커밋 접두어를 적용합니다. 커밋 접두어:PR이름과 같은 형식을 따릅니다. 수정내역을 요약할 수 있는 PR 이름이 적절합니다.

애져에는 PR 작성시 커밋 내역을 모두 명시하는 기능이 있습니다. 그 기능을 사용해서 커밋 내역을 모두 명시해주세요

이외에 어떤 부분이 바뀌었고 왜 바뀌었는지 부가 설명이 필요할 경우 자유롭게 붙여주심 됩니다. 현재 따로 형식은 없습니다.

본인이 올린 PR은 본인이 머지합니다. 이는 코드리뷰로 진행된 피드백을 확인하고, 반영할지 혹은 그렇지 않을지 본인이 선택할 수 있는 여지를 남기기 위해서입니다.

코드리뷰로 달린 코멘트들을 모두 확인하고 active에서 resolved로 바꾸는 것도 PR을 올린 사람 몫입니다. 피드백을 수용한다면 수정 후 resolved로, 피드백을 수용하지 않을 것이라면 추가 코멘트를 달고 closed로 옮겨주세요.

컨플릭트도 본인이 해결해서 컨플릭트를 리졸브하는 커밋을 하고 컴플릿합니다.

협업

개발 시작 전에

개발 시작

Git 프로젝트 관리

생겨날 수 있는 문제사항

코드리뷰 체크리스트

.eslintrc.json, prettierrc (현 nextjs 세팅 파일 그대로이므로 rule 부분 위주로 참고부탁드립니다. 그대로 사용하면 오류가 날 수 있으므로 주의)

스타일 컨벤션

Git 컨벤션

commit rule

commit prefix

Pull Request