한빛출판네트워크

1. 훌륭한 소프트웨어 개발하기
고객을 기쁘게 하라

Tom"s Trails을 온라인으로
거의 모든 프로젝트에는 두 가지 중요한 고민이 있습니다.
개발에 대한 빅뱅(Big Bang)식 접근
2주가 지났습니다.
빅뱅 개발은 보통 큰 혼란(BIG MESS)으로 끝이 납니다.
훌륭한 소프트웨어 개발이란...
이터레이션으로 목표 달성하기
각 이터레이션은 작은 프로젝트와 같습니다.
이터레이션이 품질 좋은 소프트웨어를 만듭니다.
고객의 마음은 변합니다.
수정을 어떻게 하느냐는 여러분에게 달려있습니다.
여러분은 이미 오랫동안 개발을 진행해 왔습니다.
이터레이션은 변화를 자동으로 (그것도 잘) 관리합니다.
여러분의 소프트웨어는 출시 될 때까지 완료된 게 아닙니다.
소프트웨어 개발도구 상자 활용하기

2. 요구사항 수집하기 
  고객이 원하는 것을 알아내야 합니다

오리온 우주투어 차세대 프로젝트
고객에게 더 많은 정보를 달라고 말하세요.
고객과의 블루스카이
때로는 블루스카이를 진행하는 게 아래처럼 될 수 있습니다.
사람들이 정말로 원하는 것을 찾아보세요.
여러분의 요구사항은 고객지향적 이어야 합니다.
고객 피드백으로부터 요구사항 확장하기
사용자 스토리로 프로젝트에서 무엇을 해야 하는지를 정의하고... 
언제 정의해야 하는지를 알 수 있습니다.
짤막한 대화
계획 포커 게임
가정은 살아있는 동안 재판을 받습니다.
오래 걸리는 사용자 스토리 추정은 잘못된 추정입니다.
계획 포커의 목적은 의견 수렴입니다.
이터레이션 주기를 추정하는 것에 대한 요구사항
마지막으로, 전체 프로젝트에 대해 추정할 준비가 되었습니다.

3. 프로젝트 계획하기
성공을 위한 계획

고객은 바로 지금 자신들의 소프트웨어를 갖길 원합니다.
고객과 함께 우선순위 정하기
마일스톤 1.0에 뭐가 있는지 알게 되었습니다.
기능이 맞지 않으면 우선순위를 재조정합니다.
사람을 더 투입하면 더 큰 성과가 날까요?
적정 수준의 마일스톤 1.0을 위해 일하세요.
이터레이션은 짧고 달콤해야 합니다.
게획을 현실과 비교하기
개발속도는 추정 값에서 부담되는 부분을 책임집니다.
프로그래머는 꿈결 같은 시간을 생각합니다.
개발자는 현실적인 시간을 생각합니다.
언제 이터레이션이 너무 길어지나요?
이터레이션 들어가기 전에 개발속도 반영하기
평가를 위한 시간
[피곤하게 하는] 고객 다루기
벽에 커다란 현황판을 만드세요.
팀의 생기를 없애는 방법

4. 사용자 스토리와 태스크
실제로 일을 시작해 봅시다

iSwoon을 소개합니다.
태스크의 합이란 무엇을 의미할까요?
남은 작업 구성하기
현황판에 태스크 붙이기
태스크상의 일 시작하기
태스크는 진행 중 영역에 있을 때만 진행되고 있는 겁니다.
만약 동시에 두 가지 일을 한다면 어떻게 될까요?
첫 번째 스탠드업 미팅...
태스크 1: Date 클래스 생성하기
스탠드 업 미팅: 다섯 번째 날, 첫 주의 마지막...
스탠드 업 미팅: 두 번째 주, 두 번째 날...
이번 장의 훼방꾼이 나타났어요. 
계획되지 않은 태스크를 추적해야 합니다.
계획하지 않은 태스크가 소멸 비율을 증가시킵니다.
속도가 도움이 됩니다만... 
할 일이 많이 남았습니다. 
...하지만 우리가 어디에 있는지를 정확히 알고 있습니다.
노출된 속도

5. 충분히 구현 가능한 좋은 설계
훌륭한 설계로 작업하기

