Git & Github
- 우테코 origin 저장소 → 개인 깃헙 origin 저장소 → 개인 로컬 저장소
- 개인 로컬 저장소에서 commit을 하며 과제 해결
- 개인 로컬 저장소 → 개인 깃헙 origin 저장소로 push → 우테코 origin 저장소로 PR 보내기.
원래는 PR 후 merge를 하는데 우테코에서는 PR까지만 보내는 듯.
Q. 개인 origin 저장소에서 main으로 merge하는 것도 안되는 것인가?
git push origin [BranchName] : 원격 저장소에 생성 브랜치 push
git push origin —delete [BranchName] : 원격 저장소에 있는 브랜치 delete
git branch -D [BranchName] : 로컬 저장소에 있는 브랜치 delete
Git repository에 local branch 연동하는 법
- Git repository 생성
- git init : 깃 저장소를 초기화, 이 명령어를 입력한 후에야 추가적인 깃 명령어들을 줄 수 있으며, git init은 최초 한번만 시행
- git remote add origin [깃헙 주소] : 원격 장소 remote를 생성하고, Github에서 생성한 repository를 연동
- git add . : 깃에 파일 전체(.)를 올림
- git commit -m “~” : 깃 커밋시 ~와 함께 커밋
- git push -u origin main : git에 푸시할때 origin
Clean Code
SOLID
https://blog.itcode.dev/posts/2021/08/15/liskov-subsitution-principle
SRP : 단일 책임 원칙
클래스는 단 한개의 ‘책임(기능)’을 가져야 한다.
클래스를 변경하는 이유는 단 하나여야 한다.
OCP : 개방-폐쇄 원칙
확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다.
즉, 기존의 코드를 변경하지 않고 기능을 수정하거나 추가할 수 있도록 설계해야 한다.
자주 변화하는 부분을 추상화 → 기존 코드 수정없이 기능 확장 가능한 유연함 높임.
LSP : 리스코프 치환 원칙 - 어렵다…
상위 타입 객체를 하위 타입 객체로 치환해도 정상적으로 동작해야함.
즉, 상속 관계의 두 클래스간 인풋과 아웃풋이 동일해야 함을 의미.
일반화 관계인 IS-A 관계가 확실해야한다.
아버지 ↔ 아들 X / 포유류 ↔ 동물 O
위 예시를 통해 어느 한 객체가 다른 하나를 완전히 감싸는 구조 필수(확실한 상속)
서브 클래스가 슈퍼 클래스의 기능을 오버라이딩하지 않고 추가적인 필드나 기능만 제공하는 것이다. 부모 클래스의 책임을 변화시키는 기능은 LSP 법칙에 위배되기 때문.
ISP : 인터페이스 분리 원칙
클래스는 자신이 사용하는 메소드에만 의존해야 한다.
한 클래스는 자신이 사용하지 않는 인터페이스는 구현하지 않아야 한다.
여러 세부적인 인터페이스를 구현해서 implement하라.
인터페이스는 해당 인터페이스를 사용하는 클라이언트를 기준으로 잘게 분리되어야 한다.
각 클라이언트가 필요로 하는 인터페이스를 분리함으로써 클라이언트가 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 하라.
DIP : 의존 역전 원칙
변하기 쉬운 것(구체적인 것)보다는 변하기 어려운 것(추상적인 것)에 의존해야 한다.
고수준 모듈(인터페이스 등 추상적 개념)은 저수준(구현된 객체)의 구현에 의존하면 안된다.
저수준 모듈이 변경되어도 고수준 모듈은 변경이 필요없는 형태가 이상적이다.
결론
SRP와 ISP는 객체가 커지는 것을 막아준다.
객체가 단일 책임이어야 하고, 클라이언트마다 특화된 인터페이스르 구현하게 함으로써 한 기능의 변경이 다른 곳까지 미치는 영향을 최소화한다.
LSP, DIP, OCP는 서포트를 한다.
OCP는 자주 변화하는 부분을 추상화하고 다형성을 이용함으로써 기능 확장에는 용이하되 기존 코드 변화에는 보수적이도록 한다. 여기서 ‘변화되는 부분을 추상화’하게 도와주는 원칙이 DIP이고, 다형성 구현을 도와주는 원칙이 LSP인 것이다.
MVC 패턴
M : Model (MySQL, IndexedDB 등)
앱이 포함해야 할 데이터가 무엇인지 정의.
V : View (HTML, CSS 등)
앱의 데이터를 보여주는 방식을 정의.
C : Controller (HTML, JavaScript 등)
앱의 사용자로부터의 입력에 대한 응답. 모델 및 뷰를 업데이트하는 로직을 포함.
예시1.
장바구니에 품목 추가or제거 (뷰 → 컨트롤러) → 컨트롤러를 통해 모델 업데이트 (컨트롤러 → 모델) → 업데이트된 모델(데이터)을 뷰로 전송 (모델 → 뷰)
예시2.
데이터 수정없이 뷰만 바꾸고 싶을 때 : 컨트롤러 → 뷰
매우 포괄적이고 넓은 영역의 개념이다. 각 객체의 역할만 이해하면 충분할 듯.
TDD
TDD : 테스트 주도 개발
https://wooaoe.tistory.com/33
실패하는 테스트 코드를 ‘먼저’ 작성
해당 테스트 코드를 성공시키기 위한 최소한의 코드 작성
중복 코드 제거, 일반화 등의 리팩토링 수행
→ 요구 사항에 정확히 집중할 수 있다.
→ 이번 과제에 대한 큰 그림을 그리고, 세부 기능 단위로 TDD 실천해보자.
Dependency Injection(의존 관계 주입)
의존관계 주입(Dependency Injection) 쉽게 이해하기 (techcourse.co.kr)
객체가 의존하는 또 다른 객체를 외부에서 선언하고 이를 주입받아 사용하는 것.
의존관계를 인터페이스로 추상화한다.
그 의존관계를 외부에서 결정하고 주입.
- 클래스 모델이나 코드에는 런타임 시점의 의존관계가 드러나지않는다. 그러기 위해서는 인터페이스만 의존하고 있어야 한다.
- 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제 3의 존재가 결정한다.
- 의존관계는 사용할 오브젝트에 대한 래퍼런스를 외부에서 제공(주입)해줌으로써 만들어진다.
장점
- 의존성이 줄어든다
- 재사용성이 높은 코드가 된다
- 테스트하기 좋은 코드가 된다
- 가독성이 높아진다
