내 블로그다

http://eknote.tistory.com/1367

http://blog.daum.net/thistm/7342845

http://blog.naver.com/sylphjm?Redirect=Log&logNo=130039006640

<Doxygen>

http://blog.daum.net/freemer/3759545

지 맘대로 규칙을 정하는 거다

하지만 제대로된 버전 넘버링 규칙이 없으면 버전 관리 자체가 귀찮을 뿐 아니라, 

개발자, 사용자 모두 버전으로부터 "이전 버전과 다르구나. 근데 뭐가 다르지?"란 의구심만 일으키고,

그러한 버전은 단순한 일렬번호 명시와 다를바가 없지 않을까?

버전이 프로그램 릴리즈의 모든 정보는 아니더라도 어떤 부분이 바뀌었다는 최소한의 정보를 알려주면 사용자/개발자 모두 아~주 좋아질 것이다

그럼 일단 다른 프로그램들의 버전 규칙을 보자

[1]. Linux/Windows/OS X의 규칙

http://java.tistory.com/16

[2]. 아파치의 버전관리에 관한 얘기

http://www.java2go.net/blog/163?TSSESSION=6394f9991cc2b87f1155f075496327fe

[2-1]. 아파치 문서

http://apr.apache.org/versioning.html

[3]. 버전에 대한 사전 지식

http://blueb.net/blog/576

뭐 여러 얘기가 있었지만 내 생각엔 아피치와 OS X의 경우가 제일 그럴싸하다

위 [2]문서에 적힌대로라면

"버전은 MAJOR.MINOR.PATCH의 전형적인 세쌍의 정수를 이용하여 표시된다. 기본적인 의도는 MAJOR 버전은 API에 호환되지 않는 대규모의 업그레이드를 수행한 것이며, MINOR 버전은 이전 마이너 버전과의 소스 및 바이너리 호환성은 유지한 것이고, PATCH 수준의 변경은 상하위 호환성을 완벽하게 유지한 버전이다."

이렇게 하는게 깔끔한거 같다

버전정보는 세 단위로 이루어지며,

MAJOR

아예 싹~ 바뀐 경우이다. 

대규모 업그레이드가 이루어진 경우이다

서버의 경우엔 클라이언트는 1.X.X으로의 접속 방식을 2.X.X에는 절대 접속 할 수 없다는 얘기다

MINOR

API 또는 기능에 변경이 발생되었을 경우이다

서버의 경우엔 기존 사용자들의 접속의 의사소통은 원할히 이루에 지지만, 몇몇 API가 추가/변경 되었거나 기능의 사용방법이 변경되었을 경우이다

소통은 원할히 이루어지지만 몇몇 기능들은 불가능 할 것이다

MINOR 버전이 변경되었을 경우엔 클라이언트에게 변경사항을 반드시 알려야 한다

PATCH

버그 수정의 경우

기존 클라이언트들은 접속과 수행에 아무런 변경사항을 느끼지 못한다. 2.1.3과 2.1.4를 동일한 방법으로 사용할 수 있다. 

하지만 서버 내부적으로는 버그가 수정되었거나, 내부적으로 소스가 수정되었다

그러나 클라이언트는 "뭔가 변경이 있었구나"정도로만 생각하면 될 뿐, 서버로의 접속에는 전혀 변경될 사항이 없다

이 버전은 현재 날짜를 써도 된다

버전은 

개발자 입장에서는 자신이 개발하는 프로그램의 현 시점을 알 수 있게 한다.

하지만 더욱 중요한건, 프로그램을 사용하는 입장에서는 어떤 사항이 이전 릴리즈와 다른지 대강의 정보를 알 수 있게 한다

