책서평

Ship It

vicjung 2010. 1. 7. 01:34

"탁월함이란 행동이 아닌 습관이다."

성공적인 소프트웨어 개발 프로젝트를 위한 실용 가이드
카테고리	컴퓨터/IT
지은이	자레드 리차드슨 (위키북스, 2007년)
상세보기

실제 사용하는 도구들을 많이 설명되어있는 상당히 실용적인 실용서

도구와 인프라스터럭처

모래상자 개발

한 컴퓨터가 빌드 과정 전체에 영향을 주어서는 안된다.

생산적으로 일할수 있는 환경을 주어져야 한다 => 즉 개발자마다 서로 다른 편집기 및 IDE가 사용가능해야 한다.

주요 사용 도구

소스 저장소
빌드 컴퓨터

자산을 관리하세요

필요한 모든 것을 보관 관리

문서, 리소스, 툴 등등.

소스 저장소 이용

빌드를 스크립트화 하세요

컴파일과 자원을 묶는 작업에 사용되는 스크립트, 프로그램, 기술이 모두 합쳐져 빌드 시스템이라 함

빌드 절차

코드를 컴파일한다.
컴파일된 코드를 인스톨러 프로그램에 복사한다.
제삼자가 만든 라이브러리 최신판을 옮겨놓는다. (예를 들어, 데이터베이스 드라이버, 파서 같은)
HTML 파일이나 그래픽 파일처러 코드가 아닌 파일을 가져다 놓는다.
설명서를 인스톨러에 복사한다.
인스톨러를 빌드한다.

첫날에 빌드를 스크립트화 하기

어떤 컴퓨터에서 뽑은 빌드라도 빌드 컴퓨터에서 뽑아낸 빌드와 같도록 하는게 목표

주요 도구

배치파일, 쉘 스크립트, 스크립트언어(python, perl, ruby..)

Ant

시작방법

스크립트를 작성하는 동안 팀 구성원 한 명을 뽑아 수동으로 시스템을 빌드
각 빌드 단계를 정의
빌드 도구를 선택하되 그 도구가 짐이 되면 다른 선택사항을 다시 검토
각 단계를 점진적으로 스크립트화 하기(수작업을 하나씩 제거)
다른 컴퓨터에서 스크립트 실행하기
다른 팀 구성원이 도움없이 스크립트를 사용할수 있는지 확인하기

체크사항

명령어 하나면 빌드가 되는가?
SCM에서 코드를 내려받아 빌드 가능한가?
어느 컴퓨터에서라도 빌드가 되는가?
외부 환경에 의존하지 않고도 빌드가 되는가? (특정 네트워크 드라이브 같은) => 인터넷 끊고 해보는것도 괜찮을듯.

자동으로 빌드하세요

위에 스크립트화 된 빌드를 이용하여 자동으로 빌드하는 시스템

주요 주기는 코드가 변경될 때 마다 항상하기

가볍게 구성된 스모크 테스트 집합을 추가하기

=> "테스트 장비를 사용하세요"란 혹은 http://msdn2.microsoft.com/ko-kr/library/ms182613(VS.80).aspx를 참고

위와 같은것을 지속적 통합이라 부름(CI: Continuous Integration)

이슈를 추적하세요

이슈의 세부 사항

어느 버전의 제품에 이슈가 있습니까?
어느 고객이 그 이슈에 부딪혔습니까?
얼마나 심각합니까?
그 문제가 사내에서 재현되었습니까? (누가 재현했습니까?)
고객의 환경(운영체제, 데이터베이스 등등)은 무엇입니까?
어느 버전의 제품에서 이슈가 처음 발생했습니까?
어느 버전의 제품에서 이슈가 고쳐졌습니까?
누가 이슈를 고쳤습니까?
누가 수정 사항을 검증했습니까?

시작하기

이슈 추적 시스템 고르기
테스트 시스템 구축하고 사용법 익히기
내부 사용자를 위해 한 쪽짜리 퀵-스타트 가이드 만들기
새 이슈 보관하기 => 과거꺼는 정리가능하면 하고 아니며 천천히
시간이 나면 이전 이슈를 새 시스템으로 옮기세요

