1. 프로그래밍 공통
[OOP]
- OOP는 현실 세계를 프로그래밍으로 옮겨와 현실 세계의 사물들을 객체로 보고, 그 객체로부터 개발하고자하는 특징과 기능을 뽑아와 프로그래밍하는 기법
- OOP로 코드를 작성하면 재사용성과 변형가능성을 높일 수 있다.
[OOP의 5가지 설계 원칙]
- SRP(Single Responsibility Principle, 단일 책임 원칙): 클래스는 단 하나의 목적을 가져야하며, 클래스를 변경하는 이융는 단 하나의 이유여야한다.
- OCP(Open-Closed Principle, 개방 폐쇠 원칙): 클래스는 확장에는 열려 있고, 변경에는 닫혀 있어야한다.
- LSP(Liskov Substitution Principle, 리스코프 치환 원칙): 상위 타입의 객체를 하위 타입으로 바꾸어도 프로그램은 일관되게 동작해야한다.
- ISP(Interface Segregation Principle, 인터페이스 분리 원칙): 클라이언트는 이용하지 않는 메소드에 의존하지 않도록 인터페이스를 분리해야한다.
- DIP(Dependency Inversion Principle, 의존 역전 법칙): 클라이언트는 추상화(인터페이스)에 의존해야하며, 구체화(구현된 클래스)에 의존해선 안된다.
[절차지향 프로그래밍 VS 객체지향 프로그래밍]
- 절차지향 프로그래밍
- 물이 위에서 아래로 흐르는 것처럼 순차적인 처리를 중요시하는 프로그래밍 기법이다.
- 가장 대표적인 언어로 C언어가 있다.
- 컴퓨터의 처리구조와 유사해 실행속도가 빠르다.
- 코드의 순서가 바뀌면 동일한 결과를 보장하기 어렵다.
- 객체지향 프로그래밍
- 실제 세계의 사물들을 객체로 모델링하여 개발을 진행하는 프로그래밍 기법
- 가장 대표적인 언어로 JAVA가 있다.
- 캡슐화, 상속, 다형성등과 같은 기법을 이용할 수 있다. 다형성은 동일한 키보드의 키가 다른 역할을 하는 것 처럼 하나의 메소드나 클래스가 다양한 방법으로 동작하는 것을 의미한다.
- 절차지향 언어보다 실행속도가 느리다.
[RESTful API]
REST(Representational State Transfer)ful API는 HTTP통신에서 어떤 차원에 대한 CRUD요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식이다. RESTful API는 아래와 같은 것들로 구성된다.
- Resource(자원, URI)
- Method(요청 방식[GET, POST, PUT, DELETE])
- Representation of Resource(자원의 형태[JSON, XML등])
[함수형 프로그래밍]
함수형 프로그래밍의 가장 큰 특징은 immutable data와 first class citizen으로서의 함수이다. 함수형 프로그래밍은 부수효과가 없는 순수 함수를 이용하여 프로그램을 만드는 것이다. 부수 효과가 없는 순수 함수란 데이터의 값을 변경시키지 않으며 객체의 필드를 설정하는 등의 작업을 하지 않는 함수를 의미한다.
[메모리 구조]
- 코드 영역: 실행할 프로그램의 코드가 저장되는 영역으로 텍스트 영역이라고 부른다. 사용자가 프로그램 실행 명령을 내리면 OS가 HDD에서 실행 코드를 메모리로 올리게 되고, CPU는 코드 영역에 저장된 명령어를 하나씩 처리하게 된다.
- 데이터 영역: 프로그램의 전역 변수와 정적 변수가 저장되는 영역이다. 데이터 영역은 프로그램의 시작과 함께 할당되며 프로그램이 종료되면 소멸한다.
- 힙 영역: 프로그래머가 직접 관리할 수 있는 메모리 영역으로 이 공간에 메모리를 할당하는 것을 동적 할당이라고 부른다. JAVA에서는 가비지 컬렉터가 자동으로 해제해준다. 힙 영역은 스택 영역과 달리 낮은 주소에서 높은 주소로 메모리가 할당된다.
- 스택 영역: 함수의 호출과 함께 할당되며 지역 변수와 매개 변수가 저장되는 영역이다. 스택 영역에 저장되는 함수의 호출 정보를 스택 프레임이라고 한다. 스택 영역은 함수의 호출이 완료되면 소멸한다. 스택 영역은 높은 주소에서 낮은 주소로 메모리가 할당된다.
[Parameter와 Argument의 차이]
- Parameter: 함수를 선언할 때 사용된 변수
- Argument: 함수가 호출되었을 때 함수의 파라미터로 전달된 실제 값
[Call By Value와 Call By Reference의 차이]
- Call By Value
- 인자로 받은 값을 복사하여 처리하는 방식
- Call By Value에 의해 넘어온 값을 증가시켜도 원래의 값이 보존된다.
- 값을 복사하여 넘기기 때문에 메모리 사용량이 늘어난다.
- Call By Reference
- 인자로 받은 값의 주소를 참조하여 직접 값에 영향을 주는 방식
- 값을 복사하지 않고 직접 참조하기 때문에 속도가 빠르다.
- 원래의 값에 영향을 주는 리스크가 존재한다.
[프레임워크와 라이브러리의 차이]
- 라이브러리: 사용자가 흐름에 대한 제어를 하며 필요한 상황에 가져다가 쓸 수 있다.
- 프레임워크: 전체적인 흐름을 자체적으로 제어한다.
프레임워크와 라이브러리는 실행 흐름에 대한 제어 권한이 어디 있는지에 따라 달라진다. 프레임워크를 사용하면 사용자가 관리해야하는 부분을 프레임워크로 넘김으로써 신경써야할 것을 줄이는 제어의 역전(IoC, Inversion Of Control)이 적용된다.
[병렬 처리 프레임워크의 종류와 특징]
- Hadoop
- HDFS(Hadoop Distributed File System)을 활용해 데이터를 주고 받는다.
- 데이터가 여러 노드에 분산되어 저장되기 때문에 손실의 우려가 없다는 장점이 있다.
- File I/O를 기반으로 작동하기 때문에 처리 속도가 느리다.
- Spark
- In-Memory상에서 데이터를 주고 받고 연산을 수행한다.
- 메모리를 사용해 데이터를 처리하기 때문에 Hadoop보다 속도가 100배 빠르다.
- 메모리상에서 데이터를 처리하기 때문에 장애가 발생하는 경우 응용프로그램을 처음부터 다시 시작해야한다.
[동기와 비동기의 차이]
- 동기(Synchronous)
- 요청을 보내고 실행이 끝나면 다음 동작을 처리하는 방식
- 순서에 맞추어 진행되기 때문에 제어하기 쉽다.
- 여러가지 요청을 동시에 처리할 수 없어 효율이 떨어진다.
- 비동기(Asynchronous)
- 요청을 보내고 해당 동작의 처리 여부와 상관없이 다음 요청을 동작하는 방식
- 작업이 완료되는 시간을 기다릴 필요가 없기 때문에 자원을 효율적으로 사용할 수 있다.
- 작업이 완료된 결과를 제어하기 어렵다.
[SQL Injection]
SQL Injection이란 공격자가 악의적인 의도를 갖는 구문을 삽입하여 공격자가 원하는 SQL을 실행하도록하는 웹해킹기법이다.
[메세지 큐(Message Queue)]
메세지 큐(Message Queue): Queue 자료구조를 이용하여 데이터를 관리하는 시스템으로 비동기 통신 프로토콜을 제공하여 메세지를 빠르게 주고 받을 수 있게 해준다. 메세지 큐에서는 Producer(생산자)가 Message를 Queue에 넣어두면, Consumer(소비자)가 Message를 가져와 처리하게 된다.
[Docker(도커)와 Kubernates(쿠버네티스)]
Docker는 컨테이너 기반의 가상화 기술이다. 기존에는 하드웨어를 가상화하였기 때문에 Host OS위에 Guest OS를 설치해야했다. 하지만 이런 방식은 무겁고 느리기 때문에 한계가 있었다.
이를 극복하고자 프로세스를 격리시킨 컨테이너를 통해 가상화를 하는 Docker같은 기술들이 등장하게 되었고, 도커를 통해 구동되는 컨테이너를 관리하기 위한 Kubernates(쿠버네티스)가 등장하게 되었다.
[Docker의 장/단점]
- 장점
- 쉽고 빠른 실행환경 구축
- 하드웨어 자원 절감
- Docker Hub와 같은 공유 환경 제공
- 단점
- 개발 초기의 오버헤드
- Linux 친화적
[TDD(Test-Driven Development]
- TDD(Test-Driven Development)는 매우 짧은 개발 사이클의 반복에 의존하는 개발 프로세스로, 개발자는 우선 요구되는 기능에 대한 테스트케이스를 작성하고, 그에 맞는 코드를 작성하여 테스트를 통과한 후 상황에 맞게 리팩토링하는 테스트 주도 개발 방식을 의미한다.
- 개발자는 테스트를 작성하기위해 해당 기능의 요구사항을 확실히 이해해야하기 때문에 개발 전 요구사항에 집중할 수 있도록 도와주지만 테스트를 위한 진입 장벽과 작성해야하는 코드의 증가는 단점으로 뽑힌다.
[DDD(Domain-Driven Design]
- DDD(Domain-Driven Design)는 실세계에서 사건이 발생하는 집합인 Domain을 중심으로 설계하는 방법이다. 쇼핑몰을 예로 들자면, 손님들이 주문하는 도메인, 점주들이 관리하는 도메인이 있을 수 있다. 이러한 도메인들이 서로 상호작용하며 설계하는 것이 도메인 주도 설계이다.
- 도메인 주도 설계에서 도메인은 각각 분리되어 있는데, 이러한 관점에서 MSA(MiscroService Architecture)를 적용하면 용이한 설계를 할 수 있다. DDD에서는 같은 객체들이 존재할 수 있는데 예를 들어 구매자의 입장에서 Name, Price와 같은 객체 정보를 담지만, 판매자의 입장에서는 MadeTie, Size, MadeCountry등의 정보를 확인할 수 있다. 즉, 문맥에 따라 객체의 역할이 바뀔 수 있다.
[MSA]
MSA(Microservice Architecture)는 모든 시스템의 구성요소가 한 프로젝트에 통합되어 있는 모놀리식 아키텍쳐의 한계점을 극복하고자 등장하게 되었다. MSA는 1개의 시스템을 독립적으로 배포가능한 각각의 서비스로 분할한다. 각각의 서비스는 RESTful API를 통해 데이터를 주고 받으며 1개의 큰 서비스를 구성한다.
- 장점
- 일부 서비스에 장애가 발생해도, 전체 서비스에 장애가 발생하지 않는다.
- 각각의 서비스들은 서로 다른 언어와 프레임워크로 구성될 수 있다.
- 서비스의 확장이 용이하다.
- 단점
- 서비스가 분리되어 있어, 테스팅이나 트랜젝션 처리등이 어렵다.
- 서비스간에 RESTful API로 통신하기 때문에 그에 대한 비용이 발생한다.
- 서비스간 호출이 연속적이기 때문에 디버깅이 어렵다.
