나만의 언어로 CS 지식 정리하기 : 개발 관련 지식

2022년 10월 7일

#CS

1. 좋은 코드란?

‘좋은 코드’에 대한 정의는 사람들마다 다른 것 같습니다. 주로 공통적으로 언급되는 특징은 ‘읽기 쉬운 코드’, ‘중복이 없는 코드’, ‘테스트가 용이한 코드’라고 합니다.

제가 생각하기에 좋은 코드는 위와 같은 특징들을 갖춰 ’업무의 생산성‘을 높여주는 코드라고 생각합니다.

읽기 쉬운 변수명으로 해당 변수의 역할이 무엇일지 빠르게 파악하고, 중복되는 코드를 줄여 코드 변경시의 에러를 줄이는 등… 우선 업무에서 시간 절약이 가능합니다.

좋은 코드를 위해서는 팀만의 규칙, 즉 컨벤션을 분명히하고, 지속적인 리뷰를 통해 서로의 코딩컨벤션을 맞추는 것이 중요하다고 생각합니다.

2. 객체 지향 프로그래밍 (Object Oriented Programming)

객체를 중심으로 하는 프로그래밍 패러다임입니다. 여기서 객체는 현실 세계의 사물이라고 할 수 있습니다.

객체 지향 프로그래밍 이전의 프로그래밍 패러다임은 중심이 컴퓨터에 있었습니다. 컴퓨터가 사고하는대로 프로그래밍을 하는 것입니다.

객체지향 프로그래밍이란 인간 중심적 프로그래밍 패러다임이라고 정리할 수 있습니다. 현실 세계를 프로그래밍으로 옮겨와 프로그래밍하는 것입니다.

현실 세계의 사물들을 객체라고 보고 그 객체로부터 개발하고자 하는 애플리케이션에 필요한 특징들을 뽑아와 프로그래밍 하는 것이다. 이것을 추상화라고 합니다.

class MyClass:
    name = "Joy"
    def print(self, str):
        print(self.name, str)

x = MyClass()
x.print("Developer") # Joy Developer
x.name # Joy

객체 지향 프로그래밍 방식으로 코드를 작성하면 이미 작성한 코드에 대한 재사용성이 높습니다. 자주 사용되는 로직을 라이브러리로 만들어두면 지속적으로 사용할 수 있으며 신뢰성을 확보 할 수 있습니다.
또한 라이브러리를 각종 예외상황에 맞게 잘 만들어두면 개발자가 사소한 실수를 하더라도 에러를 컴파일 단계에서 잡아낼 수 있으므로 버그 발생이 줄어듭니다.
내부적인 동작을 몰라도 개발자는 라이브러리가 제공하는 기능들을 사용할 수 있기 때문에 생산성이 높아지게 됩니다.
객체 단위로 코드가 나눠져 작성되기 때문에 디버깅이 쉽고 유지보수에 용이합니다.
또한 데이터 모델링을 할 때 객체와 매핑하는 것이 수월하기 때문에 요구사항을 보다 명확하게 파악하여 프로그래밍 할 수 있습니다.

객체 지향적 설계 원칙

SRP(Single Responsibility Principle) : 단일 책임 원칙
- 클래스는 단 하나의 책임을 가져야 하며 클래스를 변경하는 이유는 단 하나의 이유이어야 한다.
OCP(Open-Closed Principle) : 개방-폐쇄 원칙
- 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.
LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
- 상위 타입의 객체를 하위 타입의 객체로 치환해도 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.
ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
- 인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.
DIP(Dependency Inversion Principle) : 의존 역전 원칙
- 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

3. RESTful API

REST란, REpresentational State Transfer 의 약자입니다. 여기에 형용사형 어미 ~ful을 붙여 ~한 API 라는 표현으로 사용됩니다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 ‘RESTful’하다라고 표현할 수 있다.

REST는 하나의 아키텍처로 볼 수 있습니다.(‘디자인패턴이다 vs 아키텍처이다’라는 이야기가 많이 존재한다고 합니다.)

