[Study] 신입 자라기 -58

신입 자라기 58일 차, 월요일

Daily Routine

시간	Routine
6 : 30	기상
6 : 50 ~ 7 : 50	출근 시간
7 : 50 ~ 9 : 10	헬스
9 : 10 ~ 9 : 30	샤워
9 : 30 ~ 9 : 50	출근
9 : 50 ~ 10 : 00	1. 짐정리 2. 간식
10 : 00 ~ 11 : 30	에러 원인 파악
11 : 30 ~ 12 : 30	점심 시간
12 : 30 ~ 18 : 00	1. 에러 해결 2. 쿠버네티스 설정
18 : 00 ~ 19 : 00	저녁 시간
19 : 00 ~ 20 : 30	개인 공부
20 : 30 ~ 21 : 30	퇴근 시간
21 : 30 ~ 22 : 30	샤워
22 : 30 ~ 24 : 00	1. 블로그 포스팅 2. 개인 프로젝트

리눅스 명령어 free

• 메모리 사용량 확인
• total : used + free (시스템 메모리 총합 = 사용되는 메모리 + 사용 중인 메모리)

리눅스 환경에서 여러줄 주석

• 명령어 모드에서 v를 입력해서 visual 모드로 전환
• hjkl(방향키)를 사용해서 주석 처리할 줄 선택(기본 방향키 사용 가능)
• 선택하고 ':' 입력하고 'norm i#' 입력

:norm i#

nfs-server 상태 확인 명령어

systemctl status nfs-server.service

도커 상태 확인 명령어

sudo systemctl status docker

도커 conf 파일 경로

• /etc/docker/daemon.json

microk8 s inspect

• 실행 중인 microk8s의 현재 상태에 대한 자세한 전체 로그기록을 tar.gz로 변경
• 주로 문제 해결 및 버그 보고에 유용

---

출근길에 보는 CS

객체 지향 5원칙(SOLID)

SRP(Single Responsibility Principle)

• 단일 책임원칙
• 클래스는 오직 한 개의 책임만을 가져야 하는 규칙
• 여러 책임을 가지게 되면 책임마다 변경해야 하기 때문에, 클래스를 수정하는 이유는 오직 한 개여야 한다라는 말과 동일함

OCP(opend-closed -principle)

• 개방 폐쇄 원칙
• 클래스, 모듈, 함수 등은 확장에 대해서는 개방되어있어 하지만 변경에 대해서는 폐쇄되어야 한다.
• 소프트웨어 개발에 필요한 많은 모듈 중 하나를 수정할 때, 그 모듈과 연관된 다른 모듈을 줄줄이 수정하는 것은 매우 어렵기 때문에, 개방-폐쇄 원칙은 시스템 구조를 올바르게 재족해 나중에 수정을 할 필요 없게 하는 것이다.
• 나중에 기능 추가하거나 변경할 때 원래 모듈을 수정하지 않고 새로운 코드를 추가함으로써 문제를 해결하기 위함이다

LSP(Liskov Substitution Principle)

• 리스 코프 치환 원칙
• 즉 자료형 *{S}*가 자료형 *{T}*의 하위형이라면, 프로그램에서 자료형 *{T}*의 객체는 프로그램의 속성을 변경하지 않고 자료형 *{S}*의 객체로 교체할 수 있어야 한다.
• 부모 클래스의 인스턴스를 사용하는 위치에 자식 클래스의 인스턴스를 대신 사용했을 때 코드가 원래 의도대로 동작해야 함
• 부모 클래스의 인스턴스 자리에 자식 클래스의 인스턴스도 들어갈 수 있어야 함
• 부모 클래스의 행동 규약을 자식 클래스가 위반하면 안 됨
• 자식 클래스가 부모 클래스의 변수와 메서드를 있는 그대로 사용하면 문제가 없는 자식 클래스가 오버 라이딩할 때 문제가 될 수 있음
• 아래에 리스 코프 치환 원칙을 예시를 들어 설명함

https://junnyhi.tistory.com/94

[Study] 신입 자라기 - 23

ISP(Interface Segregation Principle)

• 인터페이스 분리 원칙
• 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙
• 사용하지 않는 메서드에 의존성을 띄면 안 됨
• 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메서드들만 이용할 수 있게 해야 함

DIP(Dependency Inversion Principle)

• 의존 역전 원칙
• 상위 모듈은 하위 모듈에 의존해서는 안되고 상위 모듈과 하위 모듈 모두 추상화에 의존해야 함
• 예를 들어 고수준 모듈의 ‘컴퓨터’ 클래스가 저수준 모듈인 ‘적축 키보드’를 사용하도록 설계되어있다.
• 그러면 ‘컴퓨터’는 ‘적축 키보드’에 의존하고 있는 것인데, 이때 다른 키보드로 교체하고 싶으면 그와 연관된 많은 모듈을 수정할 필요가 생길 것임
• 따라서 ‘키보드’란 모듈을 생성하고 사용하고 싶은 ‘적축, 청축, 갈축’ 키보드를 추상화해서 사용해야 하는 것
• 이렇게 저수준 키보드보다 고수준 모듈인 컴퓨터 입장에서 클래스가 만들어지는데, 고수준 모듈이 저수준 모듈에 의존하는 상황이 역전됨이라고 표현