체크사항

아직 해결 못한 최우선사항의 목록을 생성해낼 수 있습니까? 두 번째 계층에서 발생한 문제는 어떻게 됐습니까?
지난 주에 고친 것들의 목록을 생성할 수 있습니까?
시스템이 해당 이슈를 수정한 코드를 참조할 수 있습니까?
기술 리더가 이 시스템을 사용해서 개발팀이 할 일을 목록으로 뽑아낼 수 있습니까?
시스템에서 정보를 가져오는 방법을 기술 지원 팀이 알고 있나요?
어떤 이슈가 고쳐졌을 때 기술 지원팀(그리고 다른 사람이나 부서)이 알 수 있도록 시스템이 '관심 있는 관계자'에게 통지해줄 수 있습니까?

기능을 추적하세요

통합된 기능 요구 목록을 유지하세요

기능에 우선순위를 매기고, 그 기능을 연구하거나 추가하는 데 소요될 간단한 시간 예측치를 유지하세요

테스트 장비를 사용하세요

테스트 장비란 테스트를 만들고 실행시키는 데 사용할 수 있는 도구 또는 소프트웨어 툴킷을 말합니다.

'기성품' 테스트 프레임워크를 사용하면 여러 이점이 많음

예를 들면, XUnit 테스트 장비에는 출력포맷에 기반을 두고 보고서를 생성할 수 있는 지원 제품이 있음

다양한 코드 검사기가 만들어낸 출력을 수집해서 가공해주는 오픈 소스 도구인 MetaCheck 같은 것도 잇음

테스트의 종류

단위 테스트(Unit Test) - 개별 클래스나 객체를 테스트하기 위해 고안, 한 뭉치의 코드 내에 논리가 적절히 작동하는지 확인하는게 주 목적

기능 테스트(Functional Test) - 제품 전체의 적절한 동작(또는 기능)을 테스트하기 위해 작성

성능 테스트(Performance Test)

부하 테스트(Load Test)

스모크 테스트(Smoke Test) - 제품의 중요한 부분을 작동시키기 위해 작성, 기본적인 아이디어는 기본 기능을 호출했을 때, 실패했는지 알아보기 위해 제품을 돌려보는 것

통합 테스트(Integration Test)

가짜 클라이언트 테스트(Mock client test)

=> http://www.mockobject.com/Faq.html 참조

도구를 선택하는 방법

그냥 별 내용 없음

실험하지 말아야 할 때

실용주의적 프로젝트 기술

목록에 따라 일하세요

효과적으로 목록을 사용할려면

누구나 사용할 수 있어야 한다.
우선순위를 부여해야 한다.
일정에 기반해야 한다.
살아있는 문서여야 한다.
측정 가능해야 한다.
- 시간예측 (작은단위로 처음에는 하루, 1주, 2주 or 4주 이하로만 하게끔 시도)
- 측정 가능 - 항목이 끝났는지 안 끝났는지 판단 가능해야 함
  - 예) 성능 개선 (X) => 5초내 에 로그인이 완료되어야 한다 (0) 처럼 정확히 선을 그어야 함
목표가 있어야 한다.

이렇게 시작하세요

하루 통째로 잡아 , 여러분이 하고 있는 모든 작업을 목록에 적으세요
일일 업무 목록을 갖고 있다면 공식적인 '목록'사본으로 체계화 하세요
기술 리더에게 여러분이 업무에 우선순위를 부여하고 개괄적인 시간 예측 값을 추가할 수 있게 도와달라고 하세요
'목록'에서 가장 우선순위가 높은 항목부터 처리하세요. 위기가 발생해서 낮은 순위의 항목을 상향 조정해야 한다면, 그런 상황을 기록하세요.
새로운 일을 모두 '목록'에 추가하세요
작업을 완수했다면, 그 항목은 '끝낸 일' 목록에 옮겨놓으세요.

예

일별로 생산되는 위젯을 보여주는 새 보고서를 추가하기
내 새 컴퓨터에 개발 도구를 설치하기

