Day_12. 애자일 S/W만들기

애자일에서 단위 Test 가 필요한 이유
=개발자가 의도한대로 S/W 가 개발이 완료 되었음을 증명한다
=S/W 변경이 발생해도 자동화된 단위 test로 회귀 Test 가 가능하다


s/w설계시 중요한 개념 2 가지 – 습관화 시켜야 한다
=네이밍 – 클래스나 모듈의 이름을 확장성을 고려해서 지어라 (common,util 같은 이름은 나쁨 추상적으로 지으면 안된다)
=단위 Test를 할 줄 알아야 한다 – Test를 위해 Modual 을 나누게 된다 - >테스트를 위한 Design 을 만들어 낸다


단위 Test의 특징
=단위 Test는 자동화 되어야 한다


자동화 되어 실행하기 쉬운 단위 Test의 혜택
=즉각적 피드백
=회귀 Test 비용을 낮춘다
=디버깅 시간의 단축
=개발팀이 자신있게 배포하게 도와줌


Chp 13 – 리팩토링 – 기술적 부채 갚기
=단위 Test 완료 후 리팩토링 – Safety net의 구성
=모듈이 정상적으로 동작 되는 것을 확인 후 코드를 개선 하는 것


정의
=겉으로 보이는 변화에는 변화를 주지 않으면서 조금씩 점진적으로 설계를 향상 시킨다
= 단위 Test와 Refactoring 은 필수로 해야 애자일임


애자일의 특징
=기능개발(무조건) -> 단위Test -> Refactoring -> commit ->기능개발(반복)


*리팩토링이 하고싶은 마음이 들게 되어야 한다*
=Code의 bad small 이 나야 한다
=나쁜 코드인지 판단하는 능력이 필요 하다


Chp-14 - Test주도 개발 – Test Driven Development

작동의 원리
=실패하는 단위 Test를 먼저 쓴다 = 코드로 성취하고자 하는 것을 먼저 작성한다
=단위 Test를 통과하기 위한 code를 추가 한다
=리팩토링 한다
==반복한다 – 통상 1.5배의 시간이 더 소요 된다


Chp – 15 – 지속적 통합의 준비 – CI, Continous Integrited

정의
=s/w의 출시를 언제나 대비하는 문화
=매일매일 Build 한다


지속적 시스탬 구축에 필요한 사항
=코드 저장소 (Repository , GIT, SVN)
=체크인 프로세스
=빌드 자동화- Build Script도 git에 저장해서 version관리
=작은 단위로 일하려는 마음가짐
=적어도 1일 1build 의 습관을 가져가


애자일 s/w의 흐름

단위 Test	->	TDD의 실현	->	지속적 통합 CI
+
Refactoring