조엘 온 소프트 웨어 리뷰 첫번째(아담)
ada...@nate.com
저는 앞으로 매주에 그룹스에 제가 읽은 조엘 온 소프트웨어의 리뷰를 올려 놓을 생각입니다.
혼자 읽고 "땡" 처리해도 되지만 제가 스터디에 도움된적이 한번도 없기 때문에 이렇게 나마 글을 올려
구글 그룹스도 활성화(?)도 시키고 스터디 하는데에도 미력하나마 도움이 되고자 합니다.^^
리뷰는 짧으면 한달 오래걸려도 두달 정도로 생각하고 있습니다. 뭐 전체 내용을 다 할건 아니고 제가
판단하기에 중요하다 싶은것만 할 생각입니다. ㅋ
그리고 비록 제가 글은 잘 못 쓰지만 그게 뭐 제 문제만은 아니고 공대생 전체(?) 가 그러니 그려려니 하고 봐주시면
좋겠습니다. ㅎㅎ 그냥 뭐 그렇다고요...ㅋ
그리고 이책을 빌려주신 채님 책을 빌려주셔서 항상 감사하게 생각하고 있습니다. 다만 너무 재촉은 말아주세요
책이 어려워요...ㅠㅠ 이거때문에 따로 산책도 못읽고 있어요오오오...ㅋㅋ
다시한번 말하지만 제발 문맥이 아니라 내용을 봐주시고요 댓글 달아 주시면 감사하겠습니다.^^
뭐 무플이어도 상처받는 영혼이 아니니 괞찮습니다. ㅎㅎ
리뷰를 시작하기에 앞서....
비록 이책은 우리나라에 2005년도에 출판한 책이지만 조엘 온 소프트웨어는 지금 봐도 무리가 없을 것
같다는 생각이 듭니다. 왜냐... 그이유는 어느 특정한 기술에 얽매이지 않고 보편적으로 문제를 겪었던
선배 프로그래머들의 시행착오들을 정리해서 뒤를 따르는 후배 프로그래머들이 더 좋은 프로그래밍을 할
수 있게끔 도와주는 일종의 지침서나 참고서 역활을 한다고 생각되기 때문입니다. 물론 여기에 있는 모든
내용이 다 정답은 아니겠지요^^ 하지만 앞으로 겪게될 많은 문제들에 대해 미리 생각해보고 앞선이들의
대처방안을 떠올려본다는 것 만으로도 이 책의 역활은 충분할 듯 합니다.
첫번째 리뷰로는
조엘 테스트 : 더 나은 코드를 위한 12단계
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한방에 빌드를 하고 만들어 낼 수 있습니까?
3. 일일 빌드를 하고 있습니까?
4. 버그 추적 시스템을 운영하고 있습니까?
5. 코드를 새로 작성하기 전에 버그를 수정합니까?
6. 일정을 업데이트 하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업 환경에서 일하고 있습니까?
9. 경제적인 범위내에서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?
입니다.
책에 나온 조엘 테스트로 모두 12점 만점이며 각 질문은 "예","아니오" 로 점수를 매기면 되기때문에
테스트 시간 자체도 오래걸리지 않습니다. 간단하지만 그래도 빠르게 자신의 환경을 점검할 수 있다는 점에서
좋은 테스트 같습니다.
이시기의 대부분의 소프트웨어 회사들은(미국기준 울나라 아님) 2점이나 3점수준(MS는 만점)이었다고 합니다.
이 리뷰를 보시는 분들도 12개의 테스트의 문항을 보시고 자신의 환경을 채점해보시는 것도 좋은 방법일것 같네요
첫 문항, 소스 코드 관리시스템을 사용하고 있습니까?
회사에 들어오기 전까지 저는 소스코드 관리시스템이란게 있느지도 몰랐지만 지금 생각해보면 이것이 얼마나 중요한지
깨닫게 됩니다.(뒷일 생각안하고 소스 깽판쳐도 맘이 놓여요...CVS가 있으니깐...ㅎ)
정말 팀프로젝트에서는 필수적 요소인듯 합니다.
두번째 문항, 한방에 빌드를 만들어 낼 수 있습니까?
현재 저희쪽에서는 크게 적용 되지는 않지만 생각해볼 만한 문제 인 듯 합니다. 위의 질문이 의미하는 바
"최종소스코드 스냅샷에서 출시할 빌드를 만들기 위해 몇 단계를 거쳐야하나요?
모든 코드를 컴파일하고 EXE를 만들고 최종 설치 패키지를 생성하고 CD - ROM 레이아웃이나
웹사이트 다운로드 버젼과 같은 최종 매체를 생성하기까지
또한 여기서 다양한 버젼과 언어지원은 물론이고 #ifdef조합을 사용해서 EXE를 만들어 내기까지"
의 과정을 빌드의 과정으로 볼때 이런 빌드 프로세스가 한방에 끝나지 않을 경우 실수 하기 쉬우며 여러 어이없는
중간 중간 과정의 실수로 시간은 기약없이 멀어진다는 것입니다.
그렇기 때문에 출시 날짜가 가까워 질수록 버그를 수정하고 최종 EXE 파일을 생성하는 사이클을 짧게 유지해야 한다고 합니다.
저자는 인스톨 실드라는 프로그램을 사용한다고 하는데 요즘 IDE 환경이 잘되어있어서 이클립스에서 설치 패키지에 EXE 파일까지
만들었던 기억이 가물가물 하지만 납니다. 그때는 이런 생각까진 못하고 과제때문에 급급히 네 이웃(응?) 을 이용했지만 말입니
다.
ㅎ
어쨋든 요약해보면 필요없는 실수를 줄일 수 있는 환경을 만드는 것도 훌륭한 프로그래머가 되는 과정중 하나인 것 같습니다.^^
세번째 문항, 일일 빌드를 하고 있습니까?
이번 문항도 마찬가지로 저희쪽하고는 크게 적용되지 않을듯 싶은데요 한 개발자가 소스코드를 완성한다음 자신의 컴퓨터에만 컴
파일하고 소스코드 저장소(컴잇?)에 저장을 하지 않을 경우 다른 동료가 진행을 할 수 없거나 진행이 불완전하게 되는경우를
대비 하기위해서 매일 매일 최종본으로 컴파일하여 빌드가 깨지지 않게 하는데 목적이 있다고 합니다.(이런 경우가 흔히들 일어났
다고 하네요)
네번째 문항, 버그 추적시스템을 운영하고 있습니까?
버그추적 시스템에 대해 처음 들어보지만 아마도 자주 발생하는 버그들을 체계적으로 모아 두고 관리하여 나중에 버그가 발생했을
경우 추적하기 쉽게(아마도 어떠한 상황에 어떠한 버그들이 자주 발생하는지 기록해두고 상황상황마다 체크하는 시스템인듯
합니다.)하는것이 아닐까 합니다.
버그 추적 소프트웨어는 단순해야 해야 합니다.(복잡하면 오히려 방해)
아래에 보면 버그 추적에 관한 기사가 있습니다. (전 영문 기사라 gg)
http://www.joelonsoftware.com/articles/fog0000000029.html
관심있으신 분들은 가서 살펴 보셔도 좋을듯 합니다.^^
다섯 번째 문항, 코드를 새로 작성하기 전에 버그를 수정 합니까?
위의 문항중 코드를 새로 작성하기전에 버그를 수정한다는 말이 정확하게 이해가 되진 않지만 책의 내용을 읽어본바...
버그를 언제 수정할지의 문제를 다루는 것 같습니다.
개발자가 코드 작성시점에 버그를 발견했다면 모든 코드가 머리속에 남아 있기때문에 바로 수정이 가능할 것입니다.
며칠전에 작성을 끝낸 몇몇 코드에서 발견을 했다면 추적하는 과정에서 시간이 다소 걸리지만 다시 읽었을즘 기억을
떠올릴 수 있기 때문에 그다지 오래 걸리지 않아 버그를 발견 할 수 있을 것입니다.
하지만....몇달전에 개발한 코드에서 버그를 찾는다면 수정하기가 매우 힘들어 질것입니다. 출시후에는 더 막대한 비용이
들것이구요...
그리고 버그를 수정하는 시간을 예측하는것 보다 소스코드를 새로 작성하는것이 시간을 예측하는데 더 쉽다는 것입니다.
왜냐...그 이유는 바로 버그의 수정을 예측하는 것은 버그의 원인을 찾는데 얼마나 걸릴지 모르기 때문입니다.
이로 인해 버그는 시간과 비용 개발자들의 심력을 엄청나게 소모하게 하는 주된 원인이기 때문에 버그를 찾아 바로 수정하는
것이 얼마만큼 중요한 일인지 깨닫게 되었습니다.
여섯번째 문항 일정을, 업데이트하고 있습니까?
프로그래머는 일정수립에 서툴기로 악명이 높으며(책에 의하면) 불행히도 이것은 매우 중요한 문제라는 것입니다.
(회사의 입장에서 보면, 또는 윗분들한테 쪼이기 싫으면)
일정에 관해서는 다다음주 정도에 따로 리뷰를 하겠습니다.(책에 나온 파트내에서...ㅎ)
일곱번째 문항, 명세서를 작성하고 있습니까?
명세서는 모든 프로그래머가 중요하다고 생각하지만 모두가 꺼려하는 작업이라고 합니다.(아마도 문서작업때문에) 하지만
명세서를 제대로 작성하지 않는다면 제대로된 프로그램(고객이 원하는 프로그램)이 만들어질 가능성은 아마도 희박하겠지요..
이것도 다음주에 명세서파트로 따로 빼서 리뷰를 하겠습니다. ㅎ
여덟번째 문항, 조용한 환경에서 일하고 있습니까?
특히나 지식노동자들에게는 조용한 작업공간은 "필수"라고 합니다. 지식노동자는 이른바 "무아지경"이라는 흐름에 빠져야 위대한
창조물들을 또는 새로운 지식들을 발견한다고 합니다.(아인슈타인도 그랬고 에디슨도 그랬고 우리 뒷집아저씨도 그랬습니다.)
하지만 현재 우리의 상황은 그렇지 못하죠 슬픈 현실입니다. ㅠㅠ
보통 무아지경까지 걸리는데 시간은 15분이라고 하는데요 한번 빠져 나오면 다시 집중하기가 쉽지 않다고 합니다.(이문제에 관한
책
을 여러권 봐서 프로그래머의 문제만이 아니라고 생각되네요.)
아홉번째 문항, 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까?
보통 회사에서 지원해줄수 있는 자원 즉 최상급 까지는 아니더라도 현재 사용하고 있는 많은 도구(하드웨어든 소프트웨어든)들을
평균이상으로 유지하여 프로그래머들의 의욕을 꺽지 않게 하는것이 중요합니다.
열번째 문항 , 테스터를 별도로 두고 있습니까?
전문 테스터가없으면 오히려 나중에 비용이 더 드는 문제가 발생한다고 합니다. 이에 관에서는 나중에 다시 리뷰를 하겠습니다.
열 한번째 문항, 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
관리자한테 중요한 질문이네요
열 두번째 문항, 무작위 사용편의성 테스트를 수행합니까?
지나 가는 사람 5~6명 붙잡아 막 작성한 코드를 테스트 하게끔 하는 기법입니다. 그럼 코드에 존재하는 사용편의성 문제를
95%로 까지 찾아낸다고 합니다.
여기 까지가 조엘 테스트 : 더 나은 코드를 위한 12단계 리뷰 입니다.
끝까지 읽어주셔서 감사하고요 그냥 스크롤 내려주신분들도 감사합니다.^^
다음주에는 아마도 "명세서 작성법"에 대해 리뷰를 할듯 합니다.
다음 리뷰도 많이들 봐주세요~~
채강
다음 글에 이번장의 리뷰가 있는건가??
> 아래에 보면 버그 추적에 관한 기사가 있습니다. (전 영문 기사라 gg)http://www.joelonsoftware.com/articles/fog0000000029.html