소프트웨어 공학 — 좋은 코드와 좋은 프로젝트의 원칙
소프트웨어 개발 생명주기 (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(적음)
OIYO 편집부
편집부OIYO 편집부는 경제·법률·생활·자기이해 주제를 1차 자료와 공개 통계로 검증해 정리합니다. 모든 글은 출처 표기와 정기 점검을 거쳐 실용성과 정확성을 함께 유지합니다.