Github PR 처리 방식, Coding Convention

PR 올리기 전 확인해야할 사항

• 어떤 파일에 제일 많이 바뀌었는지에 대해 pull request 올리기 전 Write 구간에 작성

pr시 wirte 에 작성

• 변경된 파일 중 어떤 파일이 제일 많이 바뀌었는지에 대해 잘 설명해야한다.
• 대략적인 요구사항에 대한 링크와 요약
• 내가 아는 것은 남들은 모른다. 다른 사람들이 이 글을 읽고 어떤 부분에서 어떤 사항이 변경되었는지 글을 읽고 바로 파악할 수 있을 만큼 설명해야하고 요약 또한 들어가야함

포함 목록 
- [마이그레이션] (해당문서에 대한 링크 첨부)
- 무슨 작업을 했는지에 대한 부분을 상세하게 적을 것 

• 문의, question에 대한 부분은 draft로 만들어 진행
• 정말 간단한 작업은 PR올리는 제목과 동일하게 작성해도 되지만,, 5줄 이상인 경우는 사항에 해당되지 않는다.

변경 파일 확인

• 일반적인 띄어쓰기, 필요없는 console.log 와 같은 사항이 들어가있는지 셀프 확인
• 어쩔 수 없이 정렬해야하는 경우 자잘한 사항들이 발생했을 때 해당 commit이 아닌 다른 브랜치에서 자잘한 사항들에 대해 작성하여 merge 시키고 나서 진행하도록 한다.
• PR 완료 이후 files changed 페이지에 들어가 마지막으로 한번 더 리뷰를 진행하라
• 의도하지 않은 코드가 있는지, 해당 부분에 대한 로직이 이해가 가지 않으면 로직이 이상하다는 것임을 알고 있어야한다. => 마지막 리뷰 한번 더 진행

전체적인 PR의 의의

작업의 공유

• pr을 보고 코드의 진행상황을 알기 위함
• pr을 보고 변경지점이 어딘지에 대한 공유가 가능
• 해당 프로젝트의 정책이 바뀔 때 => 실제로 작업이 되었는데 정책이 공유되지 않았다면 pr로 공유받을 수 있는 장점이 있다.

education

• 주니어는 대체로 코드에 대한 개성이 없고 다른 스타일을 자유분방하게 사용하기 때문에 다른 사람 (해당 프로젝트, 혹은 나를 태그한 경우)에 코드를 보고 그 코드에 대해 정의되어야 한다.(코드는 새로 창작하는 것이 아닌 훔치는 것이당 .. ㅋ)
• 크로스리뷰를 일상화하고 그 테크닉에 대해 잘 탐색하고 나아져야함
• 이 때 테크닉에 대한 가이드라인 문서를 보고 리뷰해야하고 컨셉에 대한 리뷰도 진행해야한다.(또한 자신의 코드로 만드는 것이 제일 첫번째로 중요한 문제이다)

코딩 컨벤션

정의 및 이유

• 코드 컨벤션 : 관리하기 쉬운 코드를 작성하기 위한 일종의 코딩 스타일 규약
• 코딩 컨벤션을 적용하는 이유
  - 누구나 쉽게 코드를 이해하고 적용할 수 있게 하기 위해서 사용한다.
  - Clean 코드를 짜는 것도 .. 그 사람의 실력이라고 살 수 있다.

네이밍

• 네이밍은 너무나 중요함
• 또한 한 로직이 두가지를 동작한다면 해당 코드는 네이밍을 정할때도 그걸 알아보는 사람도 헷갈릴 수 있기 때문에 실패한 코드라고 할 수 있다.

component는 명사로 지어야한다.(뷰로 그려지는 렌더링에 속하는 것 : 명확히 표시되어야 함)
component안에 있는 상태(useState와 같은) => set명사 이런 식으로 작성되어야함.
boolean: isLike => 좋아한다,안한다. 해석가능하게 네이밍한다.

Tip! case Styles

• camelCase : 낙타의 모양에서 따온 방법 (첫단어는 소문자로 시작하고 두번재 단어는 대문자로 시작)

• kebab-case : 모든 단어는 소문자(단어와 단어 사이는 "-"로 연결된다.)

• PascalCase : 카멜과 유사하지만 차이점은 첫 단어도 대문자로 시작한다.

• snakecase : kebab과 다르게 "" 로 연결된다.

  현재 우리의 argos 파일에서는 kebab과 Pascal 을 동시에 쓰고 있지만 kebab으로 통일 시킨다.
  또한 const 상수와 같은 경우는 모든 단어를 대문자로 사용한다.(const TEST_ITEM 이런식으로!)