기술리더

기술 리더의 책임

팀이 나아갈 방향을 설정합니다.
프로젝트의 기능 목록을 관리합니다.
기능 요구사항에 우선순위를 부여합니다.
정신을 산만하게 만드는 외적인 요소로부터 팀을 보호합니다.

우선순위 예

필수적임
매우 중요함
있으면 좋음
광택내기
시시한 것

체크사항

팀 구성원 각자가 무슨 일을 하고 있는지 알고 있습니까?
5분 이내에 프로젝트의 현 상황에 대한 개요를 작성해낼 수 있습니까?
다음에 추가해야 할 기능이 무엇인지 5~10개 정도를 댈 수 있습니까?
우선순위가 가장 높은 결함을 서슴없이 열거할 수 있습니까?
팀 구성원을 위해 여러분이 해결한 가장 최근의 문제는 무엇이었습니까?
해결해야 할 중요한 이슈가 있을 때 팀 구성원이 여러분을 찾아옵니까?

매일 협력하고 의사소통하기

일일회의

일일회의 이렇게 시작하세요

모든 사람이 회의 형식(어떤 질문이 오갈건지 같은)을 알게 하세요
모든 사람이 질문에 대답해야 합니다. 넘어갈 수도 없고 예외도 없습니다.
처음에 느긋하게 시간 제한을 두세요
회의를 같은 시각, 같은 장소에서 매일 여세요
일일 회의를 일종의 습관처럼 만드세요
일일 회의 시간에 논의한 주제를 웹 페이지나 플로그(프로젝트 블로그)에 올립니다.
한사람씩 모두 발표합니다.(무작위도 좋은 방법)

코드를 검토하세요

코드를 조금씩 검토하세요
검토자는 한두 명을 넘어선 안됩니다.
하루에도 여러 번, 자주 검토하세요.

코드 검토를 이틀 이상 안 하고 넘어가지 않는 편이 좋음

코드 검토 지침

다른 개발자가 적어도 한 명은 있어야 합니다. (단 서너명을 넘기지는 마세요. 너무 많으면 수렁으로 빠짐)
검토하기 전까지 코드를 공개하지 마세요.
검토자들은 코드가 받아들이기 힘들다고 생각하면 거부할 권리가 있습니다. 다른 사람의 코드를 검토하다가, 주석이 제대로 달려 있지 않던가, 알고리즘이 효율적이지 않던가, 아니면 다른 문제를 발견하면, 주저하지 말고 교정하라고 말하세요.
코드 검토는 탁 터놓고 하세요. 회의 일정을 잡기보다는 거저 들러서 하는 형식으로.
도입할 때는 선임 팀 구성원 몇 명을 의무적으로 검토자가 되도록 지정할 필요가 있을 수도 있음.

이렇게 시작하세요.

코드검토가 어떤건지 모든 사람이 이해해야 함. 작은 코드 블록을 자주
처음 몇 주나 몇 달간은 선임 개발자가 매번 참석
코드 변경 통지 시스템 도입
관리자 층의 지지를 먼저 이끌어내세요

코드 변경 통지 보내기

코드 변경 내용을 항상 통지

통지 내용

검토자의 이름
코드를 변경하거나 추가한 목적(예를 들어 어떤 버그를 수정했는지, 또는 어떤 기능을 추가했는지)
새 코드와 예전 코드의 차이점 (너무 많으면 새 코드만 추가)

예광탄 개발

개발 프로세스적인 부분과 협력 설계 부분 주로 소개

아직 많이 안 와 닿는 부분.

일반적인 문제와 해결방법

이 챕터는 거의 문제점들 해결 방법은 위에 사항들 잘 지켜라라던가 아니면 어떤 사항에 어떤 항목을 해라가 대부분

도와주세요! 코드를 인수받았어요

빌드하세요. 제품 빌드 방법을 파악하고 빌드 프로세스를 스크립트로 작성하세요.
자동화하세요. 제품 전체를 자동으로 빌드하고 테스트할수 있어야 합니다. 모든 빌드 과정을 문서화하고 공개하세요.
제품을 테스트하세요.
테스트를 더 많이 하세요.