개발 환경을 갖추는 일은 성공적인 소프트웨어 개발을 위한 필수조건이다. 여기서 개발 환경이란 IDE 뿐 아니라 소스 저장소, 테스트 환경, 배포 툴, 문서화 도구, 소스 컨벤션, 관리 정책 등 소프트웨어 개발의 시작부터 끝까지 필요한 모든 것들을 포함한다. 많은 것을 제공하는 IDE를 사용하더라도 여전히 다른 많은 도구들과 연계해야 하며, 정책적인 부분의 결정 역시 개발자의 몫이다. 이런 소프트웨어 개발 환경이 잘 갖춰져 있어야 개발자들은 소모적인 작업에 노력을 들이지 않고 개발에만 집중할 수 있게 된다. 이 문서의 목적은 이러한 소프트웨어 개발 환경 구축에 필요한 것들을 간략히 소개하고 모범적인 Practice를 제공하는 것이다. 방법론과도 많은 부분이 겹칠 수 있으나 방법론보다는 좀더 기술적인 범위에 초점을 맞출 것이다. XP라면 첫번째 Iteration에서 해야할 일들이다.

아래의 목차는 중요도 순이 아니라 먼저 갖추는게 좋은 순서임을 참고하라.

1 커뮤니케이션 시스템 #

1.1 의사 결정 체계 #

의 사 결정은 비단 소프트웨어 개발 뿐 아니라 모든 집단에서 공통적으로 중요한 문제다. 의사 결정 시스템은 관련되는 사람이 많은 프로젝트일수록 프로젝트의 진행 속도에 결정적인 영향을 미친다. 많은 사람이 공동 작업을 하다보면 결정을 내려야하는 일이 빈번하게 발생한다. 결정해야할 일이 발생했을 때 이것을 알아차린 사람이 그 내용을 관련되는 사람들에게 전달하고 사람들의 의견을 모아고 결정을 내리는 과정, 그 과정의 속도가 개개인의 작업 속도 이상으로 전체의 속도에 큰 영향을 끼친다. 자신의 작업에 무언가 결정이 되어야할 내용이 있는데 그 결정이 이루어지지 않아서 작업을 못하고 있다면 그 집단은 의사 결정 시스템이 문제가 있는 것이다. 따라서 무언가를 시작하기 전에 가장 먼저 해야할 일은 앞으로 의사 결정을 어떻게 할 것인가를 정하는 것이다.

어떤 식으로 의사 결정 규칙을 정할 것인가는 조직의 상황에 따라 다르다. 정치 교과서에서 배운 의사 결정 방식들이 도움이 될 것이다. 해당 문제에 관련된 사람이 각 파트별로 한 명 이상씩 참석한 상태에서 30분 이상의 토론 후 3분의 2 이상의 찬성일 경우 찬성으로 판정한다.와 같은 식이면 될 것이다. 관련자는 누구든지 의사 결정에 참여할 수 있어야함은 물론이다. 이런 의사 결정 체계는 명문화되어 있는 것이 좋다. 암묵적인 룰이 늘어나는 것은 좋지 않을 뿐더러, 중요한 것은 의사 결정을 원하는 사람이 누군가(소속 팀장, 상사 등)의 눈치를 보지 않고 의사 결정을 요구할 수 있어야 한다는 것이다. 명문화된 룰은 불만이 있는 사람이 정당하게 불만을 표출할 수단이 된다. 의사 결정의 필요성이 발생했을 때 의사 결정 요구가 빠르게 이루어질 수 있도록 CommunicationTrigger 등을 사용하는 것도 좋은 방법이다.

1.2 문서화 도구 #

문서화의 필요성은 재차 언급할 필요가 없을 것이다. 문서화에 있어 기억해야할 것은 두 가지, 필요 없는 문서를 만들지 않는 것이 첫째이고 필요한 문서는 쉽게 만들 수 있게 하는 것이 그 둘째이다. 첫째는 정책상의 문제이니 넘어가고 둘째는 도구가 중요하다. 가장 중요한 것은 문서를 써야하는 사람이 문서를 쓰고 다른 사람이 읽게 만들기까지의 비용이 작아야한다는 것이다. 읽는 사람이 편하게 읽을 수 있는 것도 물론 중요하지만 문서 쓰기가 귀찮아서 안 쓰게 된다면 다 소용 없는 일이다. 그렇다고 귀찮은 걸 억지로 하게 만든다면 생산성이 떨어진다. 결국 쉽게 쓰고 쉽게 고치고 쉽게 공유할 수 있는 도구가 필요하다. 더불어 버전 관리까지 되어야한다.