REST 는 Resource Oriented Architecture 입니다(자원을 지향하는 아키텍처). API 설계의 중심에 자원(Resource)이 있고 HTTP Method 를 통해 자원을 처리하도록 설계하는 것입니다.

REST 6 가지 원칙

Uniform Interface
Stateless
Caching
Client-Server
Hierarchical system
Code on demand

RESTful 하게 API 를 디자인합시다! 는 무슨 뜻일까요?

리소스와 행위를 명시적이고 직관적으로 분리합니다.
- 리소스는 URI로 표현되는데 리소스가 가리키는 것은 명사로 표현되어야 합니다.
- 행위는 HTTP Method인, GET(조회), POST(생성), PUT(기존 entity 전체 수정), PATCH(기존 entity 일부 수정), DELETE(삭제) 으로 표현되어야 합니다.
Message 는 Header 와 Body 를 명확하게 분리해서 사용합니다.
- header에는? 애플리케이션 서버가 행동할 판단의 근거가 되는 컨트롤 정보인 API 버전 정보, 응답받고자 하는 MIME 타입 등을 header에 담습니다.
- body에는? Entity에 대한 내용은 body에 담습니다.
- header 와 body 는 http header 와 http body 로 나눌 수도 있고, http body 에 들어가는 json 구조로 분리할 수도 있습니다.
API 버전을 관리합니다.
- 환경은 항상 변하기 때문에 API 의 signature 가 변경될 수도 있음에 유의합니다.
- 특정 API 를 변경할 때는 반드시 하위호환성을 보장해야 합니다.
서버와 클라이언트가 같은 방식을 사용해서 요청하도록 합니다.
- 클라이언트에서는 form-data 형식의 submit 으로 보내고 서버에서는 json 형태로 보내는 식의 분리보다는, JSON 혹은 form-data 형식 중 하나로 통일합니다.

RESTful API 장점

Open API를 제공하기 쉽다
멀티플랫폼 지원 및 연동이 용이하다.
원하는 타입으로 데이터를 주고 받을 수 있다.
기존 웹 인프라(HTTP)를 그대로 사용할 수 있다.

RESTful API 장점

사용할 수 있는 메소드가 한정되어 있다.
분산환경에는 부적합하다.

4. TDD (Test Driven Development)

Test-Driven Development(TDD)는 매우 짧은 개발 사이클의 반복에 의존하는 소프트웨어 개발 프로세스입니다.

개발자는 요구되는 새로운 기능에 대한 자동화된 테스트케이스를 작성하고 해당 테스트를 통과하는 가장 간단한 코드를 작성한다. 일단 테스트 통과하는 코드를 작성하고 상황에 맞게 리팩토링하는 과정을 거치는 것이다. 테스트가 코드 작성을 주도하는 개발방식입니다.

TDD 장점은 개발자가 요구사항에 집중할 수 있게 해줍니다. 기능에 대한 요구사항에 대해 분명히 이해하고, 사용자 케이스, 스토리 등도 이해할 수 있도록 돕습니다.

새로운 기능을 개발할 때 무엇보다 안전합니다. feature 개발시 잘 작동하던 기능이 작동을 안하는 이슈, 이를 인식하지 못하는 이슈 등 다양한 이슈가 발생할 수 있습니다. 하지만 TDD는 이를 방지하도록 돕습니다.

TDD를 위한 코드 작성시, 코드량도 늘어나고, 짧은 주기의 테스트 사이클로 인해 생산성은 떨어진다는 의견이 있습니다. 코드의 퀄리티보다 빠른 작업물 도출이 중요할 때는 TDD 방식이 선호되지 않을 것 같습니다.

5. 함수형 프로그래밍

함수형 프로그래밍의 특징은 immutable data와 first citizen 으로서의 function 입니다.

immutable, 변경이 불가함을 의미합니다. 객체가 갖고 있는 값을 변경할 수 없음을 뜻하며, 값이 변경될 경우, 새로운 객체를 생성하고, 변경된 값을 주입해서 반환해야하는 것입니다.

first citizen 이란 일급 객체입니다.

