이론 정리 - < ETC > | 삐에로의 지식창고

좋은 코드

코드의 효율성으로만 따지자면 컴퓨터가 최소한의 처리를 할 수 있는 컴퓨터 친화적으로 최적화된 코드가 좋다고 생각이되지만..
코드의 활용성/범용성을 생각해보면 이 코드를 언제 누구든 수정할 수 있게 만드는 가독성도 중요하다고 생각이 된다

요약하자면 코드가 완성형이라는 가정이라면 최적화된 코드가 최고지만,
현실은 언제나 그럴 수 없기에 업무효율성을 생각한 가독성/유지보수성이 좋은 코드가 베스트라고 생각한다!

이러한 가독성/유지보수성을 올리기 위해선 프로젝트의 전체 흐름을 파악해 범용성을 늘리고,
함수나 변수명이 직관적으로 이해될 수 있을 정도의 이름으로 정해주고, 주석을 간결화해서 전체적 흐름을 한 눈에 읽기 쉽게 해야된다!

내 생각 속 좋은 코드를 짜기 위해선 여러 프로젝트 경험을 잘 기록해두며 빅데이터를 쌓는 게 중요할 것 같다!

객체 지향 프로그래밍(Object-Oriented Programming, OOP)

컴퓨터 프로그램을 명령어의 목록으로 보는 시각에서 벗어나 여러 개의 독립된 단위, 즉 “객체”들의 모임으로 파악하고자 하는 것으로 데이터를 추상화하여 상태와 행위를 가진 “객체”를 생성해 이 객체들 간의 유기적인 협력을 통해 프로그래밍을 진행하는 방법론이다.

추상화: 복잡성을 줄이고 필요한 정보만 보여줌
캡슐화: 데이터와 메소드를 하나의 단위로 묶어 외부에서의 접근을 제한함
상속: 기존 클래스의 특성을 새로운 클래스가 물려받아 코드 재사용을 촉진
다형성: 같은 이름의 메서드나 연산자가 다른 클래스에 대해 다른 동작을 하도록 하여 유연성을 높임
(오버로딩 / 오버라이딩)

형상 관리(Configuration Management)

소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 프로세스를 의미한다!

문서나 파일이 수정되었을 때 변경 내용을 기록하고 관리
나중에 이를 확인하고 변경 이유를 파악

대표적인 소프트웨어 형상 관리 도구로는 CVS / SVN / GIT 이 있다!

TDD(Test-driven Development)

소프트웨어 개발 방법론 중 하나로, 코드 작성 전에 먼저 테스트 코드를 작성하는 방식

TDD의 주된 목표는 정상적으로 작동하는 깔끔한 코드를 작성하는 것이며, 리팩토링 과정을 통해 코드의 품질을 높이고 중복을 제거하는 것이다!
(=> 미래에 대한 예측을 최대한 하지 않고,지속적으로 프로토타입을 완성 )

작은 단위의 간단한 실행 코드를 구현
실패하는 테스트 케이스를 작성
작성한 테스트를 통과하기 위한 최소한의 프로덕션 코드를 작성
테스트가 통과하면, 코드를 리팩토링하여 품질을 개선
추가 기능에 대해 반복적으로 위 과정을 진행

( 희망편 )

이러한 방식은 초반 구조설계에 큰 힘을 들이지 않고, 나중에 리팩토링을 하여 자원을 효율적으로 사용할 수 있다!
또한 디버깅을 기능별로 테스트할 수 있기 때문에 시간이 많이 단축된다

(절망편)

하지만 구현코드와 별개로 테스트용 코드도 작성 해야하고, 실패하는 케이스도 찾아야되기 때문에 투자대비 구현 효율이 단기적으론 나쁠 수 있다!

CI/CD

지속적 통합(Continuous Integration)과 지속적 배포(Continuous Delivery/Continuous Deployment)가 결합된 방법론으로, 애플리케이션 개발에서 배포까지의 과정을 자동화하여 효율성을 높이는 데 중점을 둠

대표적인 CI/CD 툴로는 Jenkins, Travis CI, CircleCI, GitLab CI 등이 있음

CI(Continuous Integration)

개발자가 애플리케이션에 적용한 변경 사항들이 병합된 후 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 빌드하고 다양한 수준의 자동화된 테스트(일반적으로 단위 테스트와 통합 테스트)를 실행하여 해당 변경 사항을 검증하는 것

CD(Continuous Delivery/Continuous Deployment)

코드 변경 사항의 병합부터 프로덕션 레디 빌드의 제공에 이르기까지 모든 단계에 테스트 자동화와 코드 릴리스 자동화가 수반되며, 이 프로세스가 종료되면 운영 팀은 애플리케이션을 프로덕션으로 신속하게 배포할 수 있음