그런 도구가 있다. 바로 이 사이트를 유지하고 있는 위키위키이 다. 위지윅 에디터에 비하면 꽤나 구식인 에디터를 써야하지만 간결한 문법으로 인해 헤딩이나 목록을 만드는 것에 대한 부담이 워드프로세서에 비해 별로 많지 않다. 오히려 복잡한 템플릿과 스타일 쓰는 것보다 편할 수도 있다. 그런 반면 공유는 워드프로세서에 비해 훨씬 쉽다. CVS를 쓰더라도 워드는 작성, 커밋, 체크아웃의 과정이 필요하고 공동 작업도 힘들고 버전 관리도 반 수동으로 해야하는 반면 위키는 자동 버전 관리에 쓰자마자 공유된다. 문서간 링크도 쉽고 점진적으로 발전하는 문서를 쓰기가 쉽다. 게시판도 이런 면에서는 워드보단 낫지만 자유도가 낮고 버전 관리, 공동 저작이 쉽지 않다. 결국 위키만한 도구는 아직은 없다. 참고로 Firefox의 mozex 플러그인은 사용하면 ?EditPlus로 에디팅할 수 있다.

간혹 위키의 문법이 어렵다는 말을 듣는다. 사실 이것은 거짓말이다. 위키의 문법은 거의 대여섯 줄로 집약되며 보통 편집 화면에 바로 나온다. 못 외워도 쓰기에 부족함이 없다. 문서화에서 중요한 제목 처리, 목록 처리, 테이블, 인덴트는 편집화면 도움말에 다 나오며 쓰기도 쉽다. 개발자가 위키가 어렵다는 말을 한다면 다른 직업을 찾아야하지 않을까? 적당한 문서화 도구를 아직 찾지 못했다면 위키위키를 쓰라.

어떤 위키엔진이 좋을까? 사실 위키 엔진은 간단하기 때문에 직접 만들어 써도 큰 부담이 아니다. 그러나, 이미 나와 있는 좋은 것들이 많다. 위키엔진을 참조하라. Tikiwiki 같은 복잡하고 다양한 기능을 가진 위키도 많지만 위키에 많은 기능이 필요하다고 생각되진 않는다. 모니위키 정도면 필요한 것은 다 갖추고 있고 국내에서 많이 쓰기 때문에 추천할 만하다.

2 소프트웨어 형상 관리(SCM) #

소프트웨어 형상 관리란 소스 버전 관리를 포함해서 product의 release 버전, 버그 추적, 기능 목록 관리 등등을 아우르는 것이다.

2.1 소스 버전 관리 #

소스 버전 관리 시스템은 CVS가 가장 대중적이다. 다른 버전 관리 시스템을 이미 사용하고 있는 것이 없다면 CVS가 가장 추천할 만하다. 물론 CVS보다 나은 것도 꽤 많다. 상용 소프트웨어를 비롯해서 CVS의 대체를 목적으로 개발된 Subversion도 있다. 그러나, 중요한 것은 버전 관리 시스템 자체의 기능보다도 얼마나 좋은 프론트엔드를 갖고 있는가, 그리고 IDE와의 통합이 얼마나 편리한가이다. 이 점에서 폭넓은 사용자층 덕분에 대부분의 IDE가 지원해주고 있고 ant, maven 등의 지원에 changelog 분석기 등의 여러 가지 툴이 많은 CVS가 유리하다. Subversion이 앞으로 얼마나 발전할지는 알 수 없으나 초기에 주목 받았던 것에 비하면 CVS를 그다지 많이 대체해나가고 있진 않다.

소스 버전 관리는 단지 소프트웨어를 CVS로 선택하는 것만으로 끝나진 않는다. CVS를 어떻게 설치하고 설정할 것인지에 대한 자질구레한 기술적 결정들을 내려야하고 브랜치를 어떻게 사용할 것인가에 대한 정책도 세워야한다. 이 문서는 이런 결정을 내리는데 도움을 주는 것이 목적이며 CVS에 대한 기본적인 사용법은 설명하지 않을 것이다.

2.1.1 CVS 설치 및 설정 #