iSwoon이 심각한 문제에 빠졌습니다.
이 설계는 단일 책임 원리를 따르지 않습니다.
설계에서 다중 책임을 갖는 곳 찾기
다중 책임을 단일 책임으로 전환하기
설계는 SRP를 준수해야 합니다. 또 DRY도 준수해야 합니다.
리팩토링 후 스탠드업 미팅
계획되지 않은 태스크도 태스크일 뿐입니다.
데모 자체도 태스크의 일부입니다.
모든 것이 완료되면, 이터레이션은 끝이 납니다.

6. 버전 관리
안전한 개발

새로운 계약을 따냈습니다 - 비트박스 프로
그리고 계속해서 GUI 작업...
고객에게 새로운 비트박스 선보이기
버전 관리를 시작합시다.
먼저 여러분의 프로젝트를 설치합니다.
...이제 코드를 체크인 또는 체크아웃할 수 있습니다.
대부분의 버전 관리 도구가 여러분이 직면한 문제를 해결해 줄 것입니다. 
서버는 수정사항을 자동으로 합치려 합니다. 
버전 관리 소프트웨어가 변경사항을 합칠 수 없으면 충돌이 발생했음을 알립니다. 
이터레이션이 많아지면 사용자 스토리도 많아집니다. 
우리는 소프트웨어에 대해 하나 이상의 버전을 갖고 있습니다. 
좋은 커밋 메시지는 예전 소프트웨어를 찾기 쉽게 해줍니다. 
이제 1.0 버전을 체크아웃할 수 있습니다. 
(긴급) 스탠드업 미팅 
여러분의 버전에 태그를 생성하세요. 
태그, 브랜치, 트렁크... 아이고! 
1.0 버전 수정하기.. 이번엔 실제 상황입니다.
이제 두 개의 코드 기반을 갖게 되었습니다. 
언제 브랜치를 사용하면 안될까요? 
BeatBox Pro 1.x브랜치 관리를 잘 하려면 
버전관리는 다음과 같은 작업을 수행합니다. 
버전관리는 여러분의 코드가 실제로 작동하는지 보장하지 않습니다.  
소프트웨어 개발 도구상자 활용하기

6.5작성한 코드 빌드하기
b 슬롯 안에 있는 a 탭을 넣으세요

개발자는 기억력 좋은 독자가 아닙니다.
한 번에 프로젝트 빌드하기
앤트(Ant): 자바 프로젝트를 위한 빌드 도구
프로젝트(proejct), 프로퍼티(property), 타겟(target), 태스크(task) 엘리먼트
좋은 빌드 스크립트...
좋은 빌드 스크립트는 기본 사항 외에 더 많은 것을 수행합니다.
빌드 스크립트도 코드입니다.
신입 개발자는 두 가지를 얻었습니다.
소프트웨어 개발 도구상자 활용하기

7. 테스트와 지속적인 통합
코드 분해하기

모든 것은 항상 잘못될 수 있습니다.
시스템을 바라보는 시각에는 3가지가 있습니다.
블랙박스 테스트는 입출력 값에 집중합니다.
그레이박스 테스트는 보다 코드 안쪽을 살펴봅니다.
화이트박스 테스트는 구현코드 내부를 확인합니다.
한 번에 모든 것을 테스트하기
테스트 프레임워크에서 테스트 자동화하기
테스트를 실행하기 위해 프레임워크 사용하기
크루즈컨트롤(Cruise Control)의 CI 사이클
테스트는 코드가 정상적으로 작동하는 것을 보장합니다. 맞나요?
모든 코드를 테스트한다는 것은 모든 분기문을 테스트한다는 의미입니다.
무엇이 테스트되었는지 알기 위해서 커버리지 리포트를 사용하세요.
높은 커버리지률을 갖는 것이 항상 쉬운 것은 아닙니다.
개발 환경에서 버전 관리 도구가 하는 것들
소프트웨어 개발 도구상자 활용하기

8. 테스트 주도 개발
코드는 항상 설명하기 쉽게 작성하세요

