개발 CS지식 정리 - #TDD #MVC패턴

진형욱·2022년 11월 7일
0

개발면접공부

목록 보기
1/8
post-thumbnail

개발 cs지식 스터디를 하며 내가 학습한 부분을 정리하는 공간입니다.

개발상식

TDD

테스트 기반 개발 - 한 번에 한 걸음씩 우물을 파는 것과 같습니다.


TDD란 무엇이며, 어떠한 장점이 있는가?

TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다.

설계 이후 코드 개발 및 테스트케이스를 작성하는 기존의 개발 프로세스와는 다르게

테스트 케이스를 작성 한 후 실제 코드를 개발하여 리펙토링 하는 절차를 따른다.

이러한 이유로 TDD를 Test First Development라고 부른다.

TDD는 작가가 책을 쓰는 과정과 유사하다.

목차를 처음 구상하고 목차에 맞는 내용을 고쳐쓰기를 반복한다.

이 과정을 TDD에 비유하면

  1. 목차구성 => "테스트코드 작성"
  2. 초안작성 => "코드개발"
  3. 고쳐쓰기 => "코드수정"에 해당한다.

반복적인 검토와 고쳐쓰기를 통해 좋은 글이 완성되는 것처럼
소프트웨어도 반복적인 테스트와 수정을 통해 고품질의 소프트웨어를 만들 수 있다.

일반적인 개발 방식과 TDD의 가장 큰 차이는
테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 점이다.

디자인(설계) 단계에서 프로그래밍 목적을 반드시 미리 정의해야만 하고,
또 무엇을 테스트해야 할지 미리 정의(테스트 케이스 작성)해야만 한다.


테스트 주도 개발(Test-Driven-Development, 이하 TDD)의 저자
켄트 벡 - “테스트 없이 프로그래밍하면 확신이 덜 생기고 시간은 더 걸린다.

TDD를 어떤 상황에서 해야할까?

  1. 처음해보는 프로그램 주제
  • 나에 대한 불확실성이 높은 경우
  • 내가 가진 불안감과 코드에 대한 확신을 테스트로 보증 할 수 있다.
  1. 고객의 요구조건이 바뀔 수 있는 프로젝트
  • 외부적인 불확실성이 높은 경우
  1. 개발하는중 코드를 많이 바꿔야 된다고 생각하는 경우

  2. 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우

  • 외부적인 불확실성

즉 ! 불확실성이 높을때 TDD를 하면 된다.


TDD의 효과

  1. 디버깅 시간을 단축

  2. 코드가 내 손을 벗어나기 전 가장 빠르게 피드백을 받을 수 있다.
    (기능 단위로 테스트를 진행하기 떄문)

  3. 작성한 코드가 가지는 불안정성을 개선하여 생산성을 높일 수 있다.

  4. 재설계 시간을 단축(게임에서 말하는 Life를 비축한 느낌)

  5. 추가 구현이 용이

TDD의 단점

  1. 코드량이 늘어난다 => 생산성의 저하 =>
    빠른 생산성이 요구되는 시점에서는 큰 걸림돌이 된다.
    (기존의 비즈니스 로직, 각종 코드 디자인 + 테스트 코드 작성)

  2. 주객전도
    실제 코드가 더 중심이 되어야 하는데,
    테스트를 위해 코드의 구조를 바꿔야하나 고민이 생긴다.

    발생할 수 있는 상황에 대한 코드를 작성하기 위해 배보다 배꼽이 더 커진다.

Summary

다양한 사용자가 존재하며, 생각지도 못한 예외 케이스가 존재할 수 있다.
테스트를 반드시 해야 하는 부분에 있어서 테스트 코드를 작성하는데
여러 난관이 겪는다면?
모든 코드에 대해서 테스트 코드를 작성할 수 없으며 작성할 필요도 없다.
또한 테스트 코드를 작성한다고 해서 버그가 발생하지 않는 것도 아니다!


MVC 패턴

MVC 패턴이란 무엇인가?

디자인패턴 중 하나로 MVC(Model-View-Controller)는 사용자 인터페이스, 데이트 및 논리 제어를 구현하는데 널리 사용되는 디자인 패턴이다.

소프트웨어의 비즈니스 로직과 화면을 구분하는데 중점을 두고 있다.

User가 Controller를 조작하면 Controller는 Model를 통해서 데이터를 가져오고, 그 정보를 바탕으로 View를 시각적 표현을 제어하여 사용자에게 전달한다.

Model

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

Model의 규칙

  1. 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
  2. 뷰나 컨트롤러에 대해 어떤 정보인지 알지 말아야 한다.
  3. 변경이 일어나면, 변경 통지에 대한 처리 방법을 구현해야 한다.

View

input text, checkbox 등 사용자 인터페이스 요소를 나타낸다.
즉, 데이터 및 객체의 입력, 보여주는 출력을 담당한다.
(데이터를 기반으로 사용자들이 볼 수 있는 화면)

View의 규칙

  1. 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
  2. 모델이나 컨트롤러와 같이 다른 구성요소들을 몰라야 한다.
  3. 변경이 일어나면 변경통지에 대한 처리방법을 구현해야 한다.

Controller

사용자가 접근한 URL에 따라 사용자의 요청사항을 파악 ->
그 요청에 맞는 데이터를 Model을 의뢰 ->
데이터를 View에 반영 -> 사용자에게 알려준다.

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

Controller의 규칙

  1. 모델이나 뷰에 대해 알고 있어야 한다.
  2. 모델이나 뷰의 변경을 모니터링 해야한다.

왜 MVC패턴을 사용해야 할까?

사용자가 보는 페이지, 데이터처리 그리고 이 2가지를 중간에서 제어하는 컨트롤
이 3가지로 구성되는 하나의 애플리케이션을 만들면 각각 맡은바에만 집중을 할 수 있게 된다. (ex. 공장의 분업화)

서로 분리되어 각자의 역할에 집중할 수 있게끔해 애플리케이션을 만든다면
유지보수성, 애플리케이션 확장성, 유연성이 증가하고 중복코딩이라는 문제점 또한 사라진다.

유연성 : 클라이언트의 새로운 요구사항에 대한 최소한의 비용으로 대체

MVC 패턴의 예시

  • Google의 Angular JS
  • PHP의 CODEIGNITER
  • Python의 django
  • Facebook의 React

MVC의 기반을 둔 다른 디자인 패턴

  • MVVM(Model View ViewModel)
  • MVP(Model View Presenter)
  • MVW(Model View Whatever)

Summary

Model - 백그라운드에서 동작하는 비즈니스 로직(데이터) 처리

View - 정보를 화면으로 보여주는 역할

Controller - 사용자의 입력 처리와 흐름 제어 담당.
화면과 Model과 View를 연결시켜주는 역할

결국 "어떻게 나눌 것인가" 에 대한 해답 중 하나이다.

어떤 특정한 역할들에 대해 역할분담을 할 때 가이드라인을 제시하는 방법중 하나가 MVC패턴이다.

profile
90% of my problems magically disappeared when I slept well, ate well and went on regular walks

0개의 댓글