Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
Tags
- 자바
- 데이터베이스
- 팀플회고
- 깃 연동
- React Native
- 모두의네트워크
- 머신러닝
- 백준 4358 자바
- 리액트 네이티브
- 깃 터미널 연동
- 백준 4358번
- 지네릭스
- 네트워크
- 스터디
- HTTP
- 깃허브 토큰 인증
- 백준 5525번
- 백준
- 깃허브 로그인
- 딥러닝
- 리액트 네이티브 시작하기
- 백준 4949번
- 리액트 네이티브 프로젝트 생성
- 데베
- 정리
- 모두를 위한 딥러닝
- SQL
- 모두의 네트워크
- 모두를위한딥러닝
- 문자열
Archives
- Today
- Total
솜이의 데브로그
[CS] 개발 상식 본문
1. 좋은 코드란 무엇인가?
컴퓨터 뿐만 아니라 함께 일하는 혹은 정보를 공유하는 개발자 간에 잘 읽히도록 짜여진 코드
- 코드 간의 의존성을 고려하며
- 합의된 규칙으로 일관성 있게 작성하고
- 적절하게 확장가능한 코드
2. Restful API란 무엇인가? Restful하게 API를 디자인한다는 것은 무슨 뜻인가?
REST API란 REST 아키텍처의 제약 조건을 준수하는 애플리케이션 프로그래밍 인터페이스를 뜻합니다.
- REST는 Representational State Transfer의 줄임말.
- 자원을 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것을 의미한다.
- HTTP URI를 통해 어떤 자원인지 명시하고, HTTP Method (Get, POST, PUT, PATCH, DELETE)를 통해 해당 자원을 처리하도록 설계된 것이다.
API가 RESTful로 간주되기 위해서는 다음 기준을 따라야 한다.
- 클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처
- 스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음
- 클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터
- 정보가 표준 형식으로 전송되도록 하기 위한 구성 요소 간 통합 인터페이스. 여기에 필요한 것은 다음과 같습니다.
- 요청된 리소스가 식별 가능하며 클라이언트에 전송된 표현과 분리되어야 합니다.
- 수신한 표현을 통해 클라이언트가 리소스를 조작할 수 있어야 합니다(이렇게 할 수 있는 충분한 정보가 표현에 포함되어 있기 때문).
- 클라이언트에 반환되는 자기 기술적(self-descriptive) 메시지에 클라이언트가 정보를 어떻게 처리해야 할지 설명하는 정보가 충분히 포함되어야 합니다.
- 하이퍼미디어: 클라이언트가 리소스에 액세스한 후 하이퍼링크를 사용해 현재 수행 가능한 기타 모든 작업을 찾을 수 있어야 합니다.
- 요청된 정보를 검색하는 데 관련된 서버(보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.
- 코드 온디맨드(선택 사항): 요청을 받으면 서버에서 클라이언트로 실행 가능한 코드를 전송하여 클라이언트 기능을 확장할 수 있는 기능.
3. REST 6가지 원칙은?
- Server-Client 구조
- 자원이 있는 쪽이 Server, 요청하는 쪽이 Client
- REST Server : API를 제공하고 비즈니스 로직을 처리 및 저장을 책임진다.
- Client : 사용자 인증이나 context(세션, 로그인 정보)등을 직접 관리하고 책임진다.
- 요청이 HTTP를 통해 관리되는 아키텍처
- 서로 간 의존성이 줄어든다.
- 자원이 있는 쪽이 Server, 요청하는 쪽이 Client
- Stateless (무상태)
- 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음.
- 각 API 서버는 Client의 요청만을 단순 처리한다.
- 이전 요청이 다음 요청의 처리에 연관되어서는 안된다.
- 이전 요청이 DB를 수정하여 DB에 의해 바뀌는 것은 허용한다.
- Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아진다.
- 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음.
- Cacheable (캐시 처리 가능)
- 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다.
- 대량의 요청을 효율적으로 처리하기 위해 캐시를 사용한다.
- Layered System (계층화)
- 요청된 정보를 검색하는데 관련된 서버 (보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.
- API Server는 순수 비즈니스 로직을 수행하고 그 앞단에 보안, 로드밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있다.
- PROXY, 게이드웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있다.
- 요청된 정보를 검색하는데 관련된 서버 (보안, 로드 밸런싱 등을 담당)의 각 유형을 클라이언트가 볼 수 없는 계층 구조로 체계화하는 계층화된 시스템.
- Uniform Interface (인터페이스 일관성)
- URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행한다.
- HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
- 특정 언어나 기술에 종속되지 않는다.
- Code-On-Demand (Optional)
- Server로 부터 스크립트를 받아서 Client에서 실행한다.
4. 절차지향 프로그래밍과 객체지향 프로그래밍의 차이는?
절차지향(Procedural Programming)이란, 순차적인 처리가 중요시되며 프로그램 전체가 유기적으로 연결되도록 만드는 프로그래밍 기법이고, 객체지향 (Object Oriented Programming) 이란, 실제 세계를 모델링하여 소프트웨어를 개발하는 방법입니다.
절차 지향
- 장점
- 컴퓨터의 처리구조와 유사해 실행속도가 빠름
- 단점
- 유지보수가 어려움
- 실행 순서가 정해져 있으므로 코드의 순서가 바뀌면 동일한 결과를 보장하기 어려움
- 디버깅이 어려움
객체 지향
- 프로그래밍에서 필요한 데이터를 추상화시켜 상태와 행위를 가진 객체를 만들고, 그 객체들 간의 유기적인 상호작용을 통해 로직을 구성하는 프로그래밍 방법론.
- 캡슐화, 상속, 다형성의 특징을 가지고 있다.
- 장점
- 남이 만든 클래스를 가져와서 이용할 수 있고, 상속을 통해 확장해서 사용할 수 있기 때문에 코드 재사용성이 용이하다.
- 수정해야할 부분이 클래스 내부에 멤버 변수 혹은 메서드로 존재하기 때문에 해당 부분만 수정이 가능해 유지, 보수가 쉽다.
- 클래스 단위로 모듈화시켜서 개발할 수 있으므로 대형 프로젝트에 적합하다.
- 단점
- 처리속도가 상대적으로 느리다.
- 설계 시 많은 시간과 노력이 필요하다.
5. OOP의 중요한 개념 중 하나인 다형성에 대해서 설명
다형성이란, 하나의 객체가 여러가지 타입을 가질 수 있는 것을 의미합니다.
- 자바에서는 한 레퍼런스 변수가 다른 형태의 객체를 참조할 수 있음을 말한다.
- 오버로딩, 오버라이딩, 업캐스팅, 다운캐스팅 등의 방법이 있다.
- 오버로딩 : 부모 클래스의 메서드와 같은 이름, 매개변수를 재정의하는 것.
- 오버라이딩 : 같은 이름의 함수를 여러개 정의하고, 매개변수의 타입과 개수를 다르게하여 매개변수에 따라 다르게 호출할 수 있도록 하는 것.
6. MVC 패턴이란 무엇인가
구성요소를 Model, View, Controller 의 세가지 역할로 분리하여 개발하는 방법론입니다.
MVC 패턴을 사용하며 서로 영향을 주지 않고 개발할 수 있습니다.
Model은 응용 프로그램의 동작 및 데이터를 관리, View로 UI를 화면에 표출, Controller는 사용자에게 입력을 받아 Model을 조작하고, View를 업데이트 시키는 패턴을 의미합니다.
Model
- 응용 프로그램의 동작 및 데이터를 관리
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
- 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
View
- UI를 화면에 표출한다. 데이터 및 객체의 입력, 그리고 출력을 담당한다.
- 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
- 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
- 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야만 한다.
Controller
- 사용자에게 입력을 받아 Model을 조작하고, View를 업데이트 시킨다.
- 사용자가 데이터를 클릭하고, 수정하는 것에 대한 이벤트를 처리한다.
- 모델이나 뷰에 대해서 알고 있어야 한다.
- 모델이나 뷰의 변경을 모니터링 해야한다.
7. 함수형 프로그래밍의 특징 2가지는?
함수형 프로그래밍(Functional Programming)의 특징은, 부수 효과가 없는 순수 함수를 1급 객체로 간주하여 파라미터나 반환값으로 사용할 수 있으며, 참조 투명성을 지킬 수 있다는 것입니다.
- 함수형 프로그래밍은 거의 모든 것을 순수 함수로 나누어 문제를 해결하는 기법으로, 작은 문제를 해결하기 위한 함수를 작성하여 가독성을 높이고 유지보수를 용이하게 해준다.
- 순수함수
- 동일한 입력에는 항상 같은 값을 반환해야 한다.
- 함수의 출력은 오로지 그 함수에 입력된 값(input)에만 의존한다.
- 함수의 실행은 프로그램의 실행에 영향을 미치지 않아야 한다.
- Functional composition
- 둘 이상의 함수를 조합하는 과정을 말한다.
- 함수형 프로그램은 여러 작은 순수 함수들로 이루어져있기 때문에 이 함수들을 연쇄적으로 또는 병렬로 호출해서 더 큰 함수를 만드는 과정으로 전체 프로그램을 구축해야 한다.
8. TDD란 무엇인가?
TDD란, Test Driven Development의 약자로, '테스트 주도 개발'이라고 합니다.
반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현합니다.
단위 테스트(unit Test)란?
- 한 단위 (일반적으로 class)만을 테스트 하는 것이다.
- TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 것이다.
- 디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고, 무엇보다 테스트해야 할 지 미리 정의해야만 한다.
- 테스트 코드를 작성하는 도중 발생하는 예외사항은 테스트 케이스에 추가하고 설계를 개선한다.
- 이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.
- TDD 개발 방식의 장점
- 보다 튼튼한 객체 지향적인 코드 생산
- 재설계 시간의 단축
- 디버깅 시간의 단축
- 테스트 문서의 대체 가능
- 단점
- 생산성 저하
9. Git을 사용하기 위한 전략 중 하나인 Git Flow에 대해 설명
Git-flow에서 사용하는 5가지 브랜치
- master(main) : 제품으로 출시될 수 있는 브랜치
- develop : 다음 출시 버전을 개발하는 브랜치
- feature : 기능을 개발하는 브랜치
- release : 이번 출시 버전을 준비하는 브랜치
- hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치
개발 흐름
- develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가된다.
- 새로운 추가 작업이 있는 경우, develop 브랜치에서 feature 브랜치를 생성한다.
- 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 된다.
- develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성한다.
- QA를 진행하면서 발생한 버그들은 release 브랜치에 수정된다.
- QA를 무사히 통과하면 release 브랜치를 master와 develop 브랜치로 merge한다.
- 마지막으로 출시된 master 브랜치에서 버전 태그를 추가한다.
10. 프레임워크와 라이브러리에 대해서 설명
라이브러리(Library)란?
- 단순 활용이 가능한 도구들의 집합
- 주로 소프트웨어를 개발할 때 컴퓨터 프로그램이 사용하는 비휘발성 자원의 집합이다.
- 개발자가 개발하는데 필요한 것들을 모아둔 도구들의 나열로, 필요할 때 호출하여 사용하는 방식을 취한다.
프레임워크(Framework)란?
- 소프트웨어의 특정 문제를 해결하기 위해서 상호 협력하는 클래스와 인터페이스의 집합
- 소프트웨어 어플리케이션이나 솔루션의 개발을 수월하게 하기 위해 소프트웨어의 구체적 기능들에 해당하는 부분의 설계와 구현을 재사용 가능하도록 협업화된 형태로 제공하는 소프트웨어 환경을 말한다.
- 애플리케이션 개발 시 필수적인 코드, 알고리즘, 데이터베이스 연동 등과 같은 기능을 위해 어느정도 뼈대를 제공해주는 것이고, 그러한 뼈대 위에 개발자가 코드를 작성하여 완성해야한다.
라이브러리와 프레임워크의 차이
프레임워크와 라이브러리의 차이는 흐름(Flow)에 대한 제어 권한이 어디에 있느냐의 차이입니다.
프레임워크는 전체적인 흐름을 자체적으로 가지고 있으며, 프로그래머가 그 안에 필요한 코드를 작성하는 반면에 라이브러리는 사용자가 흐름에 대해 제어를 하며 필요한 상황에 가져다 쓰는 것입니다.
- 프레임워크에는 제어의 역전(Inversion Of Control)이 적용되어 있다.
- 제어의 역전이란, 어떠한 일을 하도록 만들어진 프레임워크에 제어의 권한을 넘김으로써 클라이언트 코드가 신경 써야 할 일을 줄이는 전략이다.