MVC(Model - View - Controller)

소프트웨어 공학에서 사용자 인터페이스, 데이터, 논리 제어를 분리하기 위해 사용되는 디자인 패턴

Model

애플리케이션의 데이터와 비즈니스 로직을 담당
데이터베이스와의 상호작용, 데이터 검증, 데이터 처리 등을 포함
View와 Controller에 독립적으로 동작

View

사용자 인터페이스를 담당하며, 사용자에게 정보를 표시
Model의 데이터를 시각적으로 표현하고, 사용자 입력을 받음
Controller와 Model에 직접적으로 접근하지 않음

Controller

사용자의 입력을 받아 Model과 View 사이의 중재자 역할을 함
사용자의 요청을 처리하고, Model와 View를 갱신해줌
Model과 View를 연결하는 브릿지 역할

장점

코드의 재사용성과 유지보수성 향상
- Model, View, Controller로 분리된 구조는 코드의 재사용성을 높이고, 유지보수를 용이하게 하여 각 부분을 독립적으로 수정하거나 확장할 수 있음
개발 생산성 증가
- 개발자들이 특정 부분(예: 비즈니스 로직, UI 등)에 집중할 수 있어 협업이 용이함
- 병렬 개발이 가능하며, 작업 속도가 빨라짐
테스트 용이성
- 각 구성 요소가 독립적으로 동작하기 때문에 단위 테스트가 간편함
- 모델, 뷰, 컨트롤러를 개별적으로 테스트할 수 있음
유연성과 확장성
- 사용자 인터페이스와 비즈니스 로직을 분리함으로써 시스템의 유연성이 증가함
- 새로운 기능 추가나 기존 기능 수정이 용이함
명확한 역할 분담
- 각 구성 요소의 역할이 명확히 구분되어 있어 코드의 가독성이 높아짐
- 프로젝트의 구조를 이해하고 관리하기 쉬워짐

MVC vs MVVM(Model -View - ViewModel)

MVC 와 MVVM 은 중간역할을 해주는 Controller 와 ViewModel의 방식에 차이점이 있다!
Controller: Model과 View에 직접적으로 상호작용하여 값을 업데이트 해줌(= 결합성이 높음)
ViewModel: Model의 값을 읽어 View의 값에 데이터 바인딩을 해주어 간접적으로 작동하게함(= 결합성이 낮음)

HTTP / HTTP2

프로토콜 형식:
- HTTP: 텍스트 기반의 프로토콜로, 요청과 응답이 일반 텍스트로 이루어짐
  ( => 디버깅이 쉽지만, 성능 면에서 제한이 있음 )
- HTTP2: 바이너리 프레이밍을 사용하여 통신 속도를 높였음
  ( 바이너리 데이터를 사용함으로써 더 빠르고 효율적인 통신이 가능 )
멀티플렉싱:
- HTTP: 하나의 연결에서 하나의 요청만 처리할 수 있습니다. 여러 리소스를 요청할 때 지연이 발생할 수 있음
- HTTP2: 멀티플렉싱을 통해 하나의 연결에서 여러 요청과 응답을 동시에 처리할 수 있음
  ( => 페이지 로딩 시간을 단축하는 데 큰 도움이 됨 )
헤더 압축:
- HTTP: 헤더 정보가 압축되지 않고 전송되므로, 데이터 크기가 커질 수 있음
- HTTP2: HPACK 압축 알고리즘을 사용하여 헤더 정보를 압축함
  ( => 전송되는 데이터의 크기를 줄여 더 빠른 통신을 가능하게 함 )
서버 푸시:
- HTTP: 클라이언트가 요청한 리소스만 전송
- HTTP2: 서버 푸시 기능을 통해 클라이언트가 요청하지 않은 리소스를 미리 전송할 수 있음
  (=> 페이지 로딩 시간을 단축하는 데 도움이 됨 )
보안:
- HTTP: 기본적으로 암호화되지 않지만, HTTPS를 통해 암호화할 수 있음
- HTTP2: 대부분의 구현에서 HTTPS를 통해 암호화된 통신을 기본으로 지원함

Apache / NginX

Apache와 Nginx는 모두 강력한 웹 서버로, 각각의 장단점이 있음
성능 면에서는 Nginx가 일반적으로 더 우수하며, 특히 동시 접속 처리에 강점이 있습니다. 그러나 선택은 요구사항과 우선순위에 따라 달라질 수 있음
Apache는 사용자 정의 및 모듈 지원이 강력하여 여러 기능을 쉽게 추가할 수 있는 반면, Nginx는 정적 파일 제공과 연결 관리에 더 효율적입니다.