소프트웨어 공학 — 좋은 코드와 좋은 프로젝트의 원칙

소프트웨어 개발 생명주기 (SDLC)

요구사항 분석 → 설계 → 구현 → 테스트 → 배포 → 유지보수

주요 방법론:
워터폴: 단계 순차 완료 (요구사항 명확할 때)
애자일: 짧은 스프린트, 빠른 피드백 (변화 잦을 때)
DevOps: 개발+운영 통합, CI/CD 자동화

---

객체지향 프로그래밍 (OOP) 4원칙

캡슐화 (Encapsulation):
→ 데이터와 메서드를 하나의 단위로 묶음
→ 내부 구현 숨기기 (private)
→ 공개 인터페이스만 노출 (public)

상속 (Inheritance):
→ 부모 클래스의 속성·메서드 재사용
→ 코드 중복 감소, IS-A 관계

다형성 (Polymorphism):
→ 같은 인터페이스, 다른 구현
→ 오버라이딩: 부모 메서드를 자식이 재정의

추상화 (Abstraction):
→ 불필요한 세부 사항 숨기기
→ 인터페이스 / 추상 클래스로 구현

---

SOLID 원칙

좋은 객체지향 설계를 위한 5가지 원칙:

S — 단일 책임 원칙 (Single Responsibility):
→ 클래스는 단 하나의 변경 이유만 가져야 함
→ "이 클래스가 너무 많은 일을 하진 않는가?"

O — 개방-폐쇄 원칙 (Open-Closed):
→ 확장에는 열려 있고, 수정에는 닫혀 있어야 함
→ 새 기능 추가 시 기존 코드 변경 최소화

L — 리스코프 치환 원칙 (Liskov Substitution):
→ 자식 클래스는 부모 클래스를 대체할 수 있어야 함

I — 인터페이스 분리 원칙 (Interface Segregation):
→ 클라이언트가 사용하지 않는 메서드에 의존 강제 금지
→ 큰 인터페이스 → 작은 인터페이스들로 분리

D — 의존성 역전 원칙 (Dependency Inversion):
→ 고수준 모듈이 저수준 모듈에 의존 금지
→ 추상화(인터페이스)에 의존

---

디자인 패턴

반복적인 설계 문제에 대한 검증된 해결책:

생성 패턴:
싱글톤(Singleton): 인스턴스 1개만 보장 (DB 연결)
팩토리(Factory): 객체 생성 로직 분리
빌더(Builder): 복잡한 객체 단계적 구성

구조 패턴:
어댑터(Adapter): 호환되지 않는 인터페이스 변환
데코레이터(Decorator): 기능을 동적으로 추가
프록시(Proxy): 대리인 역할로 접근 제어

행동 패턴:
옵서버(Observer): 이벤트 구독-발행 (pub/sub)
전략(Strategy): 알고리즘을 캡슐화해 교체 가능
커맨드(Command): 요청을 객체로 캡슐화

---

테스트 종류

단위 테스트 (Unit Test):
→ 함수·메서드 단위 테스트
→ 빠르고 독립적
→ TDD: 테스트 먼저 작성 후 코드 구현

통합 테스트 (Integration Test):
→ 여러 컴포넌트 조합 테스트
→ DB, 외부 API와의 연동 확인

E2E 테스트 (End-to-End):
→ 사용자 시나리오 전체 테스트
→ 느리지만 가장 현실적

테스트 피라미드:
단위(많고 빠름) > 통합(중간) > E2E(적고 느림)

---

버전 관리 (Git)

핵심 명령어:
git init / clone: 저장소 초기화/복제
git add / commit: 변경사항 스테이징/커밋
git push / pull: 원격 저장소 동기화
git branch / checkout: 브랜치 관리
git merge / rebase: 브랜치 병합

브랜치 전략 (Git Flow):
main: 배포 가능한 안정 버전
develop: 개발 통합 브랜치
feature/*: 기능 개발
hotfix/*: 긴급 버그 수정

---

핵심 암기 포인트

OOP 4원칙: 캡슐화·상속·다형성·추상화 SOLID: 단일책임·개방폐쇄·리스코프·인터페이스분리·의존성역전 디자인 패턴 3분류: 생성(Singleton)·구조(Adapter)·행동(Observer) 테스트 피라미드: 단위(많음) > 통합 > E2E(적음)