View
0
Download
0
Category
Preview:
Citation preview
애자일 프로그래밍
남기룡(birdkr@gmail.com)
Agenda
애자일이란?
애자일 설계설계의 악취설계 원칙 ? SRP, OCP, LSP, DIP, ISP
TDD(Test Driven Development)TDD란?
Tips
시연
애자일이란?
애자일 선언문프로세스와 툴 -> 개인과 상호작용
포괄적인 문서 -> 동작하는 소프트웨어
계약 협상 -> 고객 협력
계획을 따르는 것 -> 변화에 대한 대응
변하지 않는 것은 없다
변하지 않는 유일한 진리 = 변하지 않는 것은 없다요구사항은 끊임없이 변한다.
게임은 만들어봐야 재미있는지 안다.
핵심은 변화에 기민하게 대응하는 것
고객과 많은 의사소통
유연한 설계
테스트
지속적인 통합
피드백
설계
애자일 설계
먼 미래를 위해 계획하거나 생각하지 않는다. No CFTL(Code First, Think Later)큰 그림은 소프트웨어와 함께 발전한다.좋은 디자인 = 유연한 소프트웨어디자인 방법
요구사항 수집 -> 도메인 분석 -> 사전 설계 -> 구현(테스트)반복적인 개발
로우 테크(low-tech) 설계변경을 예측하여 변경에 대비변경을 인정하여 쉽게 적응할 수있도록 단순하게 설계
설계의 악취
경직성(Rigidity) - 설계를 변경하기 어려움
취약성(Fragility) - 설계가 망가지기 쉬움
부동성(Immobility) - 설계를 재사용하기 어려움
점착성(Viscosity) - 제대로 동작하기 어려움
불필요한 복잡성(Needless Complexity) - 과도한 설계
불필요한 반복(Needless Repetition) - 마우스남용
불투명성(Opacity) - 혼란스러운 표현
설계 원칙
SRP ? 단일 책임 원칙(Single Responsibility Principle)
OCP - 개방-폐쇄 원칙(Open-Closed Principle)
LSP - 리스코프 교체 원칙(Liskov Substitution Principle)
DIP - 의존 관계 역전 원칙(Dependency Inversion Principle)
ISP - 인터페이스 격리 원칙(Interface Segregation Principle)
SRP(Single Responsibility Principle)
단일 책임 원칙
객체는 하나의 책임만을 맡아야 한다.
책임 = 변화의 축(산탄총 수술)
SRP 예시
국제적 은행의 계좌 관리 케이스
SRP 예시
+이자율계산()
InterestRate
+환율계산()
ExchangeRate
+환율계산()
ExchangeRateJapan
+환율계산()
ExchangeKorea
+환율계산()
ExchangeRateUS
+입금()+출금()+조회()+환율계산()
-잔고
Account
OCP(Open Closed Principle)
개방-폐쇄 원칙 소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에는열려 있어야 하고, 변경에는 닫혀 있어야 한다.
OCP
OCP
OCP
상속을 통한 다형성을 이용한 호출
Command Pattern
LSP(Liskov Substitution Principle)
리스코프 치환 원칙
기반 클래스는 서브 클래스로 대체 가능해야 한다.
Is-A 관계
잘못된 상속 관계
DIP(Dependency Inversion Principle)
의존 관계 역전의 법칙
클라이언트는 구체 클래스가아닌 인터페이스나 추상 클래스에 의존해야 한다.
Don¡t call us, we¡ll call you
Template Method Pattern
ISP(Interface Segregation Principle)
인터페이스 분리의 원칙
클라이언트에게 특화된 여러 개의 인터페이스가 하나의 범용 인터페이스보다 낫다.
ISP 적용 전
ISP 적용 후
테스트
테스트 유형
스토리 테스트비즈니스 의도(제품 설계)
사용성 테스팅탐색적 테스팅
단위 테스트개발자 의도(코드 설계)
특성 테스팅보안 테스팅부하 테스팅조합 테스팅
¡
자동
자동
수동
도구
UnitTest++
UnitTest 프레임워크
개발자 : Noel Llopis(게임 개발자)
장점작으면서도 테스트에 필요한 모든 기능이 있다.
쉽고 간단하다.
이식성이 좋음
UnitTest++ 기능
TEST()SUITE()CHECK()CHECK_CLOSE()CHECK_ARRAY_EQUAL()FIXTURETimeConstraint
UnitTest ExampleTEST(PlayerJumpTest){
const vec3 player_pos = vec3(1000,1000,0);World world;world.Create();Player player;player.Create(world, player_pos);player.Jump();player.Update(0.1f);
CHECK(player.GetPosition().z > 0);CHECK(player.GetAni() == ANI_JUMP);
}
TEST(ShieldCanBeDamaged) {
Player player;player.SetHealth(1000);Shield shield;shield.SetHealth(100);player.Equip(shield);player.Damage(200);
CHECK(shield.GetHealth() == 0);CHECK(player.GetHealth() == 900);
}
TDD(Test Driven Development)
TDD != Test
장점 단순함과 모듈화
안전망
즉각적인 피드백
문서화
과정1. 재빨리 테스트를 하나 추가한다.
2. 테스트를 실행시켜 새로 추가한 녀석이 실패하는 걸 확인한다.
3. 코드를 약간 수정한다.
4. 테스트를 실행시켜 모두 성공하는지 확인한다.
5. 중복을 제거하기 위해 리팩터링한다.
불과불과 몇몇 분밖에분밖에걸리지걸리지 않는다않는다..
테스트테스트 실패실패
테스트테스트 통과통과테스트테스트 통과통과
체크 인
체크 인
TDD의 순환과정
TEST (ShieldLevelStartsFull){
Shield shield;CHECK_EQUAL (Shield::kMaxLevel, shield.GetLevel());
}
TEST (ShieldLevelStartsFull){
Shield shield;CHECK_EQUAL (Shield::kMaxLevel, shield.GetLevel());
}Shield::Shield() : m_level (Shield::kMaxLevel){}
Shield::Shield() : m_level (Shield::kMaxLevel){}
테스트작성
코드 작성
리팩토링
TDD 시연
Tips #1
Mock ObjectDevice, Socket, DB
김밥 썰기와 해체 하기
Tips #2
단위 테스트는 매 빌드마다 항상 검사하라디버깅할 때에 단위 테스트를 사용하라테스트를 자동화하라.
처음부터 많은 것을 테스트하려 하지말고, 현실적으로 가능한 것부터 하라.
처음에는 과도할 정도로 클래스를 나눠라.
초반에는 개발 속도가 떨어지지만, 익숙해지면개발 속도가 빨라진다.
팀원들이 동의하지 않으면 혼자서라도 시작하라.(#ifdef _USING_TDD)
리팩토링을 습관화하라.
CODE
자동화
원클릭 빌드
예약 빌드
빌드 결과
테스트
피드백
일일 회의
이슈 시스템
애자일 프로그래머의 하루
출근새벽에 자동으로 테스트된 결과 확인아침 일일 회의개발짝 프로그래밍TDD
리팩토링코드 리뷰커밋
퇴근
정리
변화에 기민하게 대응하자.
알고 있는 것은 중요하지 않다. 실천하자!
습관적으로 설계하고 테스트하고 리팩토링해야 한다.
추천 서적
Head First Object-Oriented Analysis & Design(한빛미디어)
테스트 주도 개발(인사이트)
애자일 프랙티스(인사이트)
실용주의 프로그래머(인사이트)
익스트림 프로그래밍(인사이트)
Ship it,성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드(위키북스)
Q & A
Recommended