테스트는 나중에 하는 것이 아니고 처음부터 하는 것입니다.
그래서 처음부터 테스트를 수행할 예정입니다.
테스트 주도 개발(TDD)에 온 것을 환영합니다.
여러분의 첫 번째 테스트...
… 끔찍하게 실패한다는 것입니다.
테스트를 녹색으로 변경하기
적색, 녹색 그리고 리팩토링...
TDD에서 테스트는 여러분의 개발을 이끌어 줍니다.
테스크를 완료했다는 것은 필요한 모든 테스트를 했고 모두 통과했다는 의미입니다.
테스트를 통과하면 바로 다음으로 넘어가세요!
간결함이란 의존성을 최대한 제거하는 것입니다.
항상 테스트 가능한 코드를 작성하세요.
테스트 하기 어려우며 설계내용을 살펴보세요.
전략 패턴을 이용하면 하나의 인터페이스를 다양하게 구현할 수 있습니다.
테스트용 코드는 테스트 클래스에서 관리하세요.
테스트는 더 나은 코드를 만듭니다.
테스트가 많아질수록 코드도 더 늘어납니다.
전략 패턴은 결합도를 낮추고, 객체화 합니다.
다양하지만 유사한 객체가 필요합니다.
이미 객체를 생성했다면 어떨까요?
목(Mock) 객체는 실제 객체를 대체합니다.
목 객체는 실제 객체를 대신해서 동작합니다.
좋은 소프트웨어는 테스트할 수 있습니다.
녹색으로 만들기는 쉬운 일이 아닙니다.
테스트 주도 개발자의 하루...
소프트웨어 개발 도구상자 활용하기

9. 이터레이션의 마무리
모든 것이 다 잘 되어갑니다


이터레이션이 이제 막 완성되려고 합니다.
...그러나 여러분이 할 수 있는 것이 많이 남아 있습니다.
시스템 테스트는 반드시 해야 합니다.
...그런데 누가 시스템 테스트를 하죠?
시스템 테스트는 테스트할 완전한 시스템이 있어야 합니다.
좋은 시스템 테스트는 두 개의 이터레이션 사이클이 필요합니다.
이터레이션이 많을수록 문제도 많습니다.
효과적인 시스템 테스트의 특징 Top 10
버그의 일생(그리고 죽음)
버그를 발견했다면...
버그 리포트의 해부
아직 할 수 있는 일이 많이 남아있습니다.
이터레이션 리뷰
이터레이션 리뷰에 대한 질문들
부가적인 일들을 위한 일반적인 우선순위 목록
소프트웨어 개발 도구상자 활용하기

10. 다음 이터레이션
프로젝트 변화에 빠르게 대처하기

작동하는 소프트웨어는...
다음 이터레이션의 계획이 필요합니다.
속도는... 프로젝트 현설을 반영합니다.
고객에 대한 이야기를 계속해 봅시다.
다른 사람의 소프트웨어도 그저 소프트웨어일 뿐입니다.
고객 승인? 확인해보죠!
테스트하기
태권브이, 우리 문제가 생겼어요.
아무도 믿지 마세요.
누가 코드를 작성했는지는 중요하지 않습니다. 만약 그것이 여러분의 
소프트웨어라면 여러분에게 책임이 있습니다.
프로세스를 갖추지 못한 경우
프로세스를 갖춘 경우

11. 버그
프로답게 버그 잡기

먼저 고객에게 이야기해야 합니다.
우선순위 1: 코드가 빌드되도록 하라.
코드를 고칠 수야 있지만...
...하지만 기능을 수정해야 합니다.
어떤 기능이 동작하는지 알아보기
이제 여러분은 무엇이 동작안하는지 알고 있습니다.
무엇을 하시겠습니까?
추정을 위한 스파이크 테스트
스파이크 테스트의 결과가 의미하는 바는 무엇일까요?
팀원들이 실제로 느끼는 것이 중요합니다.
고객에게 버그 수정에 대해 추정한 내용을 전해주세요.
잘 되어가는 것처럼 보입니다.
...그리고 여러분은 성공적으로 이터레이션을 마쳤습니다!
그리고 가장 중요하게도 고객이 행복해 하네요.
소프트웨어 개발 도구상자 활용하기

12. 실제 세계
프로세스의 생활화

소프트웨어 개발 프로세스 명확히 하기
좋은 프로세스가 좋은 소프트웨어를 만듭니다.
형식을 갖춘 복장이 필요합니다.
더 살펴보아야 할 것들...
더 많은 지식 == 더 좋은 프로세스
소프트웨어 개발 도구상자 활용하기

부록1: 남은 것들
베스트 5(우리가 다루지 않았던)

#1. UML 클래스 다이어그램
#2. 시퀀스 다이어그램
#3. 사용자 스토리와 유스케이스
#4. 시스템 테스트 vs. 단위 테스트
#5. 리팩토링

부록 2: 기법과 원칙
숙련된 소프트웨어 개발자의 도구

개발 기법
개발 원칙