1. CVS 서버
   가급적이면 CVS 이외에는 별다른 부하가 걸리지 않는 서버가 좋다. 팀원이 많아질수록 CVS의 부하는 생각 이상으로 커질 수 있다. 주기적으로 changelog 통계 같은 것도 돌리고 하려면 큰 부하가 걸리지 않는 것이 좋다. 윈도우용 CVSNT가 있지만 추천하지 않는다. 계정 관리가 리눅스 서버보다 더 귀찮을 수 있다. 요즘 대세가 플랫폼 프리라고는 하지만 개발하는데 리눅스 서버 한 대쯤은 필수인 것 같다.
2. 계정 관리 및 프로토콜
   CVS 계정은 반드시 한 사람 당 하나가 주어져야한다. 공용 계정을 쓰는 것은 누가 소스를 수정했는지 알 수 없게 만든다. 간혹 소스에 주석으로 작성자를 남기는 경우가 있는데 CVS를 사용한다면 이런 주석은 쓰레기에 불과하다. 가장 편리한 방법은 cvs 그룹으로 개발자 각자에게 CVS 서버의 시스템 계정을 부여하는 것이다. 시스템 계정으로 만들면 ext+ssh와 pserver 모두 이용가능하고 pserver에서 별도 계정을 관리하지 않아도 된다. pserver에서 쓰는 패스워드 파일을 관리하는 것이 시스템 계정 관리하는 것보다 훨씬 귀찮다. 물론 루트 권한이 없다면 pserver를 쓸 수 밖에 없겠지만 루트 권한이 있다면 시스템 계정이 관리하기 가장 좋다. 또, 많은 경우에 개발자용 계정 외에 읽기 전용 계정이 필요할 수 있다. ext+ssh로는 권한 관리가 안되므로 이 때는 시스템 계정을 만들지 말고 패스워드 파일을 이용해서 pserver 계정을 만들어야한다.

2.1.2 브랜치 및 버전 정책 #

브 랜치란 소스의 개발 방향이 여러 갈래로 나갈 때 이를 따로 관리하기 위한 방법이며, 중간 단계의 버전을 남기기 위해서도 사용된다. 일반적으로 Main trunc라 부르는 HEAD 브랜치는 소스의 가장 최신 버전을 담는다. product가 릴리스될 때는 항상 버전을 매기고 브랜치로 남겨두는 것이 좋다. 이를테면 개발자가 매일 매일 개발하는 소스는 HEAD에 커밋하고 어느 정도 개발이 완료되어서 릴리스를 할 때는 R1_0, R2_0_1 등과 같이 버전을 붙인 브랜치를 만든다. 이런 버전용 브랜치는 가급적 재수정을 하지 않는 것이 좋다. 개발 중에 소스가 두 갈래로 분기를 해서 개발해야할 때도 브랜치를 만든다. 이를테면, 오라클용 버전과 ?MySQL 용 버전을 따로 만든다면 oracle, mysql 등과 같이 브랜치를 만들고 작업한다. 이들이 따로 릴리스가 된다면 ORACLE_R1_0, MYSQL_R3_1 등과 같이 브랜치 태그명을 정하면 좋다. 일반적으로 개발 중인 브랜치는 소문자로, 릴리스된 버전은 대문자로 태그 이름을 짓는 것이 구분이 편리하다.

2.2 이슈 추적 관리 #

이 슈 추적 관리는 두 가지가 있다. 하나는 고객(혹은 기획자)로부터 요구사항이나 버그 리포트를 관리하는 것, 또 하나는 개발자 자신이 product의 feature list를 관리하고 버그 추적을 하는 것이다. 둘다 하나의 소프트웨어로 관리할 수 있다. Issue Tracker, 혹은 Bug Tracker라고 불리는 product가 존재한다. 간단한 이슈 추적 관리 기능만 제공하는 것에서부터 gforge나 source cast처럼 아예 소프트웨어 개발 과정 전반에 걸친 collaboration system을 구축해주는 것까지 다양한 범위로 존재한다. 만약 멀리 떨어진 환경에서 인터넷으로 공동 작업을 해야한다거나, 오픈 소스 프로젝트를 한다면 대형 collaboration system이 좋을 수 있지만 대체로 CVS와 단순 Issue Tracker로 충분하다. 오픈 소스에도 상당한 품질을 가진 것들이 많이 나와 있다. mantis 정도면 국제화도 되어 있어 한글 메뉴도 나오고 설치하기도 쉽기 때문에 추천할 만하다. TUTOS도 괜찮다. trac처럼 위키를 제공해서 문서와 연동하기 좋은 것도 있지만 이슈 트래커 부분과 위키 부분 어느 쪽도 완성도가 높지 않다.

