유투브 설명
변수명,함수명
테스트 직접작성
작게 쪼개기
1주 차 공통 피드백
1. 요구사항 정확히 준수
기능, 프로그래밍, 과제 요구 사항 정확히 체크
2. 커밋 메시지 의미 있게 작성
커밋 메시지 이해가 가능하도록 작성한다.
내가 한 커밋은 어떤 기능이 있는지 알수 없다.
problem1에 여러 기능이 있으니 그 기능별로 잘라서 commit.
내 생각에 이렇게 해야지 어느 부분에 문제가 있는지, 뭘 개발했는지 알기 쉬워서 인듯.
예) Feat: problem1 - 3,6,9의 개수 만큼 손뼉을 치는 기능
3. git을 통해 관리할 자원에 대해 고려
1) git관리 필요없는 부분1
node modules 는 package.json 파일이 있으면 설치할 수 있고 버전 관리를 직접 하지 않으므로 git으로 관리하지 않아도 된다.
2) git관리 필요없는 부분2
Intellij의 .idea 폴더, VS Code의 .vscode 폴더 또한 개발 도구가 자동으로 생성하는 폴더이기 때문에 굳이 git으로 관리하지 않아도 된다.
3) 결론
git에 코드를 추가할 때는 git을 통해 관리할 필요가 있는지를 고려해볼 것을 추천한다.
뭔소린지 모르겠다.
git ingore 말하는건가
4. Pull Request를 보내기 전 브랜치를 확인
git 제출방법을 보면
https://github.com/woowacourse/woowacourse-docs/tree/main/precourse
1) fork하기 (자동으로 main branch생성)
2) 내컴퓨터로 clone하기
3) 브랜치 생성 (기능구현을 위한 branch생성)
1번의 main에 다가 기능을 만들지 말고 3번의 branch에 만들라고
git 제출방법을 지키라는 뜻인듯
5. PR을 한 번 작성했다면 닫지 말고 추가 커밋을 한다
PR(pull request)를 하고 나서 오류가 생기거나 추가 해야할거 있으면 PR삭제 하지 말고 commit하면 자동으로 반영된다고
미션 제출 기간 이후에는 추가 커밋을 하지 않는다.
6. 이름을 통해 의도를 드러낸다
1) 소통을 위해
변수, 함수(메서드), 클래스이름 짓는데 시간 투자이름으로 어떤 기능이 있는지 알수 있게 해라
연속된 숫자를 덧붙이거나(a1, a2, ..., aN), 불용어(Info, Data, a, an, the)를 추가하는 방식은 적절하지 못하다.
7. 축약하지 않는다
1) 의도를 드러낼 수 있다면 이름이 길어져도 괜찮다.
2) 클래스, 메서드 이름은 중복 제거해서 한 두 단어로 유지,
3) 예
클래스 이름 Order이면 메서드 이름은 shipOrder이 아니라 ship()
- 객체 지향 생활 체조 원칙 5: 줄여쓰지 않는다 (축약 금지)
8. 공백도 코딩 컨벤션이다
if, for, while문 사이의 공백도 코딩 컨벤션이다.
9. 공백 라인을 의미 있게 사용한다
문맥을 분리하는 부분에 사용. 과도한 공백은 다른 개발자에게 의문을 줄 수 있다.
10. space와 tab을 혼용하지 않는다
들여쓰기에 둘 중에 하나만 사용한다. 확신이 서지 않으면 pull request를 보낸 후 들여쓰기가 잘 되어 있는지 확인하는 습관을 들인다.
11. 의미 없는 주석을 달지 않는다
변수, 함수(메서드) 이름에 주석을 달지 않는다. 이름을 통해 의도를 드러내고, 의도를 드러내기 힘든 경우 주석을 다는 연습을 한다.
12. linter와 Code Formatter의 기능을 활용한다
1) 생산적인 코드 작성 방법
.js와 같은 인터프리터 언어는 런타임 에러 발생이 높다.
가능하면 eslint와 prettier를 이용해 오류를 미리 예방하고 쉽게 정돈할 수 있어. 생산적인 코드 작성 가능
2) 린트와 린터
린트(lint)는 소스코드에 문제가 있는지 탐색 작업, 린터(linter)는 이 작업을 도와주는 소프트웨어.
4) eslint
lint 중 eslint는 js 진영의 오픈소스로 확장되고 있는 정적 분석 도구이다.
5) prettier
prettier는 일종의 Code Formatter이다. Code Formatter란 개발자가 작성한 코드가 정해진 코딩 스타일을 따르도록 변환해주는 도구이다.
13. EOL(End Of Line)
최종 제출하는 코드에서 EOL을 확인한다. 환경에 따라 의도한 바와 다르게 개행 문자 처리가 되지 않도록 EOL 설정을 확인한다.
EOL을 넣어야 하는 이유와 운영체제별 EOL(EndOfLine) 차이로 인한 Git 문제 해결
페어프로그래밍 후 가져온 코드에서 eslint의 Delete cr 오류가 확인되었다.깃허브에 커밋된 내용을 살피던 중 파일의 마지막 줄에 개행(EOL)이 되어 있지 않아 빨간색 경고 아이콘이 표시되어 있음
velog.io
1) EOL(end-of-line)은 줄바꿈문자
. 텍스트의 한 줄이 끝남을 표시하는 문자(문자열)이다
2) 파일마다 EOL을 넣어야 하는 이유
POSIX 명세떄문
위반하면 오류.
파일을 구분하는 데에도 도움
깃허브에 커밋 시 경고 메시지를 볼 수도 있다
3) [해결방법] 파일마다 EOL을 자동으로 넣도록 설정
파일 작성이 끝나면 엔터키를 통해 맨 아래줄에 공백을 만들어주거나, 프리티어를 통해 저장시 자동으로 파일 맨 끝에 개행이 되게끔 하는 방법이 있다.
파일마다 직접 매번 개행을 꼼꼼히 해주거나...
.prettierrc (또는 .prettierrc.json) 파일(객체 내부)의 "endOfLine"프로퍼티를 "auto"로 설정한다.
12에서 배운 eslint와 prettier 말하는 건듯
'prettier/prettier': [
'error',
{
'endOfLine': 'auto',
}
]4) OS마다 다른 EOL 방법
기종이나 운영 체제에 따라 EOL을 나타내는 코드가 다를 수도 있다.
- 윈도우 : CRLF(\r\n)
- 유닉스 : LF(\n)
- 맥OS : LF(\n)
- 버전 9까지는 CR, 이후부터는 LF
5) 운영체제마다 다른 EOL로 인한 문제
os마다 eol이 달라서 문서를 열면 모두 한 줄로 나오고 깨지게 된다.
6) [해결방법] git에서 CRLF 관련 문제 해결
협업 시 운영체제가 서로 다르면 EOL이 다를 수 있다.
Git에는 이 문제를 해결하기 위한 설정이 있다.
autocrlf 설정 사용
윈도우로 개발하는 분과 협업하면 EOL이 다른 문제가 생긴다.
Git은 Checkout(저장소에서 가져올 때)할 때 LF를 CRLF로 변환해주고, Commit(저장소로 보낼 때) 시 자동으로 CRLF를 LF로 변환해주는 autocrlf 기능이 있다.
- Windows
윈도우에서는 아래처럼 autocrlf를 true로 설정하여 위와 같은 효과를 기대한다.
git config --global core.autocrlf true - Linux, Mac OS
리눅스, 맥, 유닉스는 LF 만 사용하므로 autocrlf 값을 input 으로 설정하여 Commit할 때만 (혹시나 있을 수도 있는) CRLF를 LF로 변환하도록 설정한다.
git config --global core.autocrlf input
git global config 구성 후에는 코드를 다시 pull해와야 한다.
참고
파일 끝에 개행을 추가해야 하는 이유
파일마다 EOL(End Of Line)을 왜 넣어야 할까
Formatting and Whitespace
git 에서 CRLF 개행 문자 차이로 인한 문제 해결하기
새줄문자
14. 불필요한 console.log를 남기지 않는다
console.log가 최종 제출하는 코드에 의미 없이 남아있지 않도록 주의
15. JavaScript에서 제공하는 API를 적극 활용한다
함수(메서드)를 직접 구현하기 전에 JavaScript API에서 제공하는 기능인지 검색을 먼저 해본다.
JavaScript API에서 제공하지 않을 경우에 직접 구현한다.
예를 들어 우승자를 출력할 때 우승자가 2명 이상이면 쉼표(,) 기준으로 출력을 위한 문자열은 다음과 같이 구현할 수 있다.
map, reduce이런거 쓰라는 말인가?
| const members = ['east', 'west', 'south']; members.map((member) => member).join(','); // "east,west,south" |
추가 학습 자료
-암호는 공통피드백 맨 밑에 잇음
- [10분 테코톡] 오리&코린의 Merge, Rebase, Cherry pick
- [10분 테코톡] 🎲 와일더의 Git Commands
'우아한테크코스' 카테고리의 다른 글
| 2주차 eslint prettier (0) | 2022.11.03 |
|---|---|
| 2주차 목표 (1) | 2022.11.02 |
| 2주차-git-[10분 테코톡] 오리&코린의 Merge, Rebase, Cherry pick (0) | 2022.11.02 |
| 2주차-git-4기 git강의 (0) | 2022.11.02 |
| 1주차 (0) | 2022.10.27 |
