들어가기 전

https://joshua1988.github.io/web-development/interview/frontend-questions/
https://github.com/JaeYeopHan/Interview_Question_for_Beginner
https://jbee.io/essay/for_junior_frontend_developer/

위의 글들을 참조하여 배경지식을 찬찬히 쌓아보자.

1. REST(REpresentational State Transfer)

1-1. REST란?

소프트웨어 프로그램 아키텍처의 한 형식

REpresentational State Transfer의 약자로
자원을 이름으로 구분해 해당 자원의 상태를 주고받는 모든 것을 의미

즉, 자원의 표현에 의한 상태 전달을 뜻함

  • 자원 : 해당 소프트웨어가 관리하는 모든 것 ( 문서, 그림, 데이터, 해당 소프트웨어 자체 등 )
  • 표현 : 그 자원을 표현하기 위한 이름 ( DB의 학생 정보가 자원이면, ‘students’를 자원의 표현으로 정함 )
  • 상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달한다. ( JSON 혹은 XML을 통해 데이터를 주고 받는 것이 일반적 )

웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에,
웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다

HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고
HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.

웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.

CRUD Operation

  • Create : 생성(POST)
  • Read : 조회(GET)
  • Update : 수정(PUT)
  • Delete : 삭제(DELETE)
  • HEAD: header 정보 조회(HEAD)

1-2. REST API와 RESTful API

REST API는 URI로 접근가능하고 내용이 JSON,XML 등으로 표현된 자원에 대한 행위를 HTTP Method로 정의한다.

RESTful하다라는 것은 REST API의 설계의도를 명확하게 지켜주는 것이다. (슬래시를 통해 계층관계를 표시한다던가 숫자는 id를 나타낸다든가 동사보단 명사를 위주로 쓴다든가 하는.)

1-3. REST API가 무엇이고, 언제 사용하나요?

REST API란 자원의 상태를 주고받는 모든 것을 의미하는 REST의 원리를 따르는 API입니다.
업무에서는 의도하는 바가 명확하게 보이도록 자원을 요청하고 받을 때에 REST API를 사용합니다.

1-4. PATCH와 PUT의 차이

https://programmer93.tistory.com/39

2. TDD

2-1. TDD(Test Driven Development)란?

Test Driven Development의 약자로 ‘테스트 주도 개발’이라고 한다.
반복 테스트를 이용한 소프트웨어 방법론으로, 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

단위 테스트(Unit Test)란?
말 그대로 한 단위(일반적으로 class)만을 테스트하는 것

2-2. TDD 개발주기


  • Red 단계에서는 실패하는 테스트 코드를 먼저 작성한다.
  • Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
  • Yellow 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.

중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과,
실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다.
이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.

2-2. 일반 방식과의 차이점

  • 일반 방식

‘요구사항 분석 -> 설계 -> 개발 -> 테스트 -> 배포’ 형태의 개발 주기를 갖는다.

=> 작은 부분의 기능 수정에도 모든 부분을 테스트해야 하므로 전체적인 버그를 검출하기 어려워진다.

  • TDD 방식

가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다

=> 🔆 이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스코드가 간결해진다.

2-3. 장단점

장점

  • 보다 튼튼한 객체 지향적인 코드 생산
    • TDD는 코드의 재사용 보장을 명시하므로 TDD를 통한 소프트웨어 개발 시 기능 별 철저한 모듈화가 이뤄진다. 이는 종속성과 의존성이 낮은 모듈로 조합된 소프트웨어 개발을 가능하게 하며 필요에 따라 모듈을 추가하거나 제거해도 소프트웨어 전체 구조에 영향을 미치지 않게 된다.
  • 재설계 시간의 단축
    • 테스트 코드를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야하는지 분명히 정의하고 개발을 시작하게 된다. 또한 테스트 시나리오를 작성하면서 다양한 예외사항에 대해 생각해볼 수 있다. 이는 개발 진행 중 소프트웨어의 전반적인 설계가 변경되는 일을 방지할 수 있다.
  • 디버깅 시간의 단축
    • 이는 유닛 테스팅을 하는 이점이기도 하다. 예를 들면 사용자의 데이터가 잘못 나온다면 DB의 문제인지, 비즈니스 레이어의 문제인지 UI의 문제인지 실제 모든 레이러들을 전부 디버깅 해야하지만, TDD의 경우 자동화 된 유닛테스팅을 전재하므로 특정 버그를 손 쉽게 찾아낼 수 있다.
  • 테스트 문서의 대체 가능
    • 주로 SI 프로젝트 진행 과정에서 어떤 요소들이 테스트 되었는지 테스트 정의서를 만든다. 이것은 단순 통합 테스트 문서에 지나지 않는다. 하지만 TDD를 하게 될 경우 테스팅을 자동화 시킴과 동시에 보다 정확한 테스트 근거를 산출할 수 있다.
  • 추가 구현의 용이함
    • 개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드에 어떤 영향을 미칠지 알지 못한다는 것이다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전제하므로 테스트 기간을 획기적으로 단축시킬 수 있다.