이슈 트래커에서 이슈 관리는 product의 릴리스 버전별로 하는 것이 좋다. 가능한 한 이슈 보고는 최초 발의자가 하는 것이 좋다. 고객 혹은 기획자에게는 보고 정도의 권한을 주고 개발자들에겐 최대한 관리자급의 권한을 주는 것이 좋다. 이슈 보고 및 관리에 대한 사람별 통계를 내보는 것도 재밌는 일이 될 것이다. 이렇게 이슈들을 관리한 내용은 release note를 만들 때도 유용하게 쓰일 수 있다.

3 개발 도구 #

개발 도구는 프로그래머의 생산성에 가장 결정적인 영향을 미치는 것이다.

3.1 프로그래밍 언어 #

프로그래밍 언어는 다분히 개발자의 취향에 의존한다. 여기서는 개발자에 의존적인 요소들은 제외한 논의만을 담는다.

프로그래밍 언어 선택에 있어서 가장 먼저 고려해야할 것은 성능이다. 그러나, 이것은 선택조건으로가 아니라 제약조건으로 고려해야할 것이다. 하드웨어 접근이 엄청나게 많거나, 엄청나게 빠른 속도를 요하거나, 컴파일러 혹은 VM을 개발하는 일이 아니라면 어셈블러나 C를 써야하는 경우는 드물다. 가급적 객체지향 언어를 선택하라.

VM 기반 언어를 사용할지 말지도 중요한 문제다. 크로스 플랫폼은 이 선택에 있어서 중요한 문제가 아니다. VM 기반이 아닌 언어도 소스레벨에서의 크로스 플랫폼은 어느 정도 보장된다. 더 중요한 것은 실행코드의 보안 정도, 그리고 빠른 시작 속도의 필요성이다. 이런 경우는 native executable binary를 만들 수 있는 언어가 필요하다. 이런 경우가 아니라면 VM 기반을 사용하든 아니든 별 상관 없다.

다음 고려 대상은 언어에 대한 지원 정도이다. 사용하려는 부분에 충분한 API가 있는지, 좋은 IDE가 있는지, 관련 자동화 도구, 문서는 충분한지, 사용자 커뮤니티가 얼마나 많은지 등등을 검토하라. 실험적인 프로젝트가 아니라면 이런 부분에서 부족한 언어는 선택하지 않는 것이 좋다. Java, C++ 등은 이미 다방면에서 성숙된 API를 갖고 있고 수준 높은 IDE가 많으므로 이런 면에서 유리하다. 참고로 현재 언어의 사용 정도는 http://www.developer.com/lang/article.php/3390001 에서 볼 수 있다. Java, C, C++, PHP, Visual Basic, Perl, Delphi/Kylix, Python 정도의 순이다.

추천하는 언어는 Python, Java이다. Python의 생산성은 놀랄 만하다. Java는 현재 언어에 대한 지원이 가장 좋은 언어이며 언어의 기본적인 부분에 충실하다.

3.2 테스트 도구 #

테스트는 이제 프로그래머의 필수 스킬 중 하나이며, 좋은 테스트 도구를 갖는 것은 생산성과도 직결된다.

3.2.1 Acceptance Test #

고객의 요구사항, 혹은 프로그램의 기능이 제대로 동작하는지를 테스트하는 도구. Acceptance Test에서 가장 중요한 것은 쉽게 테스트를 작성하고 보기 쉬운 리포트를 생성하는 것이다.

• http://xper.org/wiki/xp/FrameworkForIntegratedTest

웹이라면 ?HttpClient와 정규식 등을 통해 검사해볼 수 있다. 잘 작성된 Acceptance Test들은 웹 서버의 모니터링용으로도 활용할 수 있다.

3.2.2 Unit Test #

