깃허브에 업로드할때 커밋컨벤션을 지키면서 커밋메세지를 작성해야한다는걸 알고 찾아보았다
나 혼자 작업을하면서 comiit 이나 push할때는 관계없지만 여러사람들과 같이 개발할때 커밋메세지가 많아 질수록 가독성이 떨어지면서 코드의 유지보수,리뷰에 어려움을 겪기때문에 개발자들끼리의 약속인 커밋컨벤션을 스타일을 지키면서 작성하는걸 우선해야한다
Comiit Message 의 구조
- type,subject,body,footer로 나누고 각파트는 한줄의 공백을 두어서 구분하도록 한다
| 타입 | 의미 | 언제 쓰는지 | 예시 |
|---|---|---|---|
| feat | 기능 추가 | 새로운 기능 만들 때 | feat: 게시글 등록 기능 추가 |
| fix | 버그 수정 | 오류 고칠 때 | fix: 로그인 시 비밀번호 오류 수정 |
| docs | 문서 수정 | README, 주석 | docs: README 작성 |
| style | 코드 스타일 | 공백, 세미콜론 등 | style: 코드 정렬 수정 |
| refactor | 리팩토링 | 기능 변화 없이 코드 개선 | refactor: 계산 로직 분리 |
| test | 테스트 | 테스트 코드 추가/수정 | test: 계산기 테스트 코드 추가 |
| chore | 기타 작업 | 설정, 패키지 등 | chore: .gitignore 추가 |
ex) 타입 + 무엇을했는지 한눈에 보일수있도록
feat: "로그인 기능 구현"
로그인 시 JWT 발급
Resolves: #111
Ref: #122
related to: #30, #50
OOP (객체지향 프로그램)
KEYWORD
- 클래스 + 인스턴스(객체)
- 추상화 (abstraction)
- 캡슐화 (capsulation)
- 상속 (inheritance)
- 다형성 (Polymorphism)
클래스 + 인스턴스
클래스는 설계도 - 객체는 실제 만들어진것
집단에 속하는 속성,기능을 변수와 메소드로 정의, 실제 객체를 만들어낼 메타정보
위에 정의한것을 토대로 프로그램에서 사용되는 데이터
추상화
공통의 속성이나 행위를 묶어서 정의한다 포괄적인 범위를 가지고있기때문에
명확하게 구체화 시키지않은 미완성 메소드이며 추상클래스는 객체생성이 불가능하다
필요한것만 보여주고, 내부는 숨기는것
ex) 자동차를 운전할때 엔진이 어떻게생겼는지 부품이 뭐가들어가지는지 알순없지만
핸들과 페달만 알고있으면 운전할수있다
캡슐화
getter,setter 의 목적, 클래스내부에있는 데이터를 외부에서 잘못 접근하지못하도록 접근제어자를통한 은닉 대표적으로 접근제어자를 통해 통제한다
출저 : https://developingman.tistory.com/11
- getter : 외부에서 메서드에 접근해서 데이터값을 확인하고 출력해준다 (return값)
- setter : 외부에서 메서드에 접근해서 데이터값을 변경할수있도록 해준다 (매개변수)
상속
상속은 부모클래스의 속성과 기능을 그대로 이어받아 사용할 수 있게하고 기능의 일부분을 변경해야 할 경우 상속받은 자식클래스에서 해당 기능만 다시 수정(정의)하여 사용할 수 있게 하는 것이다.
쉽게말해 부모클래스의 기능을 물려받은거와 같다
Cat에 없는 메소드도 부모클래스에있는걸 사용가능
다형성
하나의 변수명, 함수명 등이 상황에 따라 다른 의미로 해석될수있다.
즉 같은 이름인데 상황에 따라 다르게 동작
오버라이딩(Overriding), 오버로딩(Overloading)이 가능하다
오버라이딩 : 부모클래스의 메서드와 같은 이름, 매개변수를 재정의 하는것.
오버로딩 : 같은 이름의 함수를 여러개 정의하고, 매개변수의 타입과 개수를 다르게 하여 매개변수 입력값에 따라 다르게 호출할 수 있게 하는 것.
| 구분 | 오버로딩 | 오버라이딩 |
|---|---|---|
| 위치 | 같은 클래스 | 상속 관계 |
| 메서드 이름 | 같음 | 같음 |
| 매개변수 | 달라야 함 | 같아야 함 |
| 목적 | 편의성 | 다형성 |
ONEPOINT 한줄핵심
- 클래스 / 객체 : 설계도와 실제객체
- 추상화 : 필요한 것만 보여줌
- 캡슐화 : 데이터 보호
- 상속 : 코드재사용
- 다형성 : 같은이름 다른동작