"테스트하기 전에는 다른 사람이 물려준 코드를 변경하지 마세요"

-_- 내용이 뭔가 좀 부족하고 흐리뭉턴한듯.

TIP 조언 요약

습관을 고르세요.
모래 상자 안에 머무세요.
필요한 거라면 체크인하세요.
첫날에 빌드를 스크립트화 하세요.
어떤 컴퓨터에서라도 빌드가 되어야 합니다.
지속적으로 빌드하세요.
지속적으로 테스트하세요.
모두가 잊어버리는 사태는 피해야 합니다.
제품을 작동시켜보세요 - 테스트를 자동화하세요.
유연하고 많은 사람이 사용하는 테스트 장비를 사용하세요.
업무에 가장 적합한 도구를 사용하세요.
공개된 포맷을 사용해서 여러 도구를 통합하세요.
임계 경로 기술에 친숙해지세요.
목록에 따라 일하세요.
기술 리더가 알아서 하게 놔두세요.
일일 회의를 해서 진행 방향을 수시로 바로 잡으세요.
"나중에"라고 말해도 됩니다.
항상 모든 코드를 재검토하세요.
소프트웨어가 목표지, 순응이 목표는 아닙니다.
그룹 전체가 아키텍트입니다.
제품에서 사용하는 거라면, 여러분도 사용해야 합니다.
가장 어려운 문제부터 해결하세요.
캡슐화된 아키텍처야말로 확장성 있는 아키텍처입니다.
보트가 움직이기 전엔 보트를 조정할 수가 없습니다.
테스트하기 전에는 다른 사람이 물려준 코드를 변경하지 마세요.
테스트 주도 리팩토링으로 테스트할 수 없는 코드를 깨끗이 정리하세요.
가짜 클라이언트로 최소한의 노력으로 최대의 성과를 거둘 수 있습니다.
변경되는 코드를 지속적으로 테스트하세요.
모두에게 통하는 방법이어야 합니다.
자주 통합하고, 지속적으로 빌드하고 테스트하세요.
동작하는 데모를 일찍 그리고 자주 전달하세요.
여러분이 무엇을, 왜 하고 있는지 공개하세요.
얼굴을 많이 마주칠수록 팀워크가 단단해집니다.
고쳐야 하는 것만 고치세요.
파괴적인 '우수한 업무처리기법'은 진정한 의미의 업무처리기법이라 할 수 없습니다.
밑에서부터 혁신해야 합니다.
말만하지 말고 보여주세요.
관리층의 지지를 이끌어내세요.
버그가 있는 곳을 테스트하세요.
목록은 살아있는 문서입니다. 변화가 목록의 생명입니다.
목록에 없다면, 그것은 프로젝트의 일부가 아닙니다.
항상 피드백을 빨리 해주세요.

소스 코드 관리

소프트웨어

CVS - http://www.cvshome.org

SVN - http://subversion.tigris.org

MS Visual SourceSafe

BitKeeper - http://www.bitkeeper.com

리눅스 커널 개발자들이 수년간 사용해 온 상용제품

빌드 스크립트 도구

소프트웨어

운영체제 스크립트 언어(셀, 배치파일)

make

Automake - make 파일을 만드는 걸 도와주는 펄 유틸리티

언어에 특화된 도구

Ant - http://ant.apache.org

자바를 위한 표준 빌드 스크립트 언어, 내장된 기능이 많아서 자바가 아닌 다른 언어도 스크립트화할 만큼 유연함

NAnt - http://nant.sourceforge.net

Ant의 .NET 버전

Groovy - http://groovy.codehaus.org

범용스크립트 언어인데도, Groovy는 자바 코드 내에서 Ant의 모든 기능에 접근하게 해줌

Rake - http://rake.rubyforge.org

루비를 위한 빌드도구

범용 스크립트 언어

Ruby

Python

Perl

빌드 시스템

Maven - http://maven.apache.org

Maven은 너무 많은 부분을 캡슐화 한다는게 많은 불만

빌드 위치와 태스크 이름에 대해서는 선호함