소프트웨어의 각각의 코드들이 정상적으로 동작하는지를 테스트하는 도구. 유닛 테스트에서 가장 중요한 것은 자동화가 되는 것이다. 자동화되지 않는 테스트는 자주 실행하지 않게 되어 테스트로서의 의미를 상실할 수 있다. 유닛 테스트를 작성할 때는 언제 실행시켜도 돌아가게 작성해야한다. 유닛 테스트에 대한 일반적인 이야기는 TestDrivenDevelopment 와 UnitTest 를 참조하라. 테스트 프레임워크로는 ?JUnit이 대표적이며 많은 언어들에 ?JUnit 클론이 있다. 실제 테스트에서는 이를 Mock Object들과 연동해서 사용하게 된다. Mock Object는 많은 구현체들이 있지만 가장 좋은 것은 자신이 직접 구현해서 사용하는 것이다. Mock Object의 구현은 대체로 쉽고 간단하며, 또한 쉽고 간단해야한다. Mock Object의 복잡도가 커지고 있다면 디자인을 재검토해보는 것이 좋다. 다음은 테스트를 사용에 관한 기술적인 조언들이다.

• 테스트 소스와 실제 소스는 분리해서 관리하는 것이 좋다. 이를테면, 실제 소스는 src/java에, 테스트 소스는 src/test에 담는 것과 같은 식이다.
• 테스트 케이스의 이름은 뒤에 Test를 붙이는 것을 기본으로 지원하는 도구들이 많다. 이클립스, Maven이 그렇다.
• 실행 환경에는 테스트를 위한 클래스들과 자원들이 포함될 필요가 없다. 분리해도 동작할 수 있도록 구조화해야한다.
  

또 하나 중요한 것은 주기적으로 유닛 테스트를 실행시키고 결과를 수집해서 알려주는 환경을 구축하는 것이다. 이것은 개발자가 매일매일 소프트웨어의 품질이 어떻게 변해가는지, 버그가 발생하고 있는지 아닌지를 추적할 수 있게 해준다. 적절한 스케쥴러와 Ant, Maven 등의 자동화 도구, 메일 등을 연동하여 구축하라. 아직 이런 부분에서 범용적인 요구사항을 만족시킬 수 있는 도구는 많지 않으므로 직접 구축해보는 것도 좋다.

3.2.3 Stress Test #

스 트레스 테스트는 주로 서버 사이드 애플리케이션에서 중요하다. 스트레스 테스트에서 측정해야하는 것은 보통 두 가지이다. 얼마나 많은 Concurrent Request를 견뎌낼 수 있는가(웹에서는 보통 Concurrent User라고 한다.), 그리고 각각의 애플리케이션이 얼마나 빠른 속도로 실행되는가(Throughput)이다. 이 둘은 모두 스트레스 테스트 도구에서 테스트 환경을 조절해가면서 측정할 수 있다.

3.3 통합 개발 환경 (IDE) #

IDE는 개발 도구 중에서도 프로그래머의 생산성에 가장 큰 영향을 미치는 부분이다. IDE가 기본적으로 다음과 같은 기능들을 갖추고 있어야한다.

• 빌드 및 실행의 자동화
• 문법 검사 목록 뷰
• 비주얼한 디버깅
  • 소스를 보면서 한 줄씩 실행하기
  • 변수값 보기, Watch, 실시간 표현식 평가 기능
  • 메쏘드(함수) 호출 구조 (ex:자바의 Stack trace)
• 코드 에디팅시 컨텐트 어시스트 지원, 문법 하이라이팅 지원
• 프로젝트 관리
• SCM과의 비주얼한 연동
• API 문서의 자동 연동

3.4 지속적인 통합 #

ContinuousIntegration 은 소프트웨어 개발에서 소모적인 일을 줄이는데 가장 중요한 것이다.이 부분이 개발환경 구축에서 기술적으로 가장 많은 노력이 들어가고 가장 어려운 부분이다. 먼저 통합에 필요한 작업들을 정의하고 각각의 작업들을 One-stop으로 실행하고 가능한한 비주얼하게 결과를 볼 수 있도록 구성하라. 필요한 작업들은 대략적으로 다음과 같다.

