나의 조엘 테스트
Software2005. 8. 10. 23:40
조엘 on 소프트웨어라는 책을 보면 조엘 테스트가 나옵니다. 예전에 한번 보기도 했는데, 괜찮은 테스트이므로 한번 여러분의 소프트웨어 개발 환경에 대해 점검해 보기 바랍니다.
1. 소스코드 관리 시스템을 사용합니까?
cvs, MS visual source safe, rational clear case와 같은 형상관리 툴이 있습니다.
저는 위 3가지 툴을 모두 써봤습니다.
source safe -> cvs -> clear case
source safe는 5년전에 쓰던거라 현재 버전에 대해 뭐라 평가하기는 힘들고 한사람이 소스 파일을 check-out하면 다른 사람은 코들를 수정할 수가 없었습니다. 퇴근하기전 check-in은 필수였습니다. VC++이나 VB에서 기본 제공하므로 가장 쓰기 편했습니다.
cvs는 오픈소스프로젝트에서 사용하고 있는 형상관리툴입니다. 모든 플랫폼에서 안정적으로 동작하면 특히 merge기능은 상용툴인 clear case보다 좋은 것 같습니다. 한번도 실망시킨적이 없습니다.
전반적으로는 상용 제품인 clear case가 좋긴 좋더군요. 물론 서버를 관리해주는 사람이 따로 있다고 가정할 때 말이죠. 특히 소스코드를 서로 다른 프로젝트로 이동하거나 다양한 버전을 유지할 때 그리고 폴더, 파일 이름 변경이 쉬워서 좋았습니다. cvs에서도 서버 접근만 되면 가능하면 쉽게 할 수 있긴하죠.
2. 한방에 빌드를 만들어낼 수 있습니까?
한번 빌드에 다양한 버전에 소프트웨어를 컴파일까지 하고 설치버전까지는 만드는 것입니다. 사실 이 부분은 아직까지 시도해보지 못했습니다. 여러 라이브러리를 쓰면, 라이브러리 따로 컴파일하고 실행파일도 따로 컴파일하고 dll도 따로 빌드하고 이 결과를 가지고 설치 프로그램을 만드는 것은 다소 복잡한 일이기도 하지요. 게다가 버전이 여러가지 유지한다면 분명 실수할 수도 있습니다.
3. 일일 빌드를 하고 있습니까?
일일 빌드라고 말할 수 없지만 수시로 전체 프로젝트를 업데이트해서 각자 빌드는 하고 있습니다. 문제는 실제 타겟용으로 자주 빌드를 해야 하는데, 그렇지 못해서 컴파일이 안되곤 합니다. 임베디드 환경에서는 PC에서 작업을 하고 타겟용으로 다시 컴파일을 하는데, 이때 문제가 자주 발생합니다. PC에서 잘 동작한다고 너무 자신만만해서는 안됩니다. 이것은 꼭 임베디드에 해당하는 것은 아니고 여러 플랫폼을 지원하면 자주 접할 수 있는 문제입니다.
4. 버그 추적 시스템을 운영하고 있습니까?
지금 회사에서도 훌륭하게 운영하고 있었지만 전에는 wiki를 이용하기도 했고 zero board에서 운영한적도 있습니다. 잘만 쓰면 모두 훌륭합니다. 못쓰면 아무리 좋은 툴도 소용이 없습니다.
중요한 것은 다음의 항목이 있어야 한다는 군요.
* 버그를 재현하기 위한 완벽한 단계
* 예상 수행 결과
* 실제 수행 결과
* 수정을 맡을 개발자
* 수정했는지 여부
5. 코드를 새로 작성하기전에 버그를 수정합니다.
이건 정말 중요합니다. 그렇지 못하면 소프트웨어의 위기에 빠지고 맙니다.
하지만 내 마음속에만 숨어있는 버그도 있긴합니다. 거의 발생한 일이 없으므로 아무도 못찾으면 그냥 넘어가기도 하지요.
6. 일정을 업데이트하고 있습니까?
조엘이라는 사람은 MS프로젝트에 대해 좋지 않은 평가를 내리고 있습니다. 저도 MS프로젝트를 이용하고 있지만 처음 작성할 때만 보고 그 후에는 거의 쳐다보지 않게 됩니다.
7. 명세서를 작성하고 있습니까?
정말 중요하다는 사실은 알고 있지만 코딩하는 것 보다 더 어렵습니다. 파워포인트로 아이디어를 정리하고 코딩한 후에 정식으로 문서화를 하고 있습니다.
8. 조용한 작업 환경에서 일하고 있습니까?
한 사무실에 몇십명씩 앉아서 일하는 환경이라면 조용하기가 참 힘들죠. 그 때는 해드폰으로 귀를 막고 모니터에 폭 빠져 일하는 것이 좋습니다. 2-3곡을 무한 반복으로 들으면서 일하면 집중이 잘~ 됩니다.
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
만약 관리부서 사람들이 제일 먼저 업그레이드 한다면? 그 회사는 머지 않아 망합니다.
다지이너가 제일 먼저 업그레이드를 한다면? 프로그램이 화면발은 죽이지만 버그는 엄청날 수도 있습니다...
개발자에게 LCD 모니터를 사주세요. 정말 일 잘할겁니다.
회사에서 집보다 좋은 환경을 쓰면 그만이겠죠?
10. 테스터를 별도로 두고 있습니까?
출시일이 다가오면 사장님빼고 모두 테스터가 된적도 있습니다. 지금 회사와서 놀란 것은 테스트를 전담해주는 팀이 있다는 사실입니다. 역시 큰회사라 다르군요. 전에 웹브라우저 만들 때, 정말 테스트는 힘든 작업이였습니다. 자동화하기도 힘든 부분이라 일일히 주요 웹페이지를 돌아다니면서 테스트를 했습니다. 개발자가 테스트하면 웬진 비용이 덜 드는 것 같지만 사실 엄청난 비용을 들이는 것입니다.
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
저도 이런 테스트를 받아본 적도 해본적도 없습니다. 프로그램 결과물과 소스코드를 제출한 적은 있습니다. 사실 이런 테스트를 받으면 잘 할 수 있을지 고민이 되기 합니다.
12. 무작위 사용 편의성 테스트(hallway usabiliy test)를 수행하고 있습니까?
해당 소프트웨어에 대해 문외한인 사람에게 테스트를 맡기는 것이라고 하네요. 영업부나 관리부 직원이면 적당할 것 같습니다.
1. 소스코드 관리 시스템을 사용합니까?
cvs, MS visual source safe, rational clear case와 같은 형상관리 툴이 있습니다.
저는 위 3가지 툴을 모두 써봤습니다.
source safe -> cvs -> clear case
source safe는 5년전에 쓰던거라 현재 버전에 대해 뭐라 평가하기는 힘들고 한사람이 소스 파일을 check-out하면 다른 사람은 코들를 수정할 수가 없었습니다. 퇴근하기전 check-in은 필수였습니다. VC++이나 VB에서 기본 제공하므로 가장 쓰기 편했습니다.
cvs는 오픈소스프로젝트에서 사용하고 있는 형상관리툴입니다. 모든 플랫폼에서 안정적으로 동작하면 특히 merge기능은 상용툴인 clear case보다 좋은 것 같습니다. 한번도 실망시킨적이 없습니다.
전반적으로는 상용 제품인 clear case가 좋긴 좋더군요. 물론 서버를 관리해주는 사람이 따로 있다고 가정할 때 말이죠. 특히 소스코드를 서로 다른 프로젝트로 이동하거나 다양한 버전을 유지할 때 그리고 폴더, 파일 이름 변경이 쉬워서 좋았습니다. cvs에서도 서버 접근만 되면 가능하면 쉽게 할 수 있긴하죠.
2. 한방에 빌드를 만들어낼 수 있습니까?
한번 빌드에 다양한 버전에 소프트웨어를 컴파일까지 하고 설치버전까지는 만드는 것입니다. 사실 이 부분은 아직까지 시도해보지 못했습니다. 여러 라이브러리를 쓰면, 라이브러리 따로 컴파일하고 실행파일도 따로 컴파일하고 dll도 따로 빌드하고 이 결과를 가지고 설치 프로그램을 만드는 것은 다소 복잡한 일이기도 하지요. 게다가 버전이 여러가지 유지한다면 분명 실수할 수도 있습니다.
3. 일일 빌드를 하고 있습니까?
일일 빌드라고 말할 수 없지만 수시로 전체 프로젝트를 업데이트해서 각자 빌드는 하고 있습니다. 문제는 실제 타겟용으로 자주 빌드를 해야 하는데, 그렇지 못해서 컴파일이 안되곤 합니다. 임베디드 환경에서는 PC에서 작업을 하고 타겟용으로 다시 컴파일을 하는데, 이때 문제가 자주 발생합니다. PC에서 잘 동작한다고 너무 자신만만해서는 안됩니다. 이것은 꼭 임베디드에 해당하는 것은 아니고 여러 플랫폼을 지원하면 자주 접할 수 있는 문제입니다.
4. 버그 추적 시스템을 운영하고 있습니까?
지금 회사에서도 훌륭하게 운영하고 있었지만 전에는 wiki를 이용하기도 했고 zero board에서 운영한적도 있습니다. 잘만 쓰면 모두 훌륭합니다. 못쓰면 아무리 좋은 툴도 소용이 없습니다.
중요한 것은 다음의 항목이 있어야 한다는 군요.
* 버그를 재현하기 위한 완벽한 단계
* 예상 수행 결과
* 실제 수행 결과
* 수정을 맡을 개발자
* 수정했는지 여부
5. 코드를 새로 작성하기전에 버그를 수정합니다.
이건 정말 중요합니다. 그렇지 못하면 소프트웨어의 위기에 빠지고 맙니다.
하지만 내 마음속에만 숨어있는 버그도 있긴합니다. 거의 발생한 일이 없으므로 아무도 못찾으면 그냥 넘어가기도 하지요.
6. 일정을 업데이트하고 있습니까?
조엘이라는 사람은 MS프로젝트에 대해 좋지 않은 평가를 내리고 있습니다. 저도 MS프로젝트를 이용하고 있지만 처음 작성할 때만 보고 그 후에는 거의 쳐다보지 않게 됩니다.
7. 명세서를 작성하고 있습니까?
정말 중요하다는 사실은 알고 있지만 코딩하는 것 보다 더 어렵습니다. 파워포인트로 아이디어를 정리하고 코딩한 후에 정식으로 문서화를 하고 있습니다.
8. 조용한 작업 환경에서 일하고 있습니까?
한 사무실에 몇십명씩 앉아서 일하는 환경이라면 조용하기가 참 힘들죠. 그 때는 해드폰으로 귀를 막고 모니터에 폭 빠져 일하는 것이 좋습니다. 2-3곡을 무한 반복으로 들으면서 일하면 집중이 잘~ 됩니다.
9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
만약 관리부서 사람들이 제일 먼저 업그레이드 한다면? 그 회사는 머지 않아 망합니다.
다지이너가 제일 먼저 업그레이드를 한다면? 프로그램이 화면발은 죽이지만 버그는 엄청날 수도 있습니다...
개발자에게 LCD 모니터를 사주세요. 정말 일 잘할겁니다.
회사에서 집보다 좋은 환경을 쓰면 그만이겠죠?
10. 테스터를 별도로 두고 있습니까?
출시일이 다가오면 사장님빼고 모두 테스터가 된적도 있습니다. 지금 회사와서 놀란 것은 테스트를 전담해주는 팀이 있다는 사실입니다. 역시 큰회사라 다르군요. 전에 웹브라우저 만들 때, 정말 테스트는 힘든 작업이였습니다. 자동화하기도 힘든 부분이라 일일히 주요 웹페이지를 돌아다니면서 테스트를 했습니다. 개발자가 테스트하면 웬진 비용이 덜 드는 것 같지만 사실 엄청난 비용을 들이는 것입니다.
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
저도 이런 테스트를 받아본 적도 해본적도 없습니다. 프로그램 결과물과 소스코드를 제출한 적은 있습니다. 사실 이런 테스트를 받으면 잘 할 수 있을지 고민이 되기 합니다.
12. 무작위 사용 편의성 테스트(hallway usabiliy test)를 수행하고 있습니까?
해당 소프트웨어에 대해 문외한인 사람에게 테스트를 맡기는 것이라고 하네요. 영업부나 관리부 직원이면 적당할 것 같습니다.
'Software' 카테고리의 다른 글
[Professional 소프트웨어 개발] 변하지 않는 핵심 잡기 (0) | 2005.12.19 |
---|---|
[Professional 소프트웨어 개발] 소프트웨어의 특성 (0) | 2005.12.13 |
일 잘하는 법, 마이크로소프트에서 배운다 (1) | 2005.09.13 |
프로그램 테스트 (0) | 2005.02.22 |
하버드 아키텍쳐와 폰 노이만 아키텍쳐 (0) | 2004.12.26 |
댓글()