일급 객체는 변수나 데이터 구조 안에 함수를 담을 수 있어, 함수의 파라미터로 전달할 수 있고, 반환값으로 사용할 수 있습니다.
할당에 사용된 이름과 관계없이 고유한 구별이 가능합니다
함수를 리터럴로 정의할 수 있습니다.

4. MVC 패턴

Model-View-Controller의 아키텍처입니다. 각각은 컴포넌트로 나누어져 각각의 역할을 수행합니다.

Model은 컨트롤러가 호출할 때, 요청에 맞는 역할 수행합니다. 비즈니스 로직을 구현하는 영역으로 데이터를 알맞게 처리하는 부분입니다. DB에 연결하고 데이터를 추출하거나, 저장, 삭제, 업데이트, 변환 같은 작업을 수행합니다. 상태 변화가 있을 대, 컨트롤러와 뷰에 알려주어 명령을 받을 수 있게 합니다.

View는 컨트롤러로부터 받은 모델의 결과값을 화면에 출력합니다. 만들어진 화면을 웹브라우저에 전송하는 것입니다. 사용자와의 상호작용을 위한 인터페이스를 표시하는 영역입니다.

Controller는 조정하는 영역이라고 정리할 수 있습니다. 클라이언트의 요청이 생기면, 그 요청에 대한 로직을 담당하는 모델 컴포넌트를 호출합니다. 모델에 전달하기 쉽게 데이터를 가공하고, 모델의 작업이 끝나면 결과를 뷰에 전달합니다.

5. Git 과 GitHub

Git은 버전 관리 시스템이며, GitHub는 버전 관리를 위한 프로젝트 저장소라고 정리할 수 있을 것입니다.

Git Flow 전략

최근 인턴 경험에서 해당 전략을 활용해 깃 버전 관리를 진행했던 경험이 있습니다 :)

branch는 feature > develop > release > hotfix > master 로 정리할 수 있고 이 중 중심은 master와 develop 브랜치입니다.

feature는 새로운 기능을 추가하는 브랜치입니다. develop으로부터 나오고, 반영됩니다.

release는 production의 릴리즈를 위한 브랜치입니다. develop으로부터 나오고, 릴리즈가 준비되었다고 생각하면 master로 머지하는 것입니다.

hotfix는 production에서 발생한 버그를 관리하는 브랜치입니다. master로부터 나오고, develop, master에 반영합니다.

GitHub Flow

브랜치와 PR 개념을 사용합니다. 자동화의 개념이 있습니다. 직관적이고 가볍다는 장점이 있습니다.

feature/~ 브랜치를 만든다.
파일을 추가하고 커밋을 한다.
feature/~ 브랜치를 원격 저장소에 Push한다.
GitHub에서 푸시 된 feature/~ 브랜치를 Pull Request한다.
GitHub에서 코드리뷰를 한다.
GitHub에서 Merge한다.
로컬 저장소에서 원격 저장소에 머지된 내용을 Pull한다.

GitLab Flow

Github flow는 너무 간단해서 배포, 릴리즈 등의 조금 복잡한 이슈를 보완하기 위해 나온 전략입니다. master, production 등 기존의 전략과 브랜치명이 혼동이 있을 수 있어 유의해야합니다.

feature
- 모든 기능 구현은 feature 브랜치에서 시작합니다. feature 브랜치는 master 브랜치에서 분기되고 머지됩니다.
master
- gitlab flow의 master 브랜치 역할은 git flow의 develop 브랜치와 동일합니다. master 브랜치는 feature 브랜치에서 병합된 기능에 대해 test를 진행합니다. 전체적인 테스트가 진행되어 기능에 대한 보장이 되었다면 production 브랜치로 머지합니다.
- 만약 staging 단계를 원한다면 pre-production 브랜치로 머지를 진행합니다.
production
- gitlab flow의 production 브랜치 역할은 git flow의 master 브랜치와 동일합니다. 테스트가 끝난 기능에 대해 배포를 하기 위한 브랜치입니다.
pre-production
- master → production 브랜치 사이에 pre-production 브랜치를 두어 변경 사항을 바로 production에 배포하지 않고 test server에 배포하여 통합 테스트를 진행하거나 시간을 두고 반영하는 브랜치입니다.