대부분의 사람은 좋아하거나 증오하거나 둘중 하나

Maven2

밑바닥부터 다시 작덩된 Maven의 다음 버전

용어

태스크 - 해당 도구로 실제로 할 수 있는 일. 최소한 컴파일과 링크는 필요

지속적인 통합 시스템

소프트웨어

CruiseControl - http://cruisecontrol.sourceforge.net

자바로 작성된 오픈 소스 CI 시스템. 추천 시스템

CruiseControl.NET - http://sourceforge.net/projects/ccnet

닷넷용 CruiseControl

DamageControl - http://damagecontrol.codehaus.org

루비로 작성된 CI 시스템. 빠르고 갈끔하게 설계, 멋진 웹 인터페이스와 내장된 다른 도구와의 통합 기능까지 있음

AntHill - http://www.urbancode.com/projects/anthill

빌드 관리 서버라 명명된 AntHill은 빌드 과정에 자신만의 스키마를 강요

좋은 웹 인터페이스

Continnum

continnum 은 Maven과 매우 탄탄하게 통합되도록 설계된 새로운 CI 시스템

이슈 추적 소프트웨어

소프트웨어

Bugzilla

오픈 소스 웹 기반 버그 추적 시스템

JIRA

FogBugz

PR-Tracker

테스트 프레임워크

소프트웨어

SUnit

스몰토크 유닛은 최초의 XUnit 테스트 장비

JUnit

JUnitPerf

성능 및 확장성을 쉽게 측정할 수 있도록 해주는 멋진 JUnit 확장기능을 모아놓았습니다.

NUnit

JUnit에서 이식한 .NET을 위한 단위 테스트 장비

MbUnit

NUnit를 기반으로 만들어진 MbUnit은 고수준의 테스트 기술 여러 개를 내놓았습니다.

통합된 조합 테스트, 보고, 행 테스트, 테이터 주도 테스트 등의 개념 모두가 패키지의 일부

HTMLUnit

웹 애플리케이션을 테스트하기 위해 웹 브라우저를 시뮬레이트 합니다.

HTTPUnit

HTMLUnit와 유사. 테스트를 하기 위해 HTTP 요청과 반응을 사용합니다.

JWebUnit

JWebUnit는 HTTPUnit 위에서 웹 애플리케이션을 돌아다니기 위해 쓸 수 있는 고수준의 API를 제공합니다.

테스트 도구

Cobertura

코드 커버리지 도구

Clover

코드 커버리지 도구

Fit - http://fit.c2.com

독특하고, 사용자 친화적이며, 테이블 주도적으로 인수 테스트를 함. 사용하지 않더라도 관련글은 읽어둘 가치가 있음

Fitnesse

Fit의 확장기능

독립형 위키인 동시에 테스트 프레임워크

WinRunner

기능 및 회구 테스트르 ㄹ위한 기업 수준의 도구

LoadRunner

성능 및 스트레스 테스트

Empirix E-Tester

인터넷 익스플로러에 내장된 웹 녹음기 및 재생기

Watir

자동화 된 테스트를 인터넷 익스플로러 안에 작동시키는 테스트 도구

루비기반

Systir

참고 사이트

http://www.xprogramming.com/software.htm

http://www.testingfaqs.org/t-unit.html

참고 서적 - 없거나 모르는 것만

Ruby

The Ruby Way: Hal Fulton 저

루비 언어의 일상적인 업무 방안을 쉽게 이해할수 있음

Java

Java Network Programming: 멀린 휴즈 등 저

자바 네트워크에 대해 종지부를 찍은 책

기타

The Little Schemer: Daniel Friedman, Matthias Felleisen 공저

프로그램, 알고리즘, 그리고 재귀를 바라보는 완전히 새로운 시각에 눈뜨게 해주었습니다.

Dynamic HTML: The Definitive => Danny Goodman 저

크로스 브라우저 개발에 바이블

Bugs in Writing: A Guide to Debugging Your Prose => Lyn Dupre 저

글 쓰기에 관한 책

이 글은 스프링노트에서 작성되었습니다.