단점

가장 큰 단점은 바로 생산성의 저하이다.

  • 개발 속도가 느려진다고 생각하는 사람이 많기 때문에 TDD에 대해 반신반의 한다. 왜냐하면 처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다. TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다.
  • SI 프로젝트에서는 소프트웨어의 품질보다 납기일 준수가 훨씬 중요하기 때문에 TDD 방식을 잘 사용하지 않는다.

TDD를 하기 어려운 이유?

이제까지 자신이 개발하던 방식을 많이 바꿔야 한다.

  • 몸에 체득한 것이 많을 수록 바꾸기가 어렵다.
  • 오히려 개발을 별로 해보지 않은 사람들에겐 적용하기가 쉽다.

TDD는 이렇게 해야된다는 이미지/틀이 있다.

  • 반드시 툴(단위 테스트 프레임워크)을 써서 개발해야 된다. 라고 생각한다.
  • 이러한 규칙에 얽매이는 것은 애자일 방식이 아니다.
  • 결국엔 규칙에 얽매여 똑같은 테스트를 copy&paste 한다.
  • 도구/규칙에 집착하다 보니, TDD가 어려워지는 것이다.

2-4. 요약

TDD는 테스트 주도 개발의 약자이고 테스트 케이스를 작성하고 테스트를 통과한 코드를 추가 및 개발해 나가는 것을 의미합니다.

TDD을 주도하는 개발을 할 수록 테스트 코드를 작성하면 작성하지 않은 것보다 업무가 더 오래걸릴 수도 있지만 장기적으로 볼때는 이슈를 최소화하여 더 효율적으로 업무를 진행할 수 있다고 생각합니다.

React에서는

참고

그 랜더링 흐름을 다 캡쳐해서 테스트 코드를 거쳐가게끔 테스트 코드를 짜는 것!

3. MVC 패턴


디자인 패턴 중 하나.

디자인 패턴이란?
프로그램이나 어떤 특정한 것을 개발하는 중에 발생했던 문제점들을 정리해서 상황에 따라 간편하게 적용해서 쓸 수 있는 것을 정리하여 특정한 규약을 통해 쉽게 쓸 수 있는 형태로 만든 것.

만약, 어떤 어플리케이션의 로직이 분리가 안되어있고 한꺼번에 정의가 되어있다면?
유지보수가 매우 골치아파질 것이다.
좀 더 쉽고 편리하게 사용할 수 있게 만든 특정한 방법이 바로 디자인 패턴이다.

3-1. MVC란?

MVC 는 Model, View, Controller의 약자이다.
하나의 애플리케이션, 프로젝트를 구성할 때 그 구성요소를 세가지의 역할로 구분한 패턴.

3-2. 모델 (Model)

애플리케이션의 정보, 데이터를 나타낸다.
데이터베이스, 처음의 정의하는 상수, 초기화값, 변수 등을 뜻한다.
또한 이러한 데이터와 정보들의 가공을 책임지는 컴포넌트를 말한다.

모델의 규칙

  • 1) 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
    • 화면안의 네모박스에 글자가 표현된다면, 네모박스의 화면 위치 정보, 네모박스의 크기정보, 글자내용, 글자의 위치, 글자의 포맷 정보 등을 가지고 있어야 한다
  • 2) 뷰나 컨트롤러에 대해서 어떤 정보도 알지 말아야 한다.
    • 데이터 변경이 일어났을 때 모델에서 화면 UI를 직접 조정해서 수정할 수 있도록 뷰를 참조하는 내부 속성값을 가지면 안 된다.
  • 3) 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야만 한다.
    • 모델의 속성 중 텍스트 정보가 변경이 된다면, 이벤트를 발생시켜 누군가에게 전달해야 하며, 누군가 모델을 변경하도록 요청하는 이벤트를 보냈을 때 이를 수신할 수 있는 처리 방법을 구현해야 합니다. 또한 모델은 재사용가능해야 하며 다른 인터페이스에서도 변하지 않아야 합니다.