• build 컴파일 및 리소스 복사 및 변환 작업. IDE와 잘 조화되어야 하며, 어떤 버전이든지 연관 모듈들과 항상 통합 빌드할 수 있어야한다.
• test 테스트를 쉽게 작성하고 실행시킬 수 있어야한다. 이는 주로 개발에서의 TDD와 배포 시의 검증을 위한 것이다.
• test-report 테스트와는 별개의 테스트 리포트가 필요하다. 하루하루 개발의 진척 상황, 소스의 상태를 모니터링하기 위한 것이다.
• xdoc javadoc, source xref 등의 각종 문서를 만드는 작업이다.
• dist 배포판을 만드는 작업. build + test + xdoc이다.
• deploy 서버 사이드 애플리케이션의 경우 서버에 직접 배치하는 것을 자동화하는 과정이 필요하다.
• analysis 여러 가지 코드의 품질과 상태를 검사하고 리포트를 생성하는 도구. checkstyle, jdepend 등이 그 예다.
• changelog CVS의 changelog, product의 changes 관리 등을 자동화할 수 있는 도구가 있으면 편리하다.
• schedule 각종 리포트, nightly build & test 등을 위한 스케쥴러가 필요하다.

Ant와 Maven은 이런 작업을 도와주기 위한 툴이다. Ant는 당초 build & dist 정도의 목적을 달성하기 위해 출발했으나 현재는 상당히 넓은 범위로 확장되고 있고 Maven은 Ant를 한 단계 발전시켜 project management and project comprehension tool을 지향하고 있다. 그리고 오래전부터 사용된 Make가 있다.

개인적으로 이들 중 어떤 것도 만족스럽지 않다. Ant는 지나치게 definitive하게 문제를 해결하려 한다. 프로젝트가 복잡해지고 연관 프로젝트가 늘어갈수록 procedural한 코드가 필수적인데 Ant 자체에서는 이런 스크립트를 지원하지 않는다. 또한 dependency 문제를 개발자가 해결해야하며, Ant 스크립트 자체는 human readable과는 거리가 있으며 문법의 제한으로 리팩토링하기도 어렵다. 빌드 스크립트는 한 번 만들면 계속 쓰는 게 아닌가 생각하기 쉽지만 결코 그렇지 않다. 상황은 계속 바뀔 수 있으며 프로젝트의 어떤 부분이라도 쉽게 바꿀 수 있는 체제를 갖추는 것이 좋다.

Maven은 조금 낫다. Ant보다 더 definitive하면서 더 procedural한 코드를 작성할 수 있다. 작성해야하는 스크립트는 더 적으면서 유연성은 더 높다는 뜻이다. Maven의 리포팅 기능은 대단히 훌륭하다. 그러나, 이것보다 Maven이 가져온 가장 큰 변화는 dependency의 자동화된 관리이다. 단순한 설정만으로 dependency 문제를 상당히 깔끔히 해결할 수 있다. 이것은 데비안의 dselect가 rpm에 대해 갖는 장점과도 비슷하며, 젠투의 emerge가 dependency 관리를 통해 make를 효율적으로 사용하는 것과도 비슷하다. 그러나, 아직은 dependency가 jar에 중점을 두고 설계되어 다른 종류의 dependency에는 문제가 생길 수 있다. Maven은 Ant보다 유연성이 좋다. Maven의 메인 스크립트 언어인 Jelly는 XML 기반이지만 상당히 강력한 스크립트 기능을 가지고 있고 빌드 작업간의 의존성도 쉽게 걸 수 있기 때문에 어느 정도의 리팩토링도 가능하다. 그러나, 여전히 진짜 언어보다는 불편하며 이 점은 단순한 몇 가지 태스크를 추가할 때도 단점이 될 수 있다. 어차피 빌드 스크립트는 개발자가 개발하고 읽는다는 점을 감안하면 프로그래밍 언어가 사용되지 않을 이유는 별로 없다. Maven 역시 한 단계 더 도약이 필요하다. 또, Maven 역시 스케쥴러를 포함하고 있진 않기 때문에 이런 부분은 다른 소프트웨어를 사용하거나 직접 제작해야한다.