면접 컨닝페이퍼

엽토군·2024년 6월 26일
0

겪어는 본 것들

SOLID 원칙

I SOLD로 외우는게 더 나을거 같음.

I: 인터페이스에 임무를 하나만 줄것
S: 클래스에 임무를 하나만 줄것
O: 확장당하는 클래스에서 뭔가를 추가 Open하지 말것
L: 자식이 부모를 대체할 수 있을 것 "리스코프 치환원칙"
D: 의존당하는 클래스가 더 원초적일 것

싱글톤

전체 라이프사이클에서 인스턴스가 한번만 초기화되고 그것만 쭉 재활용되는 패턴.
PHP에서는 protected 생성자와 정적메소드만 있는 클래스를 컨테이너에 넣음으로써 구현 가능.

라라벨 파사드와는 다름.
라라벨 파사드는 __callStatic() 돌려서 컨테이너 인스턴스를 꺼내주는 "정적프록시" 헬퍼.

컨테이너를 사용한다고 해서 무조건 싱글톤인 것은 아님.
라라벨 컨테이너의 경우 ->singleton(Foo::class) 의존성주입과 ->bind(Foo::class) 의존성주입을 따로 지원한다.

PSR 목록

5, 8, 9, 10은 없음.

1: PHP 파일 표준. PHP 태그, 파일인코딩, 네임스페이스, 클래스, 상수 등등
2: 코딩스타일. 12로 확장됨. "탭 말고 스페이스 4개" 등등
3: 로깅.
4: 오토로딩. 원래 0이었음. "어떤 경로의 클래스는 반드시 어떤 네임스페이스를 갖는다."
6: 캐싱.
7: HTTP 메시지. ServerRequestInterface가 여기 있음.
11: 컨테이너. get, has 2개만 있음.
14: 이벤트 리스너/디스패처.
15: HTTP 요청핸들러 (= 미들웨어)
18: HTTP 클라이언트 (GuzzleHttp 같은것)

요청-응답 줄거리

  1. (도메인을 썼을 경우) 도메인이 IP로 DNS 리졸브됨.
  2. 해당 IP의 해당 포트에 해당 프로토콜 패킷이 들어옴.
  3. 하필 그 IP의 그 포트를 그 프로토콜로 리스닝하는 프로세스가 있을경우 그 프로세스로 패킷이 전달돼 입력됨.
    • "라우팅"(path 분석)은 이 프로세스에게 전적으로/임의적으로 일임된다. 어떤 프로세스는 물리적 경로로써 처리하고 어떤 프로세스는 "가상호스트"를 처리할 수 있다.
  4. 프로세스가 그 프로토콜에 맞는 응답을 출력함.
    • 이 출력을 클라이언트/NGINX 등이 기다리지 못할 때 502가 발생한다.
  5. 출력이 요청자 클라이언트로 전달됨. 이 출력의 밈타입이 하필 text/html이고 그 클라이언트가 하필 웹브라우저일 경우 웹 화면이 렌더링 된다. 끝.

CTE

공통 테이블 표현식.
주로 재귀적 테이블을 flatten할 때 WITH RECURSIVE로 쓴다.

JIT

PHP 8에서 OPCache의 일부로서 도입.
PHP 스크립트는 바이트코드로 변환되어 Zend Engine이라는 가상머신에서 실행된다.
이 바이트코드 변환 결과를 메모리에 꽂는 게 OPCache임.
JIT는 여기서 한걸음 더 나가서 바이트코드 → CPU 기계코드 변환 결과를 메모리에 꽂는다.
이 변환 과정이 실행전(ahead of time)에 되지 않고 실행중(just in time)에 일어나기 때문에 JIT라 부른다.

  • 스크립트가 변하지 않았다면 → 그 변환 결과가 변할 리가 없으므로 → 성능은 무조건 오른다.
  • PHP JIT는 CPU 기계코드를 사용하므로 → 일부 CPU 아키텍처에서는 JIT 적용이 안된다.
  • 주의! PHP는 "컴파일"되지 않는다.

PHP 버전별 중대변화

7.0: 메소드 응답형 강제 가능. <=> 연산자 도입.
7.1: 메소드 응답형 nullable 가능. 배열 구조분할 도입. catch| 연산자 도입.
7.2: {}로 묶인 내부에서 후행 쉼표 허용됨. 그밖에 딱히 없음...
7.3: 메소드 인자 줄 때 후행 쉼표 허용됨. 그밖에 딱히 없음...
7.4: 프로퍼티 형 강제 가능. 화살표 함수 도입. ??= 연산자 도입.
8.0:

  • OPCache JIT 도입.
  • 메소드 인자를 이름 기준으로 줄 수 있음.
  • Attribute 도입. #[Foo(bar: 'dee')]
  • match문 도입.
  • ?-> 연산자 도입.
  • str_contains() 등의 헬퍼 추가.

RESTful

레프레젠테이셔널 스테이트 전송 같은 것 이라는 뜻.
GET /pets를, 진짜로 pet이라는 자원이 있어서, 그 자원'들'을 "얻어보겠다"고 요구하는 것으로 보는 관점.

  • 그리하여 GET /petsPet[]을 표현한 응답을 반환한다. 그게 XML이든 JSON이든
  • 자원 개념이 성립하지 않으면 도입하기 곤란
  • HTTP method를 고르기 어려운 경우가 있을수 있음
  • 자원 연관관계 관련해서 자칫하면 산으로 갈 수 있다. PUT /board/1/post/34/comment/8876

안 겪어본 것들 ㅡㅡ;

웹소켓

웹에서 쓸 수 있는 완전이중(full duplex) TCP.

  • "요청을 받지 않고도 응답을 줄 수 있다"
    • 그래서 서버는 이런저런 요청의 라우팅을 정의 구현하는 게 아니라 on message, on error 등을 정의 구현한다.
  • HTTP 1.1과는 다르지만, 특정 목적을 더 잘 달성하는 프로토콜.
    • HTTP 1.1에도 '영구 연결'이 있긴 하다. 그래서인지 WS 규격은 80/443 포트 사용을 권고한다.
    • 그래서 "핸드셰이킹" 필요하다. 클라이언트가 Connection: Upgrade; Upgrade: websocket; 헤더를 붙였을 때 서버가 HTTP 101을 반환하면, 이때부터는 http:// 대신 ws://를 쓰는 식.
    • TCP 통신인 관계로 CORS, secure layer 다 걸린다.

ACID

트랜잭션이란 게 성립하려면:

A: atomic. 모두 커밋되든지 모두 롤백되든지 해야 한다. "원자성"
C: consistent. 일관된 규칙으로만 작업 가능해야 한다.
I: isolated. 트랜잭션끼리 서로 간섭할 수 없어야 한다.
D: durable. 변경 안 한 데이터는 유지돼야 한다.

트랜잭션 동시성 문제

  • 낙관적으로 락걸기: UPDATE SET ver = now(), ... WHERE ver < now() AND ...
  • 비관적으로 락걸기: START TRANSACTION; ...
  • 비고: 전자는 애플리케이션이 뒤처리해야 한다. 후자는 DB 엔진이 블로킹/롤백을 한다.
profile
5년차 PHP 개발자입니다.

0개의 댓글