3-3. 뷰 (View)

input 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타낸다.
다시 말해 데이터 및 객체의 입력, 그리고 보여주는 출력을 담당한다. 데이터를 기반으로 사용자들이 볼 수 있는 화면이다.

뷰의 규칙

  • 1) 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
    • 화면에 글자를 표시 하기 위해, 모델이 가지고 있는 정보를 전달받게 될텐데, 그 정보를 유지하기 위해서 임의의 뷰 내뷰에 저장하면 안됨.
    • 단순히 네모 박스를 그리라는 명령을 받으면, 화면에 표시하기만 하고 그 화면을 그릴 때 필요한 정보들은 저장하지 않아야 한다
  • 2) 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 된다.
    • 모델과 같은 자기 자신의 빼고는 다른 요소는 참조하거나 어떻게 동작하는지 알아서는 안된다.
    • 뷰는 그냥 데이터를 받으면 화면에 표시해주는 역할만 가지는 것
  • 3) 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
    • 모델과 같이 변경이 일어났을 때 이른 누군가에게 변경을 알려줘야 하는 방법을 구현해야 함.
    • 뷰에서는 화면에서 사용자가 화면에 표시된 내용을 변경하게 되면 이를 모델에게 전달해서 모델을 변경해야 한다.
    • 그 작업을 하기 위해 변경 통지를 구현한다.
    • 재사용 가능하게끔 설계를 해야 하며, 다른 정보들을 표현할 때 쉽게 설계를 해야 한다.

3-4. 컨트롤러 (Controller)

데이터와 사용자인터페이스 요소들을 잇는 다리역할.
즉, 사용자가 데이터를 클릭하고, 수정하는 것에 대한 “이벤트”들을 처리하는 부분을 뜻한다.

컨트롤러의 규칙

  • 1) 모델이나 뷰에 대해서 알고 있어야 한다.
    • 모델과 그에 관련된 뷰에 대해서 알고 있어야 한다
      • 모델이나 뷰는 서로의 존재를 모르고, 변경을 외부로 알리고 수신하는 방법만 가지고 있는데 이를 컨트롤러가 중재하기 위해
  • 2) 모델이나 뷰의 변경을 모니터링 해야 한다.
    • 모델이나 뷰의 변경 통지를 받으면 이를 해석해서 각각의 구성 요소에게 통지를 해야 한다
    • 애플리케이션의 메인 로직은 컨트롤러가 담당

3-5. MVC 패턴의 예시

그렇다면 MVC 패턴을 사용하는 프레임워크나 라이브러리는?

Angular JS, CodeIgniter, django, React

react는 mvc 패턴만을 사용하다가 flux 패턴도 사용한다.(redux)

react는 mvc 프레임워크는 아니고 View만 신경쓰는 라이브러리다.
다른 웹프레임워크와는 달리 ajax, 데이터 모델링, 라우팅 같은 것 없이 그저 뷰만 신경쓴다.

리액트는 단방향 데이터 흐름으로 데이터 변경에 관한 DOM객체만 변경해주는 체계로,

데이타가 변경되면 양방향 데이터 바인딩처럼 모델 변경 > 뷰변경이 아니라 특정함수를 실행시킴으로써 DOM객체를 갱신한다.

3-6. MVC 패턴 요약

MVC 패턴은 디자인 패턴 중 하나로 하나의 어플리케이션, 프로그램을 구성할 때에 그 구성요소를 세가지로 구분한 패턴입니다 MVC패턴이 필요한 이유? 프로젝트의 크기가 커지면 API가 늘어나게 되고 이것들을 처리하기 위한 로직이 길어져 가독성이 떨어진다 이 문제를 MVC 패턴을 기반으로 나누어 체계적으로 관리하기 위해서 입니다

=> 프로젝트를 체계적으로 관리하기 위해 사용한다!

간단하게 말하자면


  • Controller : 서버
  • Model : DB
  • View : 프론트엔드

서버가 View로 데이터를 보내고 => View가 다시 서버로 데이터 날리고 => 서버는 DB(모델)에 저장하고

참조

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html 출처: https://wooaoe.tistory.com/33 [개발개발 울었다]